Подбирайте размер под приложение, которое вы действительно запускаете.

Перед измерением

Используйте тестовую машину Linux, которой вы управляете, со своим приложением и репрезентативными данными. Команды ниже исследуют ресурсы; они не настраивают ядро и не удаляют файлы. Вам нужны procps и GNU coreutils, а также разрешение на просмотр выбранного каталога приложения. Замените /srv/my-app на его реальный путь. Если приложение ещё нигде не запущено, используйте его среду разработки или staging, чтобы построить первоначальную оценку, а затем пересмотрите эту оценку на предполагаемой системе.

Запишите, что делит VPS: операционная система, прокси, API, база данных, воркеры и мониторинг. Отметьте, выполняются ли там сборки ассетов, сжимаются ли резервные копии локально и может ли запланированная задача пересечься с развёртыванием. Тихий процесс приложения может сосуществовать с затратным процессом выпуска.

Прочитайте доступную память и определите процессы

free -m
ps -eo pid,comm,rss --sort=-rss | head -n 12

free -m показывает мебибайты. Сосредоточьтесь на available, оценке памяти, которая могла бы поддерживать новую работу без swap; free само по себе исключает полезную освобождаемую память. Поэтому кэш сам по себе не является причиной покупать больше RAM. См. определения полей free.

Illustrative selected fields — not an OffVPS measurement
Mem total: 2048 MiB
Mem free:   180 MiB
Mem available: 800 MiB

Illustrative ps rows
  PID COMMAND     RSS
 2100 postgres 393216
 2140 node     184320
  920 caddy     32768

Значения RSS процессов выше примерно соответствуют 384, 180 и 32 MiB. Они помогают найти использование памяти, но суммирование всех значений RSS не даёт точного итога по машине: общие страницы могут учитываться более одного раза, а часть затрат ядра находится вне показателя процесса. Избегайте вывода аргументов команд или окружений при сборе отчёта, так как они могут содержать секреты. руководство ps объясняет его поля и поведение снимков.

Преобразуйте наблюдения в рабочую таблицу

Следующие допуски иллюстрируют небольшой API с локальной базой данных и одним воркером. Это выдуманные плановые значения, а не бенчмарки или минимальные требования для конкретного фреймворка. Подставьте свои измерения и отметьте, какие допуски могут достигать пика одновременно.

Эта рабочая таблица уже превышает бюджет 1,024 MiB. Тестовая среда 2,048 MiB оставила бы 676 MiB против этих допусков, но полезный результат — укладывается ли реальная репрезентативная работа, пока приложение остаётся отзывчивым. Если допуск на развёртывание доминирует, сборка артефактов в другом месте может оказаться лучшим изменением, чем увеличение постоянного сервера. Сохраняйте предположения рядом с итогом.

Следите за CPU и swap во время полезной работы

vmstat 1 10

Запустите это во время репрезентативной серии запросов, задания и выпуска. При интерпретации недавнего интервала игнорируйте первую строку: она суммирует активность с момента загрузки. Последующие строки описывают интервалы выборки. Устойчивая готовая к выполнению работа в r, низкое время простоя в id и медленные запросы вместе оправдывают исследование нагрузки на CPU. Повторяющаяся si/so активность показывает swap; один лишь выделенный swap не доказывает текущее давление. wa и st нуждаются в контексте, а не в автоматическом апгрейде CPU. Эти поля определены в vmstat.

Также фиксируйте время ответа на уровне приложения. Медленный внешний API или запрос к базе данных может заставлять запросы ждать, пока CPU остаётся в основном простаивающим. Повторите ту же нагрузку после одного изменения, чтобы знать, какое изменение помогло. Нагрузочные тесты должны нацеливаться только на системы, которыми вы управляете, с частотой и условием остановки, которые не нарушают работу других пользователей.

Отдельно планируйте рост диска и трафик

df -h /srv/my-app
df -i /srv/my-app
du -sh /srv/my-app

df описывает файловую систему, содержащую путь, включая пространство, общее с другими каталогами; df -i проверяет использование inode там, где это поддерживается. Большое количество мелких файлов может исчерпать inode раньше, чем байтовую ёмкость. du оценивает выбранное дерево с учётом прав доступа. Это разные вопросы, поэтому их итоги не обязаны совпадать. См. df и du.

Перечислите текущую базу данных, загрузки, логи, артефакты приложения и любое локальное промежуточное пространство для резервных копий. Добавьте пространство, необходимое для выпуска рядом с предыдущим выпуском, затем оцените рост на следующий интервал проверки. Например, 100 MiB новых загрузок каждый день добавляют около 3,000 MiB за 30 дней до реплик или резервных копий. Обозначайте десятичные GB и двоичные GiB согласованно при сравнении результата с каталогом.

Для трафика: иллюстративный ответ 20 kB, отправленный 50,000 раз, составляет около 1 GB полезной нагрузки ответа. Добавьте загрузки, статические файлы, накладные расходы протокола и трафик резервного копирования. Эта арифметика оценивает объём, а не пропускную способность или одновременных пользователей. Уточните, как служба считает трафик и обрабатывает превышение.

Выберите следующее действие и проверьте его

• Низкая доступная память во время обычных пиков: проверьте основных потребителей и протестируйте больший бюджет памяти.
• Медленные запросы при устойчивой нагрузке на CPU: профилируйте занятый путь, затем сравните изменения CPU на той же нагрузке.
• Растущее использование диска: определите ответственный каталог и политику хранения, прежде чем что-либо удалять.
• Ресурсы выглядят достаточными, но приложение работает медленно: исследуйте зависимости, запросы и путь запроса.

Сохраните рабочую таблицу с описанием нагрузки, временем выборки, единицами измерения и датой следующей проверки. Перепроверьте после существенного выпуска, роста данных или добавленного воркера. Выберите конфигурацию на основе этих наблюдений; никакое название плана не гарантирует ёмкость запросов. Продолжите с чтения предупреждений о памяти и диске или первым сценарием ресурса API.