Сервер для PostgreSQL: почему тормозят диски, а не процессор — 35 новых в наличии

14 октября 2026 г.

Сервер для PostgreSQL под OLTP чаще упирается в диски, а не в процессор: каждая фиксация транзакции ждёт, пока запись журнала WAL дойдёт до накопителя, а всё, что не поместилось в память, читается с него же. Поэтому подбор начинают с класса NVMe и ресурса записи, затем считают память под кэш, и только потом ядра. На складе под это три сборки новых серверов: Dell R760 с NVMe Mixed Use под тяжёлую запись, Dell R760 с восемью NVMe-отсеками под рост и HPE DL380 Gen11 под кластер с репликами.

✅ В наличии — отгрузка в день оплаты

• Dell PowerEdge R760 12LFF, позиция C — 4 шт. 2× Dell 6,4 ТБ NVMe Mixed Use U.2 + 2× 3,84 ТБ NVMe, 4× 12 ТБ SAS, 1,5 ТБ DDR5, 2× Xeon Gold 6548Y+ (64 ядра).
• Dell PowerEdge R760 24SFF, позиция E — 10 шт. 8 NVMe-отсеков, из них заняты два (2× 6,4 ТБ NVMe), 1,5 ТБ DDR5, 2× Xeon Gold 6544Y (32 ядра, 3,6 ГГц).
• HPE ProLiant DL380 Gen11 8SFF, позиция F — 21 шт. 2× 7,68 ТБ NVMe Read Intensive U.3, 1,5 ТБ DDR5, 2× Xeon Gold 6542Y (48 ядер).

Все серверы новые. У всех трёх сборок — 1,5 ТБ DDR5 (24 модуля по 64 ГБ), 2×100GbE и FC 32G.

Почему сервер для PostgreSQL упирается в диски?

PostgreSQL обслуживает каждое подключение отдельным процессом, и обычный OLTP-запрос — найти строку по индексу, обновить, зафиксировать — нагружает одно ядро ненадолго. Пока данные лежат в памяти, процессор успевает. Время ответа растёт из-за трёх вещей, и все три связаны с накопителями.

1. Фиксация транзакции. При настройке по умолчанию (synchronous_commit = on) COMMIT возвращается клиенту только после того, как запись WAL сброшена на диск. Задержка записи накопителя входит во время каждой транзакции.
2. Чтение мимо кэша. Всё, чего нет в shared_buffers и страничном кэше ОС, читается случайными блоками по 8 КБ. На HDD это медленно, поэтому основную базу OLTP держат на флеше.
3. Фоновая запись. Контрольные точки сбрасывают изменённые страницы, autovacuum переписывает таблицы и индексы. После контрольной точки первое изменение страницы пишет её в WAL целиком (full_page_writes). На диск уходит заметно больше данных, чем «полезных» изменений.

Процессор становится узким местом на аналитике, сложных соединениях, параллельных запросах и при сотнях одновременно активных сессий. Когда сервер для PostgreSQL обслуживает типичную OLTP-базу, которая почти целиком живёт в памяти, вопрос в другом: как быстро диск подтверждает запись и сколько лет он выдержит этот поток.

Как 1,5 ТБ памяти меняют нагрузку на диски

Распространённая стартовая точка — shared_buffers около четверти ОЗУ, effective_cache_size — остаток памяти. Так же советует 1С в своих рекомендациях по PostgreSQL. На 1,5 ТБ это порядка 384 ГБ буферов плюс страничный кэш ОС. Если рабочий набор базы помещается в память, чтений с дисков почти не остаётся, и на первый план выходит запись. Отсюда главный вывод статьи: при большой памяти ресурс записи NVMe важнее объёма.

Read Intensive или Mixed Use: как посчитать нужный DWPD?

DWPD — сколько раз в сутки накопитель можно полностью перезаписывать в течение пяти лет. Так этот показатель определяет HPE в своей документации. Производители делят серверные NVMe на классы по ресурсу:

• Read Intensive (RI) — для нагрузок с преобладанием чтения. У текущего поколения серверных NVMe это обычно около 1 DWPD.
• Mixed Use (MU) — для смешанной нагрузки с интенсивной записью. Обычно около 3 DWPD. Это не закон: у прежних Dell Express Flash NVMe Mixed Use было 5 DWPD.

Для конкретного диска DWPD берут из документации модели, а не из названия класса. В спецификации наших сборок ресурс в DWPD не указан — по номеру модели сверим его под ваш запрос. Подсказкой служит и ёмкость. При одном форм-факторе MU-диск обычно меньше RI — 6,4 ТБ против 7,68 ТБ. Типичная логика производителей: часть флеш-памяти отводится под резерв, который продлевает ресурс записи.

Пример расчёта (цифры условные)

1. Снимите суточный объём записи на диск. Источник — счётчики ОС (iostat, /proc/diskstats) за типичную неделю. Учитывайте всю запись: WAL, данные, индексы, vacuum, временные файлы.
2. Не делите на два в зеркале. В RAID 1 каждый диск получает полный объём записи.
3. Разделите на ёмкость. 2 ТБ записи в сутки на диск 6,4 ТБ — около 0,3 DWPD, на диск 7,68 ТБ — около 0,26 DWPD.
4. Добавьте запас. Закрытие периода, массовые загрузки, перестроение индексов и рост базы дают пики выше среднего.

Если расчёт выходит к 1 DWPD и выше, RI-класс работает на пределе, и нужен Mixed Use.

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

Тяжёлая запись: Dell R760 с NVMe Mixed Use (C)

• 2× Dell 6,4 ТБ NVMe Mixed Use U.2 — зеркало под основной кластер и WAL.
• 2× 3,84 ТБ NVMe — второй том: временные файлы, отдельное табличное пространство или второй экземпляр СУБД.
• 4× 12 ТБ SAS HDD на PERC H755 (кэш 8 ГБ, RAID 1/5/6/10) — архив WAL и локальные копии. Основная резервная копия должна жить на другом сервере.
• ОС — на BOSS-N1, 2× 960 ГБ M.2 в аппаратном RAID 1.
• 2× Xeon Gold 6548Y+, 64 ядра, 2,5 / 4,1 ГГц — запас под параллельные запросы, отчёты и большое число соединений через пул.

Все четыре NVMe-отсека в C уже заняты. Сборку берут, когда объём базы на ближайшие годы понятен заранее.

Рост базы и лицензии по ядрам: Dell R760 24SFF (E)

• 8 NVMe-отсеков, заняты два (2× 6,4 ТБ NVMe), шесть свободны. Класс ресурса установленных дисков уточним по номеру модели под ваш профиль записи.
• 2× Xeon Gold 6544Y, 32 ядра, 3,6 ГГц базовая: одиночный запрос выполняется быстрее, а лицензий меньше, если СУБД лицензируется по ядрам — так в основной модели у Postgres Pro.
• 2× 480 ГБ SATA SSD на PERC H965i, ОС — на BOSS-N1.
• 4×10/25GbE SFP28 и 2×100GbE — под потоковую репликацию на соседний узел. Трансиверы для 25/100GbE в спецификации не указаны.

Чтение, реплики и кластер: HPE DL380 Gen11 (F)

• 2× 7,68 ТБ NVMe Read Intensive U.3 — для баз, где чтение доминирует: витрины, отчётные реплики, справочники, API на чтение.
• 2× Xeon Gold 6542Y, 48 ядер, 2,9 / 4,1 ГГц.
• MR408i-o — tri-mode контроллер в слоте OCP с кэшем 4 ГБ, поддерживает RAID и режим HBA (HPE DL380 Gen11 QuickSpecs). Схему подключения NVMe в конкретном узле уточним по вашему запросу.
• 21 одинаковый узел — лидер, реплики и запасной сервер под Patroni или аналогичный менеджер кластера на одной платформе.

Опишите в письме на gpu@vistlan.ru объём базы, суточную запись и число соединений — поможем выбрать между C, E и F и сразу выставим счёт.

Как защитить базу, если NVMe без аппаратного RAID?

В Dell R760 позиций C и E NVMe подключены напрямую. По Technical Guide к R760 универсальная корзина не делает аппаратный RAID для NVMe, а смешивать NVMe с SAS/SATA за одним контроллером PowerEdge не позволяет. PERC в этих серверах работает с SAS/SATA. На HPE F стоит tri-mode MR408i-o: если NVMe идут через него, зеркало можно собрать и на контроллере. Для СУБД в этом есть плюс: между PostgreSQL и флешем нет лишнего слоя и нет кэша контроллера с батареей, за которым нужно следить.

Защиту строят на трёх уровнях:

• Программное зеркало. mdadm RAID 1 или RAID 10 в Linux либо зеркало LVM. Отказ одного NVMe не останавливает базу.
• Репликация СУБД. Потоковая репликация на второй сервер: синхронная, если потерять подтверждённую транзакцию нельзя, асинхронная — если важнее задержка записи. Менеджер кластера переключает лидера автоматически.
• Резервное копирование. Ни зеркало, ни реплика его не заменяют: ошибочный DELETE мгновенно уходит на реплику. Нужны полная копия и архив WAL для восстановления на момент времени.

И мониторинг. NVMe сообщают долю израсходованного ресурса — поле Percentage Used в SMART (nvme smart-log). Это прямая проверка вашего расчёта DWPD: если показатель растёт быстрее плана, профиль записи оценён неверно.

Частые вопросы

Какой процессор нужен для PostgreSQL?

Для OLTP важнее частота и задержка одного ядра, для аналитики и параллельных запросов — число ядер. На складе есть оба полюса: 2× Gold 6544Y (32 ядра, 3,6 ГГц базовая) и 2× Gold 6548Y+ (64 ядра, 2,5 ГГц). Середина — 2× Gold 6542Y, 48 ядер на 2,9 ГГц.

Сколько оперативной памяти нужно PostgreSQL?

Столько, чтобы рабочий набор — часто используемые таблицы и индексы — помещался в shared_buffers и кэш ОС. Начинают с четверти ОЗУ под shared_buffers и дальше смотрят на долю попаданий в кэш в pg_stat_database (blks_hit против blks_read). 1,5 ТБ позволяют держать в памяти горячую часть крупной базы.

Подойдёт ли NVMe Read Intensive под базу данных?

Да, если запись умеренная. Посчитайте суточный объём записи на диск и сравните с DWPD из документации модели. Для базы с интенсивной записью, массовыми загрузками и частым перестроением индексов берите Mixed Use.

Можно ли держать PostgreSQL на HDD?

Основную базу OLTP — не стоит: случайное чтение и подтверждение записи на HDD медленные. Жёсткие диски уместны под архив WAL и резервные копии. Для этого в позиции C есть 4× 12 ТБ SAS.

Чем этот выбор отличается от сервера для 1С?

В 1С на первом месте частота ядра и лицензирование самой платформы, СУБД — одна из частей системы. Сервер для PostgreSQL подбирают под любую нагрузку на PostgreSQL или Postgres Pro, и главный вопрос там — профиль записи. Если база обслуживает 1С, учитывайте оба набора требований.

Как купить

Пишите запрос на почту gpu@vistlan.ru — оперативно ответим, выставим счёт, заключим договор. Полный комплект документов, официальная поставка, отгрузка в день оплаты.

В письме укажите объём базы, суточную запись, нужна ли реплика, количество серверов и реквизиты компании.

Читайте также:

• Сервер для 1С на 100+ пользователей: готовая конфигурация со склада
• Кластер Proxmox + Ceph из трёх серверов со склада: 100GbE и NVMe
• Сервер резервного копирования на 12 дисков: 64 ТБ сырых сразу и 8 свободных отсеков

Материал подготовлен отделом серверных решений VISTLAN. Обновлено 14.10.2026.