Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

PG_CONFIG_TUNING_HIGH_LOAD 1С:Предприятие и СУБД

Комплексная настройка postgresql.conf для высоконагруженных баз данных 1С

Обновлено: 26.08.2026 · Официальная документация ↗
  • Низкая производительность сложных отчетов и запросов динамических списков 1С:Предприятие.
  • Массовый сброс временных данных на диск (temporary file: size ... bytes) вместо обработки в RAM.
  • Высокое потребление CPU планировщиком при неоптимальных значениях random_page_cost.
  • Блокировки и деградация при параллельном проведении документов.

1. Базовый расчет ключевых параметров для сервера с 64GB RAM и NVMe

Отредактируйте /etc/postgresql/16/main/postgresql.conf (или postgresql.auto.conf):

# --- Память и буферы ---
shared_buffers = 16GB                  # 25% от общей RAM
effective_cache_size = 48GB            # 75% от общей RAM
maintenance_work_mem = 2GB             # Для ускорения CREATE INDEX и VACUUM
work_mem = 64MB                        # Память на одну операцию сортировки/хэша

# --- Планировщик под NVMe/SSD ---
random_page_cost = 1.1                 # Для NVMe дисков (быстрый случайный доступ)
seq_page_cost = 1.0
effective_io_concurrency = 200         # Глубина очереди ввода-вывода для SSD

# --- Параллелизм (Параллельные запросы) ---
max_worker_processes = 16
max_parallel_workers = 16
max_parallel_workers_per_gather = 4
max_parallel_maintenance_workers = 4

# --- Оптимизация под 1С:Предприятие ---
from_collapse_limit = 20
join_collapse_limit = 20
escape_string_warning = off
standard_conforming_strings = on

2. Проверка выделения Shared Memory ядром Linux

# Убедитесь, что лимиты shared memory в sysctl достаточны
sysctl -w sys.kernel.shmmax=18446744073709551615
sysctl -w vm.overcommit_memory=2
sysctl -w vm.overcommit_ratio=80

3. Применение конфигурации без перезапуска сервера

-- Перечитывание параметров, не требующих рестарта инстанса
SELECT pg_reload_conf();

-- Проверка параметров, требующих обязательного рестарта
SELECT name, setting, pending_restart 
FROM pg_settings 
WHERE pending_restart = true;
💡 Практика специалистов: Для баз 1С:Предприятие обязательно используйте сборку PostgreSQL с патчами от Postgres Professional или 1С (патчи на autovacuum, fasttrun, plantuner), иначе стандартный ванильный PG будет некорректно строить планы для тяжелых запросов к временным таблицам.

Частые вопросы (FAQ)

Почему нельзя выделять shared_buffers больше 40% оперативной памяти в Linux?

PostgreSQL полагается на двойное кэширование: собственный буферный пул (shared_buffers) и кэш страниц операционной системы (Page Cache). Избыточный shared_buffers приводит к неэффективному дублированию данных и задержкам на синхронизацию.

Как параметр work_mem может вызвать Out of Memory (OOM)?

work_mem выделяется на каждую операцию сортировки или хеширования внутри плана запроса. Сложный запрос с 5 соединениями может потребовать 5 x work_mem. При 100 активных клиентах суммарный объем может легко превысить физическую память.

Зачем изменять random_page_cost с 4.0 (по умолчанию) до 1.1?

Значение 4.0 рассчитано на медленные HDD со временем поиска головки. На современных SSD/NVMe случайное чтение почти так же быстро, как последовательное, и занижение параметра заставляет планировщик чаще и эффективнее использовать индексы.

Как проверить, какие запросы создают временные файлы на диске?

Включите в postgresql.conf параметр log_temp_files = 0, после чего в логах PostgreSQL будут фиксироваться все запросы, превысившие лимит work_mem.

Полезные материалы
Рекомендуем