Нагрузка, память и медленные ответы

Оглавление серии

В предыдущем уроке разделили сетевой путь и ответ приложения. Теперь рассмотрим жалобу «заявки открываются медленно». Служба может быть активной, порт — доступным, а ответ — задерживаться. Причиной может оказаться вычисление, ожидание базы, дисковая операция, очередь запросов или ограничение окружения. Один показатель редко различает эти варианты, поэтому будем связывать наблюдения временем и контекстом.

В лаборатории нет заранее созданной нагрузки. Мы не запускаем её генератор и не описываем красивые числа как результат проведённого опыта. Используем команды наблюдения и шаблон evidence/load.md. Для своего стенда читатель запишет значения, время и выбранный процесс. У синтетического fixtures/access.tsv длительности нужны лишь для обсуждения метода, а не для оценки производительности настоящего DeskQueue.

Сначала фиксируем интервал

Жалоба пользователя относится к некоторому периоду. Снимок спокойной системы через час после события может ничего не показать. В краткой записи укажите начало и конец наблюдения, имя машины и выпуск приложения. Это позволяет сопоставить измерение с журналом и отличить изменение программы от изменения условий вокруг неё.

date -Is
uptime
nproc

uptime показывает в том числе среднюю нагрузку за несколько временных окон. nproc помогает узнать число доступных процессоров в текущем контексте. В виртуальной машине и контейнере доступные ресурсы могут отличаться от физического хоста. Сравнение чисел без этого сведения может привести к неправильной оценке: нагрузка 4 означает разные условия для одного и восьми доступных процессоров.

Load average не является процентом занятого CPU. В Linux показатель связан с количеством задач, готовых к выполнению и находящихся в некоторых состояниях ожидания. Поэтому высокий load может сочетаться с не полностью занятым процессором. Если сразу объявить его доказательством тяжёлого JavaScript, можно пропустить ожидание диска или другой ресурс. Нужны дополнительные наблюдения, отвечающие на более узкий вопрос.

Отдельный процесс и вся система

Откройте top и посмотрите общую строку CPU, память и список процессов. Затем найдите PID из состояния службы. В справке top описаны поля и режимы; формат зависит от настроек и версии. Не считайте цвет или положение строки самостоятельной оценкой здоровья приложения.

systemctl show deskqueue.service -p MainPID
ps -eo pid,user,pcpu,pmem,rss,args --sort=-rss

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

Один основной PID тоже не всегда описывает весь сервис. Приложение может создавать дочерние процессы, а рядом могут работать база и обратный прокси. Связь службы с control group помогает понять границы её процессов. Если задержка находится в PostgreSQL, низкий CPU основного Node-процесса вполне ожидаем: он может ждать ответ. Это не повод прекращать исследование только потому, что «процессор свободен».

Занятая память имеет разные задачи

Команда free -h показывает распределение памяти, включая оценку доступной. Кеш файлов является полезным использованием памяти, а не автоматически утечкой. Поэтому небольшое значение полностью свободной памяти не всегда означает, что системе нечем удовлетворить новый запрос. Рассматривайте available и изменение во времени, а не только одну колонку.

free -h
vmstat 1 5

Для vmstat первая строка может описывать усреднение с момента запуска системы, а последующие — выбранные интервалы. Не включайте её механически в сравнение секундного события. В справке vmstat Ubuntu различаются показатели процессов, памяти, обмена и CPU. Здесь важна возможность наблюдать серию значений, а не запомнить все поля сразу.

Наличие занятого swap само по себе не доказывает текущий активный обмен. Старые страницы могли остаться там после предыдущего периода давления. Посмотрите, происходит ли перемещение сейчас, и свяжите его с задержкой приложения. Аналогично большой RSS процесса не показывает автоматически, какая часть памяти может быть общей или почему она выросла. Требуется исследование конкретного приложения и его времени жизни.

Длительность команды имеет границы

time измеряет выполнение команды, но результат зависит от выбранной оболочки и программы. В первом уроке научились проверять происхождение имени; примените этот приём снова. Время одного HTTP-запроса включает условия сети и сервера, а запуск клиента тоже имеет собственные затраты. Поэтому такой опыт не является профилем внутреннего обработчика Node.js.

Для повторения можно выбрать известный локальный адрес и ограничить максимальное ожидание клиента. Запишите, был ли это первый запрос после запуска, выполнялась ли похожая операция раньше и что происходило с базой. Повторный запрос может использовать другой кеш. Сравнение без этих условий легко даёт числа, которые выглядят точными, но плохо объясняют изменение.

Если нужны исторические показатели, средства вроде sar должны собирать данные заранее. Установка инструмента после завершения события не создаст прошлые наблюдения. Даже сохранённая история системы может быть слишком грубой для одного короткого запроса. Поэтому при проектировании сопровождения полезно заранее выбрать интервалы и метрики, связанные с задачей продукта, а не только с наличием удобной команды.

От симптома к следующему вопросу

Представим, что HTTP медленный, CPU Node небольшой, а база сообщает о долгом запросе. Следующий шаг относится к SQL и его плану, а не к увеличению процессорного лимита наугад. Другой случай: процесс постоянно использует CPU и журнал показывает большой цикл обработки. Тогда пригодятся инструменты профилирования приложения. Команды системы помогают выбрать область, но не заменяют её анализ.

В evidence/load.md отделите наблюдение от гипотезы. «Available уменьшилась за пять минут» — наблюдение. «В приложении утечка» — пока гипотеза, если нет дополнительных данных. Такая форма позволяет проверять рассуждение и спокойно пересматривать его. Результат урока — связанный интервал наблюдений и конкретный следующий вопрос. Дальше рассмотрим хранение: свободное место, размеры каталогов и причины расхождения этих показателей.