Мы рассмотрим комплексную проблему, связанную с зависшими блокировками на сервере 1С и внезапным вылетом платформы на локальной машине (сервере) без каких-либо сообщений об ошибках. Эта ситуация может быть вызвана множеством факторов: от поврежденного кеша и проблем с правами доступа до некорректных настроек SQL Server или конфликтов программного обеспечения. Мы подробно разберем шаги по диагностике и устранению данной неисправности, опираясь на опыт сообщества и рекомендации экспертов, чтобы вы смогли эффективно решить эту сложную задачу.
Одна из наиболее частых причин внезапного вылета платформы 1С без ошибок — это повреждение или устаревание файлов кеша. Мы должны провести тщательную очистку как серверного, так и пользовательского кеша, чтобы исключить эту распространенную проблему.
Прежде всего, нам необходимо остановить службу агента сервера 1С. Для этого откроем "Службы" (мы можем выполнить команду services.msc через "Выполнить" или найти ее в "Администрировании") на сервере. Найдем службу с именем, похожим на Агент сервера 1С:Предприятие 8.3 (или другую версию, если вы используете не 8.3.15.1830, как у автора темы), и остановим ее. Это критически важно, так как активная служба может удерживать файлы кеша, предотвращая их полное удаление.
После остановки службы нам также следует убедиться, что все связанные с 1С процессы завершены. Откроем "Диспетчер задач" и проверим отсутствие процессов, таких как rphost.exe, rmngr.exe, ragent.exe, ras.exe. Если какие-либо из них активны, мы должны принудительно завершить их, чтобы гарантировать, что все связанные файлы будут свободны для удаления.
Кеш сервера 1С может находиться в нескольких местах, и нам необходимо удалить содержимое всех соответствующих папок. Обращаем внимание, что служба агента 1С запускается от имени определенного пользователя (например, usr1c, как указал автор в сообщении 6). Мы должны проводить очистку кеша именно для этого пользователя и в системных папках:
%ProgramFiles%\1cv8\srvinfo\reg_*\snccntx\, где reg_* — это папка с уникальным идентификатором кластера. Полностью удалим содержимое папки snccntx. Это основное хранилище временных файлов сервера 1С.%ProgramData%\1C\1cv8\. Удалим содержимое этой папки. Здесь также могут храниться служебные временные файлы.%TEMP% для пользователя, от имени которого запускается служба 1С. Для этого можем зайти под этим пользователем или перейти в папку C:\Users\<имя пользователя службы>\AppData\Local\Temp\..pfl, которые содержат настройки профиля сервера и могут быть повреждены. Их также можно найти в указанных выше папках кеша.Автор темы в сообщении 1 уже пробовал удалять папки с "snccntx", но мы рекомендуем комплексный подход.
Помимо серверного кеша, нам также необходимо очистить кеш для пользователя, под которым осуществляется вход на сервере (если мы пытаемся запустить платформу с этого сервера), и, если служба запускается от его имени, также для пользователя службы. Кеш хранится в папках:
C:\Users\<имя пользователя>\AppData\Local\1C\1cv8\C:\Users\<имя пользователя>\AppData\Roaming\1C\Как указано в сообщении 9, мы можем удалить всё содержимое в этих папках. В сообщении 10 уточняется, что можно оставить файл журнала регистрации (jr), если он нужен для дальнейшего анализа. Эти папки содержат кеш конфигурации, временные файлы форм, внешних отчетов и обработок, которые могли быть повреждены.
В окне выбора информационной базы также есть параметр запуска /ClearCache, который очищает кеш запросов "клиент-сервер", но для глубокой очистки, включающей метаданные и формы, лучше использовать ручное удаление файлов, как мы только что описали.
После всех этих операций по очистке нам необходимо запустить службу агента сервера 1С. После запуска службы мы должны проверить, сохраняются ли блокировки в консоли кластера, как было замечено автором в сообщении 14, чтобы понять, принесли ли наши действия результат.
Недостаточные права доступа для пользователя, от имени которого запускается служба 1С, или для пользователя, пытающегося запустить платформу, могут стать причиной нестабильной работы, сбоев и вылета платформы без ошибок. Мы проанализируем, как права доступа влияют на эту проблему.
Мы должны убедиться, что пользователь, от имени которого запускается служба агента 1С (например, usr1c, как упомянуто в сообщении 6), имеет полные права доступа (чтение, запись, изменение, выполнение) на следующие ресурсы:
C:\Program Files\1cv8\).%ProgramData%\1C\1cv8\, временные папки пользователя службы, папки кеша кластера).В некоторых случаях, когда другие клиенты успешно подключаются к базе, а с самого сервера запуск платформы невозможен, проблема может быть в том, что пользователь службы не имеет достаточных прав для взаимодействия с SQL Server или другими системными ресурсами, когда доступ осуществляется "изнутри" сервера. Рекомендуем временно добавить пользователя службы в группу "Администраторы" на локальной машине и проверить, исчезла ли проблема. Если проблема исчезла, это подтвердит проблему с правами. Далее постепенно уменьшайте права до минимально необходимых, чтобы не нарушать принципы безопасности.
В "Службах" (services.msc) на закладке "Вход в систему" для службы Агент сервера 1С:Предприятие 8.3 мы можем настроить, от какого пользователя она будет запускаться. Проверим, что там указан корректный пользователь и пароль, а также что у него нет проблем со входом в систему или блокировок учетной записи. Иногда смена пользователя, от имени которого работает служба, на другого пользователя с полными правами может решить проблему.
Понимание причин зависших блокировок и некорректных сеансов является ключом к решению проблемы, поскольку автор постоянно упоминает о них. Мы используем встроенные инструменты 1С и SQL Server для глубокой диагностики.
Это мощный инструмент для выявления проблем производительности, таймаутов и взаимоблокировок. Мы должны настроить технологический журнал 1С таким образом, чтобы он фиксировал события, связанные с блокировками (LOCK), транзакциями (TLOCK), ошибками (ERROR) и производительностью (PERF). Для этого необходимо отредактировать файл logcfg.xml в каталоге установки сервера 1С. После включения и сбора данных, тщательный анализ журнала поможет нам понять, какие именно запросы или операции вызывают длительные ожидания или конфликты блокировок. Обратим особое внимание на события, предшествующие вылету платформы, они могут указать на конкретный модуль или действие.
Пример настройки logcfg.xml для сбора данных о блокировках и ошибках:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\1C_Logs" history="10" maxfilesize="1024000">
<event system_level="error">
<event>ERROR</event>
</event>
<event system_level="all">
<event>LOCK</event>
<event>TLOCK</event>
</event>
</log>
</config>
Не забудьте перезапустить службу агента 1С после изменения файла logcfg.xml.
В консоли администрирования кластера 1С мы можем увидеть активные и "спящие" сеансы. "Спящие" сеансы (сеансы, которые не выполняют активных действий, но удерживают ресурсы) часто являются причиной удержания блокировок. Мы можем попробовать вручную завершать такие сеансы, чтобы освободить ресурсы. Также в конфигураторе 1С для информационной базы можно установить параметры автоматического завершения "спящих" сеансов через определенное время, что может помочь предотвратить накопление блокировок и улучшить общую стабильность системы.
Сообщение 14 четко указывает, что блокировки остаются даже после перезапуска службы, что говорит о необходимости глубокого анализа их причин и может быть признаком проблем на уровне СУБД или длительных транзакций, не завершающихся корректно.
Если используется MS SQL Server 2014 (как у автора), длительные транзакции, неоптимальные SQL-запросы или блокировки на уровне СУБД могут быть первопричиной проблемы. Мы будем использовать SQL Server Management Studio (SSMS) для мониторинга и анализа:
sp_who2 и sp_lock, чтобы увидеть, какие процессы активны и какие блокировки они удерживают. Мы можем отфильтровать по базе данных 1С, чтобы сосредоточиться на релевантных блокировках.sys.dm_exec_requests и sys.dm_exec_sessions, чтобы выявить запросы, которые выполняются слишком долго и потенциально вызывают блокировки. Анализ планов выполнения поможет нам понять, почему запросы неэффективны.Проблемы на стороне СУБД, даже если они проявляются после длительной работы без сбоев (как в случае автора, у которого система проработала полгода), могут быть причиной зависаний и вылетов. Мы рассмотрим рекомендации по настройке MS SQL Server для работы с 1С.
Если сервер 1С и SQL Server находятся на одной машине (что мы предполагаем из фразы "локальной машине" в контексте сервера 1С), мы должны убедиться, что для соединения используется протокол Shared Memory. Это самый быстрый и надежный способ взаимодействия между процессами в рамках одной системы. Для повышения стабильности и производительности рекомендуется отключить протокол Named Pipes, который является более медленным и предназначен для сетевого взаимодействия.
Настроить протоколы можно через "Диспетчер конфигурации SQL Server" (SQL Server Configuration Manager).
На сервере 1С, где установлена только клиентская или серверная платформа 1С, но не сам SQL Server, нам может потребоваться установка Microsoft SQL Server Native Client соответствующей версии (в данном случае для MS SQL 2014) для корректной связи с базой данных. Убедимся, что он установлен и обновлен до последней стабильной версии, так как его отсутствие или устаревшая версия может вызывать проблемы с подключением и выполнением запросов.
Мы проверим настройки нашей базы данных 1С в SQL Server Management Studio:
.mdf, .ldf): Убедимся, что они достаточно велики, чтобы избежать частых операций расширения (автоматического увеличения размера файлов). Частые расширения могут приводить к фрагментации и снижению производительности.ALLOW_SNAPSHOT_ISOLATION ON и READ_COMMITTED_SNAPSHOT ON. Хотя это не помогло в его случае, для других сценариев эти настройки могут значительно снизить количество блокировок и повысить конкурентность работы с базой данных, перенося часть блокировок в tempdb. Эти параметры изменяют способ обработки транзакций и могут снизить количество взаимоблокировок. Рекомендуем тщательно рассмотреть их применение, но с пониманием того, что они могут увеличить нагрузку на tempdb и потребовать дополнительной настройки.
ALTER DATABASE MyBase SET ALLOW_SNAPSHOT_ISOLATION ON;
ALTER DATABASE MyBase SET READ_COMMITTED_SNAPSHOT ON;
Для баз данных 1С, которые обычно являются OLTP-системами (транзакционными), общепринятой рекомендацией является установка значения Max degree of parallelism = 1 в настройках SQL Server. Это предотвращает распараллеливание запросов на нескольких ядрах процессора, что может снизить накладные расходы и избежать определенных видов ожиданий (например, PAGELATCH_EX), которые могут возникать в высоконагруженных системах 1С и приводить к замедлению работы или зависаниям.
Хотя система проработала полгода без проблем (как указано в сообщении 8), мы должны убедиться, что установлены последние Service Pack и Cumulative Updates для MS SQL Server 2014. Обновления часто содержат исправления ошибок, улучшения производительности и совместимости, которые могут устранить скрытые проблемы, проявившиеся со временем или после изменения нагрузки.
Автор в сообщении 8 пробовал создать новую базу в SQL, но это не помогло. Тем не менее, это хороший диагностический шаг, чтобы исключить повреждение конкретной базы данных 1С или ее специфические настройки как причину проблемы. Если с новой пустой базой 1С, развернутой на SQL, платформа запускается нормально, то проблема скорее всего в данных или метаданных основной базы.
Неочевидная, но иногда очень эффективная причина проблем с запуском 1С, о чем нам напоминает сообщение 7. Ошибки в региональных настройках могут влиять на работу платформы, особенно при обработке дат, чисел и валют.
Мы должны тщательно проверить региональные стандарты на сервере, где наблюдается проблема. Для этого перейдем в "Панель управления" -> "Региональные стандарты". Автор в сообщении 7 столкнулся с проблемой, когда платформа 1С не запускалась при установке "Русский (Казахстан)", но успешно заработала после установки "Русский (Россия)". Это может быть связано с особенностями форматирования дат, чисел, разделителей или других локализованных данных, которые платформа 1С ожидает в определенном, стандартном для России формате. Даже незначительные различия могут вызвать некорректную инициализацию или сбои.
Убедимся, что для всех пользователей, включая системные учетные записи и учетную запись службы 1С, региональные стандарты установлены единообразно и соответствуют ожиданиям платформы 1С.
Если вышеперечисленные шаги не принесли результата, мы расширим наш спектр поиска причин, переходя к менее очевидным, но потенциально критичным факторам.
В сообщении 11 запрашивается, а в сообщении 12 указывается версия платформы 1С — 8.3.15.1830. Критически важно убедиться, что версия клиентской платформы полностью совместима с версией сервера 1С и конфигурацией базы данных. Некоторые версии платформы могут содержать ошибки, которые были исправлены в последующих релизах. В сообщении 2 автор упоминает, что смена версии 1С сервера на более новую временно помогла. Мы можем рассмотреть обновление платформы до актуальной стабильной версии. Следует проверять рекомендации 1С по совместимости версий платформы и конфигураций.
Если платформа вылетает без ошибок, это может указывать на фундаментальные проблемы системы, не связанные напрямую с 1С. Мы проведем диагностику:
chkdsk, для проверки файловой системы на наличие ошибок. Также полезно проверить S.M.A.R.T.-отчеты дисков, чтобы оценить их физическое состояние и выявить возможные проблемы.memtest86+ (вне операционной системы), для тщательной проверки оперативной памяти на наличие ошибок. Поврежденная ОЗУ может вызывать самые разнообразные и труднодиагностируемые сбои.Иногда антивирусные программы или брандмауэры могут ошибочно блокировать компоненты 1С или SQL Server, вызывая их некорректную работу или сбои. Попробуем временно отключить антивирусное ПО и брандмауэр (на сервере!) и проверить, решилась ли проблема. Если да, то необходимо добавить все исполняемые файлы 1С (ragent.exe, rphost.exe, 1cv8.exe и т.д.) и SQL Server в исключения антивируса и брандмауэра.
Крупные обновления Windows Server 2012 (как у автора в сообщении 8) могут изменять системные компоненты, библиотеки или драйверы, что потенциально может влиять на работу платформы 1С. Проанализируем журнал обновлений Windows на предмет недавних изменений, которые могли совпасть по времени с началом проблемы. При необходимости, мы можем попробовать откатиться на предыдущую точку восстановления или удалить недавно установленные обновления.
В некоторых версиях платформы 1С были известные проблемы, связанные с определенными патчами, которые вызывали невозможность входа или вылеты. Проверим наличие таких патчей и при необходимости удалим их или обновим платформу до версии, где эта проблема устранена. Информацию о критических ошибках и исправлениях можно найти на портале ИТС.
Внимательно изучим системный журнал Windows (eventvwr.msc) на предмет ошибок или предупреждений, которые предшествовали вылету платформы 1С. Они могут содержать ценную информацию о корневой причине, указывая на сбои в определенных компонентах системы или приложений.
Включим детальный журнал регистрации 1С (доступен через конфигуратор или в самой базе) для отслеживания всех событий и ошибок, возникающих при работе с базой данных на уровне приложения. Это позволит получить информацию о событиях, которые могут не попадать в технологический журнал.
В конфигураторе 1С выполним "Тестирование и исправление информационной базы" с различными режимами проверки. Этот инструмент может выявить и устранить логические ошибки в данных или структуре базы, которые могут приводить к непредсказуемому поведению платформы.
Решение таких комплексных проблем, как зависшие блокировки и вылеты платформы 1С, требует систематического подхода и исключения возможных причин одну за другой. Начните с самых простых и распространенных решений, таких как очистка кеша, и постепенно переходите к более сложным диагностическим шагам, включая анализ SQL Server, системных журналов и проверку аппаратного обеспечения. После каждого шага обязательно проверяйте, исчезла ли проблема.