vk fb tw rss

Почему вылетает 1С?

Падение
Ни для кого не секрет, что платформа 1С содержит достаточно большое число ошибок, и иногда эти ошибки настолько критичны, что приводят к аварийному завершению процессов сервера приложений. О последствиях рассказывать излишне. Простои в работе обходятся дорого, особенно в больших системах. И самое печальное, что понять почему же произошла ошибка довольно сложно, но иногда все-таки можно.

 

Отладка — процесс удаления ошибок. Программирование — процесс их создания.

 

С чего начать?
Итак, допустим сегодня не ваш день и придя на работу вы узнаете от коллег, что с самого утра «вылетает 1С» или говоря по научному процессы сервера приложений самопроизвольно выгружаются из памяти. При этом все или большая часть пользователей аварийно завершают свою работу.

Первое что необходимо сделать в таком случае, это настроить технологический журнал (ТЖ).
Если кто не знает что это за зверь, то вам сюда.
Но даже если у вас все хорошо (ничего никуда не вылетает), или вы думаете что у вас все хорошо, то все равно рекомендуется настроить сбор логов. Зачем?
Есть 2 причины:

1. Если вдруг проблемы возникнут, то у вас уже будут все данные для расследования.
2. Возможно, что проблемы у вас уже есть, например процессы «падают» раз в 2-3 месяца, но вы об этом просто не знаете, т.к. пользователям легче перезапуститься и продолжить работу, чем связываться с программистами.

 

Файл настроек ТЖ, тот который logcfg.xml, должен выглядеть следующим образом:

Теперь давайте разберемся с тем, что здесь написано.

Во второй строке мы включаем запись дампа, т.е. в случае краха одного из процессов дамп будет записан в каталог «c:\v82\dumps» и при необходимости поможет разработчикам платформы найти причину ошибки.

Дамп образуется только в случае падения одного из процессов, т.е. если в каталоге damps появятся файлы, это значит, что у вас есть проблемы со стабильностью.
В третьей строке мы включаем запись логов ТЖ, как не трудно догадаться, логи будут записываться в каталог «c:\v82\logs» и храниться 48 часов.
Событие EXCP пишется в случае возникновения исключения, и нужно что бы узнать какой код выполнялся в момент ошибки.
События PROC и ADMIN могут пригодиться разработчикам платформы для расследования.

Необходимо помнить что логи могут занимать довольно много места на диске, нужно это предусмотреть.  Хотя при указанной настройке логи сильно разрастаться не должны.

 

Что делать, если появится дамп?
Допустим в каталоге dumps появился файл rphost_8.2.18.102_7c938235_20131025162441_3348.mdmp
Имя дампа строится по следующему шаблону:

ИмяПроцесса_Релиз_АдресОшибки_ГГГГММДДЧЧММСС_PIDПроцесса.mdmp
ГГГГММДДЧЧММСС – это дата и время падения, в нашем примере это 2013.10.25 16:24:41
Обычно каждая ошибка, из-за которой происходит падение, имеет свой уникальный АдресОшибки.

Это значит, что если у двух дампов одинаковый процесс, релиз и адрес ошибки, то скорее всего причина падения одна и та же.
Из названия дампа,  мы знаем точное время падения, теперь необходимо выяснить, что происходило в это время в системе, и здесь нам помогут логи ТЖ.

 

ТЖ пишется в отдельный каталог для каждого процесса, имя каталога формируется по шаблону ИмяПроцесса_PIDПроцесса.

Имя файла лога формируется по следующему шаблону ГГММДДЧЧ.log

Что бы узнать, что привело к падению, находим каталог с логами покинувшего нас процесса. Мы легко это можем сделать т.к. в имени файла дампа есть имя и PID процесса.
В данном случае нам нужен каталог rphost_3348.
Теперь в указанном каталоге нужно найти тот лог, в который писалась информация в момент падения. Опять же берем время падения из имени дампа, и таким образом находим файл лога 13102516.log
Открываем файл лога и ищем строку rphost_8.2.18.102_7c938235_20131025162441_3348
В моем случае в логе написано следующее:

0,EXCP,3,process=rphost,p:processName=Test,t:clientID=2,t:applicationName=1CV8C,t:computerName=AND-SERVER,t:connectID=196,SessionID=4,AppID=1CV8C,OSException=rphost_8.2.18.102_7c938235_20131025162441_3348,Context=’Форма.Вызов : ВнешняяОбработка.ВнешняяОбработка1.Форма.Форма.Модуль.Крах
Форма.Форма.Форма : 5 : Крах();
Форма.Форма.Форма : 5 : Крах();
Форма.Форма.Форма : 5 : Крах();
Форма.Форма.Форма : 5 : Крах();

EXCP – это событие означает, что в системе возникло какое-либо исключение, далее через запятую перечислены свойства этого события, перечислим основные из них.
Process – имя процесса, где возникло исключение
processName – имя информационной базы
applicationName – клиент с которого пришел вызов, приведший к падению, в данном случае это тонкий клиент
computerName – имя компьютера, на котором был запущен клиент
Context – код, который выполнялся в момент падения, это самое важное для нас событие.

 

С помощью контекста иногда (но реже чем хотелось бы) удается понять причину ошибки.
В моем случае причина падения очевидна, это бесконечная рекурсия.

Данный пример конечно слишком простой и достаточно редко встречается в реальной жизни, хотя иногда бывает.

 

Рассмотрим другой пример

В версии 8.2.13 есть одна очень популярная ошибка при работе с объектом «СистемнаяИнформация»
Контекст ТЖ выглядит примерно так:

Context=’Инфо = Новый СистемнаяИнформация;
Текст = «Версия 1С  » + Инфо.ВерсияПриложения;’

 

На первый взгляд ничего криминального здесь нет, но надо помнить, что 1С это многопользовательская система, и объекты должны быть спроектированы с учетом параллельности работы пользователей, как раз здесь часто и ошибаются разработчики платформы.
Причем ошибки, возникающие в момент одновременного обращения к объекту нескольких пользователей, встречаются достаточно часто, и если у вас уже образовалось несколько дампов, и при этом в контексте фигурирует один и тот же объект (в данном примере СистемнаяИнформация), то скорее всего это как раз тот случай.
Обход проблемы очень прост, нужно просто закомментировать обращение к объекту. В данном случае это не проблема, т.к. обычно без системной информации вполне можно обойтись.

 

Что делать, если понять причину падения по логам самостоятельно не удается?

Вы конечно можете обратиться в тех. поддержку 1С, но это, мягко говоря, не самый быстрый способ.
Есть и более быстрый вариант, все что требуется, это разместить на партнерском форуме пост с описанием вашей проблемы, и желательно сразу дать ссылку на архив с дампом и логами либо прикрепить его к сообщению.
Если вы не работаете во франчайзи и у вас нет доступа на партнерский форум, то наверняка у вас есть друзья или знакомые, которые там работают.
Это намного более быстрый способ, чем обращение через тех. поддержку или решение проблемы методом научного тыка.
На партнерском форуме на ваши вопросы отвечают не только специалисты, которые возможно уже сталкивались с такой проблемой, но и сами разработчики платформы.

 

При обращении на форум, обязательно указывайте следующую информацию:

  • Ссылки на архив с дампом и логами для скачивания
  • Версию и разрядность серверной ОС
  • Разрядность сервера 1С
  • Количество серверов в кластере
  • Количество запущенных рабочих процессов на сервере 1С
  • Версию используемой СУБД

 

Если у вас есть ошибка, которую никак не получается побороть, пишите в комментариях или на форум. Будем разбираться вместе.

 

Друзья, давайте не будем теряться на просторах интернета!  Я предлагаю вам получать на e-mail извещения о публикации новых статей и материалов, таким образом вы всегда будете в курсе самых интересных новостей!

 

 



Лучшие материалы по теме

Расскажите своим друзьям
Вам ничего не стоит, а им будет интересно
Подпишитесь на обновления
Ваш e-mail: * Ваше имя: *


Обсудить Вконтакте


Обсудить в Facebook

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *