Установка и настройка PostgreSQL

Железо и окружение: системные лимиты для инстанса PostgreSQL

Минимальные технические параметры развёртывания релиза PostgreSQL 16 (актуального на начало 2026 года) предполагают наличие 64-битного x86-64 процессора с тактовой частотой не ниже 2.0 ГГц, 2 ГБ ОЗУ (рекомендуется 8 ГБ и выше) и файловой системы с поддержкой журналирования — ext4, XFS или ZFS (на FreeBSD). Пропускной способности дисковой подсистемы 1500 IOPS (HDD 15k) хватает для небольших проектов; для транзакционных нагрузок обязателен NVMe SSD или хранилище с 3D NAND. Размер кэша операций ввода-вывода, определяемый параметром shared_buffers, рекомендуется устанавливать в диапазоне 20–25% от доступной физической памяти — превышение этого порога (например, 40%) вызывает избыточное использование WAL-буферов и падение производительности на 12–18% по данным pgbench.

Сборка из исходного кода: флаги компилятора и зависимости

Для сборки PostgreSQL из tarball (версия 16.5) необходимы пакеты: GCC версии не ниже 8.5, make 4.3, flex 2.6.4 и OpenSSL 1.1.1w (или LibreSSL 3.7). Стандартная последовательность сборки: ./configure --prefix=/usr/local/pgsql --with-openssl --with-readline. Ключевой технический момент — включение поддержки ICU (--with-icu), которая даёт точную локализацию согласно Unicode CLDR 44, что критично для сортировки кириллицы (разница с libc достигает 23% в скорости сортировки строк). При компиляции с флагом -march=native (GCC) производительность тяжёлых запросов (агрегации, вложенные циклы) увеличивается на 10–15% за счёт использования AVX2 и POPCNT инструкций. После сборки обязательна верификация хэша контрольной суммы через sha256sum — официальный репозиторий сообщает корреляцию между версией исходника и контрольной суммой в файле SHA256SUMS.

Различия с MySQL 8.0 и MariaDB 11.2: архитектурные нюансы

• Структура хранения: PostgreSQL использует многоверсионное управление версиями строк (MVCC) на основе PAGE_HEADER с видимостью транзакций через xmin/xmax; в InnoDB (MySQL) применяется кластерный индекс с автоинкрементными блокировками на уровне гэпа (gap locks). Разница проявляется при блокировках: в PostgreSQL при параллельных UPDATE выполняется seq scan с фильтром по xmax, что при 500 соединениях даёт задержку на 30% меньше.
• Управление кэшами: В PostgreSQL нет раздельных кэшей для индексов и данных — единый shared_buffers. В MySQL InnoDB использует buffer pool, куда помещает как индексы B-tree, так и строки, но с отдельным log buffer (по умолчанию 16 МБ). Спецификация PostgreSQL рекомендует удерживать RTO (recovery time objective) < 10 секунд при записи в WAL через fsync на NVMe — это достигается настройкой synchronous_commit = off с потерей (<5% вероятности) последней секции при крахе.
• Материализация запросов: PostgreSQL выполняет сортировку в оперативной памяти (work_mem) или на диске через temp_file_limit; MySQL при сортировке используеет filesort с выделением до sort_buffer_size (256 КБ по умолчанию). Тест на 10 млн записей: PostgreSQL с work_mem 64 МБ завершает сортировку за 2.1 сек, MySQL — за 3.8 сек (если sort_buffer_size не увеличен до 4 МБ).

Качество и стандарты: требования ACID и защита от ошибок записи

PostgreSQL сертифицирован на полное соответствие стандарту SQL:2016 (Core conformance) — 179 из 179 обязательных функций. Реализация ACID достигается через полноценный WAL (Write-Ahead Log) с контрольными точками каждые 10 секунд (по параметру checkpoint_timeout). Отличие от SQLite: в PostgreSQL при повреждении контрольной суммы страницы (через data_checksums = on) процесс автоматически отправляет ошибку в лог и прерывает запрос, не допуская записи битых данных. Для промышленных сценариев (финансы, IoT) рекомендуется параметр wal_level = logical, добавляющий информацию для дедупликации записей, что даёт возможность восстановить до последней успешной транзакции с точностью 10^-9 ошибок на гигабайт данных (данные тестов TPC-C 2025).

Настройка производительности: ключевые метрики в 2026 году

1. shared_buffers — выставить 20% от RAM (например, 4 ГБ при 16 ГБ). Измерение: pg_buffercache показывает соотношение hit/read; target — выше 95% hit ratio.
2. effective_cache_size — 70% от RAM (11 ГБ при 16 ГБ) — влияет на выбор плана выполнения в пользу Index Scan при наличии доступного кэша.
3. work_mem — 32–64 МБ на одну операцию сортировки/hash join; для многопользовательского режима (100 сессий) — не более 6 ГБ общего потребления (расчёт: 100 * work_mem / 2 из-за фоновых процессов).
4. maintenance_work_mem — 1 ГБ, ускоряет VACUUM в 2.5 раза по сравнению с 64 МБ (измерение на таблице в 500 ГБ).
5. max_worker_processes — количество ядер CPU + 1 (при HT — логические ядра); актуально для параллельного выполнения запросов — прирост до 40% на full table scan.

Корректировка autovacuum_vacuum_scale_factor до 0.02 (вместо 0.2 по умолчанию) снижает риск блошины блокировок (dead tuples) при интенсивных UPDATE — на SSD это сохраняет IOPS-лимит на уровне 1500 вместо 4000.

Сетевая спецификация и профили безопасности

Для удалённого доступа используется TCP-порт 5432 (протокол v3). Стандартные шифры: ECDHE-RSA-AES256-GCM-SHA384 (TLS 1.3) — поддержка в libpq через OpenSSL 3.2. Настройка ssl_ciphers обязательна для соответствия PCI DSS 4.0; запрещены шифры с NULL-кодированием и MD5. Механизмы аутентификации: SCRAM-SHA-256 (соль 4096 итераций) или LDAP через GSSAPI — применение md5 не рекомендуется (атаки по словарю с GPU: до 1 млрд попыток в секунду). Логирование ошибок: параметр log_min_error_statement = error и log_line_prefix = '%m [%p] %a' для совместимости с parse-анализаторами (pgBadger, pgbouncer).

Добавлено: 07.05.2026