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

Ошибка PostgreSQL 08006 connection_failure: сетевой сбой подключения

Обновлено: 26.08.2026 · Официальная документация ↗

Клиентское приложение или сервер 1С теряет связь с СУБД в процессе выполнения транзакции:

FATAL: terminating connection due to administrator command
-- либо:
server closed the connection unexpectedly
This probably means the server terminated abnormally before or while processing the request.
SQLSTATE: 08006

В журнале 1С фиксируются ошибки: Сеанс работы завершен администратором или Ошибка сочленения с сервером СУБД.

1. Анализ логов ядра PostgreSQL на факт падения (Crash / OOM)

Проверьте системный журнал сервера Linux на предмет аварийного завершения процессов PostgreSQL службой OOM Killer:

dmesg -T | grep -Ei "killed process|oom[_-]killer|postgres"
journalctl -u postgresql* -e --no-pager

Если процесс воркера PostgreSQL упал по SIGSEGV или SIGKILL, постмастер принудительно обрывает все активные клиентские соединения для защиты разделяемой памяти (shared memory buffer pool) и выполняет Crash Recovery.

2. Тюнинг сетевых таймаутов TCP Keepalive

Для предотвращения «тихих» обрывов соединений межсетевыми экранами (Firewall/NAT state timeout) настройте параметры ядра Linux в /etc/sysctl.d/99-network.conf:

net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 6

sysctl --system

И в файле postgresql.conf:

tcp_keepalives_idle = 60
tcp_keepalives_interval = 10
tcp_keepalives_count = 6

3. Проверка параметров statement_timeout и idle_in_transaction_session_timeout

-- Просмотр таймаутов принудительного сброса сессий
SHOW statement_timeout;
SHOW idle_in_transaction_session_timeout;

4. Перезапуск пулера соединений (PgBouncer)

Если используется PgBouncer, проверьте параметры server_idle_timeout, query_timeout и статус доступности сокета.

💡 Практика специалистов: При использовании виртуализации (VMware ESXi, KVM) обязательно отключайте энергосберегающие режимы процессора (C-states) и функцию объединения страниц памяти (KSM/ballooning), так как они вызывают микрозадержки и провоцируют обрыв сессий 1С по 08006.

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

Почему при падении одного запроса PostgreSQL рвет все остальные соединения?

Если серверный процесс PostgreSQL падает аварийно (SIGSEGV/SIGBUS/SIGKILL), разделяемая память (shared buffers) может оказаться в неконсистентном состоянии. Постмастер обязан немедленно отключить всех клиентов, перезапустить подсистемы ядра и восстановить данные по WAL.

Как защитить процесс PostgreSQL от уничтожения Linux OOM Killer?

Установите для главного процесса postgres параметр oom_score_adj = -1000 в Unit-файле systemd (OOMScoreAdjust=-1000).

Как отличить сетевой обрыв от намеренного завершения сессии администратором?

В логе PostgreSQL при вызове pg_terminate_backend() будет явная запись 'terminating connection due to administrator command'. При сетевом обрыве фиксируется 'could not receive data from client: Connection reset by peer'.

Как параметр work_mem может провоцировать ошибку 08006?

Если work_mem завышен, одновременный запуск десятков тяжелых запросов приводит к мгновенному исчерпанию физической RAM хоста и аварийному убийству процессов ОС через OOM Killer.