Политики EventLogService
EventLogService/ControlEventLogBehavior
| Выпуск | Windows 10 | Windows 11 |
|---|---|---|
| Домашняя | Нет | Нет |
| Pro | Да | Да |
| Для бизнеса | Да | Да |
| Корпоративная | Да | Да |
| Для образовательных учреждений | Да | Да |
Этот параметр политики управляет поведением журнала событий, когда файл журнала достигает максимального размера.
Если включить этот параметр политики и файл журнала достигнет максимального размера, новые события не будут записаны в журнал и будут потеряны.
Если вы отключаете или не настраиваете этот параметр политики и файл журнала достигает максимального размера, новые события переоценяют старые события.
Примечание. Старые события могут сохраняться или не сохраняться в соответствии с параметром политики «Резервное копирование автоматически при полном объеме».
EventLogService/SpecifyMaximumFileSizeApplicationLog
| Выпуск | Windows 10 | Windows 11 |
|---|---|---|
| Домашняя | Нет | Нет |
| Pro | Да | Да |
| Для бизнеса | Да | Да |
| Корпоративная | Да | Да |
| Для образовательных учреждений | Да | Да |
Этот параметр политики указывает максимальный размер файла журнала в килобайтах.
Если включить этот параметр политики, можно настроить максимальный размер файла журнала в 1 мегабайт (1024 килобайта) и 2 терабайта (2147483647 килобайт) в килобайтах.
Если вы отключили или не настроили этот параметр политики, максимальный размер файла журнала будет заданной для локально настроенного значения. Это значение может быть изменено локальным администратором с помощью диалогового входа Свойства и по умолчанию до 20 мегабайт.
EventLogService/SpecifyMaximumFileSizeSecurityLog
| Выпуск | Windows 10 | Windows 11 |
|---|---|---|
| Домашняя | Нет | Нет |
| Pro | Да | Да |
| Для бизнеса | Да | Да |
| Корпоративная | Да | Да |
| Для образовательных учреждений | Да | Да |
Этот параметр политики указывает максимальный размер файла журнала в килобайтах.
Если включить этот параметр политики, можно настроить максимальный размер файла журнала в 1 мегабайт (1024 килобайта) и 2 терабайта (2147483647 килобайт) в килобайтах.
Если вы отключили или не настроили этот параметр политики, максимальный размер файла журнала будет заданной для локально настроенного значения. Это значение может быть изменено локальным администратором с помощью диалогового входа Свойства и по умолчанию до 20 мегабайт.
EventLogService/SpecifyMaximumFileSizeSystemLog
| Выпуск | Windows 10 | Windows 11 |
|---|---|---|
| Домашняя | Нет | Нет |
| Pro | Да | Да |
| Для бизнеса | Да | Да |
| Корпоративная | Да | Да |
| Для образовательных учреждений | Да | Да |
Этот параметр политики указывает максимальный размер файла журнала в килобайтах.
Если включить этот параметр политики, можно настроить максимальный размер файла журнала в 1 мегабайт (1024 килобайта) и 2 терабайта (2147483647 килобайт) в килобайтах.
Если вы отключили или не настроили этот параметр политики, максимальный размер файла журнала будет заданной для локально настроенного значения. Это значение может быть изменено локальным администратором с помощью диалогового входа Свойства и по умолчанию до 20 мегабайт.
Анализ причин роста сеансовых данных
Сеансовые данные
Платформа «1С:Предприятие» в своей работе постоянно использует механизм, называемый «сеансовые данные». В этих данных хранится служебная информация, необходимая для работы сеанса «1С:Предприятия». Например, все, что введено в поля ввода на форме, при серверных вызовах сбрасывается в сеансовые данные.
При вызове методов: ПоместитьВоВременноеХранилище, ПоместитьФайл, НачатьПомещениеФайла, значения указанные в параметрах, записываются в сеансовые данные.
При фоновом исполнении отчетов СКД, результат отчета помещается в сеансовые данные, а затем передается в клиентскую часть.
Особенности работы платформы с сеансовыми данными
За работу с сеансовыми данными отвечает менеджер кластера – rmngr.exe Если в кластере несколько рабочих серверов, то сеансовые данные будут расположены в соответствии с требованиями назначения функциональности.
Если требования не заданы, то сеансовые данные распределятся равномерно по всем рабочим серверам.
Сеансовые данные растут блоками по 64 Мб. Когда заканчивается блок, то менеджер кластера выделяет следующий блок в 64Мб.Блоки большего объема возможны в результате помещения объемных данных во временные хранилища.
Для обеспечения скорости работы, платформа всегда пишет новые данные в конец, аналогично transaction log в СУБД. Таким образом, размер сеансовых данных постоянно растет. Во всем объеме сеансовых данных, существуют как актуальные, так и устаревшие данные. Актуальность данных определяется способом их помещения:
Перед выделением следующего блока на диске, проверяется, прошло ли 5 секунд с момента выделения предыдущего блока. Если 5 секунд прошло, то запускается «сборщик мусора» (key value garbage collector). Сборщик оценивает процент актуальных сеансовых данных в общем объеме. Если актуальные данные занимают менее 25% от общего объема, то все актуальные данные копируются в новые файлы, а затем все старые файлы сеансовых данных удаляются.
Так как каждый сеанс (клиенты, фоновые задания, web-сервисы) в своей работе постоянно пишет информацию в сеансовые данные, то при большом количестве пользователей, скорость дисковой подсистемы, на которой расположены файлы сеансовых данных, играет очень важную роль. При большом количестве пользователей, рекомендуется располагать файлы сеансовых данных на максимально быстрых дисках. Желательно RAM-drive. Отказоустойчивость дисков не важна, т.к. при потере сеансовых данных, никакой важной информации утеряно не будет.
Следует отметить порядок размещения сеансовых данных. Если поместить во временное хранилище двоичные данные или файл, то эти данные пройдут в качестве потока байт через rphost, затем в rmngr, который сбросит этот поток на диск. Если же, в качестве помещаемого значения, будет выступать коллекция (таблица значений, результат запроса, массив…), то сначала вся эта коллекция разместиться в памяти rphost, а только затем преобразуется в поток байт и будет передана в rmngr.
Размещение сеансовых данных в памяти
При работе кластера «1С:Предприятия», файлы сеансовых данных отображаются в память (mapping). Подробнее см. статью.
За счет данного механизма, процесс работает с файлом как с оперативной памятью. Файл загружается в память не целиком, а только необходимая часть.
Однако, в операционной системе Windows, отображенные в память файлы, влияют на счетчик Memory\Available Mbytes. При сильном росте сеансовых данных можно увидеть следующую картину:
Свободное место на диске, где расположены сеансовые данные, уменьшается синхронно со свободной памятью сервера. На самом деле, если посмотреть данные RamMap то видно, что большая часть оперативной памяти выделена под Mapped File
Размер памяти, указанный в колонке Standby – это неиспользуемая память (фактически свободная). При запросе памяти любым процессом, ему будет выделена память из этой области.
Следует учитывать данную особенность счетчика Memory\Available Mbytes при построении систем мониторинга или приложений, которые опираются на объем доступной оперативной памяти.
Для косвенной оценки эффективности работы операционной системы с сеансовыми данными, можно использовать счетчик Memory\Page Faults/sec, который показывает на сколько часто процессы обращаются за страницами в память, но не находят их там и подгружают с диска.
Если значение данного счетчика велико, то это может свидетельствовать о нехватке оперативной памяти для кэширования в ней сеансовых данных. В этом случае, необходимо принять решение об увеличении оперативной памяти, либо об оптимизации работы приложения с сеансовыми данными.
Проблемы сеансовых данных
Ошибка совместного доступа к файлу snccntx.dat
При появлении данной ошибки необходимо действовать по алгоритму:
1. Проверить права на папку сеансовых данных для пользователя, от которого запущена служба сервера «1С:Предприятия». Должны быть полные права.
2. Открыть на рабочем сервере диспетчер задач, установить видимость колонки «Командная строка»
3. Необходимо найти процессы rmngr.exe с одинаковым значением параметра –pid.
5. Сопоставить PID из диспетчера задач с PID в консоли кластера. Тот процесс rmngr.exe, которого нет в консоли – принудительно завершить.
Закончилось место на диске, где расположены сеансовые данные
Необходимо следить за наличием свободного места на диске, где расположены сеансовые данные.
Не следует размещать файлы технологических журналов на одном диске с сеансовыми данными.
Если на диске, где расположены сеансовые данные, закончится место, то картина будет совершенно «апокалиптическая». Менеджер кластера будет постоянно завершаться с формированием дампа. Начнутся сотни попыток запусков рабочих процессов, которые сразу же будут завершаться с ошибками. После того, как на диске появится свободное место, сервер «1С:Предприятия» запустится в нормальном режиме.
Так же, необходимо следить за размером самих сеансовых данных. Если периодически их размер становится существенным, то необходимо обратить на это особое внимание. Следует помнить, что при срабатывании «сборки мусора» необходимо наличие свободного места на диске, в размере 25% от общего объема сеансовых данных. Если этих 25% не будет, то кластер завершит свою работу аварийно.
Изменить расположение сеансовых данных, можно указав параметр –d в строке запуска службы агента сервера.
В данном каталоге, также расположены: реестр кластера, индекс полнотекстового поиска и журнал регистрации.
Влияние циклических ссылок на рост сеансовых данных
Чаще всего при выполнении процедуры ПоместитьВоВременноеХранилище, указывается идентификатор формы (ЭтаФорма.УникальныйИдентификатор). Как написано в документации, при указании идентификатора формы данные перестают считаться актуальными после того как форма будет закрыта.
Однако, если форма содержит в себе циклические ссылки (см. статью), то после закрытия формы она не уничтожается. Это приводит следующим отрицательным эффектам:
Чтобы избежать данной ситуации, необходимо исключить все циклические ссылки в форме (см. статью).
Необходимо стараться формировать отчеты СКД в фоновом режиме. Так как результат отчета помещается во временное хранилище фоновым заданием, то после завершения задания данный результат будет считаться неактуальным.
Методика анализа роста сеансовых данных
Сбор данных
Необходимо собрать технологический журнал:
Данный технологический журнал может занимать значительный объем. Поэтому необходимо располагать его на дисках имеющих достаточно свободного пространства, периодически переносить старые файлы журнала на другой диск и там архивировать (сохраняя структуру папок).
После того, как технологический журнал будет собран, необходимо провести «парсинг» и выгрузить его данные в файлы csv формата:
На основании данных, которые собраны в папках rmngr_*, необходимо сформировать csv файл вида:
В файле …/rmngr_7188/ 15063011. log есть строка:
Данная строка должна быть преобразована в строку:
Необходимо исключить из итогового файла строки с InBytes=0, т.к. они не представляют интереса, но занимают значительный объем.
На основании данных, которые собраны в папках rphost_*, необходимо сформировать csv файл вида:
Данная строка должна быть преобразована в строку:
На основании данных, которые собраны в папках rphost_*, необходимо сформировать csv файл вида:
В файле …/ rphost_1352 /15063011.log есть строка:
Данная строка должна быть преобразована в строку:
В итоге должно получиться 3 файла: scall.csv, call.csv, conn.csv
Пример создания файлов csv, на основании данных технологического журнала, см. в обработке.
Создание базы данных для анализа
Необходимо создать пустую базу данных (MS SQL Server), в которую добавить таблицы:
Затем, в эти таблицы необходимо загрузить данные из соответствующих csv файлов. Сделать это можно с помощью SQL Server Integration Services
После того, как информация будет загружена в таблицы, можно проводить анализ.
Анализ работы с сеансовыми данными
TOP – 10 пользователей в разрезе процессов и времени
Запрос покажет топ-10 пользователей, которые поместили больше всего сеансовых данных в час. Затем необходимо разобраться с самым верхним (в текущем случае):
Т.е. в процессе rphost_1352 за час с 11-00 по 12-00 пользователь с идентификатором 518 записал в сеансовые данные 2 046 616 858 байт (2Гб).
Далее, необходимо найти все идентификаторы вызовов, которые записывал сеанс 518:
Технологический журнал в 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 секунд. Выключить тех. журнал еще проще — нужно переместить или переименовать файл настроек.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Включаем технологический журнал для 1С:Предприятие
Если программа ведет себя неправильно, то первым делом следует смотреть логи. 1С:Предприятие не исключение, однако, в отличие от большинства иных программ, использующих для этого системные инструменты, 1С реализовали собственный механизм, названный технологическим журналом. Он позволяет достаточно гибко настраивать собираемую информацию и способен удовлетворить различные категории пользователей: от администраторов до разработчиков.
Что такое технологический журнал? Это собственный формат логов 1С собирающий всю информацию о работе установленных на данном ПК приложениях 1С:Предприятие. По умолчанию технологический журнал настроен на сохранение минимальных дампов, возникающих при аварийном завершении программы.
Однако, давайте честно, многие из читающих данную статью имеют знания и опыт чтобы работать с дампами? А те, кто все-таки умеют это делать, будут этим заниматься? Нет, так как практического смысла в этом немного. Процитирую В. Гилева:
В дампах могут разобраться только разработчики платформы! (только у них исходники 🙂 )
Платформа Windows
Для включения и настройки технологического журнала в среде Windows необходимо в папке C:\Program Files (x86)\1cv8\conf создать специальный файл настроек logcfg.xml. В самом простейшем случае он может выглядеть так:
Разберем структуру файла подробнее:
Данная настройка может подойти для клиентского приложения, однако попытка использовать ее на сервере приведет к резкому раздуванию логов и падению производительности системы.
Внимание! 1С категорически не рекомендует включать подобный тип журнала на рабочих серверах!
Поэтому настроим журнал на получение только нужной нам информации. Существуют разные варианты настройки технологического журнала, в зависимости от того, какие именно события нас интересуют. В первую очередь это нештатное поведение платформы, которое может быть связано с ошибками конфигурации или неправильной настройкой платформы. Фирма 1С рекомендует такую настройку журнала:
В данном примере фиксируются следующие события:
Этого набора вполне хватает, для разбора ошибок в повседневной деятельности администратора. С полным перечнем настроек технологического журнала с пояснениями и примерами можно ознакомиться в разделе 3.17 Руководства администратора (та самая толстая желтая книжка, которую никто не читает).
Для диагностики отдельных ситуаций можно применять и специфические настройки журнала. Если вы используете аппаратные ключи, то в случае возникновения проблем с ними примените следующую настройку журнала:
Это позволит фиксировать события обращения к ключам защиты в том виде, в котором они фиксируются системой защиты HASP, в то время как 1С подменяет их своими сообщениями, типа «ключ защиты не обнаружен», обладающими крайне низкой информативностью.
Итак, файл создан. Чтобы события начали фиксироваться в журнале необходимо запустить клиентское приложение или перезапустить службу сервера. После чего директория с логами примет примерно следующий вид:
Для каждого процесса создается отдельная папка с его именем и ID, каждая из которых содержит внутри текстовые файлы с именем формата ггммддчч, т.е. год-месяц-день-час, каждый час создается новый файл лога. Так, например, лог за 12 января 2016 года с 15 до 16 часов будет иметь имя 16011215.log, затем 16011216.log и т.д.
Для примера приведем участок лога:
Сразу видно, что система не может разрешить имя сервера W81-TEST, возможно из-за проблем в DNS. Как видим, логи вполне читабельны и понятны, что позволяет осмысленно подходить к разбору ошибок, особенно в тех случаях, когда явного сообщения об ошибке не выводится, скажем не стартует процесс сервера.
Платформа Linux
Несмотря на то, что никаких отличий в настройке технологического журнала для разных платформ нет, в Linux имеются некоторые особенности, связанные с архитектурой системы и не всегда очевидные начинающим.
Прежде всего расположение файла настроек. Он должен находиться в /home/usr1cv8/.1cv8/1C/1cv8/conf, по умолчанию данная директория не существует и ее нужно будет создать. Также, если вы предпочитаете графические инструменты настройки, учтите, что директория .1cv8 скрытая (на это указывает точка в начале имени) и просто так в файловом менеджере вы ее не увидите.
Мы предпочитаем работу в консоли, как более привычную и удобную для данной платформы. Поэтому создадим данную директорию:
а в ней файл настроек:
После чего можно приступать к его редактированию, содержимое должно быть полностью идентичным Windows-версии, за исключением пути хранения логов. В файловой системе Linux они традиционно располагаются в /var/log и мы не рекомендуем отступать от традиций, потому, что если с данным сервером придется работать другому специалисту, то он будет искать логи именно там.
Изменим строку конфигурационного файла logcfg.xml следующим образом:
Затем создадим папку для логов 1С
А чтобы 1С могла писать туда, установим пользователя и группу 1С владельцем этого каталога:
Теперь перезапускаем процесс сервера 1С
и отмечаем создание в директории папок и файлов с логами.
Данная настройка будет вести технологический журнал сервера 1С, если вам нужно фиксировать события клиентского приложения, то следует выполнить ряд дополнительных действий.
Так как клиентская платформа работает от имени запустившего его пользователя, то файлы настройки платформы хранятся в домашнем каталоге этого пользователя. Если таких пользователей несколько, то у каждого из них будет свой вариант настроек. Структура каталогов при этом полностью повторяет серверную, что не удивительно, в случае с сервером настройки хранятся в каталоге служебного пользователя от имени которого работает сервер 1С.
Если посмотреть этот каталог, то увидим, что там кроме папки conf, присутствует также папка logs, в которой создаются папки для запущенных процессов, однако самих логов там нет.
Попытка использовать для записи логов эту папку не приведет к успеху, папки процессов будут создаваться, но логи появляться не будут. Можно, конечно, перенастроить место хранения логов на любую папку в домашней директории, но лучше продолжить использовать для этого /var/log/1C.
Чтобы запущенное от имени пользователя приложение могло писать в данную папку надо предоставить ему соответствующие права. Если вы единственный пользователь компьютера и серверной версии 1С у вас не установлено, то можно просто сделать текущего пользователя владельцем данной папки, если пользователей несколько, либо на этом же ПК стоит серверная часть и вы хотите включить журнал и для нее, то нужно настроить совместный доступ.
Прежде всего добавим нужных пользователей в группу 1С:
Затем изменим права на папку логов, чтобы писать в нее мог не только владелец, но и группа:
Для применения прав нужно завершить сеанс пользователя и войти заново, после этого можно запустить клиентское приложение и убедиться, что в каталоге /var/log/1C создаются нужные папки логов.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
