Переход с MS SQL Server на связку Linux + PostgreSQL — это серьезный шаг, требующий тонкой настройки не только самой СУБД, но и параметров операционной системы. Часто администраторы сталкиваются с тем, что производительность в тестах (например, тест Гилева) оказывается неудовлетворительной, а при попытке загрузить файл выгрузки .dt большого объема (20–30 Гб и более) происходит обрыв соединения. В этой статье мы подробно разберем, как оптимизировать конфигурацию и успешно перенести данные.
Рассмотрим ситуацию: при попытке загрузить базу объемом около 29 Гб через консоль администрирования или конфигуратор 1С процесс прерывается. Ошибка «Передача данных прервана по инициативе принимающей стороны» при загрузке .dt файла чаще всего связана не с настройками PostgreSQL, а с организацией процесса загрузки и сетевыми тайм-аутами.
Проанализируем основные причины и способы их устранения:
.dt, запуская конфигуратор на клиентской машине. Передайте файл непосредственно на сервер 1С. Если на сервере Linux не установлена графическая оболочка (X-сервер), стоит ее временно установить или использовать инструменты публикации, чтобы процесс шел внутри серверного контура. Загрузка «по сетке» крайне чувствительна к любым микросбоям и задержкам..dt во временные папки. Если место закончится хотя бы на секунду, сеанс rphost будет аварийно завершен. Убедитесь, что разделы /tmp и папка сеансовых данных 1С имеют достаточный запас (минимум 2-3 объема самого .dt файла).statement_timeout. Для процесса импорта данных его рекомендуется установить в значение 0 (без ограничений).Стандартные настройки PostgreSQL не подходят для специфики запросов 1С. Рассмотрим правильный вариант настройки для сервера с 32 Гб оперативной памяти. Проанализируем ключевые параметры, которые напрямую влияют на «попугаи» в тесте Гилева.
Для начала настроим использование памяти и дисковой подсистемы. В файле postgresql.conf установим следующие значения:
shared_buffers = 8GB # Рекомендуется 1/4 от общего объема ОЗУ
temp_buffers = 128MB # Увеличиваем для работы с временными таблицами 1С
work_mem = 64MB # Память для сортировок, не ставьте слишком много при большом числе соединений
maintenance_work_mem = 1GB # Ускоряет индексацию и очистку
effective_cache_size = 24GB # Оценка доступного кэша ОС для планировщика
Важно обратить внимание на параметры, специфичные для 1С, которые отключают избыточные проверки и меняют логику работы со строками:
escape_string_warning = off
standard_conforming_strings = off
max_locks_per_transaction = 256
Одной из главных причин деградации производительности 1С на Postgres является «раздувание» (bloat) таблиц и неактуальная статистика. Выясним, как заставить систему очистки работать эффективнее. В высоконагруженных системах стандартные пороги срабатывания autovacuum слишком высоки.
Рассмотрим рекомендации по настройке порогов срабатывания (scale factor):
0.05. Это означает, что очистка начнется при изменении 5% данных в таблице.0.001. Сбор статистики должен происходить гораздо чаще, буквально после изменения каждых 0.1% строк, чтобы планировщик запросов всегда имел актуальные данные.Применим эти настройки в блоке автоматической очистки:
autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.001
Производительность СУБД на Linux сильно зависит от настроек ядра. Даже идеальный конфиг Postgres не поможет, если ОС работает в режиме энергосбережения или использует агрессивный swapping.
Выполним следующие шаги по оптимизации ОС:
never.vm.swappiness = 1 (или 10), чтобы система до последнего использовала оперативную память.performance. В Linux по умолчанию часто стоит powersave, что снижает частоту ядер при отсутствии мгновенной нагрузки, а для 1С это критично (тест Гилева сразу покажет низкий результат).Для версий Postgres Pro, оптимизированных под 1С, крайне рекомендуется использовать расширения online_analyze и plantuner. Они позволяют обновлять статистику непосредственно в момент выполнения транзакции, что жизненно важно для временных таблиц, которые 1С создает и удаляет постоянно.
Включим их в параметре shared_preload_libraries и настроим поведение:
shared_preload_libraries = 'online_analyze, plantuner'
online_analyze.enable = on
online_analyze.table_type = 'temporary'
online_analyze.verbose = off
plantuner.fix_empty_table = on
Проанализируем результат: после внесения этих изменений, локальной загрузки .dt и настройки параметров ОС, производительность в тесте Гилева должна стабилизироваться на уровне «Хорошо» или «Отлично», а ошибки разрыва соединения исчезнут.