VMSTAT : Изменение статистических данных при росте нагрузки на CPU

Разница в показаниях позволяет получить очень много важной информации

Вопрос

Как используя утилиту vmstat можно сравнить производительность сервера СУБД при двух разных сценариях тестовой нагрузки ? Первый сценарий комбинированной нагрузки для тестовой базы созданной pgbench : select only (50% нагрузки), select+update(30%) , insert only (15%) . Во втором сценарии добавляется повышенная вычислительная нагрузка на CPU (5%). Какие характерные значения vmstat будут во втором сценарии ?

Ответ

Анализ и характерные значения во втором сценарии

Второй сценарий добавляет 5% генеративной CPU-нагрузки. Это напрямую отразится на метриках процессора и косвенно — на других подсистемах.

Вот на какие колонки вывода vmstat нужно смотреть в первую очередь и какие изменения в них произойдут:

1. Процессор (us, sy, id, wa)

Это наиболее важные метрики для вашего вопроса.

• us (user time): Время, затраченное на выполнение пользовательского кода (код СУБД Postgres, ваши SQL-запросы).
• В первом сценарии: Высокое значение, так как основная нагрузка — это работа приложения (СУБД).
• Во втором сценарии: Останется высоким или незначительно уменьшится. 5% дополнительной CPU-нагрузки "откусят" долю от общего CPU времени. Так как эта нагрузка чисто вычислительная, она тоже будет учитываться здесь. Общее us может даже немного вырасти.
• sy (system time): Время, затраченное ядром ОС на обработку системных вызовов (управление памятью, планировщик задач, обработка сетевых пакетов и операций I/O).
• В первом сценарии: Умеренное значение, зависящее от интенсивности операций ввода-вывода и сетевой активности.
• Во втором сценарии: Скорее всего, останется примерно таким же, если только дополнительная нагрузка не генерирует много новых системных вызовов (маловероятно для чистых вычислений).
• id (idle time): Время простоя процессора.
• В первом сценарии: Низкое значение, так как сервер под нагрузкой.
• Во втором сценарии: Уменьшится примерно на те самые 5%, которые забрала новая нагрузка. Это очень явный признак.
• wa (I/O wait time): Время, которое CPU простаивает в ожидании завершения операций ввода-вывода (диск, сеть).
• В первом сценарии: Может быть заметным, особенно во время операций UPDATE и INSERT, которые пишут на диск (WAL, dirty pages).
• Во втором сценарии: Вполне может незначительно увеличиться. Когда CPU становится более загруженным, у подсистемы I/O меньше квантов времени для своевременной обработки запросов, что может привести к росту очередей и, как следствие, к увеличению времени ожидания. Это пример косвенного влияния.

2. Память (swpd, free, buff, cache, si, so)

• swpd (used swap space): Количество используемой swap-памяти.
• Во втором сценарии: Дополнительная нагрузка потребляет больше памяти. Если физическая память (RAM) была на грани исчерпания, возможно начало использования swap (swpd > 0) или его рост.
• free (free memory): Свободная оперативная память.
• Во втором сценарии: Скорее всего, уменьшится, так как и СУБД, и новая нагрузка используют память.
• si (swap in) / so (swap out):
• Во втором сценарии: Если память исчерпана, эти значения станут больше нуля, что является очень тревожным признаком резкого падения производительности.

3. Процессы (r, b)

• r (runable processes): Процессы, готовые к выполнению и ожидающие своей очереди на CPU.
• В первом сценарии: Обычно стабильное невысокое значение.
• Во втором сценарии: Значение вырастет. Это ключевой признак! Когда все CPU заняты, задачи начинают скапливаться в очереди. Рост r при высокой загрузке CPU (us+sy > 90%) — явный показатель нехватки вычислительных ресурсов.
• b (processes in uninterruptible sleep): Процессы, заблокированные ожиданием I/O (чаще всего диска).
• Изменения будут зависеть от дисковой подсистемы. Может немного вырасти из-за возросшей конкуренции за ресурсы.

Вывод

Характерные значения для второго сценария, на которые нужно обратить внимание:

1. Снижение id: Процессор теперь простаивает меньше.
2. Рост r (очередь на CPU): Это самый яркий индикатор нехватки CPU. Задачи ждут своей очереди на выполнение.
3. (Возможный) рост wa: Из-за большей загрузки CPU обработка I/O может начать запаздывать.
4. (Возможное) снижение free памяти: Дополнительный процесс потребляет память.

Сравнивая логи vmstat по двум сценариям, вы сможете не только констатировать факт изменения производительности (например, падение TPS в pgbench), но и точно определить его причину — в данном случае, исчерпание ресурсов CPU, что проявляется в росте очереди выполняемых процессов (r).