Оптимальная настройка PostgreSQL на i7-13700 под Windows OLTP

Оптимальная конфигурация для OLTP на Intel i7‑13700 под Windows Server 2019 — вариант 2: отключить E‑ядра и оставить Hyper‑Threading на P‑ядрах. Такая настройка PostgreSQL на Windows и оптимизация PostgreSQL снижает задержки однопоточных бэкендов, уменьшает джиттер планировщика и в реальных тестах часто даёт рост TPS и улучшение p99‑латентности (порядка 10–25% в сообщениях сообщества и практических экспериментах).

---

Содержание

• Резюме: оптимизация PostgreSQL на i7-13700
• Почему P‑ядра важны для OLTP (настройка PostgreSQL)
• Практическая настройка: BIOS, Windows и affinity
• Рекомендации по postgresql.conf и Windows tuning
• Тестирование и валидация конфигурации
• Ограничения и компромиссы
• Источники
• Заключение

---

Резюме: оптимизация PostgreSQL на i7-13700

Коротко: выбираем вариант 2 — отключаем E‑ядра, включаем Hyper‑Threading только на P‑ядрах, привязываем PostgreSQL к P‑ядрам и тонко настраиваем postgresql.conf под P‑ядра. Intel и сообщество отмечают, что в гибридной архитектуре P‑ядра лучше подходят для latency‑sensitive задач, а E‑ядра — для фоновой нагрузки; для OLTP это означает меньшую задержку и более предсказуемое поведение при массовых коротких транзакциях Managing Performance with Heterogeneous Cores, Our Future with Hierarchical Heterogeneous Computing, а также наблюдения администраторов БД на Windows-серверах Server Fault: PostgreSQL on Windows.

---

Почему P-ядра важны для OLTP (настройка PostgreSQL)

PostgreSQL при обработке клиентских соединений обычно использует отдельный процесс (backend) на соединение; многие OLTP‑операции короткие и ограничены одним потоком исполнения. Проще говоря: single‑thread latency matters — скорость одного потока часто важнее количества «лёгких» ядер. Это объясняет, почему P‑ядра с высокой IPC и высокой частотой выигрывают для OLTP‑нагрузок: они дают более быструю обработку отдельных транзакций и меньше задержек при переключениях контекста Can a single PostgreSQL query use multiple cores?, PostgreSQL uses only one core.

E‑ядра хороши для фоновой работы и плотной параллельной загрузки, но у них ниже IPC и они могут вызвать задержки, если планировщик Windows переместит latency‑sensitive PostgreSQL‑бэкенд на E‑ядро. Поэтому для OLTP целесообразно минимизировать влияние E‑ядер на бэкенды и оставлять P‑ядра для транзакций, а E‑ядра — для фоновых задач ОС и вспомогательных процессов (если их оставлять включёнными).

---

Практическая настройка: BIOS, Windows и affinity

Ниже — пошаговый план действий и рекомендации с практическими примерами.

1. Стратегия по умолчанию — отключить E‑ядра в BIOS, если это возможно

• Отключение на уровне BIOS даёт самый стабильный результат: ОС и планировщик не видят E‑ядра и всё работает на P‑ядрах/HT. Это избавляет от риска миграций потоков между «типами» ядер и даёт предсказуемую производительность (часто самый большой выигрыш по TPS/латентности) Intel docs.
• Если BIOS не даёт гибкого переключения — переходите к программным методам (ниже).

2. Если отключить E‑ядра нельзя — жёстко привяжите PostgreSQL к P‑ядрам (CPU affinity)

• Для теста или временного запуска можно стартовать сервер вручную с маской процессора:
  start /affinity <mask> C:\path\to\postgres\bin\postgres.exe -D "C:\PGDATA" — пример использования под Windows, где — битовая маска логических процессоров (пример из практики администраторов) StackOverflow пример.
• Для сервисного запуска используйте обёртку/скрипт, который выставляет affinity до старта службы, либо инструменты управления процессами (PowerShell Start‑Process + ProcessorAffinity) Hatena blog об affinity.
• Учтите: номера логических процессоров (ID) зависят от BIOS/Windows‑карты топологии — проверьте соответствие P‑ядер/HT‑нитей с помощью системных утилит и Task Manager, прежде чем задавать маску.

3. Hyper‑Threading — включён на P‑ядрах (обычно оставить)

• HT на P‑ядрах даёт полезную прибавку при большом числе конкурентных подключений (много бэкендов), поэтому рекомендуют оставлять HT включённым для P‑ядер в OLTP‑сценариях; при малом числе подключений можно экспериментировать с отключением HT, но это чаще снижает пропускную способность при высокой конкуренции Intel community наблюдения.

4. Резерв для ОС и фоновых задач

• Оставьте 1 логический поток (или 1–2 P‑ядра/логических треда) для системы/мониторинга/backup‑задач — это упрощает стабильность и уменьшает конкуренцию за ресурсы ServerFault рекомендации.

5. Windows: power‑plan и энергосбережение

• Включите «High Performance» / отключите энергосбережение и C‑state агрессивности (если можно), чтобы CPU держал частоты и не переключался в глубокие режимы, которые повышают латентность. 1C‑рекомендации также указывают отключать энергосбережение для OLTP‑нагрузок на Windows 1C методика.

6. Инструменты: если BIOS нет — CoreDirector / Process Lasso / сторонние утилиты

• Существуют утилиты, которые помогают вынудительно исключить E‑ядра для конкретных приложений (пример — CoreDirector) — они полезны, если нет доступа к BIOS или нужен гибкий контроль Overclockers CoreDirector.

---

Рекомендации по postgresql.conf и Windows tuning

Ниже — практические значения и настройки, ориентированные на OLTP (CRM: обновления цен, импорты). Значения — отправная точка; тестируйте и корректируйте под реальную RAM/IO.

• max_parallel_workers = 8

• Соответствует числу P‑ядер; даёт запас для параллельных операций в PostgreSQL, но контролируйте общее число активных рабочих потоков, чтобы не перегружать CPU. (совпадает с рекомендациями по сопоставлению параллельных воркеров и P‑ядер) Sematext / community рекомендации.

• max_parallel_workers_per_gather = 1–2

• По умолчанию оставьте 1–2, чтобы избежать чрезмерного параллелизма в коротких транзакциях OLTP.

• max_connections = 100–200 (или меньше) + использовать пул соединений (pgbouncer)

• На i7‑13700 для CRM целесообразно ограничить число «тяжёлых» бэкендов и проксировать мелкие подключения через пул, чтобы не расходовать память и ядра избыточно mydbops рекомендации.

• shared_buffers = ~25% RAM (для выделенного сервера) — тестируйте под Windows

• Общая рекомендация PostgreSQL; на Windows стоит тестировать диапазон и не задавать чрезмерно большие значения без проверки (см. EnterpriseDB и Sematext) EnterpriseDB tuning.

• effective_cache_size = 50–75% RAM

• Оценка доступной файловой системы/ОС‑кеша для планировщика запросов.

• work_mem = 4–16MB (в зависимости от вида операций и числа одновременных соединений)

• Для OLTP лучше меньшие значения; большие work_mem увеличивают память на каждый сорт/hash.

• maintenance_work_mem = 512MB–2GB

• Для VACUUM/REINDEX/maintenance‑операций.

• autovacuum tuning: уменьшите thresholds/aggressiveness при большом числе обновлений/импортов, чтобы не накапливались bloat и дедлоки. Следите за autovacuum‑латентностью.

• wal_buffers, checkpoint_completion_target, synchronous_commit

• Для CRM обычно оставляют synchronous_commit = on (безопасность), но можно тестировать asynchronous режимы для не‑критичных операций. Настройте checkpoint‑параметры под быстрые NVMe‑диски, если они используются.

Windows‑уровень:

• Установите High Performance power plan и отключите энергосбережение/processor parking.
• Следите за Pagefile/IO: быстрые NVMe/RAID дают заметный выигрыш для OLTP; убедитесь, что драйверы дисков оптимизированы.
• Используйте инструменты мониторинга (PerfMon + pg_stat_statements/pgbench) для измерения p50/p95/p99.

Ссылки для подробных гайдов по параметрам: Sematext tuning, EnterpriseDB tutorial.

---

Тестирование и валидация конфигурации

Как понять, что выбранный вариант лучше? Проведите контролируемые A/B тесты:

1. Набор тестов: pgbench (TPCC‑style), реальные фрагменты импортов/обновлений, нагрузочные скрипты из CRM. Можно использовать примеры OLTP‑бенчмарков как ориентир AlloyDB OLTP benchmark guide.

2. Сценарии:

• A: стоковая (все ядра активны, HT включён)
• B: E‑ядра отключены, HT на P‑ядрах включён (рекомендуемая конфигурация)
• C: HT отключён на P‑ядрах, E‑ядра включены

3. Метрики:

• TPS (transactions/sec), p50/p95/p99 latency на ключевых сценариях, CPU utilization по ядрам, context‑switch rate, IO latency, wait events в PostgreSQL (pg_stat_activity, pg_stat_statements).

4. Продолжительность: прогоните тесты достаточно долго (несколько минут — для стресс‑замеров; часы — для реальной нагрузки с автovacuum и фоновой активностью), чтобы увидеть поведение фоновых процессов.

5. Интерпретация:

• Для OLTP ожидаемая закономерность: B > A по p99/латентности и TPS в большинстве реальных сценариев. Если же C даёт лучший результат — это сигнал, что у вас крайне специфичная нагрузка (малое число соединений или сильно параллельные операции), и нужен другой подход.

---

Ограничения и компромиссы

• Отключение E‑ядер уменьшает общую «пассивную» вычислительную ёмкость системы для фоновых задач и может повысить энергопотребление и тепловыделение в пиковые моменты.
• Жёсткое выставление affinity — хрупкая операция: обновления BIOS/драйверов и патчи Windows могут менять нумерацию/поведение, поэтому автоматизация и документация обязательны.
• Для смешанных нагрузок (OLTP + серьёзный OLAP/аналитика на том же сервере) E‑ядра и HT могут оказаться полезными; в таких случаях лучше держать аналитические задачи на репликах или отделять узлы по профилю. См. рекомендации по разграничению OLTP/OLAP и репликации Tinybird / OLAP guidance.

---

Источники

• Managing Performance with Heterogeneous Cores (Intel)
• Our Future with Hierarchical Heterogeneous Computing (Intel community)
• Is PostgreSQL suited to one OS? Is it better on Linux than Windows? (Server Fault)
• Is there a way to set CPU affinity for PostgreSQL processes through its configuration files? (StackOverflow)
• PostgreSQL Performance Tuning and Optimization Guide (Sematext)
• PostgreSQL Performance Tuning: Ultimate Guide (EnterpriseDB)
• PostgreSQL Parameter Tuning Best Practices 2025 (MyDBOps)
• CoreDirector помогает деактивировать E‑ядра (Overclockers)
• Can a single PostgreSQL query use multiple cores? (DBA StackExchange)
• Benchmark OLTP performance on AlloyDB for PostgreSQL (Google Cloud)
• Affinity mask / Server configuration options (Microsoft Learn)

---

Заключение

Итог: для OLTP‑нагрузки CRM на Intel i7‑13700 под Windows Server 2019 оптимален вариант 2 — отключить E‑ядра и оставить Hyper‑Threading на P‑ядрах, привязать PostgreSQL к P‑ядрам и выполнить целенаправленную настройку postgresql.conf (включая max_parallel_workers ≈ 8, разумные значения shared_buffers/effective_cache_size и контроль max_connections через пул). Проведите A/B тесты (сток vs E‑off vs HT‑off) с pgbench/реальными сценариями, фиксируйте TPS и p99‑латентность и применяйте изменения по результатам тестов: это даст реальную оптимизацию PostgreSQL под вашу систему.