Сервер баз данных под PostgreSQL и MS SQL: как выбрать процессор, память и диски

Сервер баз данных — сердце учётных систем: 1С, ERP, CRM и складские программы упираются в скорость СУБД. При этом требования к «железу» у базы данных другие, чем у файлового или терминального сервера. Разберём, как подобрать сервер для PostgreSQL и MS SQL: какой процессор, сколько памяти и какие диски действительно влияют на производительность.

Что ограничивает производительность СУБД

Узкие места сервера баз данных, в порядке частоты появления:

1. Дисковая подсистема — задержки при записи журнала транзакций и случайном чтении.
2. Оперативная память — если рабочий набор данных не помещается в кэш, СУБД постоянно читает с дисков.
3. Процессор — частота ядра влияет на скорость отдельных запросов, количество ядер — на число параллельных операций.
4. Сеть — актуальна при раздельных серверах приложений и баз данных.

Процессор

Для OLTP-нагрузки (1С, учётные системы, множество коротких транзакций) важна высокая частота ядра: каждый запрос выполняется преимущественно в одном потоке. Выбирайте процессоры с базовой частотой от 3 ГГц. Для аналитики, отчётности и хранилищ данных (OLAP) полезнее больше ядер: тяжёлые запросы распараллеливаются.

Учитывайте лицензирование. MS SQL Server лицензируется по ядрам, поэтому лишние ядра стоят дорого — выгоднее меньше быстрых ядер. PostgreSQL, включая российские сборки Postgres Pro, не привязывает стоимость к числу ядер в базовых редакциях, поэтому для него оправданы многоядерные конфигурации.

Оперативная память

Правило: объём ОЗУ должен вмещать «горячие» данные — таблицы и индексы, к которым обращаются постоянно. Практические ориентиры:

• база до 50 ГБ — 32–64 ГБ ОЗУ;
• база 50–200 ГБ — 128–256 ГБ ОЗУ;
• база от 200 ГБ — 256–512 ГБ и более, исходя из рабочего набора.

В PostgreSQL под shared_buffers обычно отводят около 25% ОЗУ, остальное использует файловый кэш ОС. MS SQL по умолчанию занимает всю доступную память, поэтому параметр max server memory нужно ограничить, оставив ресурсы системе. Используйте только память с ECC — ошибка в памяти сервера БД может испортить данные.

Диски: главное — задержки

Для СУБД важны не мегабайты в секунду, а количество операций ввода-вывода (IOPS) и задержка записи. Рекомендации:

• Только SSD, предпочтительно NVMe класса enterprise с защитой от потери питания (PLP) — без неё SSD при сбое питания может потерять подтверждённую запись.
• Обращайте внимание на ресурс записи (DWPD): для активных баз — от 1 DWPD, для высоконагруженных — 3 DWPD.
• Разделяйте нагрузку: отдельный массив под журнал транзакций (WAL / transaction log), отдельный — под данные, отдельный — под tempdb (MS SQL) и резервные копии.
• Уровень RAID — RAID 10. RAID 5/6 замедляет запись и для рабочих баз не рекомендуется. Подробнее — в статье о выборе уровня RAID.

Типовые конфигурации

Отказоустойчивость

Для критичных систем одного сервера недостаточно. Используйте репликацию (потоковая репликация PostgreSQL, Always On в MS SQL) на второй сервер, два блока питания, резервирование сетевых подключений и регулярное резервное копирование с проверкой восстановления.

Российские СУБД

При переходе на отечественное ПО чаще всего выбирают Postgres Pro или другие сборки на базе PostgreSQL — платформа 1С с ними работает штатно. Требования к оборудованию такие же, как у PostgreSQL. Для полного импортозамещения сервер под СУБД можно подобрать из российских моделей, включённых в реестр Минпромторга.

Подбор сервера

Готовые серверы баз данных в каталоге SK Server разделены по классам — 2 CPU и 4–8 CPU. Для 1С есть отдельный раздел серверов для 1С. Пришлите размер базы, число пользователей и используемую СУБД — инженеры подберут конфигурацию с запасом на рост.