Серия «СУБД PostgreSQL»

Взято с основного технического канала Postgres DBA

Очередная иллюстрация -ЛЮБОЙ ответ нейросетей необходимо экспериментально проверять.

Вопрос DeepSeek

Как изменится производительность СУБД PostgreSQL при нагрузке создаваемой pgbench и количестве подключений от 5 до 100 для СУБД размером 300MB при ресурсах CPU = 2 и RAM = 2GB при изменении настроек автовакуума с настроек по умолчанию на агрессивные настройки ?

Ответ DeepSeek

Исходные параметры:

• Размер БД: 300 MB

• Ресурсы: 2 CPU, 2 GB RAM

• Количество подключений: 5–100

• Нагрузка: pgbench в режиме TPC-B (смесь SELECT/UPDATE).

• Сравнение:
  Настройки по умолчанию:

autovacuum_vacuum_scale_factor = 0.2

autovacuum_vacuum_threshold = 50

autovacuum_vacuum_cost_delay = 20ms

autovacuum_vacuum_cost_limit = 200

Агрессивные настройки:

autovacuum_vacuum_scale_factor = 0.05 # Запуск при 5% изменений вместо 20%

autovacuum_vacuum_threshold = 25 # Нижний порог срабатывания

autovacuum_vacuum_cost_delay = 5ms # Меньшая задержка между операциями

autovacuum_vacuum_cost_limit = 1000 # Больше операций за один проход

Прогнозируемые результаты:

1. Низкая нагрузка (5–20 подключений):

• По умолчанию:
  Автовакуум запускается редко. Мертвые кортежи накапливаются, но не критично. Производительность стабильна.
  TPS: ~600–800.

• Агрессивные настройки:
  Автовакуум срабатывает чаще, но нагрузка от него незначительна. Мертвые кортежи удаляются своевременно.
  TPS: ~650–850 (+5–10%).

2. Средняя нагрузка (30–60 подключений):

• По умолчанию:
  Накопление мертвых кортежей приводит к:
  Увеличению размера таблиц (из-за "раздувания").
  Замедлению SELECT (сканирование большего объема данных).
  Блокировкам при UPDATE из-за долгих вакуумных операций.
  TPS: падение до 400–500.

• Агрессивные настройки:
  Частые, но короткие вакуум-сессии. Меньше "раздувания", быстрее доступ к данным.
  TPS: ~550–700 (+20–40%).

3. Высокая нагрузка (80–100 подключений):

• По умолчанию:
  Критическое накопление мертвых кортежей. Автовакуум не успевает очищать данные, что вызывает:
  Резкое падение TPS (до 200–300).
  Рост времени отклика (блокировки, конкуренция за I/O).

• Агрессивные настройки:
  Плюсы: Минимизация "раздувания", стабильный TPS (~450–600).
  Минусы: Конкуренция за ресурсы CPU между фоновым вакуумом и рабочими процессами. При 2 CPU возможны просадки из-за нехватки вычислительной мощности.

Ключевые метрики для сравнения:

1. TPS (Transactions Per Second):
   Агрессивные настройки дадут прирост на 20–40% при 30–60 подключениях.
   При 80–100 подключениях рост TPS будет менее значительным (+10–15%) из-за ограничений CPU.

2. Задержки (Latency):
   В агрессивном режиме задержки будут стабильнее, особенно в диапазоне 30–60 подключений.

3. Размер таблиц (Table Bloat):
   Агрессивный автовакуум уменьшит "раздувание" на 40–60% по сравнению с настройками по умолчанию.

4. Использование CPU:
   При агрессивных настройках нагрузка на CPU вырастет на 15–25% из-за частого выполнения вакуума.

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

1. Для тестовой конфигурации (2 CPU, 2 GB RAM):
   Агрессивные настройки целесообразны при 20–60 подключениях.
   При 80–100 подключениях требуется мониторинг CPU: если загрузка достигнет 90–100%, производительность может ухудшиться.

2. Оптимизация под высокую нагрузку:
   Увеличьте autovacuum_max_workers (если нужно параллелить вакуум).
   Настройте maintenance_work_mem (выделите 256–512 MB для операций вакуума).

3. Дисковый I/O:
   Если диск медленный (HDD), агрессивный автовакуум может вызвать contention I/O. Используйте SSD для минимизации рисков.

Заключение:

Агрессивные настройки автовакуума улучшат производительность на 20–40% при 30–60 подключениях, предотвращая "раздувание" таблиц. Однако при экстремальной нагрузке (80–100 подключений) и ограниченных ресурсах CPU (2 ядра) возможна конкуренция за процессорное время, что снизит эффективность. Тестирование на реальной инфраструктуре с мониторингом CPU/I/O обязательно.

Результаты сравнительных экспериментов

Конфигурация виртуальной машины

CPU = 2RAM = 2GB

Версия СУБД:Postgres Pro (enterprise certified) 15.8.1 on x86_64-pc-linux-gnu, compiled by gcc (AstraLinuxSE 8.3.0-6) 8.3.0, 64-bit

Сценарий нагрузки "Mix Without median time"

Эксперимент-1 : Настройки автовакуума по умолчанию

autovacuum_vacuum_scale_factor = 0.2

autovacuum_vacuum_threshold = 50

autovacuum_analyze_scale_factor = 0.1

autovacuum_analyze_threshold = 50

autovacuum_vacuum_cost_limit = -1

vacuum_cost_limit = 2000

autovacuum_vacuum_cost_delay = 2ms

Эксперимент-2 : "агрессивные" настройки автовакуума

autovacuum_vacuum_scale_factor = 0.01

autovacuum_vacuum_threshold = 25

autovacuum_analyze_scale_factor = 0.005

autovacuum_analyze_threshold = 10

autovacuum_vacuum_cost_limit = 2000

vacuum_cost_limit = 2000

autovacuum_vacuum_cost_delay = 2ms

maintenance_work_mem = 128MB

autovacuum_naptime = 5s

Результаты сравнительных экспериментов

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

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

Итоги и проверка гипотез DeepSeek

1. Операционная скорость для данной СУБД и данных ресурсах ВМ - не увеличилась и даже уменьшилась до -5% при оптимальной нагрузке.

2. Характерные ожидания - не изменились .

3. Гипотеза нейросети о влиянии "агрессивной" настройки автовакуума на производительность СУБД - не подтвердилась:

Агрессивные настройки автовакуума улучшат производительность на 20–40% при 30–60 подключениях, предотвращая "раздувание" таблиц.

Как обычно , для развлечения задал вопрос нейросетям :
Как размер тестовой базы данных pgbench влияет на производительность СУБД при проведении нагрузочного тестирования с использованием pgbench в качестве инструмента создания нагрузки ?

Ответ YandexGPT:

При проведении нагрузочного тестирования с использованием pgbench размер тестовой базы данных играет ключевую роль в определении производительности СУБД. Вот основные аспекты, которые следует учитывать:

Инициализация тестовой базы:

Инструмент pgbench позволяет инициализировать тестовую базу с определенным масштабом, используя параметр --scale=количество. Например, --scale=4000 задает базу размером 4000 записей.

Влияние размера базы на производительность:

Больше данных — ниже производительность: Увеличение размера базы данных может привести к снижению производительности, так как большее количество данных требует больше времени на обработку транзакций.

Кэширование: Если база данных помещается в кэш СУБД, операции могут выполняться быстрее за счет уменьшения времени доступа к диску. Однако при превышении объема кэша производительность может значительно упасть.

Внешние ключи и соединения:

При инициализации базы можно использовать параметр --foreign-keys для включения внешних ключей, что усложняет схему данных и может повлиять на время выполнения запросов.

Параметры нагрузки:

Нагрузочное тестирование с pgbench обычно включает циклы нагрузок с переменным числом клиентов (например, 1, 10, 20, 50, 100) в течение заданного времени (например, 600 секунд с параметром -T 600).

Результаты тестирования логируются в отдельные файлы, что позволяет строить графики зависимости показателей (например, транзакций в секунду или средней задержки) от числа клиентов.

Дополнительные метрики:

Помимо основных показателей, таких как TPS (транзакций в секунду), полезно отслеживать среднюю задержку (Latency average), которая показывает время выполнения транзакций.

Автоматизация с pg_perfbench:

Для точного фиксирования всех деталей окружения и результатов тестирования рекомендуется использовать инструмент pg_perfbench. Он автоматизирует сбор системной информации и генерацию отчетов, что упрощает сопоставление и анализ результатов различных тестов.

Таким образом, размер тестовой базы данных существенно влияет на производительность СУБД при нагрузочном тестировании с использованием pgbench. Увеличивая размер базы, можно наблюдать снижение производительности из-за роста времени обработки данных. Важно учитывать все параметры конфигурации и детали окружения для точного анализа и воспроизводимости тестов.

Ответ ChatPPG:

Размер тестовой базы данных может существенно влиять на результаты тестирования с использованием pgbench. Вот несколько ключевых моментов, которые стоит учесть:

1. **Коэффициент масштаба (-s)**:
- Параметр -s (или --scale) позволяет умножить количество строк в таблицах на заданный коэффициент. Например, с ключом -s 100 в таблицу pgbench_accounts будет записано 10 000 000 строк.
- Более крупные базы данных могут потребовать больше времени на выполнение операций вставки, обновления и выборки, что может повлиять на общую производительность и количество транзакций в секунду (TPS).

2. Размер таблиц и индексов:
- Большие таблицы и индексы могут увеличивать время выполнения запросов из-за увеличения времени поиска и обновления данных.
- В больших базах данных могут возникать дополнительные задержки из-за увеличения объема данных, которые нужно обрабатывать.

3. Память и кэширование:
- В больших базах данных может быть меньше данных, которые умещаются в памяти, что приводит к увеличению количества операций ввода-вывода (I/O) и замедлению производительности.
- Кэширование данных в памяти может быть менее эффективным, что также может сказаться на результатах тестирования.

4. Примеры результатов тестирования:
- В документации [pg_stat_statements](https://postgrespro.com/docs/postgresql/15/pgstatstatements#...) приведены примеры результатов тестирования с использованием pgbench. Например, при выполнении 300 транзакций с 10 клиентами можно увидеть, что время выполнения запросов может значительно различаться в зависимости от размера базы данных и количества операций.

Пример команды для инициализации базы данных с коэффициентом масштаба 10:
pgbench -i -s 10 bench


Пример команды для запуска тестирования с 10 клиентами и 300 транзакциями:
pgbench -c 10 -t 300 bench


Таким образом, увеличение размера тестовой базы данных может привести к снижению производительности и количества транзакций в секунду, что важно учитывать при настройке и интерпретации результатов тестирования с использованием pgbench.

Как обычно , в рассуждениях нейросети есть 2 принципиально слабых момента:
1-У нейросети нет результатов экспериментов и никаких фактов , только статистическая обработка текстов документации.
2-Нейросеть , в принципе не способна логически рассуждать , и не знает , что рост размера тестовой базы данных приводит к снижению количества тяжелых блокировок при выполнении update.

P.S. А вот ответ DeepSeek удивил, полнотой ответа и упоминанием влияния конкурентного обновления .

Размер тестовой базы данных в pgbench существенно влияет на производительность СУБД PostgreSQL во время нагрузочного тестирования. Вот основные аспекты этого влияния:

### 1. **Кеширование данных в памяти**
- **Маленькая база**: Если данные полностью помещаются в кеш (например, в `shared_buffers` или оперативной памяти), операции чтения выполняются быстрее, так как минимизируются обращения к диску. Это увеличивает TPS (транзакций в секунду) и снижает задержки.
- **Большая база**: При превышении объема данных над доступной памятью возникают промахи кеша, что приводит к частым чтениям с диска. Это замедляет выполнение запросов, особенно для операций `SELECT`.

### 2. **Конфликты доступа (Contention)**
- **Маленькая база**: Выше вероятность конфликтов при параллельных обновлениях (например, в таблицах `accounts`). Это увеличивает время ожидания блокировок и снижает пропускную способность.
- **Большая база**: Данные распределены по большему числу строк, что снижает конкуренцию за одни и те же записи. Это особенно важно для тестов с высокой долей операций `UPDATE`.

### 3. **Планирование запросов**
- На маленьких базах статистика, собираемая PostgreSQL, может быть недостаточно репрезентативной, что приводит к неоптимальным планам выполнения запросов (например, выбор полного сканирования вместо использования индекса).
- На больших базах оптимизатор чаще выбирает эффективные планы, так как статистика точнее отражает распределение данных.

### 4. **Нагрузка на подсистему ввода-вывода (I/O)**
- При больших размерах базы возрастает нагрузка на диск из-за:
- Чтения данных, не помещающихся в кеш.
- Записи WAL (Write-Ahead Log) и выполнения checkpoint’ов, которые требуют больше времени.
- Это может стать узким местом для write-heavy нагрузок.

### 5. **Эффективность индексов**
- Большие индексы (например, в таблице `accounts`) требуют больше ресурсов для обновления и поиска. Если они не помещаются в память, производительность снижается.

### 6. **Фоновые процессы**
- **Checkpoint**: На больших базах checkpoint’ы выполняются дольше, что может вызывать всплески нагрузки на диск.
- **Autovacuum**: Чаще срабатывает на больших базах, конкурируя с рабочими транзакциями за ресурсы.

### Примеры сценариев
- **Read-only тесты**:
- Маленькая база: Высокий TPS из-за кеширования.
- Большая база: Снижение TPS, если данные не помещаются в память.
- **Write-heavy тесты**:
- Маленькая база: Риск contention и частые блокировки.
- Большая база: Меньше конфликтов, но выше нагрузка на WAL и диск.

### Рекомендации
- Выбирайте размер базы, сопоставимый с реальными данными, чтобы тесты отражали эксплуатационные условия.
- Для тестирования предельной производительности в идеальных условиях используйте базу, которая помещается в память.
- Чтобы оценить работу с диском, задайте размер базы, превышающий доступную память.
- Увеличивайте масштабный фактор (`-s`) постепенно, анализируя, как меняется производительность.

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

На всех конференциях - стандартный вопрос, по окончании практически любого доклада о очередном инструменте анализа производительности СУБД :

А как это влияет на производительность СУБД ?

С методологической точки зрения, вариантов использования сбора и анализа метрик производительности всего 2 :

1. Не использовать сбор и мониторинг метрик производительности СУБД и не иметь никакой достоверной информации о причинах изменения производительности СУБД. Зато - никакого влияния.

2. Использовать сбор метрик производительности СУБД, иметь информацию о причинах изменения производительности и учитывать влияние сбора метрик .

Или проще говоря

• в первом случае: меньше знаешь - крепче спишь ,

• во-втором : за все надо платить.

С точки зрения физики - СУБД не является исключением и эффект наблюдателя , конечно же имеет место и да, любой сбор метрик производительности СУБД - влияет на производительность СУБД .

И это влияние можно оценить не только качественно но и количественно и обязательно нужно учитывать при анализе производительности СУБД:

PG_HAZEL : Влияние расчета медианного времени на производительность СУБД.

Взято с основного технического канала Postgres DBA

Начало экспериментов :

PG_HAZEL : ожидания СУБД PostgreSQL при отсутствии индексов.

Задача эксперимента

Определение и анализ характерных ожиданий, вызванных использованием индексов при массовых операциях INSERT.

Сравнительные эксперименты

Эксперимент-1 : Стандартный сценарий "Insert only"

Эксперимент-2 : Cценарий "Insert only" с использование индексов на таблице.

Сценарий "Insert only"

INSERT INTO pgbench_history (tid, bid, aid, delta, mtime)

VALUES ( current_tid , current_bid , current_aid , current_delta , CURRENT_TIMESTAMP );

Тестовая таблица

Table "public.pgbench_history"

Column | Type | Collation | Nullable | Default

--------+-----------------------------+-----------+----------+---------

tid | integer | | |

bid | integer | | |

aid | integer | | |

delta | integer | | |

mtime | timestamp without time zone | | |

filler | character(22) | | |

Foreign-key constraints:

"pgbench_history_aid_fkey" FOREIGN KEY (aid) EFERENCES pgbench_accounts(aid)

"pgbench_history_bid_fkey" FOREIGN KEY (bid) REFERENCES pgbench_branches(bid)

"pgbench_history_tid_fkey" FOREIGN KEY (tid) REFERENCES pgbench_tellers(tid)

Тестовая таблица с добавленными индексами (индексы по столбцам aid , delta, mtime)

Table "public.pgbench_history"

Column | Type | Collation | Nullable | Default

--------+-----------------------------+-----------+----------+---------

tid | integer | | |

bid | integer | | |

aid | integer | | |

delta | integer | | |

mtime | timestamp without time zone | | |

filler | character(22) | | |

Indexes:

"pgbench_history_idx1" btree (aid)

"pgbench_history_idx2" btree (delta)

"pgbench_history_idx3" btree (mtime)

Foreign-key constraints:

"pgbench_history_aid_fkey" FOREIGN KEY (aid) REFERENCES pgbench_accounts(aid)

"pgbench_history_bid_fkey" FOREIGN KEY (bid) REFERENCES pgbench_branches(bid)

"pgbench_history_tid_fkey" FOREIGN KEY (tid) REFERENCES pgbench_tellers(tid)

Операционная скорость и медианное время тестового SQL запроса

Результат

Создание дополнительных индексов ухудшило скорость на 16-18% и увеличило время на 24-28%.

Корреляция между типами ожиданий и ожиданиями СУБД

Результат

1. Использование индексов резко увеличивает ожидания типа IO и LWLock.

Корреляция между типом ожидания и событиями ожидания при выполнении тестового запроса

Тип ожидания "IO"

Результат

• Резкий рост корреляции с ожиданием DataFileRead

Тип ожидания "Lock"

Тип ожидания "LWLock"

Результат

Резкий рост корреляции с событием ожидания CheckpointerComm.

Итог и результаты анализа

Отключение индексов при массовых операциях вставки данных дает прирост операционной скорости 16-18% .

Характерными признаками наличия лишних индексов при преобладании операция вставки по таблице являются:

1. Высокое значение коэффициента корреляции с событием ожидания IO/DataFileRead , LWLock/BufferMapping и LWLock/CheckpointerComm

BufferMapping : Ожидание при связывании блока данных с буфером в пуле буферов.

CheckpointerComm : Ожидание при управлении запросами fsync.