Сервер для PostgreSQL
Подбор платформы под профиль нагрузки: объём данных, число подключений, доля чтений и записей, задержки и резервное копирование. Ниже — методика, рабочий пример расчёта памяти и типовые конфигурации для интеграторов и заказчиков.
- Нехватка RAM под кэш и рабочие процессы — диск читает то, что могло бы остаться в памяти.
- WAL на медленных дисках или нет разделения WAL и данных — растёт задержка commit.
- Слабый CPU при высокой конкуренции за блокировки и сложных аналитических запросах.
- Нет быстрого и проверенного резервного копирования под требуемые RPO/RTO.
- Не заложен запас «на вырост» — через год сервер упирается в потолок по памяти или дискам.
Сначала определяем профиль нагрузки
OLTP
Много коротких транзакций, высокая конкуренция, важны низкая задержка WAL и быстрые случайные операции. Акцент — CPU с высокой частотой, память, NVMe под WAL.
OLAP / аналитика
Сложные запросы по большим объёмам, агрегации и последовательное чтение. Акцент — число ядер, объём памяти и пропускная способность дисков.
Смешанная
Транзакции и отчётность вместе, часто несколько баз на одном сервере. Нужен баланс CPU, памяти и изолированной дисковой подсистемы.
Как компоненты влияют на PostgreSQL
| Компонент | На что влияет | Рекомендация |
|---|---|---|
| Память | shared_buffers, кэш ОС, рабочие процессы, сортировки | RAM под горячие данные — ключевой фактор |
| CPU | Параллельные планы, конкуренция, сложные запросы | OLTP — выше частота; OLAP — больше ядер |
| Диски данных | Случайные и последовательные операции | NVMe SSD; разделять данные и WAL |
| Диски WAL | Задержка фиксации (fsync) | Отдельный быстрый NVMe с гарантированной записью |
| Сеть | Репликация, бэкапы, приложения | 10/25 Гбит/с при реплике и сетевых бэкапах |
| Резервирование | RPO/RTO, восстановление после сбоя | Реплика + PITR на отдельное хранилище |
Пример расчёта: память и диски под OLTP-базу
База размером 500 ГБ, около 1 000 активных подключений в пике, нагрузка преимущественно OLTP, горячая (часто читаемая) часть — примерно 20% данных. Считаем память, затем диски.
shared_buffers ≈ 25% = 64 ГБ
кэш ОС ≈ 50% = 128 ГБ (сюда помещаются горячие ~100 ГБ)
остальное — под соединения, сортировки, техпроцессы
Правило «shared_buffers = 25% RAM» — практическая отправная точка на Linux; остальную память оставляют Page Cache ОС. Если горячая часть не помещается в кэш, RAM увеличивают.
Тысячи прямых подключений держать неэффективно: перед PostgreSQL ставят пул (PgBouncer) в transaction-режиме, тогда реальное число рабочих процессов снижается до десятков.
- Данные — массив NVMe/SAS SSD с избыточностью (RAID10 или эквивалент), 4–8 дисков под 500 ГБ и рост.
- WAL — отдельный зеркальный NVMe-том с низкой записью-задержкой; не смешивать с данными.
- Сеть — 10/25 Гбит/с под streaming-реплику и PITR-бэкапы на внешнюю СХД.
Для OLAP логика другая: упор на число ядер для parallel query и суммарную пропускную способность NVMe, а объём RAM считают под рабочие наборы и hash-агрегации.
Три типовых уровня решения
- 2U, 2 × Xeon
- 128–256 ГБ DDR5
- NVMe данные + отдельный WAL
- Бизнес-приложения, учётные системы
- 2U, 2 × Xeon, высокая частота/ядра
- 256–512 ГБ DDR5
- All-flash, реплика + PITR
- Несколько баз, аналитические запросы
- Многоядерные 2U/4U
- 512 ГБ – 1–2 ТБ RAM
- Высокая пропускная способность NVMe
- Возможно расширение на внешнюю СХД
Готовые конфигурации
Как мы подбираем сервер
Поставка для B2B
Работаем с системными интеграторами, участниками тендеров и разработчиками ПАК. Договор, экспортные документы, безналичный расчёт и доставка в РФ и страны СНГ. Гарантия на новые серверы — до 3 лет по договору с Beijing Xinchuan Technology Co., Ltd.
Частые вопросы
Сколько памяти нужно для PostgreSQL?
Отправная точка на Linux — shared_buffers около 25% RAM, ещё примерно половину памяти оставляют под Page Cache ОС, в который должны помещаться горячие данные. Для базы 500 ГБ с горячей частью ~20% обычно достаточно 256 ГБ; если горячие данные не помещаются в кэш, память увеличивают.
Зачем WAL выносить на отдельный NVMe?
Фиксация транзакции требует записи WAL и fsync; если WAL делит диски с данными, к задержке добавляется конкуренция ввода-вывода. Отдельный быстрый NVMe снижает задержку commit и делает поведение базы предсказуемым под нагрузкой.
Нужен ли PgBouncer?
При сотнях и тысячах подключений — да. Пул в transaction-режиме снижает число реальных рабочих процессов и экономит память; само приложение при этом видит привычное число соединений.
Как обеспечить отказоустойчивость?
Streaming-реплика на standby-сервер плюс настроенный и регулярно проверяемый PITR на отдельное хранилище. Реплика закрывает отказ узла, PITR — логические ошибки и порчу данных, когда нужен возврат к моменту времени.
Что выбрать под OLAP?
Больше ядер для параллельных планов, объём RAM под рабочие наборы и NVMe с высокой суммарной пропускной способностью. При больших объёмах данных рассматривают внешнюю СХД или шардирование.
Какая гарантия на сервер?
На новые серверы — до 3 лет по договору с Beijing Xinchuan Technology Co., Ltd.; конфигурацию RAID, NVMe и адаптеров фиксируем в спецификации.