PG_HAZEL : анализ СУБД и инфраструктуры по результатам нагрузочного тестирования (малая ВМ)

Скромность в потребных ресурсах это похвально

Архивный материал - методика устарела

Задача

Провести комплексный анализ результатов нагрузочного тестирования со стороны метрик производительности СУБД и операционной системы.

Виртуальная машина 06

• CPU = 2
• RAM = 2GB
• Astra Linux 1.7
• PostgreSQL 15

Сценарий тестирования и нагрузка на СУБД

Mix

1. Select only : 50% нагрузки
2. Select + Update : 30% нагрузки
3. Insert only : 15% нагрузки

Нагрузка

Ось X - тестовая итерация. Ось Y - количество сессий pgbench

Операционная скорость

Ось X - точка наблюдения . Ось Y - операционная скорость

Классический график изменения операционной скорости в ходе нагрузочного тестирования:

1. Горизонтальный тренд: производительность не растет
2. Вертикальный тренд: резкий рост производительности
3. Горизонтальный тренд: производительность практически не меняется
4. Нисходящий тренд: производительность снижается с ростом нагрузки

Ожидания СУБД

Ось X - точка наблюдения . Ось Y - ожидания СУБД

Горизонтальный тренд ожидания совпадает с горизонтальным трендом скорости.

Дальнейший рост ожиданий экспоненциально зависит от нагрузки.

Статистические показатели VMSTAT

Абсолютные значения vmstat

корреляция между ожиданиями СУБД и показателями vmstat

Анализ показателей VMSTAT

Дисковая подсистема - cpu_wa ожидание IO

Ось X - точка наблюдения . Ось Y - cpu_wa ожидание IO

Результат: С ростом нагрузки ожидания IO - снижаются до нуля.

Признаки конкуренции за ресурсы CPU

1.Длина очереди исполнения (procs -> r)

Ось X - точка наблюдения . Ось Y - длина очереди исполнения (procs -> r)

Результат: постоянная конкуренция за процессорное время. Длина очереди исполнения существенно превышает количество ядер CPU.

2.Частота переключений контекста (system -> cs)

Ось X - точка наблюдения . Ось Y - Частота переключений контекста (system -> cs)

Результат: После достижения максимальной производительности СУБД, с ростом нагрузки частота переключений контекста - снижается

3. Процент времени, проводимого в ядре (cpu -> sy)

Ось X - точка наблюдения . Ось Y - Процент времени, проводимого в ядре (cpu -> sy)

Результат: после достижения максимальной производительности СУБД , процент времен, проводимого в ядре, существенно не меняется.

Признаки конкуренции за ресурсы RAM

1. Высокий уровень свопинга (swapping)

Результат: свопинг отсутствует

2. Низкая свободная память (менее 5% от общей RAM)

Результат: свободная память менее 5%

3. Активность кэша и буферов

Результат: не анализируется - свопинг отсутствует

4. Высокая активность дисков I/O

Результат: не анализируется - свопинг отсутствует

5. Процессы в состоянии ожидания I/O

Результат: очень низкое количество процессов в состоянии ожидания I/O

6. Частота контекстных переключений и прерываний (cs (context switches) и in (interrupts))

Ось X - точка наблюдения . Ось Y - Частота контекстных переключений

Результат: после достижения максимальной производительности СУБД , частота контекстных переключений снижается

Ось X - точка наблюдения . Ось Y - Частота прерываний

Результат: после достижения максимальной производительности СУБД , частота прерывание снижается.

Влияние гипервизора на CPU и IO

cpu_st stolen (украдено гипервизором)

cpu_st stolen (украдено гипервизором) = 0

Влияние гипервизора на CPU - нет

Рост wa и b при стабильных bi/bo

Ось X - точка наблюдения . Ось Y - cpu_wa ожидание IO

Ось X - точка наблюдения . Ось Y - procs_b процессы в uninterruptible sleep (обычно ждут IO)

Влияние гипервизора на подсистему I/O - нет

Продолжение - большая ВМ