Здоровье базы, в которой документы все время создаются и удаляются

[anna]

Коллеги, я помню, что почему-то плохо, когда в базе документы постоянно создаются и удаляются. Я понимаю, что в таком случае лучше, чтобы не было SoftDeletion, что нужно делать все время компакт на такую базу. Напомните все имеющиеся грабли, пожалуйста, еще раз.
Такое ощущение, что со временем такая база становится плохой, архивация в ней не идет (clean), после компакта остаются прежние цифры (60%, например).

 

[romych2004]

У нас в такой базе ломался индекс регулярно. При чем ломался прям серьёзно, приходилось его удалять физически с диска(кнопка "удалить индекс" не помогала)

 

[lmike]

@anna зачем идет постоянное удаление?
Сколько добавляется документов, в месяц?

 

[anna]

@anna зачем идет постоянное удаление?
Сколько добавляется документов, в месяц?

ну, как постоянное - удаление раз в неделю, в принципе, можно удалять только обработанные. Незнаю, неск тысяч

 

[lmike]

Незнаю, неск тысяч

ну это не критичный объем наполнения... можно вовсе не удалять (просто форму меняйте - чтобы в виды не попадало)

 

[anna]

Ну ок, а когда сотни тысяч добавляются и чаще удаляются?

 

[lmike]

сотни тысяч

за какой период - год? - создают архив от БД и раз в год удаляют
я транслирую мысль - удалять (доки, часто) не нужно, а если процесс позволяет - просто менять доки (создание тоже - не быстрый процесс)

 

[savl]

создают архив от БД и раз в год удаляют

мы удаляли всегда раз в месяц, но количество обычно не более 1000 доков

 

[rinsk]

Ну ок, а когда сотни тысяч добавляются и чаще удаляются?

По практике, при 200-300 тыщ. окурков уже могут возникнуть проблемы - особенно на ODS < 52 .
Причем бывает что не срабатывает параметр cutoff date (удаление стабов через хх дней) .
Выход - по возможности не удалять документы, а переводить например в пул повторно используемых.
Или периодически запускать агента по удалению стабов -

Ссылка скрыта от гостей

Доработка для Linux/64 тут:
https://codeby.net/threads/how-to-count-and-delete-deletion-stubs.30190/page-2
Но тут надо понимать риски, в случае наличия реплик на других серверах.
Начиная с 9.0 есть возможность компактить с опциями -REPLICA -RESTART . Учитывая что после нее FT индекс надо перестроить)

 

[lmike]

Выход - по возможности не удалять документы, а переводить например в пул повторно используемых.

золотые слова

 

[anna]

Пасиба, коллеги. В общем, переделала. Правильно, нафиг такое вообще.

 

[anna]

В базе, переделанной, чтобы документы заново использовались, остаются низкие цифры после компакта - 65%. Запускала и вручную - все равно магическая цифра не меняется. Что сделать?

 

[lmike]

остаются низкие цифры после компакта - 65%

вот совсем не понятно

 

[anna]

вот совсем не понятно

нашли миллионы окурков. При этом, в свойствах базы - нет SoftDeletion

 

[rinsk]

нашли миллионы окурков. При этом, в свойствах базы - нет SoftDeletion

Это разные вещи

 

[oshmianski]

Время жизни окурков, причем не важно, стоит галочка или нет.

 

[oshmianski]

Забыл добавить 90 / 3 = время жизни окурков

 

[lmike]

Посмотреть вложение 7785
Время жизни окурков, причем не важно, стоит галочка или нет.

опасная галочка

 

[oshmianski]

не, не, галочку трогать не нужно. циферку только.
мне смущает сам факт привязки времени жизни окурков к этому полю. но, индусы решили по-другому...

 

[ToxaRat]

По практике, при 200-300 тыщ. окурков уже могут возникнуть проблемы - особенно на ODS < 52 .
Причем бывает что не срабатывает параметр cutoff date (удаление стабов через хх дней) .
Выход - по возможности не удалять документы, а переводить например в пул повторно используемых.

было у меня раз подобное, взял и поставил не 90 а 0
база подвисла, подвисла так что потом отвисла но cutoff date больше не работал - вообще, никогда

чтобы избежать проблем с окурками на тех базах в которых часто удаляются доки нужно поставить cutoff date = 0, вот чтобы окурки удалялись сразу - тогда база живучая

естественно подобные базы реплицировать нельзя