После внедрения журнала, база 1С стала работать очень медленно

После внедрения журнала, база 1С стала работать очень медленно

Данная проблема появляется в основном если используется «слабое железо», которое и до внедрения журнала работало не особенно быстро, а после внедрения стало еще медленней. Стоит понимать, что «добавление» дополнительного функционала никогда не идет на пользу производительности, она всегда будет падать, так как от конфигурации требовали раньше столько, а после добавления чего-нибудь, столько же и еще чуть-чуть. Поэтому конфигурация после внедрения подсистемы, априори будет работать медленней чем без нее. Другой вопрос насколько медленней… Если время записи упало с 0.1 сек. до 0.5 сек., то не существенно и субъективно Вы не почувствуете разницу. Если с 2 сек. до 5 сек., то это будет заметно.

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

Итак, проблема есть, что же делать и как ее решить? Приведем основные моменты по оптимизации скорости работы журнала:

1. Отключите фиксирование входов/выходов пользователей.

2. В настройках отключите ведение истории по объектам, для которых история не нужна. Пересмотрите все объекты метаданных по которым ведется журнал и не нужные, по которым никогда не будет споров и проблем, кто же их изменил – отключите.

3.Особое внимание уделите регистрации регистров сведений. Старайтесь чтобы в настройках подсистемы фиксировались изменения как можно меньшего количества регистров сведений. А еще лучше отключить в случае если информационная база 1С работает очень медленно регистрирование изменений всех регистров сведений. Зачастую пользователи говорят, а как фиксировать вообще все? В связи с этом вопрос: вы хотите регистрировать служебные регистры, которые не меняются пользователями, а только системой? Пользователь говорит: нет… а зачем тогда регистрировать изменения этих регистров? Или зачем регистрировать изменения регистра «Адресный классификатор»? Это огромные регистры, которые не дадут нам информации ни о чем. Отключите их регистрацию смело.

4. Настройте перенос кэша журнала в ИБ хранителя в те моменты, когда с информационной базой работает как можно меньше пользователей.

5. В ИБ «Хранитель журнала регистрации» так же настройте регламентные так, чтобы они не влияли на производительность сервера. Тут есть два пути. Первый – уменьшить интервал работы регламентных заданий. Тогда малые порции будут обрабатываться за маленькое время, что в целом не повлияет на производительность. Второй – перенести работу регламентных в то время, когда с ИБ работает мало пользователей, или вообще не работает.

6. В настройках на вкладке «Дополнительно» установите «Период просмотра в журнале по умолчанию» в «За последний день» или «За последнюю неделю». Это позволит открывать журнал регистрации быстрее.

7. Пройдите в настройках по метаданным и удалите из логируемых те реквизиты объектов, которые могут содержать данных больших объемов и которые могут серьезно увеличить информационную базу «Хранителя» (хранилища значений, файлы, тексты, картинки и т.п.). Если эти данные не нужны, то отключите эти реквизиты убрав их из регистрации. Для хранилищ значений в настройках регистрируемых объектов есть специальная кнопка, которая отключит реквизиты, которые содержат тип "ХранилищеЗначения".

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


Логотип
 Не переносятся данные. Ошибки V83.COMConnector | Описание курса | Что делать, если очень быстро растет база данных журнала в Хранителе?