Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

ЖР SQLite - внезапно 1Cv8.lgd-journal

ЖР SQLite - внезапно 1Cv8.lgd-journal
Я
   AlexSTAL
 
06.11.20 - 09:29
Может кто сталкивался или подскажет, с чего начать

Кластер из 3-х серверов (2 центральных и 1 лицензирования)
Несколько инсталляций в разных филиалах, версия 8.3.17.1549, windows server, промышленная эксплуатация

В одном из филиалов пользователи начали жаловаться на внезапные полные зависания системы на продолжительное время (3-25 минут).
Вчера сам столкнулся с данной ситуацией, полез в каталог с ЖР и обнаружил, что по мимо файла 1Cv8.lgd присутствует файл журнала транзакций 1Cv8.lgd-journal и он постоянно растёт
Т.е. основной файл примерно 1,5 Гб, а файл журнала транзакций за 15 минут вырос до 0,4 Гб и исчез. В это время работа в 1С была не возможна. Записей в ЖР в этом промежутке нет.

Что может 1С делать с журналом регистрации?
   AlexSTAL
 
1 - 06.11.20 - 09:32
Выглядит это вот так:
https://ibb.co/wdQvRDx
   dmpl
 
2 - 06.11.20 - 09:38
(0) Отбор не попал в индекс, пошел тупой перебор.
   AlexSTAL
 
3 - 06.11.20 - 09:52
(2) Речь про отображение ЖР? Ни у кого нет доступа к нему, никто не мог запрашивать из него информацию
   vis_tmp
 
4 - 06.11.20 - 09:56
(3)Сделать отбор и проверить
   AlexSTAL
 
5 - 06.11.20 - 09:59
(4) я не понимаю, про что речь. Отбор чего? В конфигураторе в ЖР все отборы по всем событиям работают. У пользователей нет доступа к ЖР, посему никто ничего в нём смотреть не может
   mistеr
 
6 - 06.11.20 - 09:59
(0) Журнал SQLite растет, когда данные не могут быть надежно записаны в основной файл (например, его кто-то блокирует).

Смотрите логи сервера 1С, возможно там есть ответ.
   mistеr
 
7 - 06.11.20 - 10:00
Может антивирус шалит.
   AlexSTAL
 
8 - 06.11.20 - 10:01
(6) какая-либо незавершённая транзакция? Которая потом откатывается?
ЖР смотрел, ничего вообще подозрительного найти не смог
   AlexSTAL
 
9 - 06.11.20 - 10:01
(7) Хм, спасибо, посмотрю
   fisher
 
10 - 06.11.20 - 10:06
На всех больших базах перевожу ЖР в текстовый формат с разделением по периодам. Надежно и удобно. Правда и журналирование переделываю, чтобы в ЖР срало как можно меньше.
   Жан Пердежон
 
11 - 06.11.20 - 10:07
(0) ставишь текстовый по дням и забываешь о проблеме
   mistеr
 
12 - 06.11.20 - 10:11
(8) ЖР пишется вне транзакций.
   mistеr
 
13 - 06.11.20 - 10:12
(8) А, если ты про транзакцию SQLite, то да, возможно.
   D_E_S_131
 
14 - 06.11.20 - 10:12
На больших базах с интенсивным вводом данных SQLite быстро загнется. Держим там не более 2-х дней последних, остальное отрезаем и "складируем" отдельно (в базе 1С на MSSQL).
   Ёпрст
 
15 - 06.11.20 - 10:13
(0) понять и простить, жр на скульлайте не удался на селезнёвке..пользуй текстовый жр
   dmpl
 
16 - 06.11.20 - 10:16
(3) А если УстановитьПривилегированныйРежим()? И потом программно запустить отбор.
   AlexSTAL
 
17 - 06.11.20 - 10:18
(all) Перевести в текстовый - очень быстрое решение, но при наличии наработок (агрегация ЖР, выгрузка в ИБ и т.д.) не простое решение.
Кроме того, отбор за большой период (скажем год) в SQLite будет работать в разы быстрее.

Сейчас самый большой файл ЖР 45 Гб, и ничего, работает... Значит проблема решаемая, главное понять, при каких обстоятельствах она проявилась
   AlexSTAL
 
18 - 06.11.20 - 10:21
(16) Я не понимаю, что за отбор и при чём тут отбор
   fisher
 
19 - 06.11.20 - 10:26
(17) Хозяин - барин. Но во всех "взрослых" системах, если необходим быстрый анализ - сбоку прикручивается система агрегации логов с нужными свистоперделками. А первичные логи всегда ведутся локально в тексте, как в самом простом и надежном варианте, для которого в том числе легко настраивается ротация. Только 1С изобретает велосипед не подумав, а потом устраивает метания. Лично меня пока необходимость агрегации ни разу не прижимала. И "расследования" и анализ статистики проводятся не настолько часто и занимают приемлемое время, чтобы необходимость сверх-быстрого анализа стала насущной.
А проблемы с SQLite на больших базах возникают редко, но закономерно.
   fisher
 
20 - 06.11.20 - 10:30
Причем когда они возникают, это как правило всегда выглядит как "стоп-система".
   fisher
 
21 - 06.11.20 - 10:32
Идеальный ЖР был в 7.7
А в 8-ке на старте ТЖ не было и они попытались скрестить ежа и ужа, при этом не предоставив возможностей гибкой настройки. В результате ЖР для обеих задач (анализ работы системы и анализ действий пользователей) в своем дефолтном виде стал подходить очень плохо. И вместо решения проблемы в корне чья-то "светлая голова" решила прикрутить скулайт.
   dmpl
 
22 - 06.11.20 - 10:33
(18) Только поиск в ЖР приводит к такому поведению. Причем поиск, который не попал в индекс, и начинается перебор. Перебор идет со скоростью порядка 10-30 Мб/с, на это время блокируются любые операции, требующие работы с ЖР (например, которые добавляют записи в него).
   dmpl
 
23 - 06.11.20 - 10:35
+(22) Прекратить это можно, например, принудительно завершив процесс rmngr.
   fisher
 
24 - 06.11.20 - 10:36
(23) Подтверждаю. Эффективный способ прекратить любые безобразия в 1С.
   mistеr
 
25 - 06.11.20 - 10:38
(22) Если бы блокировалась запись, журнал бы не рос. :)
   dmpl
 
26 - 06.11.20 - 10:43
(25) В журнале вполне может быть аналог tempdb, куда складываются временные данные по выполняемому запросу.
   fisher
 
27 - 06.11.20 - 10:58
Из доки по скулайту -journal - это rollback journal. С помощью которого в скулайте транзакции реализуются. Просто какого-то хрена система зафигачила в скулайт большую транзакцию. Что это такое может быть - самому интересно. Но тут, ИМХО, только ТЖ может помочь прояснить картину.
   fisher
 
28 - 06.11.20 - 11:02
Еще вариант - кластер какого-то хрена переводил лог в режим эксклюзивной блокировки (PRAGMA lock_mode = EXCLUSIVE;)
Это вызывает аналогичное поведение.
   Вафель
 
29 - 06.11.20 - 11:13
вернуться на старый журнал
   Вафель
 
30 - 06.11.20 - 11:15
говорят на него теперь можно и индексы навешать
 
 Рекламное место пустует
   AlexSTAL
 
31 - 06.11.20 - 11:26
Хм. Нашёл в ЖР примерно в то проблемное время событие Транзакция начало, статус транзакции - не завершена. Источник - фоновое задание
В других базах нет таких событий
   fisher
 
32 - 06.11.20 - 11:36
(31) Сам по себе, откат транзакции 1С не должен приводить к откату транзакции скулайта. Это ж лог и записи о неудачных транзакциях туда тоже пишутся. Возникает вопрос, каким образом в лог происходит запись статуса об откате транзакции в сделанные ранее записи. Подозреваю, что именно после отката транзакции в 1С кластер находит все записи сделанные этой транзакцией в лог и меняет в них значение поля статуса транзакции. И именно во время этой операции произошел глобальный лок.
   fisher
 
33 - 06.11.20 - 11:43
Скорее всего, изменение поля статуса транзакций в куче записей лога делается в транзакции. И так как это лочит все последние записи, то вероятно скулайт в это время не позволяет добавлять новые записи.
В сиквеле, ИМХО, будет такое-же поведение. Если эксклюзивно залочить последние строки кластерного индекса - новую строку добавить не даст.
   dmpl
 
34 - 06.11.20 - 11:45
(33) Но тут же индексы должны рулить, а потому эта операция должна быть относительно быстрой.
   fisher
 
35 - 06.11.20 - 11:46
Получается, что откат любых больших транзакций в 1С с журналом на скулайте приводит к stop the world
Интересно, что в аналогичной ситуации происходит на текстовых логах. Может, тоже самое, просто быстрее обрабатывается.
   fisher
 
36 - 06.11.20 - 11:48
(34) Если у тебя транзакция на 10 мин растянулась - ее откат физически не способен произойти быстро.
   AlexSTAL
 
37 - 06.11.20 - 11:49
Хм2... больше таких записей не нашёл, когда у сотрудников был stop the world. Может разные проблемы конечно...
Самое простое, насколько я понимаю, написать мониторинг наличия/отсутствия файла лога в каталоге
   fisher
 
38 - 06.11.20 - 11:49
Вернее, транзакция в скулайте оказывается очень большая. В обычной ситуации их вообще как бы и нет - тупо строчка добавляется.
   fisher
 
39 - 06.11.20 - 11:50
(37) Вероятно, это просто редкий случай когда откатывалась очень большая транзакция. Скорее всего на очень большое количество мелких объектов.
   fisher
 
40 - 06.11.20 - 11:51
Хотя не обязательно. Там же по дефолту и движения регистров логируется.
   fisher
 
41 - 06.11.20 - 12:06
(37) Можно косвенно прикинуть справедливость гепотезы - если ты посчитаешь количество записей в лог, которое сделала транзакция которая откатилось. Если это объективно очень большое число, то субъективно можно предположить, что в этом могла быть причина :) А если не очень большое - тогда неясно. Гипотеза может быть верной, просто мог вмешаться какой-то дополнительный фактор. Например просто начались проблемы с диском в том месте, где лежит лог и производительность записи в него резко упала. На добавлениях незаметно, а на массивных операциях уже проявляется.
   fisher
 
42 - 06.11.20 - 12:10
Предварительно количество записей должно быть очень большим. Раз размер файла транзакции составил четверть размера от основного файла. Если лог ведется от начала работы базы - то это как-то ненормально много. Может, у тебя там перепроведение в транзакции? :)
   Вафель
 
43 - 06.11.20 - 12:11
зачем пытаться разобратся с этим сиквел лайт, когда сама 1с рекомендует на старый журнал переходить
   Вафель
 
44 - 06.11.20 - 12:12
(42) транзакции ЖР никакого отношения не  имеют к транзакциям внутри самой 1с
   dmpl
 
45 - 06.11.20 - 12:18
(42) Структура ЖР в SQLite практически такая же, как в текстовом виде. Т.е. 1С просто вместо текстового файла отправляет записи в базу SQLite. Поэтому все предварительные записи есть только в памяти 1С.
   mistеr
 
46 - 06.11.20 - 12:27
(33) Откуда такие фантазии?
   fisher
 
47 - 06.11.20 - 12:31
(44) Прямого - не имеют. Но при откате транзакции 1С в ЖР необходимо проставить признак неудачной транзакции для всех записей, по которым она сделала записи в ЖР
(46) Все фантазии - они от воображения. Воображение нужно развивать!
   fisher
 
48 - 06.11.20 - 12:32
Тьфу! "Но при откате транзакции 1С в ЖР необходимо проставить признак неудачной транзакции для всех записей, которые она сделала в ЖР"
   Cyberhawk
 
49 - 06.11.20 - 12:41
(43) В том-то и дело, что нет такой рекомендации. Только намеки :)
   fisher
 
50 - 06.11.20 - 12:46
(43) Причем это после того, как они сначала вообще отключили в интерфейсе возможность выбрать текстовый формат и для всех новых баз форсили скулайтный по дефолту.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.