От диагностики к действию

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

Эта статья — не теория, а готовый план как по конкретным симптомам (OLAP-нагрузка, неэффективный кэш, блокировки) выявить корень проблемы и применить целенаправленные правки: от выбора IO-планировщика и настройки виртуальной памяти до оптимизации файловой системы. Каждое изменение объяснено, обосновано и снабжено конкретной командой. Следуя этому руководству, вы системно оптимизируете производительность IO, переводя подсистему из состояния «выживания» в режим эффективной работы.

Начало: Получение данных о производительности IO

PG_EXPECTO: Анализ производительности подсистемы IO по результатам нагрузочного тестирования СУБД PostgreSQL

Задача

Сформировать список изменений параметров ОС для оптимизации производительности IO.

Промпт

Используя данные о результатах производительности системы IO,

необходимо подготовить список изменений параметров операционной системы для оптимизации производительности подсистемы IO:

**Общее описание оптимизируемых параметров и ожидаемый эффект**

**Оптимизация параметров IO**

- Получение текущего значения параметра

- Изменение значения параметра

- Основание для изменения

- Ожидаемый эффект от изменения

**Итог**

Тюнинг параметров ОС

На основе анализа предоставленных данных о производительности IO-подсистемы выявлены следующие проблемы:

1. Высокая загрузка диска vdd (100% utilization).

2. Высокая корреляция между использованием кэша памяти и операциями чтения/записи, что указывает на недостаточную эффективность кэширования.

3. Большое количество процессов в состоянии ожидания IO (uninterruptible sleep), превышающее количество ядер CPU.

4. Высокое отношение операций чтения к записи (OLAP-сценарий).

5. Низкая корреляция между операционной скоростью и IOPS/MB/s, что говорит о том, что узкое место — не в дисках, а в других подсистемах (CPU, блокировки, параметры СУБД).

📋 Список изменений параметров ОС для оптимизации IO

1. Общие параметры производительности

Параметр: vm.dirty_ratio, vm.dirty_background_ratio

• Текущее значение:

sysctl vm.dirty_ratio
sysctl vm.dirty_background_ratio

• Изменение:

sysctl -w vm.dirty_ratio=10
sysctl -w vm.dirty_background_ratio=5

• Основание: Снижает объем «грязных» страниц в памяти перед записью на диск, уменьшая пиковую нагрузку на IO.

• Ожидаемый эффект: Более равномерная запись, снижение пикового времени ожидания записи.

2. Параметры IO-планировщика

Параметр: Выбор планировщика для дисков vdd и vdc

• Текущее значение:

cat /sys/block/vdd/queue/scheduler
cat /sys/block/vdc/queue/scheduler

• Изменение:

echo deadline > /sys/block/vdd/queue/scheduler
echo deadline > /sys/block/vdc/queue/scheduler

• Основание: deadline уменьшает задержки для операций чтения, что критично при OLAP-нагрузке.

• Ожидаемый эффект: Улучшение времени отклика на чтение, снижение r_await.

3. Увеличение размера очереди запросов

Параметр: nr_requests

• Текущее значение:

cat /sys/block/vdd/queue/nr_requests

• Изменение:

echo 256 > /sys/block/vdd/queue/nr_requests

• Основание: Увеличивает глубину очереди запросов, позволяя диску эффективнее планировать операции.

• Ожидаемый эффект: Снижение aqu_sz (средней длины очереди), улучшение утилизации диска.

4. Настройки кэширования и буферизации

Параметр: vm.vfs_cache_pressure

• Текущее значение:

sysctl vm.vfs_cache_pressure

• Изменение:

sysctl -w vm.vfs_cache_pressure=50

• Основание: Уменьшает давление на кэш dentry и inode, что может улучшить кэширование файловых операций.

• Ожидаемый эффект: Улучшение эффективности кэша, снижение нагрузки на дисковые операции чтения.

5. Увеличение лимитов на количество открытых файлов

Параметр: fs.file-max, ulimit -n

• Текущее значение:

sysctl fs.file-max
ulimit -n

• Изменение:

sysctl -w fs.file-max=655356
echo "* soft nofile 65535" >> /etc/security/limits.conf
echo "* hard nofile 65535" >> /etc/security/limits.conf

• Основание: При большом количестве операций чтения/записи может требоваться больше открытых файлов.

• Ожидаемый эффект: Избежание ошибок “too many open files”, стабильность работы.

6. Настройка параметров виртуальной памяти

Параметр: vm.swappiness

• Текущее значение:

sysctl vm.swappiness

• Изменение:

sysctl -w vm.swappiness=10

• Основание: Уменьшает склонность системы к свопингу, что важно при высокой нагрузке на IO.

• Ожидаемый эффект: Больше оперативной памяти доступно для кэширования, меньше свопинга.

7. Настройка параметров сетевой подсистемы (если есть сетевые FS) - опционально

Параметр: net.core.rmem_max, net.core.wmem_max

• Текущее значение:

sysctl net.core.rmem_max
sysctl net.core.wmem_max

• Изменение:

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216

• Основание: Увеличивает буферы сетевой подсистемы, если используется NFS или другие сетевые хранилища.

• Ожидаемый эффект: Улучшение пропускной способности сетевого IO.

8. Оптимизация параметров файловой системы

Параметр: Монтирование с опциями noatime,nodiratime

• Текущее значение:

mount | grep /data

• Изменение:
  В /etc/fstab добавить для разделов /data, /log, /wal:textnoatime,nodiratime
  

• Основание: Уменьшает количество операций записи метаданных времени доступа.

• Ожидаемый эффект: Снижение нагрузки на запись.

9. Увеличение размера буферов для операций с блочными устройствами

Параметр: /sys/block/vdd/queue/read_ahead_kb

• Текущее значение:

cat /sys/block/vdd/queue/read_ahead_kb

• Изменение:

echo 4096 > /sys/block/vdd/queue/read_ahead_kb

• Основание: Увеличение предварительного чтения может улучшить производительность последовательных операций чтения.

• Ожидаемый эффект: Улучшение rMB/s для последовательных рабочих нагрузок.

10. Настройка параметров энергосбережения для дисков - опционально

Параметр: Управление APM (Advanced Power Management)

• Текущее значение:

hdparm -B /dev/vdd

• Изменение:

hdparm -B 255 /dev/vdd

• Основание: Отключает энергосберегающие режимы, которые могут увеличивать задержки.

• Ожидаемый эффект: Снижение r_await и w_await.

Итог

Предложенные изменения направлены на:

• Снижение нагрузки на диски за счёт оптимизации кэширования и буферизации.

• Улучшение отклика подсистемы IO через настройку планировщика и очередей.

• Увеличение эффективности использования оперативной памяти для снижения количества операций чтения/записи.

• Оптимизацию работы файловых систем и сетевых подсистем.

Рекомендация:

Вносить изменения постепенно, тестируя каждый параметр под нагрузкой.

Для постоянного применения добавлять настройки в /etc/sysctl.conf, /etc/security/limits.conf и /etc/fstab.

В современных системах обработки данных производительность подсистемы ввода-вывода (IO) часто становится ключевым фактором, определяющим общую эффективность СУБД. Даже на мощном оборудовании неправильная настройка или неоптимальные паттерны доступа к данным могут привести к “узким местам”, которые сводят на нет всю производительность системы. В статье разбираются результаты нагрузочного тестирования PostgreSQL с помощью инструмента PG_EXPECTO, чтобы выявить скрытые проблемы IO, проанализировать их причины и предложить конкретные шаги по оптимизации.

Задача

Подготовить промпт для формирования нейросетью отчета по анализу производительности подсистемы IO по результатам нагрузочного тестирования.

Формирование файлов статистических данных и промптов для нейросети, по итогам нагрузочного тестирования

cd /postgres/pg_expecto/sh/performance_reports

./load_test_report.sh

Результирующие файлы:

• Статистические данные по производительности СУБД и инфраструктуры : 1.summary.txt

• Промпт для нейросети для формирования отчета по производительности СУБД и инфраструктуры : _1.prompt.txt

• Статистические данные по производительности подсистемы IO: _2.io_performance.txt

• Промпт для нейросети для формирования отчета по производительности подсистемы IO: _2.io_performance_prompt.txt

• Метрики производительности дискового устройства файловой системы /data: linux.x.iostat_vdd_performance.txt

• Метрики производительности дискового устройства файловой системы /wal linux.x.iostat_vdc_performance.txt

Нагрузка на СУБД

Показатели производительности IO

Диск vdd (/data)

IOPS

MB/s

Диск vdc (/wal)

IOPS

MB/s

Формирование итогового отчета по производительности IO

Промпт

Подготовь итоговый по результатам анализа производительности подсистемы IO

Состав отчета:

**Общая характеристика системы**

- Период анализа

- Основные устройства хранения

- Тип нагрузки

**Критические проблемы производительности**

**Анализ корреляций и паттернов нагрузки**

**Диагностика узких мест IO**

- r_await(ms)

- w_await(ms)

- aqu_sz

- proc_b

- cpu_wa(%)

- Корреляция speed с IOPS

- Корреляция speed с пропускной способностью

- Вывод по диагностике узких мест IO

**Рекомендации по оптимизации**

**Итоговый вывод по производительности IO**

Отчет по анализу производительности подсистемы IO

Период анализа: 2026-01-03 12:59 — 2026-01-03 14:48 (≈2 часа)
Основные устройства хранения:

• /data → устройство vdd (100 ГБ, LVM)

• /wal → устройство vdc (50 ГБ, LVM)

Тип нагрузки: OLAP-сценарий (соотношение чтения к записи ≈ 2.68:1). Преобладают операции чтения, что характерно для аналитических запросов.

1. Файловая система /data (устройство vdd)

Критические проблемы производительности

• Загрузка устройства 100% (%util = 100) на всём интервале наблюдения.

• Высокая длина очереди запросов (aqu_sz до 18), что указывает на перегрузку диска.

• Высокое время ожидания CPU для IO (cpu_wa > 10% в 100% наблюдений).

• Корреляция cache – w/s (0.5183) и buff – wMB/s (0.6776) — память неэффективно используется для снижения нагрузки на диск.

Анализ корреляций и паттернов нагрузки

• Отрицательная корреляция wa – util (–0.2384) — задержки CPU не связаны напрямую с утилизацией диска.

• Высокая корреляция cache – r/s (0.5023) — кэш слабо помогает снизить операции чтения.

• Соотношение чтение/запись ≈ 2.68:1 — подтверждает OLAP-характер нагрузки.

Диагностика узких мест IO

Вывод по диагностике:
Узкое место — не в диске, а в CPU и подсистеме памяти. Высокий cpu_wa и большая очередь (aqu_sz) указывают на то, что процессы блокируются из-за ожидания IO, но сами задержки диска (r_await, w_await) низкие. Возможно, проблема в недостаточном буферизации/кэшировании или в настройках СУБД.

Рекомендации по оптимизации

1. Увеличить оперативную память для более эффективного кэширования данных.

2. Настроить параметры СУБД:
   Увеличить shared_buffers (если PostgreSQL).
   Оптимизировать work_mem для тяжёлых запросов.

3. Проверить план запросов — возможно, избыточные full scan или отсутствие индексов.

4. Рассмотреть использование более быстрого хранилища (например, SSD) для /data, если нагрузка чтения критична.

5. Мониторить процессы в D состоянии (proc_b) — выявить конкретные запросы, вызывающие ожидание.

2. Файловая система /wal (устройство vdc)

Критические проблемы производительности

• Загрузка устройства в норме (%util ≤ 53%).

• Очередь запросов отсутствует (aqu_sz ≤ 1).

• Задержки записи минимальны (w_await ≈ 1 мс).

Анализ корреляций и паттернов нагрузки

• Отрицательная корреляция wa – util (–0.2795) — CPU не простаивает из-за IO.

• Слабая корреляция cache – w/s (0.4105) — кэш умеренно влияет на запись.

• Операции чтения отсутствуют (r/s = 0) — нагрузка чисто на запись (WAL-логи).

Диагностика узких мест IO

Вывод по диагностике:
Устройство vdc не является узким местом. Запись в WAL идёт эффективно, задержки минимальны, очередь не формируется.

Рекомендации по оптимизации

1. Текущая конфигурация адекватна — изменений не требуется.

2. Мониторить рост WAL — убедиться, что место не заканчивается.

3. При увеличении нагрузки на запись — рассмотреть отдельный быстрый SSD для WAL.

Итоговый вывод по производительности IO

1. Основное узкое место — устройство vdd (/data):
   Постоянная 100% загрузка, высокая очередь запросов.
   Проблема не в скорости диска, а в неэффективном использовании памяти и CPU.
   Рекомендуется оптимизировать кэширование и настройки СУБД.

2. Устройство vdc (/wal) работает в штатном режиме:
   Загрузка умеренная, задержки низкие.
   Не требует срочных изменений.

3. Общая система:
   Нагрузка имеет OLAP-характер (много чтений).
   CPU простаивает из-за ожидания IO (высокий wa), но диски не являются медленными — проблема в организации доступа к данным.
   Рекомендуется фокус на оптимизацию запросов и увеличение памяти.

Рекомендуемые действия в порядке приоритета:

1. Увеличить объём оперативной памяти.

2. Настроить параметры кэширования СУБД.

3. Провести анализ и оптимизацию медленных запросов.

4. Рассмотреть переход на SSD для /data, если нагрузка продолжит расти.

*Отчет составлен на основе анализа метрик iostat, vmstat и корреляций за период 2026-01-03 12:59–14:48.*

Нагрузочное тестирование — это не просто сбор метрик, а сложный процесс их интерпретации. Традиционный анализ требует значительного времени и опыта. Проект PG_EXPECTO демонстрирует, как современные нейросети могут стать мощным соавтором инженера, мгновенно выявляя узкие места, коррелируя данные из разных источников (СУБД, ОС, диски) и формулируя конкретные рекомендации. Эта статья — практический пример превращения сырых данных нагрузочного теста в готовый план действий с помощью искусственного интеллекта.

Задача

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

Шаг-1: Формирование файлов статистических данных и промптов для нейросети по окончании нагрузочного тестирования

cd /postgres/pg_expecto/sh/performance_reports

./load_test_report.sh

$ ./load_test_report.sh

TIMESTAMP : 03-01-2026 15:10:17  : OK :  ОТЧЕТ ПО НАГРУЗОЧНОМУ ТЕСТИРОВАНИЮ - НАЧАТ

…

TIMESTAMP : 03-01-2026 15:10:22  : OK : 1.ВХОДНЫЕ ДАННЫЕ ДЛЯ НЕЙРОСЕТИ - СУБД И VMSTAT/IOSTAT

TIMESTAMP : 03-01-2026 15:10:22  : OK : 2.ВХОДНЫЕ ДАННЫЕ ДЛЯ НЕЙРОСЕТИ - IO PERFORMANCE

TIMESTAMP : 03-01-2026 15:10:22  : OK :  DEVICE =  vdd

TIMESTAMP : 03-01-2026 15:10:22  : OK :  DEVICE =  vdc

TIMESTAMP : 03-01-2026 15:10:22  : OK :  ОТЧЕТ ПО НАГРУЗОЧНОМУ ТЕСТИРОВАНИЮ - ВЫПОЛНЕН

Результирующие файлы:

• Статистические данные по производительности СУБД и инфраструктуры : 1.summary.txt

• Промпт для нейросети для формирования отчета по производительности СУБД и инфраструктуры : _1.prompt.txt

• Статистические данные по производительности подсистемы IO: _2.io_performance.txt

• Промпт для нейросети для формирования отчета по производительности подсистемы IO: _2.io_performance_prompt.txt

Шаг-2: Формирование итогового отчета по производительности СУБД и инфраструктуры

Промпт

Проанализируй данные по метрикам производительности и ожиданий СУБД , метрикам инфраструктуры vmstat/iostat. Подготовь итоговый отчет по результатам анализа.

1. Общая характеристика системы

• PostgreSQL версия: конфигурация из postgresql.auto.conf

• Аппаратные ресурсы:
  CPU: 8 ядер (Intel Xeon)
  RAM: 7.5 GB
  Диски: отдельные разделы для данных (100GB), WAL (50GB), логов (30GB)

• Нагрузка: тестирование проводилось с 12:59 до 14:48, нагрузка возрастала с 5 до 22 единиц

2. Ключевые проблемы производительности

2.1. Дисковый ввод-вывод (I/O) — критическая проблема

• Ожидания IO составляют 99.93% от всех ожиданий СУБД

• Основное событие ожидания: DataFileRead (чтение данных с диска)

• В системных метриках (vmstat):
  wa (ожидание I/O) постоянно превышает 44-50%
  100% наблюдений имеют wa > 10% (крайне тревожный показатель)
  Высокая корреляция (0.9755) между ожиданиями IO и процессами в состоянии непрерываемого сна (b)
  Количество процессов в состоянии b возрастает с 5 до 14

2.2. Падение производительности под нагрузкой

• Производительность (SPEED) снизилась на ~5% (с 284,895 до 265,388)

• Ожидания (WAITINGS) выросли в 2.7 раза (с 27,055 до 72,905)

• Сильная отрицательная корреляция (-0.71) между SPEED и WAITINGS

2.3. Проблемы с памятью

• Свободной оперативной памяти менее 5% в 100% наблюдений

• При этом свопинг не используется — вся память активно задействована

2.4. Конкуренция за ресурсы

• Заметные ожидания по блокировкам:
  Lock: extend (67.61%), transactionid (23.17%)
  LWLock: ProcArray (51.61%), BufferContent (31.85%)

• Высокая корреляция (0.91) между LWLock и user time CPU

3. Анализ запросов

Три основных запроса вызывают 80% проблем:

1. scenario1 (queryid: 65003243407475111) — 80.18% ожиданий IO

2. scenario3 (queryid: 2179758041927844257) — проблемы с блокировками

3. scenario2 (queryid: -1379548677898522698) — также вносит вклад в ожидания

4. Конфигурационные проблемы PostgreSQL

4.1. Агрессивные настройки autovacuum

autovacuum_naptime = '1s' # Слишком часто
autovacuum_vacuum_cost_delay = '2ms' # Слишком мало
autovacuum_work_mem = '256MB' # Много для каждого воркера

Может создавать избыточную фоновую нагрузку на I/O.

4.2. Параметры памяти

• work_mem = '32MB' — может быть недостаточно для сложных операций

• shared_buffers = '2GB' — разумно, но стоит мониторить эффективность

5. Рекомендации

5.1. Оптимизация запросов (высший приоритет)

• Сфокусироваться на оптимизации scenario1 (80% проблем с I/O)

• Рассмотреть:
  Добавление индексов для уменьшения полных сканирований таблиц
  Оптимизацию JOIN-операций
  Кэширование часто запрашиваемых данных

5.2. Настройка PostgreSQL

• Увеличить work_mem до 64-128MB для уменьшения дисковых операций

• Настроить autovacuum менее агрессивно:
  Увеличить autovacuum_vacuum_cost_delay до 10-20ms
  Увеличить autovacuum_naptime до 30s-1min

• Проверить эффективность shared_buffers и effective_cache_size

5.3. Инфраструктурные улучшения

• Рассмотреть переход на более быстрые диски (SSD/NVMe)

• Настроить параметры виртуальной памяти ОС (как указано в отчете):
  Проверить и оптимизировать vm.dirty_background_bytes, vm.dirty_bytes

• Рассмотреть увеличение оперативной памяти

5.4. Мониторинг и дальнейший анализ

• Установить мониторинг дисковых задержек (latency)

• Анализировать план выполнения проблемных запросов

• Рассмотреть разделение нагрузки на несколько дисковых массивов

6. Заключение

Система упирается в производительность дискового ввода-вывода. При росте нагрузки диски не справляются с объемом операций чтения, что приводит к резкому росту ожиданий и падению производительности. Критически важна оптимизация запросов (особенно scenario1) и улучшение дискового подсистемы. Без этих мер дальнейшее увеличение нагрузки приведет к еще более серьезным проблемам с производительностью.

Шаг-3: Формирование итогового отчета по производительности подсистемы IO

Промпт

Подготовь итоговый отчёт по результатам анализа производительности подсистемы IO

1. Общая информация

• Период анализа: 2026-01-03 12:59 - 2026-01-03 14:48 (109 минут)

• Анализируемые устройства: vdd и vdc

• CPU: 8 ядер, Intel Xeon Processor (Skylake)

2. Ключевые выводы по устройству vdd (/data)

Критические проблемы:

1. Постоянная 100% загрузка устройства - во всех 110 замерах %util = 100%

2. Высокая глубина очереди - 100% наблюдений с aqu_sz > 1 (до 18)

3. Неэффективное использование памяти:
   Высокая корреляция (buff - wMB/s): 0.6776
   Высокая корреляция (cache - r/s): 0.5023
   Высокая корреляция (cache - w/s): 0.5183

Производительность:

• IOPS: 3949-4052 операций/сек

• Пропускная способность: 36-40 МБ/сек

• Latency чтения: 2-5 мс (в пределах нормы)

• Latency записи: 2-5 мс (в пределах нормы)

• Нагрузка на CPU (wa): 44-50% (высокая)

3. Ключевые выводы по устройству vdc (/wal)

Статус: Удовлетворительно

1. Умеренная загрузка: 42-53% utilization

2. Низкая глубина очереди: менее 25% наблюдений > 1

3. Latency в норме: w_await ≈ 1 мс

4. Корреляции в основном в норме

Производительность:

• IOPS записи: 758-971 операций/сек

• Пропускная способность: 6-8 МБ/сек

• Нагрузка на CPU (wa): 44-50%

4. Рекомендации

Срочные меры для vdd:

1. Рассмотреть апгрейд диска - текущий диск работает на пределе

2. Оптимизировать использование кэша - выявлена неэффективность

3. Балансировка нагрузки - возможно перенести часть операций на другие диски

4. Увеличить память для улучшения кэширования

Оптимизационные меры:

1. Мониторинг - установить постоянный мониторинг загрузки vdd

2. Анализ паттернов доступа - понять причину высокой нагрузки

3. Настройка параметров IO - оптимизировать размеры блоков и очереди

5. Общий вердикт

• Устройство vdd требует немедленного внимания - работает в режиме saturation

• Устройство vdc функционирует в нормальном режиме

• Система в целом имеет резерв по CPU (wa < 50%), но дисковый IO является узким местом

Приоритет: Высокий (необходимы срочные меры по оптимизации vdd)

Методология исследования

Тестовая среда, инструменты и конфигурация СУБД:

• СУБД: PostgreSQL 17

• Инструмент нагрузочного тестирования: pg_expecto

• Тестовые базы данных:

• Вариант нагрузки №1 - "Демобаза 2.0" (большой размер, сложная схема)

• Вариант нагрузки №2 - Тестовая база pgbench (большой размер, простая схема)

• Условия тестирования: параллельная нагрузка от 7 до 22 сессий (количество сессий для тестового сценария определяется согласно весовому коэффициенту).

Вариант нагрузки №1

• Высокая нагрузка на CPU

• Высокая читающая нагрузка

• Низкая пишущая нагрузка.

Вариант нагрузки №2

• Низкая нагрузка на CPU

• Низкая читающая нагрузка

• Высокая пишущая нагрузка.

Вариант нагрузки №1 - анализ с точки зрения производительности СУБД

checkpoint_timeout=1 минута:

• Преимущества: Наивысшая пиковая производительность (2 599 957)

• Недостатки:
  Наиболее выраженное снижение производительности со временем
  Сильная обратная корреляция между скоростью и ожиданиями (-0.79)
  Высокая нагрузка на LockManager

checkpoint_timeout=15 минут:

• Преимущества: Более плавное снижение производительности

• Недостатки:
  Наибольшие максимальные ожидания (10 128)
  Появление конкуренции за буферы (BufferMapping)
  Наихудшая минимальная производительность (140)

checkpoint_timeout=30 минут:

• Преимущества: Наиболее стабильные показатели

• Недостатки:
  Наименьшая максимальная производительность (1 888 191)
  Средние показатели по всем метрикам

Рекомендации для заданной нагрузки

Для варианта нагрузки №1 (высокая CPU, высокая читающая нагрузка, низкая пишущая):

• Оптимальное значение checkpoint_timeout: 15-30 минут
  Более редкие checkpoint снижают конкуренцию за ресурсы
  Уменьшают нагрузку на подсистему ввода-вывода
  Обеспечивают более стабильную производительность

Общий вывод

Параметр checkpoint_timeout оказывает значительное влияние на производительность СУБД при заданной нагрузке. Для варианта с высокой читающей и низкой пишущей нагрузкой рекомендуются более редкие checkpoint (15-30 минут), что обеспечивает более стабильную производительность и снижает конкуренцию за системные ресурсы.

Вариант нагрузки №2 - анализ с точки зрения производительности СУБД

Положительные эффекты увеличения интервала:

• Более высокая начальная производительность:
  При checkpoint_timeout=15-30мин производительность на 44% выше, чем при 1 мин
  Меньше накладных расходов на частые checkpoint-ы

Негативные эффекты увеличения интервала:

• Более быстрая деградация производительности:
  Производительность падает быстрее при длинных интервалах checkpoint

• Рост максимальных ожиданий:
  При checkpoint_timeout=30мин ожидания достигают 123 362 (против 112 965 при 1 мин)

• Усиление корреляции между скоростью и ожиданиями:
  Корреляция усиливается с -0.53 до -0.94, что указывает на более сильную зависимость производительности от ожиданий

Механизмы влияния checkpoint_timeout на пишущую нагрузку

При коротком интервале (1 мин):

• Частые checkpoint-ы → меньше данных для записи за раз

• Меньший объем WAL-файлов между checkpoint-ами

• Более равномерная нагрузка на IO, но больше накладных расходов

• Меньше блокировок extend (выше доля в общем объеме, но меньше абсолютное значение)

При длинном интервале (15-30 мин):

• Редкие checkpoint-ы → накопление больших объемов изменений

• Более интенсивные всплески записи при checkpoint-ах

• Увеличение объема DataFileRead (чтение "грязных" страниц для записи)

• Рост конкуренции за ресурсы (LWLock, BufferContent)

Рекомендации для заданного варианта нагрузки

Для высокой пишущей нагрузки с низким чтением:

• Оптимальный диапазон checkpoint_timeout: 5-10 минут
  Компромисс между накладными расходами (1 мин) и всплесками нагрузки (15-30 мин)
  Позволяет снизить частоту checkpoint-ов без чрезмерного накопления изменений

Выводы

1. Checkpoint_timeout существенно влияет на производительность при высокой пишущей нагрузке, определяя баланс между накладными расходами и объемом единовременной записи.

2. Экстремальные значения (1 мин и 30 мин) неоптимальны:
   1 мин: слишком высокие накладные расходы, низкая начальная производительность
   30 мин: быстрая деградация, высокие пиковые ожидания

3. Наиболее стабильное поведение наблюдается при checkpoint_timeout=15 мин, хотя и с быстрой деградацией производительности.

4. Основной лимитирующий фактор — IO-ожидания (DataFileRead), что необычно для пишущей нагрузки и указывает на необходимость оптимизации процессов чтения при checkpoint-ах.

5. Рекомендуется тестирование промежуточных значений checkpoint_timeout (5-10 мин) для нахождения оптимального баланса для конкретной конфигурации и нагрузки.

Итоговый вывод с точки зрения производительности СУБД

Чем выше интенсивность пишущей нагрузки на СУБД тем более оптимальнее будет уменьшение интервала между контрольными точками.

Вариант нагрузки №1 - анализ производительности ОС

Влияние параметра checkpoint_timeout

• Нагрузка на CPU:
  Увеличение checkpoint_timeout с 1 до 15 минут снижает нагрузку на CPU (очередь процессов уменьшается с 98.21% до 79.57%).
  Дальнейшее увеличение до 30 минут ухудшает показатель (88.89%).

• Использование памяти:
  Увеличение checkpoint_timeout снижает дефицит свободной RAM (с 100% до 77.78%).
  Наиболее эффективно значение 30 минут.

• I/O:
  Параметр не оказывает значимого влияния на I/O при низкой пишущей нагрузке.

Итог

Параметр checkpoint_timeout влияет на баланс между нагрузкой на CPU и использованием памяти. Для заданного варианта нагрузки оптимальным является значение 15 минут, которое обеспечивает наименьшую нагрузку на CPU при приемлемом использовании памяти. Однако системные ресурсы (CPU и RAM) недостаточны для данной нагрузки, что требует дополнительной оптимизации или масштабирования.

Вариант нагрузки №2 - анализ производительности ОС

Параметр checkpoint_timeout почти не влияет на IO-проблемы:

• Во всех трёх экспериментах наблюдается одинаково высокий уровень ожиданий IO (wa).

• Количество процессов в состоянии uninterruptible sleep (ожидание IO) стабильно превышает количество ядер CPU.

• Это указывает на системную проблему с подсистемой IO, не связанную напрямую с частотой контрольных точек.

Увеличение checkpoint_timeout снижает нагрузку на CPU от LWLock:

• В эксперименте-1 (1 мин) корреляция LWLock-sy = 0.7721 (ALARM).

• В эксперименте-2 (15 мин) корреляция снижается до 0.4114 (INFO).

• В эксперименте-3 (30 мин) — 0.6755 (WARNING).

• Вывод: Более редкие контрольные точки снижают конкуренцию за лёгковесные блокировки (LWLock) в ядре.

Память — узкое место:

• Во всех экспериментах свободной памяти < 5%.

• Несмотря на это, свопинг не используется, что может указывать на:
  Неэффективное использование кэширования/буферизации.
  Возможную утечку памяти или недостаточный размер RAM для рабочей нагрузки.

Диски недогружены:

• При заявленной "высокой пишущей нагрузке" диски загружены лишь на 0.02–0.03%.

• Это может означать:
  Нагрузка буферизуется в памяти и ещё не сброшена на диск.
  Проблема не в дисках, а в подсистеме ввода-вывода на уровне ОС или СУБД.

Итог

Параметр checkpoint_timeout не является ключевым фактором для производительности ОС при заданном профиле нагрузки (низкий CPU, низкое чтение, высокая запись). Основные проблемы связаны с подсистемой IO и нехваткой памяти. Увеличение checkpoint_timeout до 15–30 минут может снизить нагрузку на CPU от LWLock, но не решит фундаментальных проблем с IO и памятью.

Итоговый вывод с точки зрения производительности ОС

Для данной инфраструктуры виртуальной машины и заданных вариантов нагрузки, параметр checkpoint_timeout не является ключевым фактором для производительности инфраструктуры из-за неоптимальной настройки управления IO и RAM.