Добрый день.
Папка d:\srvinfo\reg_1541\ растет как на дрожжах, по 0.5-1Гб в сутки. Перед праздниками, пробовал сократить журнал регистрации из конфигуратора на 1 год (с сохранением архива на другой диск). На сегодня srvinfo весит даже больше, чем было до сокращение журнала. Подскажите, в чем особенность данного поведения? ЧЯНТД?
Платформа: 8.3.10.2580.

Новый формат ЖР скорее всего

взять тулзы от sqlite и сказать им vacuum

(1) Есть способ это побороть?

(3) только если почистить журнал регистрации, в (2) описан способ.

(3) Стоит попробовать вернуться на старый формат журнала с делением на месяцы.

Тоже перешел на старый формат. Новый - это какое то недоразумение. Ну писали бы прямо в базу или на крайняк внешнее соединение с отдельной базой для логов.

Если временно перенести папку srvinfo с SSD на HDD, это как-то может повлиять на быстродействие базы в пользовательском режиме?

Это как-то может повлиять, да

(0)
Тут может быьт 2 варианта:
1. ЖР
2. Индекс фуллтекстового поиска
Оба жрут место, причем второй жрёт от размера базы, а первый - от интенсивности логирования в ЖР (интенсивность работы в ИБ)

Побороть п.2 можно:
1. Очистить текущий ЖР. Для этого, как вариант:
Остановить сервер, удалить файл lgd (ессно сделать перед удалением его копию и сложить куда-нибудь в виде архива)
2. Позаботиться о том чтобы в дальнейшем ЖР не рос:
2.1. Каждую ночь например его скидывать регламентными заданиями куда-нибудь, затем скинутые записи удалять
2.2. Перейти на старый формат ЖР, разделять его по дням (часа), и скриптом архивировать разделенные файлы куда-нибудь.

ИМХО
Возвращаться на старый формат не стоит, надо просто организовать нормально очистку ЖР.

(9) Как будем искать в НовомЖР, который по частям валяется в архиве?

П.С.
На моей базе 500 гигов индекс полнотекстового поиска занимает 170 гигов.
ЖР за пол года занимал примерно столько же.
После реализации п. 2.2. ЖР не успевает вырасти более 1 гига, каждую ночь чикается и аккуратно скидывается в отдельную базу.

(10)
Никак, поэтому его лучше складывать куда-нибудь в одну таблицу
Кто-то видимо использует Elastic Search, кто-то даже Click House, я - просто ИБ на 1С + SQL

(10) а что в нем искать то?
А если реально нужно искть, то лучше в эластик все грузить

(12) Переношу журнал в другую базу-копию без регистров. В рабочей базе журнал висит за 2 последних дня. Функция СкопироватьЖурналРенистрации. И vacuum еще.

(14)
Для vacuum приходит сервер останавливать, не все себе могут позволить эту роскошь

(13) Поясни за эластик. Как его готовить, что это за зверь?

(15) Для ЖР отдельный сервер (По требованию функциональности). А так, текущий ЖР лежит в RAM-памяти. Все происходит очень быстро, основной журнал на SSD.

(17)
Неплохо, но без остановки всё равно не взлетит же

посмотреть название\уид быстро растущей папки  (windirstat например)
найти в ibases.v8i названия базы где ID= "название\уид папки"
посмотреть журнал и найти что именно создает много записей, думаю какое то регламентное задание очень часто выполняется,
п.с.
можно зайти в конфигуратор и изменить настройки журнала

посмотри что пишется в ЖР
попадались деятели, которые в ЖР писали изменения объектов по всем полям (типа убогого версионирования такого)

(11) мне вот интересна, какая польза от полнотекстового индекса?

(19) +1
Поддержу, в каталоге d:\srvinfo\reg_1541 найти папку с большим размером, название папки - это гуид базы, которую нужно найти в "ibases.v8i". У меня была проблема с регламентным заданием, которое выполнялось каждую минуту и каждое событие писало в журнал "Задание запущено", "Задание закончено" итд..., через какое-то время каталог очень сильно распухал.

(11) Можно подробнее про " чикается и аккуратно скидывается в отдельную базу."? Как это происходит?

(23)
Вот моё решение
http://catalog.mista.ru/public/846675/

Операции - управление полнотекстовым поиском -очистить индекс - не уменьшает объем?

Кстати - в 8.3.13 упонянуто о снижении размера кэша полнотекстового поиска

(20) Вот я такой деятель, ещё в 2009 году сделал подсистему.
Только изменения пишутся не по всем полям, а по изменившимся.