Додайте бюджет одночасної пам'яті
Почніть з процесів, які перекриваються, а не з їхніх середніх показників у стані спокою. Ілюстративний робочий аркуш 4 GB міг би зарезервувати 700 MiB для інструментів хоста, 900 MiB для процесів API, 1,200 MiB для бази даних, 500 MiB для одного воркера та 700 MiB для невизначеності: 4,000 MiB загалом. Це майже вичерпує номінальний профіль і залишає мало впевненості для більшого перекриття релізів.
Оцініть попит на CPU за виміряною роботою
Виміряйте час CPU для одного репрезентативного запиту або завдання, потім помножте на пікову швидкість завершення. Наприклад, 25 мс часу CPU × 20 запитів за секунду = 500 мс CPU щосекунди, або 0.5 ядра в середньому. Повторіть з активним реалістичним воркером і перевірте піки; середні значення приховують сплески, планування та очікування бази даних.
Відокремте сигнали обмежень
| Спостережуваний сигнал | Ймовірна наступна перевірка |
|---|---|
| Високий CPU з роботою, готовою до виконання | Профілюйте гарячий шлях, потім порівняйте більше CPU. |
| Тиск на пам'ять або завершення процесу | Зменште перекриття або додайте виміряну RAM. |
| Низький CPU з повільними запитами | Перевірте базу даних, пул та зовнішні очікування. |
| Вік черги зростає зі збільшенням воркерів | Знизьте паралелізм і перевірте спільну залежність. |
Ухваліть рішення щодо ресурсів
Виберіть більше CPU лише коли профілювання показує стійку конкуренцію за обчислення. Виберіть більше RAM, коли одночасний робочий набір не має резерву. Знизьте паралелізм, коли паралельна робота шкодить затримці API або корисній швидкості завершення. Запишіть вимірювання, що спричинило зміну, потім повторіть те саме навантаження після зміни однієї змінної.