Конфликт блокировок при выполнении транзакции в ЗУП
Здравствуйте, у нас имеется серверная Зарплата и управление персоналом КОРП, редакция 3.1 (3.1.10.135) , сильно доработанная. В один вечер при сохранении копии через конфигуратор стал показывать что в базе работает еще один пользователь которого не было в активных сеансах (ни в активных пользователях, ни в сеансах Администрирования серверов 1С). После перезагрузки служб проблема исчезла и появилась новая (на скриншоте). Перечитал кучу текста, но не смог понять в чем может быть проблема. Перезапуск служб на несколько часов решает проблему, а после процесс SQL съедает кучу оперативки, тормозит и начинает выдавать такую ошибку в рандомных документах. Пытался откатывать изменения на момент корректной работы, но результат тот же. Подскажите пожалуйста, что еще может быть.
Прикрепленные файлы:
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Еще как вариант заметил такую вещь. SQL и 1С начали сжирать гигантское количество места на ЖД, если перезапустить службы, то освобождается больше 40+ Гб. Очень сильно напрягается память, в связи с этим зависания, замедление работы и как итог блокировки.
1) в администрировании сервера 1с предприятия, отключить работу всех фоновых заданий
2) Перезапустить сервер 1с предприятия.
3) Проверить.
Если не поможет
Выгрузить базу в файловую, развернуть ее файловом варианте проверить, на повторение ошибки, в случае повторении ошибки. chdbfl тестирование исправление, выгрузка в dt загрузка из dt
Если не поможет.
4) Смена платформы заливка cf той же версии базы обновление. все на файловой
2) Перезапустить сервер 1с предприятия.
3) Проверить.
Если не поможет
Выгрузить базу в файловую, развернуть ее файловом варианте проверить, на повторение ошибки, в случае повторении ошибки. chdbfl тестирование исправление, выгрузка в dt загрузка из dt
Если не поможет.
4) Смена платформы заливка cf той же версии базы обновление. все на файловой
(14) На файловой теперь в местах где выходили блокировки, пишет следующее.
Самое что интересное, сделал замеры производительности и "задумывается" он при выполнении обычного запроса, в абсолютно типовом модуле...
Попробовал обновить, тоже не дало результатов.
Неспецифицированная ошибка работы с ресурсом
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
Недостаточно свободной памяти для выполнения операцииСамое что интересное, сделал замеры производительности и "задумывается" он при выполнении обычного запроса, в абсолютно типовом модуле...
Попробовал обновить, тоже не дало результатов.
Судя по сообщениям, блокировки идут на уровне СУБД. А конфигурация на управляемых блокировках. Один из вариантов такого поведения - это эскалация блокировок. Поэтому сразу вопрос - сколько записей в документах? Если число сотрудников там тысячи, то наверняка эскалация. Если сотни - то тоже возможно.
Обновление железа вам вряд ли сильно поможет в такой ситуации.
Период ожидания тоже увеличивать не стоит.
На SQL включен рекомендуемые флаги трассировки? Проверьте флаги 1211 и 1224. Если выключены - включите один из них. Эти флаги описаны в статье на ИТС "Флаги трассировки для работы с MS SQL Server". Еще стоит включить 1118, если версия сервера ранее 2016, иначе могут быть блокировки на временных таблицах в одном экстенте.
Если все это не поможет - то надо включать трассировку событий (профайлер, либо расширенные события на SQL) и выяснять точные причины. Технологический журнал тут вряд ли сильно поможет.
Обновление железа вам вряд ли сильно поможет в такой ситуации.
Период ожидания тоже увеличивать не стоит.
На SQL включен рекомендуемые флаги трассировки? Проверьте флаги 1211 и 1224. Если выключены - включите один из них. Эти флаги описаны в статье на ИТС "Флаги трассировки для работы с MS SQL Server". Еще стоит включить 1118, если версия сервера ранее 2016, иначе могут быть блокировки на временных таблицах в одном экстенте.
Если все это не поможет - то надо включать трассировку событий (профайлер, либо расширенные события на SQL) и выяснять точные причины. Технологический журнал тут вряд ли сильно поможет.
В общем решилось все следующим путем:
Один сотрудник добавлял данные регистров начислений через обработку и ошибочно добавил данные за период 2301ого года, как итог программа не могла это нормально рассчитать. Исправил удалением этих данных. Спасибо всем кто помогал.
Один сотрудник добавлял данные регистров начислений через обработку и ошибочно добавил данные за период 2301ого года, как итог программа не могла это нормально рассчитать. Исправил удалением этих данных. Спасибо всем кто помогал.
(21) ставишь точку останова в месте модуля, где блокировка сработала ,в отладку подключаешь всех активных пользователей = таким образом отловишь "активного" пользователя - он сам к тебе позвонит - скажет что 1с висит. А она не висит, ты просто поймал его в отладке. Далее узнаешь, что он делал и смотришь что "не так" сделал.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот