После жалоб пользователей на замедление 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С:Предприятие (в любом режиме). Кстати регламентные задания в журнале отражаются как фоновые. Почему так? Зачем понадобилось два термина?
И только при запуске 1С:Предприятие в режиме конфигуратора или обычного приложения создадутся все оставшиеся необходимые таблицы. Записи создаются по такому же алгоритму. К примеру, есть таблица MetadataCodes, в которой хранятся объекты конфигурации. Но все объекты разом не записываются, хотя это можно было бы сделать, к примеру, при обновлении конфигурации, а записываются только по требованию.
Структура базы нормализована по полной программе. Размер записи основной таблицы равен примерно 140 байт, что совсем немного для такого рода сценария использования как ведение логов.
Но есть вопросы. К примеру, для чего нужно было создавать отдельные таблицы используемых портов? Сколько килобайт планировали сэкономить авторы? Видимо это все ради того, чтобы потом быстро показать/использовать в форме отбора. Другого объяснения не нашел. Но опять же для чего надо было создавать поле Name, когда его значение можно было хранить в поле Code. Если у кого есть идеи, поделитесь.
Следующий момент больше похож на ошибку разработчиков. Столкнулся с ней, когда попытался соединить эти таблицы. Дело в том, что ключ metadataCodes в основной таблице EventLog имеет тип TEXT, хотя должен был быть INTEGER. Выкрутился преобразованием «на лету»: SELECT 0+ metadataCodes FROM ... Драйвер ODBC позволил такое проделать. Хотя можно просто изменить структуру таблицы, работоспособность журнала от этого никак не пострадает.
И эта песня тянется уже не один год.
При любом несложном нарушении структуры базы она будет восстановлена. К примеру, мной были удалены некоторые индексы, и при следующем моем обращении к журналу из главного меню конфигуратора Администрирование – Журнал регистрации все индексы были благополучно восстановлены после небольшой паузы.
Итак, вернемся к файлу журнала, с которого все и началось. Размер его чуть превышал 1 гигабайт, что по меркам авторов sqlite это копейки. Нельзя не отметить всеобщий сарказм администраторов в отношении к 1С, многие относят ее к разряду «для киосков с оборотом 3 рубля». Это, конечно же, отдельная история. Хотя предыдущая статья лишь подтверждает этот момент, особенно аргументы в обсуждении.
Принимая во внимание все вышеперечисленные проблемы, сомнения все же оставались. Мною было решено просто проверить, как влияет рост размера журнала на производительность. Была создана обработка, которая в цикле выполняла одну лишь команду:
ЗаписьЖурналаРегистрации(«TEST», УровеньЖурналаРегистрации.Ошибка);
20 циклов/замеров по миллиону записей. Размер файла вырос с пары-тройки десятков килобайт до почти трех гигабайт. Обратите внимание, что скорость никоим образом не изменилась, более того даже не деградировала от того, что файл сильно распух. Все же авторы sqlite правы, говоря, что это копейки.
Так же для контроля скорости записи на диск использовалась программа Process Monitor (Procmon) из набора утилит Sysinternals Марка Руссиновича и Брюса Когсвела, которая лишь подтвердила полученные данные.
Вывод
Размер файла журнала регистраций никак не влияет на скорость записи. Конечно, надо учитывать еще много других факторов. Но текущая задача была лишь проверить как сама 1С:Предприятие работает с файлами sqlite большого размера.
