Все, что вы хотели знать о журнале регистрации




Исследование файла Журнала регистраций в формате lgd.

После жалоб пользователей на замедление 1С:Предприятие администраторы высказали подозрение, что причиной тормозов является Журнал регистрации. Журналы – это несколько файлов формата lgd от одного до двух гигабайт. Чтобы развеять все сомнения, и вооружившись трехзвенкой 8.3.12.1469 x86, а также инструментами от производителя, решено было изучить вопрос вдоль и поперек  или другими словами, узнать, «что там под капотом».

Чтобы 1С:Предприятие хранила журнал в данном формате, необходимо его указать явно в конфигураторе или файле настроек. Либо просто удалить все файлы из каталога журнала, если там файлы предыдущего формата. Разделение данных, как было в предыдущей версии, не поддерживается. Корневой каталог журналов указывается в параметрах запуска службы после ключа -d. Например, -d “d: empsrvinfo”

Итак, журнал представляет из себя не что иное, как базу данных sqlite,  хотя 1С использует свое именование расширения и даже свой драйвер для доступа, который входит в поставку платформы. Разработчики 1С не стали использовать предлагаемый авторами sqlite драйвер, а просто скомпилировали свой, видимо для совместимости и/или простоты использования, благо исходники доступны на сайте sqlite. Но используется он своеобразно. К примеру, если пометить на удаление записи в журнале любым доступным вам способом, то это ничего не даст потому, что 1С просто игнорирует эту метку. То есть при просмотре отразятся все без исключения записи.

Разработчики sqlite утверждают, что размер файла базы данных может превышать сотню гигабайт и даже сотню терабайт. Так что, если бы 1С:Предприятие тормозила из-за журнала, то скорее всего это могло случиться только из-за кривого драйвера от 1С или неумения его правильно готовить использовать. Хотя конечно могут влиять и внешние факторы, как например, дефрагментация диска и тому подобное. К примеру, одно из последних нововведений разработчиков sqlite – метод VACUUM. И хотя он также упоминается в драйвере 1С, на деле этот метод никак не используется или я не смог спровоцировать его выполнение. Если вы решите сократить полностью журнал из Конфигуратора, то вместо того, чтобы заново создать файл или основную таблицу журнала, 1С:Предприятие начнет удалять все записи в таблице EventLog. И если у вас он большого размера, то придется запастись терпением. За то при этом все пользователи могут продолжать свою работу в обычном режиме, вот только вряд ли при этом что-то отразится в журнале об их работе. Многопоточность? Нет, не слышал.

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

Службы 1С:Предприятие автоматически создает файл 1Cv8.lgd при первом же обращении будь то конфигуратор или web-приложение. Что интересно база не формируется сразу же целиком, а только по необходимости. К примеру, если установить уровень «Регистрировать ошибки», запустить регламентное задание, то создадутся только две таблицы, пусть и пустые. То есть о выполнении регламентных заданий вы не узнаете, пока не начнется нормальное ведение журнала, а для этого нужно хотя бы раз открыть 1С:Предприятие (в любом режиме). Кстати регламентные задания в журнале отражаются как фоновые. Почему так? Зачем понадобилось два термина?

 

Скрипт создания таблицы EventLog  

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

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

Но есть вопросы. К примеру, для чего нужно было создавать отдельные таблицы используемых портов? Сколько килобайт планировали сэкономить авторы? Видимо это все ради того, чтобы потом быстро показать/использовать в форме отбора. Другого объяснения не нашел. Но опять же для чего надо было создавать поле Name, когда его значение можно было хранить в поле Code. Если у кого есть идеи, поделитесь.

Следующий момент больше похож на ошибку разработчиков. Столкнулся с ней, когда попытался соединить эти таблицы. Дело в том, что ключ metadataCodes  в основной таблице EventLog имеет тип TEXT, хотя должен был быть INTEGER. Выкрутился преобразованием «на лету»: SELECT 0+ metadataCodes FROM … Драйвер ODBC позволил такое проделать. Хотя можно просто изменить структуру таблицы, работоспособность журнала от этого никак не пострадает.

И эта песня тянется уже не один год.

 

 Скрипт для исправления типа поля MetadataCodes (TEXT =664; INTEGER) таблицы EventLog

При любом несложном нарушении структуры базы она будет восстановлена. К примеру, мной были удалены некоторые индексы, и при следующем моем обращении к журналу из главного меню конфигуратора Администрирование – Журнал регистрации все индексы были благополучно восстановлены после небольшой паузы.

Итак, вернемся к файлу журнала, с которого все и началось. Размер его чуть превышал 1 гигабайт, что по меркам авторов sqlite это копейки. Нельзя не отметить всеобщий сарказм администраторов в отношении к 1С, многие относят ее к разряду «для киосков с оборотом 3 рубля». Это, конечно же, отдельная история. Хотя предыдущая статья лишь подтверждает этот момент, особенно аргументы в обсуждении.

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

ЗаписьЖурналаРегистрации(«TEST», УровеньЖурналаРегистрации.Ошибка);

Пример кода

 

20 циклов/замеров по миллиону записей. Размер файла вырос с пары-тройки десятков килобайт до почти трех гигабайт. Обратите внимание, что скорость никоим образом не изменилась, более того даже не деградировала  от того, что файл сильно распух. Все же авторы sqlite правы, говоря, что это копейки.

Так же для контроля скорости записи на диск использовалась программа Process Monitor (Procmon) из набора утилит Sysinternals Марка Руссиновича и Брюса Когсвела, которая лишь подтвердила полученные данные.

 

Вывод

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

25 Comments

  1. Gilev.Vyacheslav

    вроде и делаете все правильно, но не ваше это, не ваше

    во-первых ЗаписьЖурналаРегистрации( не единственный кто пишет

    во-вторых тестировать надо многопоточно

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

    Reply
  2. PerlAmutor

    Согласен с Вячеславом. Тема не раскрыта полностью. Для более менее полноценного теста необходимо создать не менее 1000 фоновых заданий, причем не только писать в журнал параллельно, но и читать. Еще при этом желательно создать стороннюю нагрузку на дисковую подсистему где лежит журнал, чтобы эмитировать работу с контекстными данными, индексацию полнотекстового поиска, работу с TEMPDB и т.д. Кроме того на скорость выборки влияет сложность отборов. У нас, по непонятной причине, на ЖР на базе SQLITE отбор за день где в качестве отбора задавалась ссылка на любой объект базы приводил к полному зависанию фонового процесса навсегда. Проблема ушла только после перехода на старый формат. Отбор стал медленнее, не спорю, но зато результат выдает в конечном итоге.

    Пока я вижу одно решение: самой фирме 1С ввести новый формат ЖР на базе NoSQL. Добавить еще один ключ к запуску агента сервера 1С, который позволит выбрать размещение одного лишь ЖР, а не всей папки srvinfo, т.к. в текущем варианте невозможно её перенести на RAM диск. Если контекстными данными мы еще можем пожертвовать в случае сбоя, то записями в ЖР нет.

    Reply
  3. dmarenin

    сократить полностью журнал можно не только из конфигуратора, и записи она(sql lite) позволяет удалять при других соединениях с базой.

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

    предлагаю автору сделать тест с заранее подготовленным жр на 10-15 гб, и запустить туда запись на 400 сеансов, в 8 рпхостах, и да как уже выше говорилось читать еще в это время. это к тому что «Размер файла журнала регистраций никак не влияет на скорость записи»

    Reply
  4. acanta

    Поднятие кластера не может поделить журнал регистрации на части для онлайн записи к примеру по 200 и 200 с какой-нибудь консолидацией всего где-нибудь в стороне без конкуренции с 400 сеансами?

    Reply
  5. Fox-trot

    посоветуйте, какие мне диски купить для ваших хотелок

    Reply
  6. Gilev.Vyacheslav

    вы что, генератор случайных фраз включаете? )))

    Reply
  7. A_Max

    (5) Причём тут диски?

    Уже давно известно (тем кто занимается администрированием больше чем дале-далее), в чём узкие места ЖР в обоих его ипостасях. И вы своим тестированием не проверили и не выявили ничего полезного.

    Reply
  8. AntonSm

    (2)

    который позволит выбрать размещение одного лишь ЖР, а не всей папки srvinfo, т.к. в текущем варианте невозможно её перенести на RAM диск.

    Можно поставить периодичность ЖР час и скидывать с RAM-диска файлы прошлых часов на другой диск.

    ЖР на другом диске можно просматривать обработкой из инструментов разработчика.

    Как вам такая схема?

    RAM-диск в этом случае не нужен очень большой.

    Reply
  9. Fox-trot

    нет свободных дисков, отсюда и сарказм 🙂

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

    а старый формат видима вернули все же для «киосков»

    жаль, что по теме мало что сказано

    вы все время уходите на какие-то философские темы типа а что если добавить процессов, монопоточность и так далее

    куча терминов… но все вокруг да около

    но самое смешное то, что я все это уже продел. правда не такие количествах, 1000 заданий плодить не стал, мне 50 хватило

    если обратили внимание на картинки во вложении, то это второй график

    всем спасибо

    Reply
  10. herfis

    Убежден, что идея писать первичные логи в SQLite была не от большого ума. Ни гранулярность хранения нормально не настроить, ни ротацию. Всего-то и нужно было — дать больше возможностей кастомизации, чтобы писалось только то что надо, а не «все или ничего». И половина проблем ушла бы сразу. А для агрегаций и быстрого поиска кому надо — можно что-то сверху прикрутить, как весь мир и поступает.

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

    У журнала в SQLite есть только один сомнительный плюс — индексы. Все остальное — явные минусы.

    Reply
  11. Fox-trot

    так там и индексов не хватает lol

    но лично мне задумка нравится. негоже в 21 века хранить данные в текстовиках

    может корпоративы повлияли, тенденция так сказать

    но плюсы очевидны

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

    Reply
  12. herfis

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

    Reply
  13. Gilev.Vyacheslav

    (9)

    штатная гляделка логов никак не годится для файлов большого размера

    но вы говорите что проблем с жр нет, вас бы в передачу «где логика»

    вы все время уходите на какие-то философские темы типа а что если добавить процессов, монопоточность и так далее

    куча терминов… но все вокруг да около

    это вам так кажется

    вы нарушили все условия тестирования

    плюс условия и задачи теста четко не сформулированы

    даже не очень понимаете, какую проблему доказываете

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

    но самое смешное то, что я все это уже продел

    и главное тест не покрывающий полностью, из такого теста ни каких выводов нельзя сделать

    у вас с логикой явно проблемы

    «мы проделали тест и проблем не увидели»

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

    подобные вам рассуждают в стиле:

    В каждом электронном компоненте есть невосполняемый запас дыма. Если этот дым выходит, то деталь перестаёт работать.

    Вот Вам домашнее задание — найдите ошибку в рассуждениях.

    Reply
  14. Fox-trot

    ты снова передергиваешь, сам того видимо не замечая

    все же гляделка это не сам журнал, так что проблем тут не вижу

    тем более, что ею я не пользуюсь от слова совсем

    очередное задание? я почему-то не удивлен. однако замечу, что ты все же не в корпоративном чате, подчиненных здесь нет, опять таки от слова совсем

    ну не понравилась статья, тест, аватар, да мало ли чего еще… так бывает. ничего страшного в этом нет

    и кстати про дым. в нерезиновой трава так себе
    Reply
  15. Gilev.Vyacheslav

    нда, еще раз убеждаюсь, можно объяснить всё, но не всем

    Reply
  16. Denanhel

    По теме у меня возникает вопрос — какого тогда счастья когда я запускаю выборку в журнале за пару месяцев по полю данные пользователи не могут работать? И да до 200 Гб у меня журнал разрастается за пол года, приходится его копировать (требования руководства) и создавать по-новому. Конечно в журнал пишется каждый чих, но я не могу переубедить руководство что так делать не нужно. Согласен sqlite — идея хорошая, но почему бы не сделать журнал переодическим — мне непонятно. Пусть бы писался в отдельные файлы за какой-то определённый период (сам уже выбираешь за какой), так-то лучше, а просмотрщик собирающий данные из разных файлов я думаю создать небольшая проблема…

    Reply
  17. fvadim

    Журнал в 50 Гб, попытка установить отбор при просмотре приводит к фризу всех сеансов (полторы сотни) на неопределённое время с лечением перезапуском службы. Пишутся-то данные без проблем, но смысла в этом становится не сильно много.

    Пришлось уйти на старый формат.

    Reply
  18. Fox-trot

    (16)штатная с одним файлом справится не может, с чего ВНЕЗАПНО она управится с несколькими, пусть даже меньшего размера

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

    Reply
  19. Denanhel

    (18) В том-то и проблема. Логи временами очень важны когда идет «Разбор полетов». в 1С этим не сильно озаботились. Ну есть журнал и есть, а в том что ним пользоваться ни разу невозможно — ваша личная проблема. Насчет кучи гляделок. А стандартную нормальной сделать — не судьба?

    Reply
  20. Denanhel

    (17) Вот-вот… Это мой любимый момент, особенно когда нужно срочны и ты по своей глупости ткнул в отбор, а работаю 50 человек. Они не очень довольны перезапуском службы.

    Reply
  21. Gilev.Vyacheslav

    Лучше бы фирма 1С для старого формата сделала инструмент штатного портирования на субд, причем даже не сильно принципиально какую, а можно и в несколько, в NoSQL, в кубы

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

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

    Reply
  22. herfis

    (21) Да если бы просто сделали возможность тонкой настройки логируемых событий и оптимальные дефолты — уже бы на старом формате у мелко-средних компаний отпало большинство вопросов.

    Reply
  23. dmarenin

    (20)

    (17)

    я вот так решил эти проблемы https://infostart.ru/public/862310

    Reply
  24. JulianK

    журнал регистрации в новом формате дорос до 131 гигабайт. В 1с в результате просматривался лишь небольшой отрезок времени, меньше месяца, остальных записей как будто не замечая. Попытка очистить журнал привела к глобальному фризу с восстановлением только после ручного удаления жураналов и перезапуска сервера. Вернулись на старый формат с разбивкой по месяцам — их удалять хотя бы можно в процессе работы (за предыдущие периоды). Конфигурация типовая.

    Reply
  25. Fox-trot

    (24) был случай: при конвертации журнала с разбивкой по месяцам грохнулся скази диск, то есть был один файловый решили поделить на месяцы… и вот те раз

    диск был на гарантии, но кому от этого легче )

    но то была 8.2, хотя вряд ли там в этом плане что-то серьезно поменялось (

    Reply

Leave a Comment

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