Всем привет! Вопрос такой: когда ОТИЗ проводит "Сдельный наряд" программа его проводит минут 10, в это время блокируются регистры бухгалтерии видимо, и ни один документ связанный с бухгалтерским учетом не проводится из-за конфликта блокировок (превышено время ожидания конфликт блокировок). То же самое происходит когда допустим проводится "Отчет производства за смену", а другие ждут. Конфигурация типовая, и такие траблы не дают работать в базе одновременно. Это так не продумано разработчиками стандартной конфы УПП 1.3 или где-то что-то можно поднастроить?
1С:Предприятие 8.3 (8.3.5.1248)
УПП 1.3.76.3
1С:Предприятие 8.3 (8.3.5.1248)
УПП 1.3.76.3
По теме из базы знаний
- Работа с управляемыми блокировками в примерах. Новая схема проведения документов 1с 8.2.
- Методика оперативного проведения и управляемые блокировки
- Простое программное решение проблем с блокировками SQL
- Подсистема настройки управляемых блокировок
- Формирование движений документов по выбранным регистрам без проведения
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Anesk,
Вообще, странно что проводятся по 10 минут. Особенно сдельный наряд. Вроде как никаких выдающихся расчетных механизмов в нем не было.
Не, ну я понимаю, там ОПС с 100 наименований продукции и 1000 материалов, но сдельный наряд...
База большая? Сколько пользователей работает? Какой сервер БД?
Вообще, странно что проводятся по 10 минут. Особенно сдельный наряд. Вроде как никаких выдающихся расчетных механизмов в нем не было.
Не, ну я понимаю, там ОПС с 100 наименований продукции и 1000 материалов, но сдельный наряд...
База большая? Сколько пользователей работает? Какой сервер БД?
(5) Anesk,
Мне кажется, можно найти резерв на увеличение производительности в аппаратно-программной части (начиная от железа конкретных серверов, сети, включая MSSQL, и заканчивая 1с-сервером)
Если про 10 минут вы выразились буквально, а не переносно - ИМХО какая-то там есть аномалия.
Есть сравнимая база (~100 гб, около 70 польз, УПП), причем с чудовищным бардаком внутри (что не добавляет ей производительности), работающая на откровенной рухляди 2008-х годов сборки. Она, конечно, не то, чтобы летает - но так не тормозит.
Пять лет назад была база примерно такая же в другом месте, и тоже работало вменяемо. Не на самой новой технике даже по тем временам.
Проверьте время проведения при работе в базе 1 пользователя (чтобы гарантированно не толкаться блокировками).
Проверьте время проведения при запуске клиента непосредственно на сервере 1с.
Пройдите отладчиком/профайлером - определите "долгие" команды, т.е. слабые звенья программной части.
Если это работа с запросами / запись регистров, то проверьте загрузку компонентов системы при таких операциях - CPU, память, диски. На сервере 1С, на сервере БД, сеть между ними, сеть с клиентами.
Возможно, в некоторых регистрах висят жутко доисторические незамкнутые остатки, которые не нужны для учета и нужно их спилить.
Возможно, есть какие-то дописки, которые плохо работают.
Мне кажется, можно найти резерв на увеличение производительности в аппаратно-программной части (начиная от железа конкретных серверов, сети, включая MSSQL, и заканчивая 1с-сервером)
Если про 10 минут вы выразились буквально, а не переносно - ИМХО какая-то там есть аномалия.
Есть сравнимая база (~100 гб, около 70 польз, УПП), причем с чудовищным бардаком внутри (что не добавляет ей производительности), работающая на откровенной рухляди 2008-х годов сборки. Она, конечно, не то, чтобы летает - но так не тормозит.
Пять лет назад была база примерно такая же в другом месте, и тоже работало вменяемо. Не на самой новой технике даже по тем временам.
Проверьте время проведения при работе в базе 1 пользователя (чтобы гарантированно не толкаться блокировками).
Проверьте время проведения при запуске клиента непосредственно на сервере 1с.
Пройдите отладчиком/профайлером - определите "долгие" команды, т.е. слабые звенья программной части.
Если это работа с запросами / запись регистров, то проверьте загрузку компонентов системы при таких операциях - CPU, память, диски. На сервере 1С, на сервере БД, сеть между ними, сеть с клиентами.
Возможно, в некоторых регистрах висят жутко доисторические незамкнутые остатки, которые не нужны для учета и нужно их спилить.
Возможно, есть какие-то дописки, которые плохо работают.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот