Розраховуйте розмір для застосунку, який ви справді запускаєте.

Перед вимірюванням

Використовуйте тестову машину Linux, яку контролюєте, з вашим застосунком і репрезентативними даними. Наведені нижче команди перевіряють ресурси; вони не налаштовують ядро і не видаляють файли. Потрібні procps і GNU coreutils, а також дозвіл на перевірку вибраного каталогу застосунку. Замініть /srv/my-app на його реальний шлях. Якщо застосунок ще ніде не запущено, використайте його середовище розробки або стейджингу, щоб побудувати початкову оцінку, а потім перегляньте цю оцінку на цільовій системі.

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

Прочитайте доступну пам’ять і визначте процеси

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

free -m показує мебібайти. Зосередьтеся на available, оцінці пам’яті, яка могла б підтримувати нову роботу без свопінгу; 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 не доводить поточний тиск. 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.