Технологический журнал в 1С

Технологический журнал — это средство логирования действий платформы происходящих на самом низком уровне. Данные предоставляемые технологическим журналом позволяют выявить причины «тормозов», зависаний, утечек памяти и «падений» рабочих процессов.

Общая информация

Технологический журнал является основным источником информации для всех инструментов анализа производительности платформы.

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

Технологический журнал может продуцировать два вида информации:

Включение технологического журнала

По умолчанию технический журнал включен и работает, дампы хранятся здесь:

%LOCALAPPDATA%\1C\1cv8\dumps (пример: C:\Users\USR1CV8\AppData\Local\1C\1cv8\dumps )

%LOCALAPPDATA%\1C\1cv8\logs (пример: C:\Users\USR1CV8\AppData\Local\1C\1cv8\logs )

USR1CV8 — имя пользователя под которым работает сервер 1С. Логи хранятся 24 часа, при этом делятся на файлы — каждый час новый файл.

Собираемая таким образом информация минимальна — формируются дампы минимального размера при аварийном завершении работы рабочих процессов, а в логи попадают только события SYSTEM с уровнем Error.

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

Выбор директории зависит от задачи: если нужно настроить тех. журнал для всех версий 1С, то файл настроек нужно разместить здесь:

Если настроить нужно конкретную версию, то здесь (зависит от версии):

Иногда может потребовать включить тех. журнал для конкретного пользователя, из под которого запущен сервер 1С, в этом случае файл настроек следует разместить тут:

Перезагружать сервер не требуется, настройки считаются и будут применены не более чем через 60 секунд. Выключить тех. журнал еще проще — нужно переместить или переименовать файл настроек.

Источник

Как диагностировать ошибки платформы «1С:Предприятие 8»

Другие статьи по оптимизации 1С:

Как диагностировать ошибки платформы «1С:Предприятие 8»

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

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

С чего начать?

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

В данной ситуации для начала необходимо настроить технологический журнал (далее – ТЖ).

Даже если Вы не наблюдаете проблем, рекомендуется настроить сбор логов. Для чего?

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

Файл настроек logcfg.xml технологического журнала должен выглядеть так:

Рассмотрим более подробно, что в нем содержится.

Первая и последняя строка открывают и закрывают xml-файл настроек.

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

Таким образом, наличие файлов в указанном каталоге c:\v82\dumps говорит о наличии проблем со стабильностью работы.

Третья строка включает запись логов ТЖ: логи будут храниться в указанном каталоге в течении 48 часов. Событие EXCP будет зафиксировано в случае возникновения исключения, это нужно, чтобы узнать, какой код выполнялся в момент ошибки.

События PROC и ADMIN вполне могут пригодиться разработчикам платформы для анализа проблем.

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

Что делать, если появится дамп?

Рассмотрим пример: в каталоге dumps появился файл: rphost_8.2.18.102_7c938235_20131025162441_3348.mdmp

Его имя построено по шаблону: ИмяПроцесса_Релиз_АдресОшибки_ГГГГММДДЧЧММСС_PIDПроцесса.mdmp

В котором ГГГГММДДЧЧММСС – это дата и время падения.

Каждая ошибка, из-за которой происходит падение, имеет свой уникальный АдресОшибки.

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

ТЖ записывается для каждого процесса в свой отдельный каталог, имя которого задается по шаблону ИмяПроцесса_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 – данное событие означает, что в системе возникло какое-либо исключение. Через запятую перечислены свойства этого события, приведем основные из них:

Иногда с помощью контекста удается установить причину возникновения ошибки. В нашем случае причина падения достаточно очевидна – бесконечная рекурсия.

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

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

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

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

Проблема решается тривиально: нужно закомментировать обращение к объекту. В нашем случае это не проблема, так как без системной информации можно обойтись.

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

Прежде всего, Вы можете обратиться в техническую поддержку фирмы «1С». Но это не самый быстрый способ.

Есть более удобный и быстрый вариант: разместить на партнерском форуме сообщение с описанием проблемы и прикрепить архив с дампом и логами к сообщению или дать ссылку на него.

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

Следует отметить, что этот вариант доступен только сотрудникам фирм-партнеров компании «1С».

PDF-версия статьи для участников группы ВКонтакте

Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.

Статья в PDF-формате

Вы можете скачать эту статью в формате PDF по следующей ссылке: Ссылка доступна для зарегистрированных пользователей)

Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)

Содержание курса и форма заказа: https://курсы-по-1с.рф/1c-v8/optimization/

35 учебных часов, подготовка к 1С:Эксперт, правильная настройка серверной части, оптимизация кода, мониторинг загруженности оборудования и прочие взрослые вещи.

Комментарии / обсуждение (3):

Добрый день.
Подскажите пожалуйста как создать настройку технологического журнала – где начать это нужно сделать – в конфигураторе или в консоли кластера или …?

Источник

Анализ потребления памяти процессами платформы 1С:Предприятие

В рамках проектов ЦКТП и в КОРП поддержке платформы 1С:Предприятие теперь доступна возможность провести анализ памяти процессов платформы 1С:Предприятие на предмет выявления причин проблем, приводящих к значительному потреблению памяти.

Для того чтобы воспользоваться этой услугой, необходимо сделать следующее.

Шаг 1

Убедиться, что потребление памяти одним процессом платформы 1С:Предприятие составляет значительный объем, например, превышает 20 Гб. Значительный объем памяти не объясняется известными ресурсоемкими операциями, выполняемыми на сервере в этот момент.

Шаг 2

Оценить, воспроизводится ли проблема. Проблема также может воспроизводиться в рабочей системе периодически. Если воспроизведение проблемы известно, то его следует передать в поддержку.

Шаг 3

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

Этот шаг опциональный. Но если его выполнить, то расследование и анализ может упроститься.

Шаг 4

Воспроизвести проблему или дождаться момента её воспроизведения.

Шаг 5

Если выполнялся шаг 3, то убедиться, что pid процесса не изменился. Это нужно для того, чтобы в итоге получить два дампа от одного и того же процесса.

Получить дамп процесса со значительным потреблением памяти.

Шаг 6

Поместить собранные дампы в архив и передать в КОРП поддержку или ЦКТП.

Шаг 7

Специалисты поддержки проанализируют полученные данные и предоставят заключение с результатами анализа.

Как получить дамп процесса

Для получения дампа процесса в ОС Windows можно воспользоваться утилитой procdump:

Пример команды: procdump.exe –ma 1234

где 1234 – это PID процесса.

Для получения дампа процесса в ОС Linux можно воспользоваться утилитой gcore.

Пример команды: gcore –o d.core 1234

где d.core – это имя файла дампа, а 1234 – это PID процесса.

В случае использования Linux потребуется также получить библиотеки зависимостей. Для этого необходимо воспользоваться скриптом.

где d.core.1234 – это имя файла дампа, а /opt/1C/v8.3/x86_64/rmngr – это путь до исполняемого файла. В результате его запуска будет сгенерирован скрипт сбора библиотек: d.core.1234_getlibs.sh. После его запуска на целевой системе будет создан архив libs-d.core.1234.tar.gz, который нужно передать в поддержку вместе с файлом дампа.

В случае использования Windows полезным также будет использование утилиты vmmap.

При запуске утилиты необходимо выбрать исследуемый процесс, далее сохранить полученную статистику в файл *.mmp. Полученный файл следует передать в поддержку вместе с файлом дампа.

Источник

Ошибки 1С 8.3 и их исправление

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

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

Чтобы научиться быстро исправлять ошибки в 1С необходимо изначально их проанализировать. Часто во всплывающем окне написана суть некорректного поведения, что помогает решить проблему.

Причины появления ошибки в 1С

Разберем основные моменты, связанные с частым появлением сбоев при работе с базой данных. Они возникают в разных ситуациях, и определить их истинную причину не всегда возможно.

Одна из самых частых причин нарушение работы связанна с компьютером, на который установлена база данных 1С. Рабочая область может автоматически закрываться из-за нехватки оперативной памяти на сервере. Все возникающие неисправности должны быстро устраняться. В противном случае есть вероятность потери данных.

Часто возникающие ошибки 1С

Все имеющиеся сбои выводят на экран разные уведомления. Одинакового текста не бывает. Чтобы проще ориентироваться, разделим существующие ошибки 1С на следующие пункты:

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

Недостаточно памяти

Подобный сбой проявляется только в том случае, если на выполнение операций с программой выделено мало оперативной памяти. Приложение не может обрабатывать большие объемы информации, поэтому выдает «Недостаточно памяти 1С». Это случается при формировании отчета, обработки «тяжелого» файла, обновлении конфигурации и т.д. Причина – мощности компьютера недостаточно.

Пользователь может самостоятельно решить проблему с памятью. По умолчанию операционная система выделят фиксированное значение гигабайт на обслуживание приложения: 32 bit ОС – 2 Гб, 64 bit – 4 Гб.

Увеличить размер выделенной памяти можно вручную. Для этого запускается адресная строка (Пуск – Выполнить, вводиться фраза cmd). После нажатия «Ентер» достаточно ввести фразу bcdedit /set increaseuserva 4096 и подтвердить действие (клавиша «Enter»). Цифра 4096 – новый выделяемый объем «оперативки». Выполняется перезагрузка системы. Проблема должна быть устранена.

Ошибка доступа

Она возникает, если учетная запись не имеет достаточно прав. Проявляется при выполнении определенного действия, которое доступно только ограниченному кругу пользователей. Для исправления ситуации достаточно изменить роль выбранного профиля в конфигураторе (вкладка «Администрирование – Пользователи»). В некоторых случаях это увеличивает безопасность базы данных, если необходимо защитить файлы от изменения сторонними людьми.

Ошибка формата потока

Когда пользователь только запускает программу, на экране может появиться окно сбоя. Оно предлагает завершить работу или перезапустить. Причиной выступает некорректное завершение работы приложения.

Устранение подобной ошибки 1С выполняется простой чисткой кэша. Для этого необходимо перейти в папку, где хранятся временные файлы. В Windows 7 и выше она находится по адресу C:\Users\Username\AppData\Local\1C или C:\Users\Username\AppData\Roaming\1C. Для Windows ХР другой путь – Local Settings\Application Data\1C\. Все файлы, начинающиеся на 1cv8, кроме «1Cv8.1CD» полностью удаляются.

Если «Ошибка формата потока» возникает в процессе работы, то нужно провести тестирование (Администрирование – Тестирование и исправление), выбрать первые 2 галочки и запустить процесс.

Ошибка СУБД: Файл базы данных поврежден

Если всплывает информационное окно с подобной надписью, неисправность базы данных решается тестированием файла и всей информационной базы. Такое мероприятие может проводиться 2 способами:

Неправильное отображение блоков формы

Такая неисправность возникает от разных факторов. Чтобы привести программу к нормальной работоспособности, пользователю необходимо последовательно выполнить несколько команд. После проведения каждой проверяется устранение сбоя:

Если приведенные методы не помогают, рационально будет провести обновление платформы.

Внутренняя ошибка компоненты dbeng

Подобное сообщение говорит о повреждении структуры базы данных. Приведенный в названии документ хранится в папке с программной. Решение сбоя находится простой переустановкой платформы. Если такой метод не помог, можно воспользоваться тестированием и исправлением базы данных.

Dump при запуске

Возвращение 1С в рабочее состояние проводится простым обновлением MS Visual Studio (Visual C++) и дополнительными манипуляциями. Чтобы отследить конкретный файл, в котором возникает ошибка, открывается «Просмотр событий». Для этого пользователь переходит в «Панель управления – Система и безопасность – Администрирование». С левой стороны раскрывается «Журнал Windows – Приложение».

На экране появляется список ошибок и точное расположение поврежденного файла. После установки новой версии MS Visual Studio (Visual C++) с папки System32 копируется одноименный файл dll и вставляется в папку платформы 1С. Проблема решилась.

Неверный формат хранилища

В появившемся окне обязательно будет надпись, содержащая «AppData/Local/». Она указывает на точное расположение проблемного файла. В этом сообщении уже написан правильный путь решения. Пользователю достаточно перейти по указанному адресу и удалить временные файлы. Очистка кэша помогает решить множество проблем.

Ничего не работает

Если программа перестала нормально работать без видимых причин, значит пользователю придется самостоятельно искать неисправность. Для восстановления работоспособности базы данных проводятся следующие мероприятия:

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

Источник

Когда 1С падает в дамп

Все из нас когда-нибудь сталкивались с подобными сбоями платформы. Кто-то чаще, кто-то реже. Решений тоже уйма от простой чистки кэша и переустановки платформы, до изменений политик и правки глубин реестра. Все уже давно описано и поисковик выдает рецепты счастливой жизни без записей в dump.

Сомневаюсь, что моя ситуация уникальна, но найти что-то похожее не удалось. Поэтому изложу свой опыт в надежде, что кому-то он сэкономит время и нервы.

На рабочий компьютер был установлен свежий Windows 10 Pro Версия 1803 (Сборка ОС 17134.345) и платформа (8.3.12.1595).

Платформа работала нестабильно и периодически выпадала в ошибку наподобие этой

Чаще вылетало даже не предприятие, а конфигуратор, когда помещаешь что-то в хранилище. Перезапуск не помогал. После очистки кэша все становилось нормальным, но проблема снова возвращалась.

Ок. Открываем «Панель управленияСистема и безопасностьАдминистрированиеПросмотр событий». Далее смотрим ветку «Журналы WindowsПриложение» и фильтруем по ошибкам. Видим следующую картину

Смотрим имя сбойного модуля и его расположение. Далее идем по этому пути разбираться

Оказывается это компонента MS Visual Studio 2015 (Visual C++). Идем на официальный сайт, выкачиваем и ставим более свежую версию.

После установки идем в System32 и копируем нашу dll. Далее заменяем в папке с платформой 1С.

1C приняла библиотеку как родную и на данный момент сбои прекратились. Если что-то изменится, то дополню статью.

Источник