Нагрузочное тестирование — это не просто сбор метрик, а сложный процесс их интерпретации. Традиционный анализ требует значительного времени и опыта. Проект 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)

Что стоит на почти всех китайских автомобилях, ставится на новые самолеты и даже на космические спутники? Да и почти все остальные гаджеты сейчас идут на так называемом Андроиде. Красиво начал: самолеты, спутники и другие гаджеты! И тем не менее...

Тут непонятно даже, что вы сейчас будете кричать: что самолетов у китайцев нет или Андроид им запретили. Это неважно, просто заведите свой китайский автомобиль – там видоизмененный Андроид. Как так получилось?

Надо начать с главного, что Андроид – это Линукс. Ну, не знаю, как построить это предложение, чтобы было четко понятно и не вызывало криков - врут. Давайте так, Андроид – это разновидность Линукса. А Линукс как бы и бесплатный. Т.е. следуя китайской логике…

Ну это ж невозможно, Гугл не взломаешь, без него ничего не сделаешь. Так и кто вам сказал, что надо ломать, тексты Андроида открыты и в открытом доступе. Все китайские телефоны работают на измененном Андроиде и отлично переваривают приложения для Андроида. Хотя официально всё это запрещено и закрыто.

Но китайцы пошли дальше. Они стали шерстить Андроид так, чтобы он работал только в рамках заданных задач, чтобы исключить все критические ошибки. В свои гаджеты от ТВ-приставки до самолета они поставляют разные версии с разным набором программных модулей. Правда, почти всегда можно хакнуть ядро и доустановить недостающие компоненты. Под эту тему развернулась уже целая индустрия. Хотите поставить на китайскую тачку Ютьюб или игрушку – Увелком то гараж.

Но самое занимательное не это. Их операционные системы реально хорошо работают на критически важных задачах. Само по себе управление автомобилем – это не игрушка, туда винду не поставишь, чтобы она постоянно перезагружалась при сбоях.

Корпорация GOOGLE смогла создать супернадежную ось Android, о чем почти каждый из нас знает, ну, кроме тех, кто пользуется «яблоком». Китайцы без зазрения совести берут все наработки Гугла и вставляют в свою версию Линукса, на самом деле Андроида. И ведь надежно.

Но тут не просто выигрыш в гонке программного обеспечения, здесь всё гораздо интереснее. Не только ПО, под Андроид легко менять архитектуру компьютера, добавляя ему мощи. Персональный комп по своим составным элементам не менялся уже – дайте вспомню – никогда. Под какие-то задачи он вообще не подходит. Для видеонаблюдения обязательно нужны аппаратные декодеры H.264/265. В Андроид их вставить нет проблем. А на ПК высоконагруженные задачи декодирования хаотичным образом распределены между процессорами ЦПУ и ГПУ, которые при этом еще выполняют миллион задач и так глючат, как коту Мурзику и не снилось.

А что с искусственным интеллектом? Да, на ПК он безграничный, но само это определение не синоним надежности. Нейросети в Андроиде не только аппаратные, но и прикладные. Нейрочипы уже по своей архитектуре настроены и испытаны под конкретные вычисления. Высокий уровень оптимизации позволяет получить беспрецедентную надежность - вообще не сравнить с картами nVidia. Если ПК – как пушка по воробьям, то видеоблейзер на китайском Андроиде – это прикладные нейросети для распознавания людей, машин, вещей, дронов… - всего того, что нужно пользователю в конкретном решении. 

В целом, модельки можно починить в Meshmixer, использовать их, как основу для дальнейшего улучшения, придания нужного вида.

Предисловие

В мире высоконагруженных баз данных выбор метода пагинации может стать решающим фактором для производительности системы. Эксперимент, проведённый с двумя подходами — классическим ROW_NUMBER и отложенным соединением (Deferred Join) — показал, что даже архитектурно более совершенный метод не гарантирует победы без тонкой настройки СУБД. Исследование раскрывает, как правильная конфигурация памяти PostgreSQL перевесила преимущества Deferred Join и позволила ROW_NUMBER добиться превосходства на параллельной нагрузке до 22 сессий.

Начало экспериментов с методом пагинации ROW_NUMBER

Прогноз нейросети

Вопрос

Используя информацию о размерах таблиц, схеме баз данных и тестовых запросах, дай прогноз и обоснование - какой тестовый запрос покажет большую производительность для нагрузочного тестирования с параллельной нагрузкой от 5 до 22 сессий для СУБД PostgreSQL 17 c ресурсами CPU=8 RAM=8GB

Прогноз:
Наибольшую производительность при параллельной нагрузке (5–22 сессии) покажет запрос plan-1 (ROW_NUMBER()) после оптимизации индексами.

Экспериментальная проверка

Анализ ситуации нейросетью

Почему не оправдался прогноз нейросети о большей эффективности метода ROW_NUMBER для заданных условий ?

5. Условия, при которых ROW_NUMBER() действительно был бы эффективнее:

Сценарий 2: Адекватный размер work_mem

Если бы work_mem был ≥ 256MB для сортировки в памяти

какие значение work_mem необходимо установить для получения преимущества метода row_number при максимальной нагрузке 22 параллельные сессии при общем размере RAM=8GB ?

-- Для получения преимущества ROW_NUMBER():
SET work_mem = '180MB';
SET max_parallel_workers_per_gather = 1;
SET max_parallel_workers = 16;

-- В postgresql.conf:
work_mem = 180MB
max_parallel_workers_per_gather = 1
max_parallel_workers = 16
max_worker_processes = 16
shared_buffers = 2GB
effective_cache_size = 6GB

Задача

Экспериментальная проверка рекомендации нейросети по оптимизации метода пагинации ROW_NUMBER

Изменение конфигурационных параметров СУБД

ALTER SYSTEM SET work_mem = '180MB';

ALTER SYSTEM SET max_parallel_workers_per_gather = 1;

ALTER SYSTEM SET max_parallel_workers = 16;

ALTER SYSTEM SET max_worker_processes = 16 ;

ALTER SYSTEM SET shared_buffers = '2GB';

ALTER SYSTEM effective_cache_size = '6GB';

Производительность и ожидания СУБД в ходе нагрузочного тестирования

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

Результат

Среднее превышение операционной скорости , при использовании метода ROW_NUMBER составило 12.59%

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

Результат

Среднее снижение ожиданий СУБД, при использовании метода ROW_NUMBER составило 18.06%

Характерные особенности тестовых запросов и планов выполнения

1. Общая цель запросов

Оба запроса решают задачу случайной пагинации (выбор случайной "страницы" из 100 строк) для отфильтрованных данных (билеты с бизнес-классом).

2. Основные различия в подходах

Первый запрос (ROW_NUMBER()):

• Использует оконную функцию ROW_NUMBER() для нумерации всех строк

• Фильтрует по диапазону номеров строк после нумерации

• Ключевая проблема: Выполняет полную сортировку и нумерацию всех 2.15 млн строк

Второй запрос (Deferred Join):

• Использует отложенное соединение (deferred join)

• Сначала выбирает только ticket_no с помощью OFFSET/LIMIT

• Затем соединяет остальные данные по отобранным ключам

• Преимущество: Сортирует только ключи, а не все данные

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

Первый запрос:

• Время выполнения: 12.65 секунд

• Основные затраты:
  Merge Semi Join: 9.3 секунды
  Сортировка 2.15 млн строк: 850-1000 мс (quicksort, 170 МБ памяти)
  WindowAgg (оконная функция): 1723 мс

Второй запрос:

• Время выполнения: ~16.1 секунды (неполные данные в выводе)

• Основные затраты:
  Merge Semi Join: 8.75 секунды
  Сортировка для OFFSET: 5.5 секунды (top-N heapsort, 15 МБ памяти)
  Hash Join: 5575 мс

4. Критические различия в планах

Сортировка:

1. Первый запрос: Сортирует все столбцы (ticket_no, book_ref, passenger_name) - 92 байта на строку

2. Второй запрос: Сортирует только ticket_no - 32 байта на строку

Использование памяти:

1. Первый: 170 МБ для сортировки всех данных

2. Второй: 15 МБ для сортировки только ключей

Фильтрация:

1. Первый: Сначала нумерует все строки, затем фильтрует 100

2. Второй: Сначала выбирает 100 ключей, затем соединяет данные

5. Проблемы обоих подходов

1. Общая проблема: floor(random() * COUNT(*)/100) требует полного сканирования для подсчета строк

2. Производительность OFFSET: Во втором запросе OFFSET должен "пропустить" много строк (случайная страница * 100)

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

Для оптимизации:

1. Второй подход лучше архитектурно (deferred join), но в данном случае медленнее из-за:
   Необходимости вычислять OFFSET
   Hash Join вместо более эффективного соединения

2. Потенциальные улучшения:
   Использовать keyset pagination вместо OFFSET
   Кэшировать общее количество строк
   Рассмотреть материализованные представления для filtered_tickets

В текущей реализации:

• Первый запрос быстрее (12.65с vs ~16.1с), но использует больше памяти

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

7. Вывод

Оба запроса имеют проблемы с производительностью из-за необходимости обработки всех 2.15 млн строк для случайной выборки. Deferred Join (второй подход) - более правильная архитектурная паттерн, но требует оптимизации OFFSET и соединения для повышения эффективности в данном конкретном случае.

Характерные особенности производительности СУБД

1. Производительность (SPEED)

ROW_NUMBER подход:

• Начальная производительность: 60

• Стабильная после 45 итерации: 96

• Максимум: 96 (после адаптации)

• Прирост: 60 → 96 (+60%)

Deferred Join подход:

• Начальная производительность: 52

• Стабильная после 55 итерации: 84

• Максимум: 84

• Прирост: 52 → 84 (+61.5%)

Вывод: ROW_NUMBER показывает на 14.3% выше абсолютную производительность (96 vs 84).

2. Динамика адаптации

ROW_NUMBER:

• Быстрый рост до 96 за 55 итераций

• Более резкие скачки производительности

• Ранняя стабилизация (с 55 итерации)

Deferred Join:

• Более плавный рост до 84

• Дольше адаптируется (до 55 итерации)

• Стабильнее на низких нагрузках

3. Ожидания и блокировки

ROW_NUMBER:

• TIMEOUT появляются с итерации 46 (при нагрузке 10 соединений)

• LWLOCK стабилизируются на уровне 3-6

• WAITINGS: 4-7

Deferred Join:

• IO ожидания появляются с итерации 73 (при нагрузке 15+ соединений)

• LWLOCK: 4-8 (выше, чем у ROW_NUMBER)

• WAITINGS: до 21 пикового значения

• Более выраженные скачки в ожиданиях (74 итерация: 21 ожидание)

4. Корреляция с нагрузкой

• Нагрузка растет от 5 до 22 соединений

• Критические точки:
  10 соединений (итерация 46): ROW_NUMBER начинает показывать TIMEOUT
  15 соединений (итерация 73): Deferred Join показывает IO ожидания
  18+ соединений: оба подхода стабилизируются на максимальных значениях ожиданий

5. Ключевые различия в поведении

ROW_NUMBER:

1. Выше пиковая производительность (96 vs 84)

2. Раннее появление TIMEOUT (с 10 соединений)

3. Меньше LWLOCK в среднем (3-6 vs 4-8)

4. Более предсказуемые паттерны ожиданий

Deferred Join:

1. Лучше масштабируется при низких нагрузках

2. Более стабильные WAITINGS (кроме пиков)

3. Появление IO ожиданий вместо TIMEOUT

4. Сильнее страдает от LWLOCK

6. Анализ проблемных точек

ROW_NUMBER:

• Проблема: TIMEOUT при 10+ соединениях

• Причина: WindowAgg + сортировка больших данных конкурируют за ресурсы

• Симптом: Конкуренция за CPU/память

Deferred Join:

• Проблема: IO ожидания при 15+ соединениях

• Причина: Hash Join + сортировка для OFFSET требуют disk I/O

• Симптом: Конкуренция за disk I/O и LWLOCK

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

Для ROW_NUMBER:

1. Увеличить work_mem для уменьшения disk spills

2. Рассмотреть материализованные представления для filtered_tickets

3. Кэшировать COUNT(*) для random_page

Для Deferred Join:

1. Оптимизировать индексы для сортировки ticket_no

2. Увеличить shared_buffers для кэширования hash таблиц

3. Рассмотреть использование keyset pagination вместо OFFSET

8. Общий вывод

1. ROW_NUMBER лучше для:
   Максимальной производительности (14.3% выше)
   Систем с достаточными CPU/памятью
   Сценариев с <10 конкурентных соединений

2. Deferred Join лучше для:
   Систем с ограничениями по памяти
   Сценариев с предсказуемыми IO паттернами
   Приложений, чувствительных к TIMEOUT

3. Оба подхода требуют оптимизации при >10 конкурентных соединений

4. Критическая нагрузка: 10-15 соединений (точка деградации производительности)

Метрики производительности инфраструктуры

1. Использование CPU

ROW_NUMBER:

• Начало: 61% user, 3% system, 36% idle

• Критическая точка (итерация 50): резкий переход на 95-96% user, 4% system, 0% idle

• Стабильная нагрузка: 96% user, 4% system, 0% idle

• Вывод: Полная загрузка CPU с преобладанием пользовательского времени

Deferred Join:

• Начало: 61% user, 2% system, 36% idle

• Критическая точка (итерация 52): переход на 97% user, 3% system, 0% idle

• Стабильная нагрузка: 97% user, 3% system, 0% idle

• Вывод: Аналогичная полная загрузка, но меньше системного времени

Сравнение: Deferred Join показывает на 1% выше user CPU и на 1% ниже system CPU.

2. Использование памяти

ROW_NUMBER:

• Свободная память: 1791 → 2753 KB (+53% рост)

• Буферы: 47 → 6 KB (-87% снижение)

• Кэш: 4955 → 2751 KB (-44% снижение)

• Своп: 70 → 67 KB (минимальное изменение)

• Вывод: Активное использование кэша и буферов

Deferred Join:

• Свободная память: 4567 → 2207 KB (-51% снижение)

• Буферы: 18 → 6 KB (-67% снижение)

• Кэш: 2211 → 2728 KB (+23% рост)

• Своп: 69 → 73 KB (незначительный рост)

• Вывод: Увеличение использования кэша, снижение свободной памяти

Сравнение: ROW_NUMBER активнее использует кэш в начале, Deferred Join наращивает кэш в процессе.

3. Ввод-вывод (IO)

ROW_NUMBER:

• io_bo: 52 → 58 (+11.5% рост)

• Пиковые значения: до 59

• Вывод: Умеренный рост IO при увеличении нагрузки

Deferred Join:

• io_bo: 59 → 65 (+10% рост)

• Пиковые значения: до 68

• Вывод: Более высокий базовый уровень IO

Сравнение: Deferred Join имеет на 10-15% выше активность IO, что соответствует ожиданиям из предыдущего анализа (IO ожидания).

4. Системные метрики

ROW_NUMBER:

• Прерывания (system_in): 5687 → 8279 (+45% рост)

• Переключения контекста (system_cs): 657 → 1053 (+60% рост)

• Процессы в run queue (procs_r): 6 → 15 (+150% рост)

Deferred Join:

• Прерывания (system_in): 5652 → 8274 (+46% рост)

• Переключения контекста (system_cs): 652 → 1063 (+63% рост)

• Процессы в run queue (procs_r): 5 → 15 (+200% рост)

Сравнение: Оба подхода показывают схожий рост системных метрик, Deferred Join имеет немного больше переключений контекста.

5. Критические точки перехода

ROW_NUMBER:

• Итерация 50 (нагрузка 10): переход на 0% idle CPU

• Сопровождается: Ростом procs_r до 9

• Симптом: Резкое изменение паттерна использования памяти

Deferred Join:

• Итерация 52 (нагрузка 10): переход на 0% idle CPU

• Сопровождается: Ростом procs_r до 9

• Симптом: Снижение свободной памяти до 4000 KB

6. Корреляция с нагрузкой

• 5-8 соединений: Оба подхода работают с простоями CPU (36% idle)

• 10 соединений: Критическая точка (0% idle)

• 12-15 соединений: Стабилизация на максимальной нагрузке

• 18-22 соединений: Дальнейший рост системных метрик

7. Ключевые различия по метрикам

ROW_NUMBER преимущества:

1. Меньше IO операций (58 vs 68)

2. Лучшее использование памяти (растущая свободная память)

3. Более стабильный кэш (меньше колебаний)

Deferred Join преимущества:

1. Меньше системного времени CPU (3% vs 4%)

2. Более предсказуемое использование кэша (постепенный рост)

3. Меньше начальных буферов (более эффективное использование)

8. Проблемные паттерны

ROW_NUMBER:

• Проблема: Резкое падение кэша с 4955 до 2751

• Причина: Оконные функции требуют больших рабочих наборов

• Риск: Потенциальные page faults при недостатке памяти

Deferred Join:

• Проблема: Высокий базовый уровень IO (59 vs 52)

• Причина: Hash Join и сортировка для OFFSET

• Риск: Disk I/O bottlenecks при высокой нагрузке

9. Общие выводы по метрикам

1. Оба подхода CPU-bound: 0% idle при нагрузке ≥10 соединений

2. Deferred Join более IO-intensive: на 10-15% выше IO активность

3. ROW_NUMBER более memory-intensive: активнее использует кэш и буферы

4. Критическая нагрузка: 10 соединений для обоих подходов

5. Масштабирование: Deferred Join лучше сохраняет кэш, но требует больше IO

10. Рекомендации по оптимизации системы

Для ROW_NUMBER:

1. Увеличить work_mem для сортировки в памяти

2. Настроить shared_buffers для кэширования рабочих наборов

3. Мониторить page faults и swap активность

Для Deferred Join:

1. Оптимизировать индексы для уменьшения IO

2. Рассмотреть SSD для уменьшения latency IO операций

3. Настроить effective_io_concurrency для параллельного IO

Итог:

Выбор между подходами зависит от конфигурации системы -

• ROW_NUMBER для CPU-обеспеченных архитектур

• Deferred Join для систем с хорошим IO.