Может кто сталкивался или подскажет, с чего начать

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

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

Что может 1С делать с журналом регистрации?

Выглядит это вот так:
https://ibb.co/wdQvRDx

(0) Отбор не попал в индекс, пошел тупой перебор.

(2) Речь про отображение ЖР? Ни у кого нет доступа к нему, никто не мог запрашивать из него информацию

(3)Сделать отбор и проверить

(4) я не понимаю, про что речь. Отбор чего? В конфигураторе в ЖР все отборы по всем событиям работают. У пользователей нет доступа к ЖР, посему никто ничего в нём смотреть не может

(0) Журнал SQLite растет, когда данные не могут быть надежно записаны в основной файл (например, его кто-то блокирует).

Смотрите логи сервера 1С, возможно там есть ответ.

Может антивирус шалит.

(6) какая-либо незавершённая транзакция? Которая потом откатывается?
ЖР смотрел, ничего вообще подозрительного найти не смог

(7) Хм, спасибо, посмотрю

На всех больших базах перевожу ЖР в текстовый формат с разделением по периодам. Надежно и удобно. Правда и журналирование переделываю, чтобы в ЖР срало как можно меньше.

(0) ставишь текстовый по дням и забываешь о проблеме

(8) ЖР пишется вне транзакций.

(8) А, если ты про транзакцию SQLite, то да, возможно.

На больших базах с интенсивным вводом данных SQLite быстро загнется. Держим там не более 2-х дней последних, остальное отрезаем и "складируем" отдельно (в базе 1С на MSSQL).

(0) понять и простить, жр на скульлайте не удался на селезнёвке..пользуй текстовый жр

(3) А если УстановитьПривилегированныйРежим()? И потом программно запустить отбор.

(all) Перевести в текстовый - очень быстрое решение, но при наличии наработок (агрегация ЖР, выгрузка в ИБ и т.д.) не простое решение.
Кроме того, отбор за большой период (скажем год) в SQLite будет работать в разы быстрее.

Сейчас самый большой файл ЖР 45 Гб, и ничего, работает... Значит проблема решаемая, главное понять, при каких обстоятельствах она проявилась

(16) Я не понимаю, что за отбор и при чём тут отбор

(17) Хозяин - барин. Но во всех "взрослых" системах, если необходим быстрый анализ - сбоку прикручивается система агрегации логов с нужными свистоперделками. А первичные логи всегда ведутся локально в тексте, как в самом простом и надежном варианте, для которого в том числе легко настраивается ротация. Только 1С изобретает велосипед не подумав, а потом устраивает метания. Лично меня пока необходимость агрегации ни разу не прижимала. И "расследования" и анализ статистики проводятся не настолько часто и занимают приемлемое время, чтобы необходимость сверх-быстрого анализа стала насущной.
А проблемы с SQLite на больших базах возникают редко, но закономерно.

Причем когда они возникают, это как правило всегда выглядит как "стоп-система".

Идеальный ЖР был в 7.7
А в 8-ке на старте ТЖ не было и они попытались скрестить ежа и ужа, при этом не предоставив возможностей гибкой настройки. В результате ЖР для обеих задач (анализ работы системы и анализ действий пользователей) в своем дефолтном виде стал подходить очень плохо. И вместо решения проблемы в корне чья-то "светлая голова" решила прикрутить скулайт.

(18) Только поиск в ЖР приводит к такому поведению. Причем поиск, который не попал в индекс, и начинается перебор. Перебор идет со скоростью порядка 10-30 Мб/с, на это время блокируются любые операции, требующие работы с ЖР (например, которые добавляют записи в него).

+(22) Прекратить это можно, например, принудительно завершив процесс rmngr.

(23) Подтверждаю. Эффективный способ прекратить любые безобразия в 1С.

(22) Если бы блокировалась запись, журнал бы не рос. :)

(25) В журнале вполне может быть аналог tempdb, куда складываются временные данные по выполняемому запросу.

Из доки по скулайту -journal - это rollback journal. С помощью которого в скулайте транзакции реализуются. Просто какого-то хрена система зафигачила в скулайт большую транзакцию. Что это такое может быть - самому интересно. Но тут, ИМХО, только ТЖ может помочь прояснить картину.

Еще вариант - кластер какого-то хрена переводил лог в режим эксклюзивной блокировки (PRAGMA lock_mode = EXCLUSIVE;)
Это вызывает аналогичное поведение.

вернуться на старый журнал

говорят на него теперь можно и индексы навешать

Хм. Нашёл в ЖР примерно в то проблемное время событие Транзакция начало, статус транзакции - не завершена. Источник - фоновое задание
В других базах нет таких событий

(31) Сам по себе, откат транзакции 1С не должен приводить к откату транзакции скулайта. Это ж лог и записи о неудачных транзакциях туда тоже пишутся. Возникает вопрос, каким образом в лог происходит запись статуса об откате транзакции в сделанные ранее записи. Подозреваю, что именно после отката транзакции в 1С кластер находит все записи сделанные этой транзакцией в лог и меняет в них значение поля статуса транзакции. И именно во время этой операции произошел глобальный лок.

Скорее всего, изменение поля статуса транзакций в куче записей лога делается в транзакции. И так как это лочит все последние записи, то вероятно скулайт в это время не позволяет добавлять новые записи.
В сиквеле, ИМХО, будет такое-же поведение. Если эксклюзивно залочить последние строки кластерного индекса - новую строку добавить не даст.

(33) Но тут же индексы должны рулить, а потому эта операция должна быть относительно быстрой.

Получается, что откат любых больших транзакций в 1С с журналом на скулайте приводит к stop the world
Интересно, что в аналогичной ситуации происходит на текстовых логах. Может, тоже самое, просто быстрее обрабатывается.

(34) Если у тебя транзакция на 10 мин растянулась - ее откат физически не способен произойти быстро.

Хм2... больше таких записей не нашёл, когда у сотрудников был stop the world. Может разные проблемы конечно...
Самое простое, насколько я понимаю, написать мониторинг наличия/отсутствия файла лога в каталоге

Вернее, транзакция в скулайте оказывается очень большая. В обычной ситуации их вообще как бы и нет - тупо строчка добавляется.

(37) Вероятно, это просто редкий случай когда откатывалась очень большая транзакция. Скорее всего на очень большое количество мелких объектов.

Хотя не обязательно. Там же по дефолту и движения регистров логируется.

(37) Можно косвенно прикинуть справедливость гепотезы - если ты посчитаешь количество записей в лог, которое сделала транзакция которая откатилось. Если это объективно очень большое число, то субъективно можно предположить, что в этом могла быть причина :) А если не очень большое - тогда неясно. Гипотеза может быть верной, просто мог вмешаться какой-то дополнительный фактор. Например просто начались проблемы с диском в том месте, где лежит лог и производительность записи в него резко упала. На добавлениях незаметно, а на массивных операциях уже проявляется.

Предварительно количество записей должно быть очень большим. Раз размер файла транзакции составил четверть размера от основного файла. Если лог ведется от начала работы базы - то это как-то ненормально много. Может, у тебя там перепроведение в транзакции? :)

зачем пытаться разобратся с этим сиквел лайт, когда сама 1с рекомендует на старый журнал переходить

(42) транзакции ЖР никакого отношения не  имеют к транзакциям внутри самой 1с

(42) Структура ЖР в SQLite практически такая же, как в текстовом виде. Т.е. 1С просто вместо текстового файла отправляет записи в базу SQLite. Поэтому все предварительные записи есть только в памяти 1С.

(33) Откуда такие фантазии?

(44) Прямого - не имеют. Но при откате транзакции 1С в ЖР необходимо проставить признак неудачной транзакции для всех записей, по которым она сделала записи в ЖР
(46) Все фантазии - они от воображения. Воображение нужно развивать!

Тьфу! "Но при откате транзакции 1С в ЖР необходимо проставить признак неудачной транзакции для всех записей, которые она сделала в ЖР"

(43) В том-то и дело, что нет такой рекомендации. Только намеки :)

(43) Причем это после того, как они сначала вообще отключили в интерфейсе возможность выбрать текстовый формат и для всех новых баз форсили скулайтный по дефолту.