На сервере 1С:Предприятия периодически возникает критическая ошибка, которая сопровождается сообщением "На сервере 1С:Предприятия произошла неисправимая ошибка. Приложение будет закрыто". Чтобы минимизировать влияние зависших соединений, можно использовать автоматическое отключение старых задублированных сеансов. После появления этой ошибки у одного из пользователей, у остальных работа с базой данных на некоторое время зависает, а затем восстанавливается. Пользователю, получившему ошибку, приходится перезапускать приложение. Данная проблема проявляется нерегулярно (рандомно).
Давайте вместе разберем эту ситуацию, проанализируем предоставленные данные и выработаем комплексный план по диагностике и устранению проблемы. В нашем случае используется конфигурация УТ 11.4.10.62 на платформе 8.3.26.1581, сервер работает под управлением Linux, а в качестве СУБД используется PostgreSQL 14.
Прежде всего, внимательно рассмотрим предоставленный отчет об ошибке. Он содержит множество ценной информации:
Windows_x86_64, версия приложения 8.3.26.1581, клиент 1CV8C (тонкий клиент). Клиентская ОС: Microsoft Windows 10 (Build 19045). Интересно, что клиент 64-битный.8.3.26.1581 (совпадает с клиентской), тип Linux_x86_64 (64-битный), СУБД PostgreSQL.УправлениеТорговлей, версия 11.4.10.62. Самое главное — режим совместимости Version8_3_12. Это очень важный момент, к которому мы вернемся.clientStack и serverStack): Это наиболее технически сложная, но и самая информативная часть отчета. Стек указывает на последовательность вызовов функций, которые привели к сбою. Мы видим, что в стеке присутствуют модули core83.dll, vrscore.dll, mngui.dll, bsl.dll, frame.dll, backbas.dll на клиенте и rserver, vrsbase, rtrsrvc, rscalls, core83, libc.so на сервере. Эти модули относятся к основным компонентам платформы 1С и библиотекам операционной системы, что свидетельствует о системном характере ошибки, а не о банальной ошибке в коде конфигурации.Судя по характеру ошибки и зависаниям, мы имеем дело с проблемой, которая затрагивает сам кластер серверов 1С или СУБД, а не только отдельного пользователя.
Давайте теперь рассмотрим потенциальные причины данной неисправимой ошибки и методы их диагностики, начиная с наиболее вероятных.
Мы обратили внимание, что конфигурация УТ 11.4.10.62 работает на платформе 8.3.26.1581, но при этом ее режим совместимости установлен на 8.3.12. Это критически важный аспект. Режим совместимости указывает, с какой минимальной версией платформы конфигурация гарантированно работает. Если этот режим значительно ниже текущей платформы, это может приводить к неожиданным эффектам и ошибкам, поскольку более новая платформа может выполнять код, написанный для старого режима, не так, как ожидалось.
УТ 11.4.10.62 действительно требует режима 8.3.12. Для современных релизов УТ 11.4 обычно рекомендуются более новые режимы совместимости, которые соответствуют актуальным версиям платформы.УТ до более актуального релиза. Зачастую, при обновлении конфигурации, режим совместимости также автоматически повышается до рекомендованного разработчиком, что может устранить внутренние конфликты.Фактор, который нельзя игнорировать: представители фирмы "1С" в своих облачных сервисах "1С:Фреш" активно используют версии платформ 8.3.25, 8.3.27 и даже 8.5.1, но практически не задействуют 8.3.26. Это может косвенно указывать на то, что платформа 8.3.26 имеет меньшую стабильность или содержит известные ошибки, которые были исправлены в последующих релизах. Несмотря на то, что в версии 8.3.26 были улучшения, например, связанные со стабильностью видеозвонков, общее впечатление о ее стабильности может быть неоднозначным.
8.3.27 или одну из 8.5.x. Перед обновлением обязательно изучите список изменений и исправленных ошибок для выбранной версии платформы.Одна из наиболее распространенных причин "неисправимых ошибок" и зависаний в системах 1С:Предприятия — это проблемы с памятью. Это может быть как банальная нехватка физической оперативной памяти на сервере, так и утечки памяти в процессах 1С или PostgreSQL, а также неэффективное использование памяти.
rserver.Linux, используя мониторинг потребления ресурсов базами кластеров сервера. Используйте утилиты типа htop, top, free -h, чтобы отслеживать потребление памяти процессами ragent, rhost, rmngr и postgres. Обращайте внимание на пиковые значения и тенденции роста потребления памяти перед возникновением ошибки.Linux (что и подтверждается отчетом Linux_x86_64). 32-разрядные процессы ограничены в использовании памяти (обычно до 3.8 Гб на процесс), что часто приводит к падениям при интенсивной работе. В вашем случае платформа 64-битная, что исключает это как прямую причину, но подтверждает, что проблемы с памятью могут быть связаны с ее утечками или неэффективным использованием, а не с архитектурными ограничениями процесса.PostgreSQL на Linux требует очень тщательной настройки для оптимальной работы с 1С. Дефолтные настройки СУБД совершенно не подходят для промышленной эксплуатации и могут быть источником низкой производительности и нестабильности.
postgresql.conf:
Linux и для PostgreSQL отключены все функции энергосбережения, которые могут замедлять работу дисковой подсистемы или процессора.PostgreSQL в своп. Это можно сделать, например, установкой параметра vm.swappiness = 1 (или 0) в /etc/sysctl.conf и transparent_hugepages=never.postgresql.conf:
shared_buffers: Рекомендуется устанавливать в четверть от объема ОЗУ сервера (RAM/4). Например, если у сервера 64 Гб ОЗУ, то shared_buffers = 16GB.work_mem: Память, используемая для внутренних операций сортировки и хеширования. Рекомендуется 32MB или 64MB, но может потребоваться подбор.maintenance_work_mem: Память для операций VACUUM, REINDEX, CREATE INDEX. Обычно 256MB или 512MB.max_connections: Максимальное количество одновременных подключений. Должно быть достаточным для всех сеансов 1С, плюс системные соединения.max_files_per_process: Максимальное количество файлов, которые может открыть процесс. Рекомендуется увеличить до 2000 или 4000.max_parallel_workers: Количество фоновых процессов, которые могут быть использованы для параллельных запросов.autovacuum_vacuum_cost_limit: Лимит стоимости автовакуума.wal_buffers, checkpoint_timeout, max_wal_size, min_wal_size: Параметры журнала предзаписи (WAL), влияющие на производительность записи.postgresql.conf необходимо перезапустить службу PostgreSQL.Linux. Некорректная локаль может вызывать ошибки при работе с текстовыми данными в 1С, создании баз данных или временных таблиц. Убедитесь, что установлена и правильно используется локаль ru_RU.UTF-8.PostgreSQL крайне важно:
vacuumdb): Регулярный VACUUM FULL или, при активной работе, VACUUM и ANALYZE (автовакуум должен быть включен и настроен). Это предотвращает разрастание таблиц и потерю производительности.reindexdb): В случае сильной фрагментации индексов может потребоваться их перестройка.В вашем отчете мы видим, что используется 22 расширения. Это довольно много. Каждое расширение — это дополнительный код, который может содержать ошибки или конфликтовать с другими расширениями, особенно если они пытаются модифицировать одни и те же объекты метаданных.
Зависания и "неисправимые ошибки" также могут быть вызваны проблемами с серверным оборудованием или некорректной настройкой операционной системы Linux.
Zabbix, Prometheus или аналогичные системы.Linux (/var/log/syslog, dmesg) на предмет ошибок памяти, дисковых ошибок или сообщений о нехватке ресурсов.PostgreSQL, либо потреблять чрезмерные ресурсы.BIOS/UEFI или ОС отключены, поскольку они могут негативно сказываться на производительности и стабильности.Администраторы отключили технологический журнал "для экономии места". Это серьезная ошибка, так как технологический журнал является важнейшим инструментом для диагностики любых проблем в кластере 1С. Он фиксирует подробную информацию о событиях на сервере, включая контекст возникновения исключений, идентификаторы потоков, параметры вызовов, потребление ресурсов и многое другое. Без ТЖ диагностика "неисправимой ошибки" становится практически невозможной.
logcfg.xml позволяет гибко регулировать, какие события и с какой детализацией записывать. Начните с базового набора событий (EXCP, DBMSSQL, CALL, MEM, SESN) и при необходимости расширяйте его.EXCP, DBMSSQL, а также внезапные завершения сеансов или процессов rhost.При аварийном завершении процессов 1С (rserver, rhost, ragent) система может формировать файлы дампов (.dmp). Эти файлы содержат "снимок" состояния процесса в момент краха, включая стек вызовов, состояние памяти и регистров процессора.
Linux дампы могут находиться в каталоге установки сервера 1С или в системных каталогах для крэш-дампов (например, /var/crash)..pdb-файлам), которые есть только у фирмы "1С".Хотя в вашем случае версии платформы на клиенте и сервере совпадают (8.3.26.1581), важно помнить, что несовпадение версий может быть частой причиной ошибок соединения и работы. Всегда следите за тем, чтобы клиентские и серверные компоненты 1С работали под одной и той же версией платформы.
Проблемы со связью между клиентом, сервером 1С и сервером PostgreSQL могут вызывать "неисправимые ошибки".
PostgreSQL доступен по сети, и что на нем не менялись параметры аутентификации или адрес.USR1CV8.Для эффективного решения проблемы мы рекомендуем выполнять действия поэтапно, от наиболее простых и очевидных к более сложным. Не забывайте о тестировании после каждого шага.
Linux.postgresql.conf для работы с 1С (особое внимание shared_buffers, work_mem, maintenance_work_mem).ru_RU.UTF-8.VACUUM, ANALYZE, при необходимости REINDEX).УТ 11.4.10.62 корректно работает с режимом 8.3.12 на платформе 8.3.26. Рассмотрите возможность обновления конфигурации до актуальной версии для автоматического повышения режима совместимости.8.3.27 или 8.5.x. Предварительно изучите список изменений и совместимость.Linux на предмет аппаратных ошибок (память, диски).При совместной работе с системными администраторами и тщательном подходе к каждому из этих пунктов, мы уверены, что вы сможете выявить и устранить причину неисправимой ошибки на сервере 1С:Предприятия.