Блокировки и сервер 1С #346170

Эксперементальным путем выяснено, что причиной блокировок является сервер 1С. Со временем он накапливает какието вредные данные в своих временных файлах, в с этим очень сильно замедляется проведение документов. Особено сильно это проявляется на документах релизации на процедуре списание по партиям (Движение по регистам). Нормальное время для нашей базы 17с на документ. После "большого" перепроведения документов становится невозможно работать, врямя проведения реализации около 3х минут. Лезут блокировки. Помогает только полная переустановка сервера 1С. Как сервер можно вылечить? Переустанавливать сервер раз в три дня это ни куда не годится.

Переход на последнюю платформу 8.1.11.67 в первую очередь. 1С доработала сервер по многим параметрам. Второе регламентные операции с SQL, то биш очистка кеша, обновление статистик, дефрагментация.

Ну и оптимизация запросов в конфигурации, особенно "самописные", да и обновление до послежней версии (если конечно типовую используете)

"полная переустановка сервера 1С" Зачем???! Есть просто перезапуск :)

платформа стоит 8.1.11.67 Конфигурацию УПП серьезно не переписывали можно считать что она типовая 1.2.16.1 Просто перезапуск сервера не помогает, только полная переустановка

эта проблема стала проявлятся как раз после перехода на версию сервера 8.1.11.67

Погодите, а сервер 1С ли? На самом деле блокировками не только он заведует, а в первую очередь SQL. Скажите: после переустановки сервера вы просто добавляете базы и используете или проводите еще какие то операции? Используете ли "типовые рекомендации" для SQL? Увеличение числа блокировок в первую очередь возникает из-за процедурного кеша, накапливаються "неправильные" запросы, и SQL начинает все чаще их выбирать.

В догонку вопрос, после перехода 8.1.11.67 делали полную реструктуризацию таблиц???

Блокировки возникают из-за значительного увеличения времени проведения по регистрам. Опытным путем обнаружена прямая зависимость от 1С сервера, а не от SQL. На SQL сервере постоянно выполняются процедуры переиндексации и дефрагментации.   После переустановки сервера 1С добаваляем базы и просто их используем. После перехода на 8.1.11.67 полную реструктуризацию таблиц не делали. На сколько это важная процедура? Делается она очень долго, а остановить работу предприятия на столько времени очень проблематично.

Очень важная! 1С кроме изменения самих таблиц добавила кластерные индексы, поэтому SQL проводит поиск именно по ним, в приведущих версиях поиск записей проводился методом сканирования таблицы (ест. блокируя ее), что увеличивало количество блокировок и ожидания. Это как минимум. У нас тоже большое предприятие, но ничего, в суботний день делали переход, база в 35 гиг (достаточно сильно перелопаченая УПП) реструктуризация шла примерно 1.5 часа...

Спасибо, попробуем сделать реструктуризацию.

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

Бэкап делаем каждый день Подскажите как делать отчистку процедурного кеша? или где почитать про это?

Если у вас "почти" типовая УПП, то переведите ее в управляемый режим блокировок, по-идее должно стать лучше.

Еще включите "быстрое перепроведение документов"

не стал бы я торопиться с управляемым режимом, имхо дело в чём то другом. можно тут почитать:

На ИТС очень подробно расписано..

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

В режиме управляемых блокировок, используя PostgreSQL скорость и параллельность проведения для базы размером 36 Гб выросла настолько, что 70 пользователей не замечают идущего фоном проведения по партиям, база - переписанная УТ 10.2.6, в режиме управляемых блокирок даже на MS SQL об этом можно было только мечтать

дак то PostgreSQL, в автоматическом он блокирует таблицы как и в файловом, т.е. таблицы а не записи, потому так выросла скорость, имхо

а поподробнее - как размер лога влияет на блокировки? первый раз слышу

мысли вслух ... Странно, блокировки живут во время транзакции ...

Скорее не блокировки, а ожидание, увеличивается время записи в лог,соответственно запросы находяться в режиме ожидания и начинают отваливаться по таймауту. Для пользователя вылетает ошибка транзакции... Так же наблюдается общее замедление работы, в принципе по той же причине...

внимательней читай пост :) написано же что PostgreSQL с управляемыми на порядок быстрее чем MS SQL  с автоматическими.

этож на сколько должно увеличится время записи?

Порядком :) У нас особенно после перепроведения доков напрмер за месяц лог пухнет капитально. Дня за 3 может сьедать до 70 гигов.... Бывало, как то отключали бекап... Вот и представь, он такой лог открывает :) Вот база и тормозит не по детски...

>Вот и представь, он такой лог открывает эм.. чувак, а ты хоть паскаль изучал,а ?

Чувак, а ты реально с такими базами работал? Когда поработаеш, посмотриш как все раком стоит, часик пошринкуеш лог, после этого база начинает летать, тогда поймеш и причину. А можеш наглядно  в ЦУП отловить... Можно вручную в технологическом журнале ошибки разобрать и сопоставить... Теоретики блин...

а в simple не переводите кстати? не помогает? от логов всмысле

Однозначно установленна причина увеличения времени проведения по партиям! Характерно только для неоперативного проведения. Сервер 1С не чистит за собой свои временные папки, когда они достигают достаточно большого размера работать становится невозможно. Помогает только их удаление вручную. включили, эффект нулевой SQL сервер непричем, с ним все хорошо Как заставить сервер 1с чистить свои папки?

Отключил полнотекстовый поиск! Время на проведение документов стабилизировалось и стало укладываться в приемлемые рамки, а вот время на построение отчетов увеличелось в раза два, но это не критично.

Индексы полнотекстового поиска пишуться в папку сервера. Они и есть причина существенного замедления работы.

:) О полнотекстовом поиске я даже не подумал, так как мы его не включали. Как я понял, поиск в временных папках хранит индексы, отсюда "чистка" как бы заключается в обновление индекса.  К стати если у пользователей есть доступ к журналу регистрации и они им пользуются, то лучше забрать. Так же тормозит систему особенно если несколько залезут.