Доброго времени суток.
В мае поднимал вот эту тему: https://1cers.ru/topic.php?upd&id=550143
В прошлый раз победил с помощью удаления ИБ с сервера 1С 8.2 и повторного ее создания под тем же именем. И вот, пару недель назад снова началось.
Симптомы: при установке первого соединения с ИБ (после обновления, перезагрузки сервера, или просто когда все вдруг решили выйти из 1С), процесс rmngr на сервере 1С грузит одно ядро процессора на 100% в течении 3-5 минут, после чего пускает в базу без проблем.
С помощью Process Monitor выяснил, что в это время rmngr занят тем, что медленно и грустно читает журнал регистрации ИБ (а именно файл 1Сv8.lgf). Просто читает, не пишет даже. И что-то там свое думает.
Казалось бы проблема решена - журнал регистрации очень легко сократить. Но, журнал регистрации я сокращаю раз в месяц, сейчас там есть данные с 1-го ноября 2011-го года. А вот в этом самом файле 1Cv8.lgf есть записи с начала ИЮНЯ, т.е. с того момента когда ИБ была "пересоздана" на сервере.
Вопрос. Как грамотно почистить этот файл? Есть какие-нибудь обработки для нормальной очистки журнала регистрации? Пересоздавать базу на сервере раз в 2-3 месяца не очень хочется - как-то это не правильно. Отключить ведение ЖР нельзя.
Платформа: 8.2.13.205. Обновлять платформу очень-очень нежелательно (в связи с до сих пор предстоящим переходом на 8.2z:)), но если кто-то проверит на своей платформе старшей версии и напишет, что у него файл 1Cv8.lgf уменьшается в размерах после сокражения ЖР - будет серьезная почва для размышлений

+ сам по себе файл 1Cv8.lgf довольно-таки небольшой. Сейчас он весит 8 мегабайт с копейками.

точно именно 1Сv8.lgf? а чего у тебя там так много?
режим разделения по периодам какой стоит?

(2)
1) именно он. Смотрю process monitor'ом, как только доходит до конца - пускает в базу.
2) дак, собственно, все. "Ошибки, предупреждения, информация, примечания."
3) По дням. Насколько я понимаю, сильно не влияет ни на что. Файлики, которые каждый день создаются, при сокращении ЖР исправно удаляются. А вот содержимое 1Cv8.lgf не меняется.

а если попробовать тупо:
остановить сервер 1с, изъять все логи у этой базы (т.е. очистить их вручную, переместив файлы в другую папку), запустить - как изменится поведение?

(4) все отлично. Запускается за доли секунды

вот так и оставь

(7) Я, как бэ, понимаю, что так делать можно. Но решение такое мне не нравится. Интересует более "красивый" вариант.

куда уж красивее-то?

(7)остановить сервер 1с, изъять все логи у этой базы (т.е. очистить их вручную, переместив файлы в другую папку), запустить - как изменится поведение?
И смотри в это время репродукцию картины Серова "Девочка с персиками".

Такое решение напоминает костыль. Обработка нормально сокращающая ЖР - красивее. Собственно, про то видел ли кто-нибудь такую, и был вопрос.

(9) чо?

(10) пакетный режим и ключ:
/ReduceEventLogSize -SaveAs"тут имя файла".elf

или вот поиск что дает: v8: Обрезка журнала регистрации

(11)Так красивее.

(14) а-а-а...

(12) та же фигня получилась. 1сv8.lgf не уменьшился.

(16) Удаление журнала полностью единственный вариант.
lgf - это не сам журнал, а файл формата, в нем хранятся имена метаданных и прочая информация; он, естеественно,никогда не уменьшится при сокращении журнала.

Его можно сократить вручную частично; но это очень кропотливая работа.

Решение не айс, но все-таки лучше ручного удаления файла.
Если в конфигураторе, при сокращении ЖР выбрать дату <= текущей, то ЖР обрезается, но злополучный файл 1cv8.lgf остается нетронутым, следовательно, проблема не решается.
Однако, если выбрать следующий день, содержимое 1cv8.lgf удаляется и проблема решается. Единственное, что я обрезал журнал когда с базой было только одно соединение - мое. Т.е. - можно ли это делать в течении рабочего дня (точнее, будет ли достигнут нужный результат) я пока не знаю, но попробую.

(19) эх и лучше, просто офигеть

(20) то есть ты разницы не видишь?

+(19) во время работы пользователей тоже нормально. Файл сокращается.

(19) Лол, ну это абсолютно идентично тому, что если бы ты сам удалил файлы.

(23) я че-то не понимаю. Как, блин, идентично?
Что тут идентичного? То что фактически у меня журнала не будет в этой базе - это да, это идентично. Но пользователям он не нужен, а открыть журнал из расшаренной папки - сложностей нет.
В то же время вижу два преимущества:
1. Это сделано стандартными средствами 1С. Если меня не будет на месте - не надо давать права на доступ к серверу/службам кому бы то ни было. Любой из наших программистов с доступом к конфигуратору сможет это сделать.
2. Не надо никого выгонять из 1С. Работа круглосуточная и за простой в лишние 5 минут меня уже будут жестоко карать.

В чем ошибка?

(24) Нет ошибки, я имел в виду, что без разницы, адинэсом ты файлы удалишь или руками.
Если тебе нужно регулярно удалять - то, мб, проще вообще отключить его?

+ (25) Про требование, что нужно обрезать во время работы, ты не оговаривался ранее.

(25) Отключить нельзя.
А разницу в том как удалять я описАл.

(26) Ну, сорри, конечно. Но это как бы самособой разумеющееся, что пользователи то, что я что-то там делаю, вообще замечать не должны.

Из перечисленных "обновить платформу", "пересоздать базу", "проблема при первом запуске" - не вытекало что "пользователи замечать не должны". Вытекало что нужно разово что-то сделать.
В общем, ладно, если решение тебя устраивает, то и слава богу.

(24) ты бы лучше разобрался, отчего у тебя этот файл так быстро пухнет