1с журнал регистрации зависает
Проблема: На сервере растут логи баз на платформе 8.3.
Необходимо: Часть логов, например, за месяц, оставить доступными напрямую из базы, остальные обрезать и хранить на других дисках. Делать это необходимо автоматически.
Как было раньше(8.1 и 8.2): В конфигураторе можно было указать настройку: «Разделять хранение журнала по периодам» и указать период, например, Неделя. Таким образом, каждая неделя логов хранилась в отдельном файле. Батником копировались и архивировались старые логии на отдельный диск, чтобы они не занимали место на сервере. При необходимости посмотреть «древний» лог, мы возвращали файл за требуемый период на место и просматривали его стандартными средствами 1С.
Как нынче в 8.3: Журнал регистрации хранится в файле 1Cv8.lgd – это файл базы данных sqlite. Настройка «Разделять хранение журнала по периодам» в конфигураторе отсутствует. Осталась кнопка «Сократить», с помощью которой обрезается часть журнала и переносится в указанный файл. Однако после этого размер логов не уменьшается. Что нужно сделать, чтобы размер файла уменьшился, напишу чуть ниже.
Напомню, что все должно работать автоматически. Конфигурация типовая, поэтому трогать ее не будем.
Что было сделано: В планировщике заданий добавил задание, которое выполняет cmd-файл, который запускает 1С с параметрами. В параметре "/Execute", указан путь до обработки, которая копирует часть журнала регистрации в файл, затем эту часть обрезает.
В обработке воспользовался процедурами по работе с журналом регистрации:
Обработку запускаю cmd-файлом:
В параметре «/С» передается период деления журнала регистрации (День / Неделя / Месяц / Год) и путь до места, где будут храниться обрезанные логи.
После сокращения журнала регистрации размер файла журнала регистрации не изменяется. Чтобы он изменился, необходимо остановить агент сервера и выполнить команду vacuum. Затем запустить службу агента сервера. В планировщике заданий добавил задание, которое выполняет следующий cmd-файл:
Утилиту sqlite3.exe можно скачать с официального сайта
Есть идея более простого обрезания и сохранения логов без запуска 1С на сервере с обработкой: можно останавливать агент сервера, переименовывать файл 1Cv8.lgd и запускать сервер. При первом запуске 1С будет создан новый пустой файл журнала регистрации. Главный минус этого варианта: если после переименования файла потребуется посмотреть журнал регистрации, то придется открывать журнал из внешнего файла, который может лежать на недоступном для пользователя диске сервера. В варианте же приведенном выше, в журнале будет храниться история не меньше, чем за указанный период (День / Неделя / Месяц / Год).
В общем-то и все. Если есть замечания и дополнения, добро пожаловать в комментарии. Все важные нюансы обязательно добавлю в статью. Спасибо.
И становится невозможным повторное подключение к базе. Как это можно лечить, есил это как-то лечится?
(3) Это скорее разработчики, которые вместо нормальной СУБД взяли нечто, не обеспечивающее нормальной многопользовательской работы.
(6) Что тот, что другой - тормозят. Только один еще и блокирует запись. Что мешало добавить настройки для базы ЖР на любом поддерживаемом SQL (MS SQL, PostgreSQL и т.д.)? Это, как минимум, не сложнее встраивания SQLite. Зато никаких проблем с масштабированием.
Как раз только завершил "минипроект" по перегрузу данных из SQLite в отдельную базу 1С на MSSQL. При больших объемах данных в ЖР наверное никакой формат не поможет. SQLite блокируется на запись, пока не выдаст нужные данные (да и читает как-то странно - любым вьювером делаешь запрос и быстрее выводится чем платформой 1С). Текстовый формат - если большой период выборки и данные разделяются на файлы по периодам (по дням, например), то при чтении сервер 1С генерит много фоновых заданий для выборки информации из текстовых файликов (в идеале - 1 ФЗ на файл), а такое кол-во соединений не всякий сервер потянет. Возможно сильный рост ЖР можно сдержать, настроив регистрацию только ошибок и предупреждений.
У нас файл lgd за полгода разросся на +100Г. 80% информации в нем были события транзакций (Begin, Commit, Rollback) - их просто не стали тащить в базу MSSQL.
(16) Если уж в 1с решили использовать СУБД в качестве хранилища для ЖР, лучше было бы использовать не блокировочник, а версионник. Тот же firebird имеет встраиваемую версию. А он позволяет писать без блокировок при чтении.
(18) Платформа 1С пока еще не умеет с firebird, а делали не только хранилище, но и отчеты по данным, и поиски в динамическом списке, и регл.задания там же по закачке/обрезке ЖР пакетной. А еще и некоторое из БСП прикрутили.
(19) Значит наоборот, для чтения лучше. Короче в какую-то сторону перекос (по сравнению с текстовым).
Стандартный подход к логированию - локальный лог писать в текст с разбитием на файлы по периодам. Просто. Быстро. Надежно. Удобно сопровождать. А при необходимости тяжелых агрегаций и быстрых выборок - перевыгружать в что-то большое и умное. Типа того же сиквела.
А в 1С в чью-то "светлую" голову пришла идея скрестить ежа и ужа (я про скулайт).
(0) не используйте ЖР в пользовательском режиме, там тупит не сам ЖР а то как его на форму затащили.
откройте его из конфигуратора.
новый формат куда лучше чем старый, у меня 40 гигов на старом формате вешал сервак а на новом все нормально (относительно)
Внимание! Данный форум является модерируемым.
Для получения к нему доступа необходимо зарегистрироваться или авторизоваться на сайте.
Добрый день. Столкнулась со следующей проблемой. В справочнике Пользователи изменила полное наименование (добавила отчество, больше ничего не трогала), и теперь в журнале регистрации, когда пытаюсь сформировать историю только по этому пользователю, то ничего не отображается, а когда смотрю весь журнал регистрации, то вижу, что в колонке Имя пользователя данный пользователь написан как раньше, без отчества. Как же сформировать журнал регистрации по этому пользователю?
Добрый день.
Какими средствами формируется журнал регистрации?
Дело в том, что в журнале регистрации не хранятся ссылки. В противном случае объекты (в данном случае пользователи) не смогут быть удалены, т.к. появятся битые ссылки. Имя пользователя фиксируется в журнале в том виде, какой он был на момент создания записи в журнале.
Сейчас заметила, что если формировать журнал регистрации через Сервис - Журнал регистрации, то действительно имя указывается верное, то которое сейчас. А вот старое (до изменения) имя, не правильное, отображается, если формировать журнал регистрации через АРМ (администратор) на вкладке Журнал регистрации. С чем может быть связано различие, при формировании из разных мест?
Добрый день.
Вы пробовали после внесенных изменений зайти через того пользователя, у которого изменили данные?
да, пробовала, все зашлось. Но и после этого имя в журнале старое. Мне всех больше не понятно, почему при отборе по этому пользователю (из справочника пользователи) в журнале 0 позиций, хотя данный пользователь работает в базе
В АРМ администратора выводится та информация, которую возвращает платформа. И именно имя пользователя это строка, которая фиксируется в журнале на момент возникновения события (это имя нами и выводится).
Что касается текущего имени в журнале (тот что формируется средствами платформы) то это уже какая то постобработка полученных данных.
Добавим индикатор текущего имени пользователя как отдельная колонка.
Добрый день.
Не стал создавать новой темы.
У нас возникла проблема с журналом регистрации - зависает.
Конфигурация Альфа Авто Автосалон 5
Релиз 5.0.05.08
Платформа 8.2.16.368
Конфигурация сервера E5430 2,66 12Gb ОЗУ
WinServer 2008 R2
БД SQL 2008 Standart
Количество пользователей 15-20 человек.
БД Альфа ведется с начала 2012 года с учетом выгруженной из старой БД.
Объем документов примерно 20-40 заказ нарядов в день.
Журнал регистрации ведется чуть менее полугода с внедрения новой версии. Специально его никогда не настраивали, все настройки по умолчанию.
В данный момент при просмотре, фильтрации, или попытке получить какую либо выборку, журнал "намертво" зависает, приходится завершать сеанс. Это не зависит от степени загрузки БД, пробовали и тогда, когда никого из пользователей в базе нет, а также и от места запуска журнала (в режиме 1С Предприятия или Конфигуратора)
А просматривать и фильтровать журнал по пользователям в настоящий момент нужно постоянно.
В финансовых решениях консолидационного класса или класса ERP предлагается функциональность, связанная с составлением оперативных или мастер-бюджетов, например, работа с бюджетом доходов и расходов.
Экземпляр бюджета — это хрестоматийный пример сложной формы, где есть:
- данные в разрезе каждого месяца года (в колонках);
- группировка по настраиваемой структуре разделов и статей (в строках);
- возможность внесения изменений онлайн;
- автоматический пересчет сумм зависимых формул;
- отрисовка плана и факта рядом на пересечении месяца и статьи;
- вывод в будущих месяцах плановых значений в ячейках факта.
Как видно, логика работы достаточно нагруженная и, как следствие, данных на форме много.
Руководитель подразделения открывает форму экземпляра бюджета и долго ждет ее открытия. Если время ожидания слишком велико, то в конечном итоге менеджер переходит для осуществления процесса бюджетирования в табличный инструмент класса Excel.
После разработки и включения в рабочую базу оказалось, что открытие формы бюджета в терминах структур разделов и статей компании занимает 1,5 минуты и более. Это неприемлемо, тем более что основные пользователи системы — руководители подразделений, и без того сталкивающиеся с нехваткой времени.
Мы поставили перед собой задачу сократить открытие такой формы до времени
Программная и аппаратная инфраструктура
- Нетиповая конфигурация собственной разработки.
Замечание: подобные проблемы могут также быть актуальны для иных систем класса ERP, например:
Используется трехзвенная клиент-серверная архитектура с доступом тонкого клиента через веб-сервер. Сервер СУБД и Сервер 1С:Предприятия совмещены на одной машине.
Сервер СУБД
- Процессор: Intel Xeon CPU E5-2637 v2, 2 процессора 3,5 Ghz.
- Память: 96 GB (разрешено потреблять СУБД не более 73728 MB).
- Жесткий диск SSD.
- MSSQLServer 2014 (12.0.4237.0).
- MS Windows NT 6.1 (7601).
Сервер «1С:Предприятие»
- Тот же сервер, что и сервер СУБД.
- Память: доступна вся свободная память, то есть, не менее 24576 MB.
Веб-сервер
- Процессор: Intel core 2 DUO E7500 2,93 GHz.
- Память: 4 GB.
- MS Internet Information Services 8.5.96.
- MS Windows Server 2012 R2.
Тонкий клиент
- Процессор: Intel Core i5.
- Память: 16 GB.
- Диск SSD.
- 1С 8.3.14.1694 — тонкий клиент.
- MS Windows 10.
Ищем причину медленного открытия формы и устраняем ее в «1С»
1. Для начала расследования снимаем замер производительности в «1С» процесса открытия формы
В замере видно, что лидер по абсолютному времени выполнения — метод «ОткрытьФорму».
Из 104 секунд открытия 64 приходятся на этот метод.
При этом сделать вывод о причинах медленного открытия из этого замера невозможно.
2. Соберем технологический журнал для анализа медленного открытия
Какие события собираем
Собираем события CALL и SCALL.
Выдержка из документации по платформе:
- SCALL — исходящий удаленный вызов (исходящий вызов на стороне источника вызова).
- CALL — входящий удаленный вызов (удаленный вызов на стороне приемника вызова).
Эти события возникают при клиент-серверном взаимодействии.
Бытует мнение, что SCALL всегда возникает при обращении с клиента на сервер, а CALL — при приходе этого обращения на сервер.
Нередко это так и есть, например, когда клиент обращается к серверу.
Однако это не всегда так. Например, могут быть обращения внутри сервера между менеджером кластера и рабочим процессом, между сервером и клиентом и так далее.
Пример иного случая возникновения событий CALL и SCALL.
Цели сбора
Преследуем 2 цели:
- посмотреть длинные по времени вызовы;
- найти «лаги» в технологическом журнале.
С длинными вызовами вопросов не возникает: есть оператор программы, который длится слишком долго, и это можно в явном виде обнаружить в ТЖ. По сути, хотим увидеть то же, что в замере производительности.
Что такое «лаг технологического журнала»? Под ним понимается ситуация, когда в явном виде событий с большим временем исполнения в журнале нет, но косвенно об этом догадываемся за счет присутствия большой паузы между двумя соседними событиями в журнале по одной сессии.
Метод сбора
Метод сбора технологического журнала (далее — ТЖ) — обычный:
- в папке C:\Program Files\1cv8\conf создаем файл logcfg.xml (структура файла ниже);
- ждем, пока в папке с логами, указанной в logcfg, появятся подпапки с именами процессов сервера;
- выполняем открытие формы;
- убираем файл logcfg.xml из папки;
- ждем не более 5 минут, пока система завершит запись файлов журнала;
- забираем файлы технологического журнала из подпапки rphost_.
В нем настроено:
- папка для сбора логов C:\logs;
- отбор по событиям CALL и SCALL;
- отбор по имени базы rarus_fb.
Анализируем данные собранного лога технологического журнала. Нехитрым скриптом посмотрим наиболее долгие вызовы.
Примечание по скрипту
По сути, скрипт отбирает из ТЖ события, с длительностью от 2 знаков (с 10 секунд и более). Т. к. время в ТЖ 8.3 — в микросекундах, то нам нужен отбор по времени > 8 разрядов; чтобы не писать много букв в регулярном выражении, используем синтаксис расширенных регулярных выражений: , который включается ключом -E.
Видим, что существует долгое событие CALL длительностью 85 секунд, на котором происходит большое потребление памяти 554 Мб, а в пике 701 Мб и оно возникает на методе ПолучитьФорму.
Соберем лаги ТЖ.
Сделаем это более сложным скриптом, суть которого в том, чтобы сравнить по времени 2 соседних события ТЖ и найти среди них наибольшие паузы.
- в скрипте делаем отбор по t:clientID, равному ID нашего клиента, чтобы учесть только события по текущему пользователю.
В результате получаем:
В первой колонке — время лага в микросекундах, далее — время старта двух соседних событий.
Видно, что первым номером идет лаг, сопоставимый по времени с временем открытия формы.
Делаем предположение, о том, что тяжелая форма долго загружается с сервера на клиент.
3. Посмотрим на форму в конфигураторе
Что же такое разработчик заложил на форме? Может быть данные формы перегружены избыточной информацией?
Важный элемент расследования — просто посмотреть на творение рук разработчика глазами в конфигураторе «1С».
Видим несколько таблиц значений на форме. Отладчиком посмотрим для реального бюджета, какое количество строк в них.
А строк совсем немало. И всё это при открытии перегружается с сервера на клиент.
Убедимся в этом тезисе.
4. Используем Fiddler в режиме ReverseProxy
Чтобы окончательно убедиться в том, что медленная работа обусловлена «большими» данными формы и понять, что именно это за данные, перехватим их.
Режим Reverse proxy позволяет «вставить Fiddler в разрыв» между веб-сервером и клиентом и проанализировать пакеты обмена.
Настройка Fiddler в режиме ReverseProxy
Настройку будем производить на копии рабочей базы, которая развернута в той же инфраструктуре.
Настройка режима состоит на верхнем уровне из двух этапов:
- настроить на веб-сервере переадресацию url-rewrite на сервер с Fiddler’ом;
- настроить сам Fiddler.
Для настройки веб-сервера вводим правило url-rewrite на сервер finsrv, порт 8888, на котором будет слушать Fiddler.
Устанавливаем на отдельный сервер наш Fiddler и настраиваем в режиме Reverse proxy, как описано здесь.
-
Проверяем в опциях, что установлен флаг «Allow remote computers to connect».
-
if (oSession.host.toLowerCase() == "webserver:8888") oSession.host = "webserver:80";
Отслеживаем взаимодействие между веб-сервером и клиентом «1С»
Зайдем в копию базы и дойдем до открытия формы экземпляра бюджета, но открывать не будем. Перейдем в Fiddler, посмотрим, пакет с каким номером был получен последним, и запомним его номер. Теперь откроем форму бюджета, дождемся окончания открытия и посмотрим все пакеты от запомненного до самого последнего.
Видим входящий запрос с большим объемом данных.
Предполагаем, что это и есть данные формы. Смотрим подробности данных в правом окне:
Обращаем внимание, что прочитать можно только заголовки, а данные, похоже, сжаты, о чем также свидетельствует надпись 1C‑SDCversion и далее — MZ, что соответствует началу сжатой части.
- По 1C-SDCversion — ищем на партнерском форуме «1С» и встречаем упоминание о том, что это метод сжатия deflate.
Вспоминаем, что по умолчанию клиент «1С» запрашивает работу со сжатием данных между клиентом и сервером.
С помощью запуска тонкого клиента со специальным параметром отключаем этот режим.
Делаем повторное открытие формы и видим в Fiddler’е уже вполне читаемую картину.
Обращаем внимание, что без сжатия данные формы весят более 1 Мб, что немало.
Наконец справа видим данные формы:
Переходим на представление «TextView», копируем в буфер и сохраняем как xml.
Обращаем внимание на наличие больших блоков в ветке props c внушительным количеством строк, которое сопоставимо с числом строк таблиц значений на форме:
а также со свойством fullChanged="true". Последнее скорее всего означает разрешение на изменение строк объекта на клиенте.
Выдвигаем предположение о том, что в данных формы на клиента приходят с сервера служебные таблицы значений.
С точки зрения функционирования алгоритма они не требуются на клиенте. Принимаем решение избавиться от таблиц значений на клиенте.
5. Разгружаем форму в «1С»
Что тяжелее всего?
- На форме есть таблицы значений с большим числом строк.
- Обработка объект содержит табличные части с большим числом строк.
Отказываемся от использования таблиц значений на форме и табличных частей в пользу такого подхода:
- на сервере создаем таблицы значений;
- при переходе на клиента помещаем их во временное хранилище, а на форме храним только его адрес;
- после возврата на сервер получаем таблицы значений из временного хранилища.
6. Смотрим в Fiddler результат «разгрузки» формы
Видно, что объем данных формы сократился более чем в 5 раз.
7. Делаем повторный замер производительности и смотрим потребление памяти и лаги в ТЖ
Накатываем изменения на рабочую базу, собираем замер производительности «1С».
Видим, что теперь открытие формы экземпляра бюджета составляет 25 секунд, а метод ОткрытьФорму — всего 2,1 секунды.
Журнал регистрации в 1С 8.3 крайне полезен тем , что записывает все ошибки, предупреждения, информацию, примечания, произошедшие в базе с указанием времени, имени компьютера, пользователя и ссылки на измененные даные.
Найти журнал регистрации в 1С 8.3 можно через меню «Все функции» -> «Стандартные» или меню «Администрирование» -> «Поддержка и обслуживание».
Журнал регистрации позволяет ответить на один из самых популярных вопросов - Кто последний вносил изменения в конкретный объект ?
Зачем это ?
При большом количестве изменений файл журнала регистрации может вырасти до необъятных размеров. Рекордное количество, которое я видел - 90 Гб за месяц и, естественно, оставлять это просто так нельзя.
Настройка
Настройка журнала регистрации производится из режима Конфигуратор, в меню « Администрирование » - > «Настройка журнала регистрации »
Где хранится файл журнала регистрации ?
Это зависит от того, файловая база или клиент-серверная.
Файловая база
При данном режиме размещения, журнал регистрации находится в папке с самой базой. Месторасположение можно узнать либо из списка баз, либо из справки «О программе».
Если перейти по адресу снизу, Вы найдёте папку с именем «1Cv8Log», в ней и находится файл журнала регистрации 1Cv8.lgd.
Клиент-серверная база
В таком режиме все так же, как и в предыдущем, только данные журнала регистрации 1С хранятся на сервере. Чаще всего его место расположения следующее:
Оптимизация
Одним из способов является рассмотренная выше настройка регистрации только определенных событий. Например, незачем отслеживать примечания, если они вам попросту не нужны.
В более старых релизах платформы в настройках журнала регистрации было доступно разделение журнала регистрации по периодам. Весь журнал можно было разделить на отдельные файлы с указанной периодичностью (день, месяц, год и т. п.).
Начиная с версии платформы 1С 8.3.5.1068, журнал регистрации хранится в файле базы данных sqlite с расширением *.lgd, и данная настройка стала недоступна. Данный способ хранения журнала регистрации значительно производительнее, чем старый.
Как уменьшить или удалить журнал регистрации в 1С
В случае необходимости частичной, либо полной очистки записей журнала регистрации в окне настроек нажмите на кнопку «Сократить». В появившемся окне укажите дату, до которой все записи должны удалиться. Так же удаляемые записи можно сохранить в файл на всякий случай.
На этом всё, если у Вас появились вопросы или есть какие-либо замечания, оставьте комментарий 🙂
Читайте также: