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

Администрирование - Журнал регистрации

sqlite журнал регистраций

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

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

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

Итак, журнал представляет из себя не что иное, как базу данных 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 большого размера.

21

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Gilev.Vyacheslav 1799 23.09.18 00:08 Сейчас в теме
вроде и делаете все правильно, но не ваше это, не ваше

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

не просто так в последних версиях платформы разработчики вернули возможность интерактивно выбирать старый формат...
SerebanSK; collider; master555; kalyaka; Danila-Master; A_Max; Dream_kz; +7 1 Ответить
2. PerlAmutor 33 23.09.18 08:26 Сейчас в теме
Согласен с Вячеславом. Тема не раскрыта полностью. Для более менее полноценного теста необходимо создать не менее 1000 фоновых заданий, причем не только писать в журнал параллельно, но и читать. Еще при этом желательно создать стороннюю нагрузку на дисковую подсистему где лежит журнал, чтобы эмитировать работу с контекстными данными, индексацию полнотекстового поиска, работу с TEMPDB и т.д. Кроме того на скорость выборки влияет сложность отборов. У нас, по непонятной причине, на ЖР на базе SQLITE отбор за день где в качестве отбора задавалась ссылка на любой объект базы приводил к полному зависанию фонового процесса навсегда. Проблема ушла только после перехода на старый формат. Отбор стал медленнее, не спорю, но зато результат выдает в конечном итоге.

Пока я вижу одно решение: самой фирме 1С ввести новый формат ЖР на базе NoSQL. Добавить еще один ключ к запуску агента сервера 1С, который позволит выбрать размещение одного лишь ЖР, а не всей папки srvinfo, т.к. в текущем варианте невозможно её перенести на RAM диск. Если контекстными данными мы еще можем пожертвовать в случае сбоя, то записями в ЖР нет.
Gilev.Vyacheslav; +1 Ответить
8. AntonSm 24.09.18 15:10 Сейчас в теме
(2)

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


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

Как вам такая схема?
RAM-диск в этом случае не нужен очень большой.
3. dmarenin 76 23.09.18 12:41 Сейчас в теме
сократить полностью журнал можно не только из конфигуратора, и записи она(sql lite) позволяет удалять при других соединениях с базой.
проблема ожиданий отклика рабочих процессов связана с рагентом, он монопольно держит файл(handle), рпхосты сбрасывают ему свою очередь на запись, отсюда и просадка в производительности. это к тому что "решено было изучить вопрос вдоль и поперек."

предлагаю автору сделать тест с заранее подготовленным жр на 10-15 гб, и запустить туда запись на 400 сеансов, в 8 рпхостах, и да как уже выше говорилось читать еще в это время. это к тому что "Размер файла журнала регистраций никак не влияет на скорость записи"
A_Max; Gilev.Vyacheslav; +2 Ответить
4. acanta 45 23.09.18 13:02 Сейчас в теме
Поднятие кластера не может поделить журнал регистрации на части для онлайн записи к примеру по 200 и 200 с какой-нибудь консолидацией всего где-нибудь в стороне без конкуренции с 400 сеансами?
5. Fox-trot 91 24.09.18 11:01 Сейчас в теме
посоветуйте, какие мне диски купить для ваших хотелок
7. A_Max 16 24.09.18 14:57 Сейчас в теме
(5) Причём тут диски?

Уже давно известно (тем кто занимается администрированием больше чем дале-далее), в чём узкие места ЖР в обоих его ипостасях. И вы своим тестированием не проверили и не выявили ничего полезного.
Gilev.Vyacheslav; +1 Ответить
6. Gilev.Vyacheslav 1799 24.09.18 12:58 Сейчас в теме
вы что, генератор случайных фраз включаете? )))
9. Fox-trot 91 24.09.18 15:31 Сейчас в теме
нет свободных дисков, отсюда и сарказм :)
а если по делу, то штатная гляделка логов никак не годится для файлов большого размера. поэтому пришлось рисовать свою конфигурацию для этого. не самое оптимальное решение в плане ресурсоемкости конечно же, но за то для пользователей все максимально понятно и просто
а старый формат видима вернули все же для "киосков"
жаль, что по теме мало что сказано
вы все время уходите на какие-то философские темы типа а что если добавить процессов, монопоточность и так далее
куча терминов... но все вокруг да около
но самое смешное то, что я все это уже продел. правда не такие количествах, 1000 заданий плодить не стал, мне 50 хватило
если обратили внимание на картинки во вложении, то это второй график
всем спасибо
13. Gilev.Vyacheslav 1799 25.09.18 12:09 Сейчас в теме
(9)
штатная гляделка логов никак не годится для файлов большого размера

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

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

и главное тест не покрывающий полностью, из такого теста ни каких выводов нельзя сделать
у вас с логикой явно проблемы
"мы проделали тест и проблем не увидели"
это не означает что проблемы нет, это означает что тест мог условий воспроизведения проблемы не создать
подобные вам рассуждают в стиле:
В каждом электронном компоненте есть невосполняемый запас дыма. Если этот дым выходит, то деталь перестаёт работать.
Вот Вам домашнее задание - найдите ошибку в рассуждениях.
WellMaster; +1 Ответить
10. herfis 270 24.09.18 15:51 Сейчас в теме
Убежден, что идея писать первичные логи в SQLite была не от большого ума. Ни гранулярность хранения нормально не настроить, ни ротацию. Всего-то и нужно было - дать больше возможностей кастомизации, чтобы писалось только то что надо, а не "все или ничего". И половина проблем ушла бы сразу. А для агрегаций и быстрого поиска кому надо - можно что-то сверху прикрутить, как весь мир и поступает.
Слава богу, вернули штатную возможность переключаться на текстовый лог и не нужно больше извращаться.
У журнала в SQLite есть только один сомнительный плюс - индексы. Все остальное - явные минусы.
11. Fox-trot 91 24.09.18 16:03 Сейчас в теме
так там и индексов не хватает lol
но лично мне задумка нравится. негоже в 21 века хранить данные в текстовиках
может корпоративы повлияли, тенденция так сказать
но плюсы очевидны
другой вопрос, что готовить тож надо уметь. и вот тут есть вопросы к разработчикам сие чуда
12. herfis 270 24.09.18 16:05 Сейчас в теме
(11) Вернее не только индексы. В общем, оптимизация на выборку данных (страничная организация данных и все такое). Фишка в том, что для первичного лога это вовсе не главное.
14. Fox-trot 91 25.09.18 12:59 Сейчас в теме
ты снова передергиваешь, сам того видимо не замечая
все же гляделка это не сам журнал, так что проблем тут не вижу
тем более, что ею я не пользуюсь от слова совсем
очередное задание? я почему-то не удивлен. однако замечу, что ты все же не в корпоративном чате, подчиненных здесь нет, опять таки от слова совсем
ну не понравилась статья, тест, аватар, да мало ли чего еще... так бывает. ничего страшного в этом нет

и кстати про дым. в нерезиновой трава так себе
15. Gilev.Vyacheslav 1799 25.09.18 18:16 Сейчас в теме
нда, еще раз убеждаюсь, можно объяснить всё, но не всем
Morkhe; Fox-trot; +2 Ответить
16. Denanhel 26.09.18 10:17 Сейчас в теме
По теме у меня возникает вопрос - какого тогда счастья когда я запускаю выборку в журнале за пару месяцев по полю данные пользователи не могут работать? И да до 200 Гб у меня журнал разрастается за пол года, приходится его копировать (требования руководства) и создавать по-новому. Конечно в журнал пишется каждый чих, но я не могу переубедить руководство что так делать не нужно. Согласен sqlite - идея хорошая, но почему бы не сделать журнал переодическим - мне непонятно. Пусть бы писался в отдельные файлы за какой-то определённый период (сам уже выбираешь за какой), так-то лучше, а просмотрщик собирающий данные из разных файлов я думаю создать небольшая проблема...
WellMaster; solary; +2 Ответить
18. Fox-trot 91 26.09.18 17:32 Сейчас в теме
(16)штатная с одним файлом справится не может, с чего ВНЕЗАПНО она управится с несколькими, пусть даже меньшего размера

(17)на деле есть целая куча гляделок и прочего для управления журналом. так сказать на любой кошелек. но пользоваться штатным инструментом для просмотра я перестал и вам всем советую отказаться от него
Denanhel; acanta; +2 Ответить
19. Denanhel 27.09.18 07:39 Сейчас в теме
(18) В том-то и проблема. Логи временами очень важны когда идет "Разбор полетов". в 1С этим не сильно озаботились. Ну есть журнал и есть, а в том что ним пользоваться ни разу невозможно - ваша личная проблема. Насчет кучи гляделок. А стандартную нормальной сделать - не судьба?
Gilev.Vyacheslav; +1 Ответить
17. fvadim 6 26.09.18 16:52 Сейчас в теме
Журнал в 50 Гб, попытка установить отбор при просмотре приводит к фризу всех сеансов (полторы сотни) на неопределённое время с лечением перезапуском службы. Пишутся-то данные без проблем, но смысла в этом становится не сильно много.
Пришлось уйти на старый формат.
WellMaster; Gilev.Vyacheslav; Denanhel; +3 Ответить
20. Denanhel 27.09.18 07:41 Сейчас в теме
(17) Вот-вот... Это мой любимый момент, особенно когда нужно срочны и ты по своей глупости ткнул в отбор, а работаю 50 человек. Они не очень довольны перезапуском службы.
23. dmarenin 76 29.09.18 20:38 Сейчас в теме
21. Gilev.Vyacheslav 1799 27.09.18 14:20 Сейчас в теме
Лучше бы фирма 1С для старого формата сделала инструмент штатного портирования на субд, причем даже не сильно принципиально какую, а можно и в несколько, в NoSQL, в кубы
очевидно же что это инструмент отложенного анализа, значит не обязательно читать оттуда, куда первоначально пишется, можно и из реплик

пока выглядит это все как "озаботились только записью, но не последующим чтением, да и с записью сделали кое как".
Denanhel; herfis; +2 Ответить
22. herfis 270 27.09.18 14:42 Сейчас в теме
(21) Да если бы просто сделали возможность тонкой настройки логируемых событий и оптимальные дефолты - уже бы на старом формате у мелко-средних компаний отпало большинство вопросов.
Оставьте свое сообщение