С отборами в Журнале Регистрации 1С проблемы есть уже очень давно — работают они очееееееееееееень мееееееееееееедленно. Не особенно помог и переход на формат SQLite3.
Данная проблема уже давно не осталась без различных решений:
- Некоторые мееедленно отбирают нужные данные из копий базы с подкинутым ЖР. Просто, чтобы не вешать основную базу.
- Другие научились хранить записи в таблицах на SQL-сервер и работать с данными быстрее, но им нужно загружать данные в СУБД. Да и места и ресурсов база для большого ЖР может потребовать изрядно.
- Самые продвинутые научились выгружать данные в Elastic Search и хранить там полную копию собранного Журнала Регистрации, а так же умеют выбирать данные с превосходной скоростью.
У нас же есть особенное решение:
Мы научились строить индексы для имеющихся Журналов Регистрации (без выгрузок и трансформаций) и молниеносно отбирать данные в любых разрезах.
Ключевые особенности:
- Используется движок Luscene (как и в ElasticSearch).
- Не нужно ничего настраивать — всё работает из коробки — установил и наслаждайся.
- Работа и со старым, и с новым форматом Журнала Регистрации 1С.
- Обработка повреждённых файлов Журнала Регистрации старого формата — вся уцелевшая информация будет из них получена. Более никаких записей "Журнал Регистрации повреждён"
- Журнал Регистрации индексируется непосредственно из файлов в формате 1С на Сервере Приложений. Никаких COM-Соединений и доступа в базы.
- Индекс занимает до 30% от размера исходных файлов Журнала Регистрации.
- Скорость отбора — очень и очень быстрый отбор. Даже по кусочку комментария.
- В нашей обработке реализовано отображение общего количества событий ЖР в соответствии с отбором.
Видео ниже демонстрирует отборы в журнале старого формата размером 95 ГБ.
Системные требования:
- Windows x64
- Версия платформы 1С не ниже 8.3.5.1068
- Версия конфигурации 1С не имеет значение
Инструкция по установке:
- Программу необходимо устанавливать на сервере приложений 1С, если он один. Либо на том сервере кластера, для которого установлены требования назначения функциональности "Сервис журналов регистрации".
- Выберите каталог установки на диске, где достаточно свободного места для построения индексов. Их размер может достигнуть 30% от размеров файлов ЖР.
- После запуска службы начнётся индексация Журналов Регистрации на этом Сервере Приложений.
- Открыть в любом клиенте 1С внешнюю обработку из каталога установки (Journal2Ct.epf). Обработка обращается к серверу приложений 1С по http на порт 8984 за данными, она не ломится в интернет. Если у Вас кластер и Журнали2Ста установлен на отдельном сервере, то в форме обработки нужно будет указать его имя.
Важно: программа индексирует журналы регистрации напрямую на том сервере, на котором она установлена. Если у Вас в кластере несколько серверов, то журналы регистрации окажутся размазаны между ними.
История версий
2024.11.28
Добавил в обработку все возможные сиволы UTF-8, исключая квадратное письмо Пагба-ламы.
2024.11.24
Обновил Solr до 8.3
Оптимизировал индексацию — размер индекса снижен (старый и новый индексы несовместимы, установка поверх не заработает, ставить эту версию только после удаления предыдущей и её индексов)
Переделал механизм работы с несколькими службами
2024.10.23
Обновил JavaVM в сборке
2024.09.29
Дополнение в регулярном выражении обработки текстовых ЖР — добавлены символы неразрывного пробела и вертикальной черты. События с такими символами ранее не попадали в индекс.
2024.09.13
Исправлена ошибка, возникавшая в некоторых случаях с базами, у которых в названии есть русские буквы
2024.09.12
Устранена цикличной обработки на базах с отключенным ЖР нового формата
Строка размещения каталога может содержать любые символы
2024.08.26
Роман поймал и разобрался с ситуацией, когда база в кластере прописана, а на диске её нет. В этом случае была значительная утилизация CPU. Этот нюанс учтён в новой сборке и не нагружает CPU.
Для обновления ставить можно поверх (просто запустить установщик). Если выскочит сообщение об ошибке servicemanager.pyd, то её нужно игнорировать.
2024.08.22
Solr обновлён до версии 8.2.0
2024.07.17
Java обновлена до версии 1.8.0_221
2024.06.11
Ярлыки создавались только под устанавливающим пользователем
Solr обновлён до версии 8.1.1
2024.06.11
Обновлена версия Java до 1.8.0_211
2024.04.02
Исправлена ошибка при отборе по полю данные, возникающая в редких случаях.
2024.03.28
Реализована работа с несколькими службами сервера 1С:Предприятие, развёрнутых на одном сервере (даже если они разных версий).
Исправлена ошибка в индексации файлов старого формата для баз, в которых нет транзакций.
2024.03.25
В форме обработки реализован выбор сервера Журнали2Ст (для многосерверных кластеров).
Значительно ускорена обработка на серверах с большим количеством баз и многочисленными (>10000) файлами ЖР.
2024.03.23
Устранены проблемы в работe со "сломанными" Sqlite3 базами.
2024.03.20
Оптимизации в парсере старого формата ЖР. Теперь он работает ещё быстрее.
2024.03.19
Обновление поискового движка.
2024.03.14
Повышена стабильность работы при индексации больших (>100 Гб) ЖР нового формата.
2024.03.12
Комментарий в обработке толстого клиента обрезался до 1000 символов.
2024.03.05
Обновление движка полнотекстового поиска.
Снижен размер дистрибутива.
2024.03.04
Корректно обрабатываются любые символы в именах баз на кластере.
2024.03.03
Добавил поток для прогревания кэша. Первый запуск больше не будет долгим.
2024.02.28
Улучшения в работе формы отбора для тонкого клиента.
Исправление ошибок.
2024.02.27
Добавлена автоматическое подключение к индексации новых баз, создаваемых в кластере уже после установки программы.
2024.02.24
Поправлен расчёт % от проиндексированного журнала.
Выключен лог отладочных сообщений по умолчанию.
Добавлена кнопка выбора количества значений в обработке тонкого клиента.
Добавлена пара описаний типов событий, отсутствующий ранее.
Процесс обновления больше не вызывает невозможность удаления компоненты службы.
2024.02.15
Заведён Change-лог в публикации.
Оптимизирована работа с новым форматом ЖР.
Исправлена ошибка при работе с обрезанным журналом нового формата.
Снижена нагрузка на CPU при индексации старого формата.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Видео не доступо.
Поясните, пожалуйста, 2-х недельная лицензия за стартмани? А потом что, за рубли покупать?
(1) Отдельно ссылкой
(2) Исправил описание. Хвосты от коммерческой публикации. Спасибо за Вашу внимательность.
Интересно было бы почитать про техническую составляющего данного решения, хотя бы в общих чертах.
(5) Служба индексирует имеющиеся жр напрямую в Solr. Обработка запрашивает у службы отбор, служба стучится в Solr и возвращает данные, обработка обогащает их и выводит.
Сразу после запуска служба откусила почти 1Гб оперативки. Она всегда так будет делать или только до тех пор, пока не проиндексирует все журналы на сервере?
И еще вопрос, индексы она хранит прямо в своем собственном каталоге установки?
(9) Java сразу откусит два гига. Оперативы потребляет до 10% от размера ЖР. Но макс размер ограничен в 32ГБ.
Можно ли указывать какие журналы требуется индексировать?
Вообще было бы круто как в Виндоус, отдельный журнал регистрации для конфигуратора и для пользовательского режима.
(10) На текущий момент в этот некоммерческий продукт новые фичи будут добавляться очень ограниченно.
(9)
Да.
(11) java так и откусила, но потом расход памяти снизился до 300 Мб.
Немного потестил — действительно круто работает!
Служба самой Журнали2Сты проц нагрузила на 30% — это тоже будет только пока не построит индексы, или так все время?
А скажите, плз, какие отличия от коммерческой версии? Мне просто очень нравится работа «из коробки», думаю и моему руководству она тоже понравится. И дайте плз ссылку на коммерческий аналог.
(14) Вчера имеющеяся коммерческая версия стала бесплатной. Рад, что Вам нравится работа продукта. Если будут какие-то изменения, то я отражу их в этой публикации.
По CPU — на время индексации потребление CPU будет больше, потом снизится.
Добрый день!
Подскажите, пожалуйста, в системных требованиях указана Версия платформы 1С не ниже 8.3.5.1068, есть ли разница если версия платформы выше, но конфигурация в режиме совместимости?
Спасибо.
(16) Там используется функционал, появившийся в 8.3.5.1068 ( не скажу на память что именно ). Можете попробовать. Если получите ошибку — код обработки открыт.
(17) Я прикинул количество своих событий в ЖР и решил возобновить свою старую идею заливки ЖР в elasticsearch.
Посмотрел ради интереса количество событий в ЖР в одной из своих баз за 1 минуту и количество в виде 44к немного меня расстроило.
(18) Это с включенными данными по транзакциями? (в событиях по умолчанию отображение транзакций отключено)
(19) Это с максимальным уровнем протоколирования в настройках журнала регистрации + куски кода в конфигурации для доп. логирования событий.
Службы Журнали2Сты стабильно расходует 30% процессора. Если и разворачивать ее в продуктиве, то видимо, надо поднимать отдельный рабочий сервер в кластере чисто для ЖР.
(21) 30% у вас после завершения начальной индексации или во время неё?
(22)
Я свой локальный рабочий ПК оставлял на выходные специально. Индексы по идее, должны были уже построиться. Файл индекса занял 40 Гб (при размере самого ЖР в 100 Гб). Утром проверил — служба расходует 30 проц процессора. Обработка показывает «готовность данных» = 99%
(23) Посмотрите в ПУСКе в Журанли2Ст = > Панель управления.
(24) посмотрел, пишет — 100% обработано. Расход цп такой же по прежнему
(25) Ответил про диагностику в ЛС.
(25) Потрачено.
в описании
однако далее по тексту
Не нужно ничего настраивать — всё работает из коробки — установил и наслаждайся.
маркетинг такой нонче?
Индексация ЖР будет для всех баз или можно настраивать для конкретных?
(30) Для всех, причём при добавлении новых баз они тоже начнут индексироваться.
Можно как то подружить с Линукс-сервером? (папку с журналом расшарить, Журналидвасту как-то объяснить, куда лезть)
(29) Спасибо за Ваше замечание.
(32) Можете выделить отдельный сервер для журналов регистрации под Windows (через требования назначения функциональности, лицензия 1С для сервера в этом случае не должны быть нужна) и использовать его.
Программа установилась, все логи проиндексировались. При открытии обработки — она пустая, в сообщении: «Exception8 ‘[НазваниеБазы]'»
В чем может быть ошибка? Или сейчас работает только коммерческая версия
(35) Всё должно работать. Ответил по диагностике в ЛС.
Народ, поделитесь, кто уже пользовался на рабочем сервере?
Пытались запустить на рабочем сервере.
При во таких параметрах службы программа не видит журналы регистрации на сервере;
«C:Program Files1cv88.3.12.1529in
agent.exe» -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d «E:user-1c1c_cachesrvinfo»
(38) Исправлено.
(37)
Мы начали использовать. Впечатления очень положительные.
Были кое-какие ошибки в работе службы, но Алексей все оперативно починил.
У нас довольно нагруженная база, в день ЖР прирастает на 3 Гб, количество событий в секунду 150-160.
3 Гб журнал программа проиндексировала за 20 минут. Индексы весят примерно 20% от веса журнала.
Отборы работают мухой, даже когда накладываешь отбор на комментарий или на представление данных. И при этом не «вешают» все приложение у всех пользователей.
По расходу ресурсов на сервере — java потребляет примерно 1.5 Гб оперативки, сама служба — 80 Мб. Процессорное время тратится не более 5-10%.
(40) Звучит очень убедительно в пользу использования. Эти ресурсы стоят того.
Спасибо за отзыв.
Параметры службы 1С: «C:Program Files1cv88.3.12.1714in
agent.exe» -srvc -agent -regport 1541 -port 1540 -d «E:srvinfo-upp82»
В файле Journal2ctdebugJournal2Ct.10504.log:
2019-09-15 18:12:22.194595::::::service start
2019-09-15 18:12:22.194595::::::service start threads
2019-09-15 18:12:22.194595::::::В файле конфигурации нет информационных баз
2019-09-15 18:12:22.194595::::::Debug enabled = 1
2019-09-15 18:12:22.194595:::my little cherry:::Thread initialized
2019-09-15 18:12:22.210195:::my pretty solr thread:::Thread initialized
2019-09-15 18:12:22.210195:::my pretty solr thread:::starting «injava.exe» -server -Xms -Xmx -Duser.timezone=UTC -XX:NewRatio=3 -XX:SurvivorRatio=4 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=8 -XX:+UseConcMarkSweepGC -XX:ConcGCThreads= -XX:ParallelGCThreads= -XX:+CMSScavengeBeforeRemark -XX:PretenureSizeThreshold=64m -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50 -XX:CMSMaxAbortablePrecleanTime=6000 -XX:+CMSParallelRemarkEnabled -XX:+ParallelRefProcEnabled -XX:-OmitStackTraceInFastThrow -XX:+ExitOnOutOfMemoryError -Xss256k -Dsolr.log.dir=»serverlogs» -Dlog4j.configuration=»file:server
esourceslog4j2.xml» -DSTOP.PORT=7983 -DSTOP.KEY=solrrocks -Dsolr.log.muteconsole -Dsolr.solr.home=»serversolr» -Dsolr.install.dir=»» -Dsolr.default.confdir=»serversolrconfigsets\_defaultconf» -Djetty.host= -Djetty.port= -Djetty.home=»server» -Djava.io.tmpdir=»server mp» -jar «start.jar» «—module=http» «»
2019-09-15 18:12:22.210195:::list lgp:::Thread initialized
2019-09-15 18:12:22.210195:::lgp parser:::Thread initialized
2019-09-15 18:12:22.210195:::list lgd:::Thread initialized
2019-09-15 18:12:22.210195:::lgd parser:::Thread initialized
2019-09-15 18:12:22.210195:::IB monitor:::Thread initialized
2019-09-15 18:12:22.210195:::warming cache:::Thread initialized
2019-09-15 18:12:37.217203::::::Exception srv_1c list index out of range
Процесс java не стартует, индексирование ЖР не производится.
(42) Добрый день. Спасибо за сообщение, ответил в ЛС.
У меня есть обрезанные файлы логов в формате SQlite (один файл = 1 месяц). Каждый файл порядка 100 Гб, лежат на локальной машине. Что я должен сделать, чтобы проанализировать их?
Поднять отдельный сервер, подсунуть туда логи? Какой наиболее простой путь?
(44) Ответил в ЛС.
не видит папку с логами если используется swpuser.ini с указанием папки с логами
(46) Всё так. Добавляю в таск-лист для реализации.
Добрый день! Возник вопрос (возможно невнимательно читал). будет работать такая схема?
Схема:
1) Журналы регистрации считываются в Журнали2Ст
2) Журналы регистрации очищаются/удаляются/нечитаемы
3) В Журнали2Ст остаются данные очищенных журналов? или он обрабатывает только те, что существуют?
Спасибо!
(48) Добрый день. В текущем релизе этого нет. Вообще я делал так изначально.
А почему вы хотите очищать ЖР? Если проблема в том, что они занимают много места, то здесь выручает дедупликация.
(49)Спасибо за ответ. Интересует именно хранение. Тут скорее имеет ситуация не «очищать», а «битый», либо «удаленный».
(50) Могу добавить в wishlist. Но быстро не сделаю — приоритет сейчас другой.
(51) На ваше усмотрение. Я думаю этот функционал не всем нужен.
У меня тоже есть отдельно лежащие логи. Напишите пожалуйста и мне как их обработать.
(53) Пока — только подложить в одну из баз (или копий баз).
(40) Мы встречались на прошлой неделе и я консультировался по этому вопросу. Попытался написать в ЛС, но не могу из за ограничений инфостарта. Напишите мне пожалуйста