Частые блокировки и медленная работа пользователей 1С ЗУП 3.1
Добрый день!
Платформа 1С:Предприятие 8.3 (8.3.11.3034)
Конфигурация Зарплата и управление персоналом, редакция 3.1 (3.1.5.129), режим серверный, используется СУБД MS SQL Server 2016
Пользователей в базе до 50, одновременно работающих 25-35
Осуществили переход с ЗУП 2.5 на ЗУП 3 в начале этого года переносом остатков, соответственно база пока не большая по объему (около 5 Гб на сервере)
К сожалению, большого опыта работы с ЗУП 3 нет, соответственно, не было понимания как будет вести себя программа в версии конфигурации 3х, на версии 2х работа программы была вполне сносной.
Теперь проблемы случаются практически каждый день, пользователи жалуются на очень медленную работу программы, постоянно виснут, ждут элементарно открытия справочника Сотрудники бывает и минут 15-20, документы открываются очень долго, на сервере 1С Предприятия все время наблюдаю в колонке "Захвачено СУБД" растущие цифры сразу у нескольких пользователей.
С момента перехода на версию 3 перепробовали несколько настроек по производительности серверов, в частности сервера MS SQL, все приведено в соответствии с рекомендациями как специалистов MS SQL Server, так и специалистов по 1С, как в части выделенных аппаратных ресурсов, так и в части настроек параметров СУБД. Но воз и ныне там, ничего кардинально не произошло.
Подозреваем больше всего настройку в конфигурации ЗУП "Ограничивать доступ на уровне записей", и самое главное, на "Доступ с точностью до физических лиц", используется этот режим в первую очередь чтобы разграничить доступ групп пользователей к группам сотрудников, которые разделены по обособленным подразделениям компании. А сотрудников в компании очень много - порядка 4 тыс. человек.
На данный момент есть только соображения, сейчас в базе есть только одна организация, обособленные подразделения выделены подразделениями в справочнике, так сделано исходя из того, что отчетность нужно сдавать единую по обществу, например, 4 ФСС.
Так вот, нужны советы, есть 2 предположения как все устроить:
1. Обособленные подразделения все же сделать организациями, убрать настройку "Доступ с точностью до физических лиц", эту настройку считаем стержнем наших проблем, источником тормозов. Отчетность, которую требуется сделать единой по обществу, нужно дописать, чтобы была возможность сформировать единую.
2. Сделать РИБ, филиалы будут работать только в своих информационных базах, где будут присутствовать только их физические лица, но РИБ можно организовать только в разрезе организаций, не по подразделениям. Да и с РИБ гораздо больше заморочек, гораздо удобнее работать в единой информационной базе.
Подскажите, кто уже сталкивался с подобной проблемой, что можете порекомендовать. Очень нужны советы.
Платформа 1С:Предприятие 8.3 (8.3.11.3034)
Конфигурация Зарплата и управление персоналом, редакция 3.1 (3.1.5.129), режим серверный, используется СУБД MS SQL Server 2016
Пользователей в базе до 50, одновременно работающих 25-35
Осуществили переход с ЗУП 2.5 на ЗУП 3 в начале этого года переносом остатков, соответственно база пока не большая по объему (около 5 Гб на сервере)
К сожалению, большого опыта работы с ЗУП 3 нет, соответственно, не было понимания как будет вести себя программа в версии конфигурации 3х, на версии 2х работа программы была вполне сносной.
Теперь проблемы случаются практически каждый день, пользователи жалуются на очень медленную работу программы, постоянно виснут, ждут элементарно открытия справочника Сотрудники бывает и минут 15-20, документы открываются очень долго, на сервере 1С Предприятия все время наблюдаю в колонке "Захвачено СУБД" растущие цифры сразу у нескольких пользователей.
С момента перехода на версию 3 перепробовали несколько настроек по производительности серверов, в частности сервера MS SQL, все приведено в соответствии с рекомендациями как специалистов MS SQL Server, так и специалистов по 1С, как в части выделенных аппаратных ресурсов, так и в части настроек параметров СУБД. Но воз и ныне там, ничего кардинально не произошло.
Подозреваем больше всего настройку в конфигурации ЗУП "Ограничивать доступ на уровне записей", и самое главное, на "Доступ с точностью до физических лиц", используется этот режим в первую очередь чтобы разграничить доступ групп пользователей к группам сотрудников, которые разделены по обособленным подразделениям компании. А сотрудников в компании очень много - порядка 4 тыс. человек.
На данный момент есть только соображения, сейчас в базе есть только одна организация, обособленные подразделения выделены подразделениями в справочнике, так сделано исходя из того, что отчетность нужно сдавать единую по обществу, например, 4 ФСС.
Так вот, нужны советы, есть 2 предположения как все устроить:
1. Обособленные подразделения все же сделать организациями, убрать настройку "Доступ с точностью до физических лиц", эту настройку считаем стержнем наших проблем, источником тормозов. Отчетность, которую требуется сделать единой по обществу, нужно дописать, чтобы была возможность сформировать единую.
2. Сделать РИБ, филиалы будут работать только в своих информационных базах, где будут присутствовать только их физические лица, но РИБ можно организовать только в разрезе организаций, не по подразделениям. Да и с РИБ гораздо больше заморочек, гораздо удобнее работать в единой информационной базе.
Подскажите, кто уже сталкивался с подобной проблемой, что можете порекомендовать. Очень нужны советы.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Из своей практики скажу настройка разграничений доступа в разрезе организаций (если организация как филиал) неработоспособна из коробки, придется дорабатывать. Разграничить можно только в разрезе отдельных независимых организация, иначе возникают различного рода ошибки доступа.
С другой стороны если вам нужен например доступ некоторым категориям сотрудников в разрезе подразделений (например табельщики), а большинству нет надобности разделять (кадровики, расчетчики), можно доработать пару форм, сделать свои журналы документов.
С другой стороны если вам нужен например доступ некоторым категориям сотрудников в разрезе подразделений (например табельщики), а большинству нет надобности разделять (кадровики, расчетчики), можно доработать пару форм, сделать свои журналы документов.
(2) У нас как раз таки у единиц пользователей нет ограничения по доступу к физ лицам, у остальных присутствует. То что придется дорабатывать в плане сводной отчетности, да, к этому морально готовы
(3) Делали какие то определенные настройки MS SQL Server и сервера 1С Предприятия? Блокировки не появлялись ни разу?
(3) Делали какие то определенные настройки MS SQL Server и сервера 1С Предприятия? Блокировки не появлялись ни разу?
(4) На мой взгляд лучше отключить доступ на уровне физлиц, т.к. это во-первых тормоза, во-вторых проблемы с постоянной настройкой групп лиц, появился новый сотрудник добавьте его в группу, а если надо чтоб одни пользователи видели две группы лиц то тут тоже настройка групп и т.д.
Делайте доступ на уровне филиалов, да придется дорабатывать, но это будет работать надежней и быстрее. Дорабатывать нужно т.к. в большинстве регистров измерение ГоловнаяОрганизация, а не Организация. Плюс при создании сотрудника еще не известно в какую организацию пойдет сотрудник (у сотрудника нет реквизита организация, можно выбрать лишь головную организацию), поэтому пользователи с ограничениями филиалов(организаций) без доработки не смогут создавать сотрудников.
Итого: Нужно добавить свои роли, там настроить права на некоторые регистры, где либо убрать правила RLS, либо изменить с головной организации на организацию. Для справочника сотрудники в RLS разрешить отображение сотрудников у которых нет записи в РС ОрганизацииВКоторыхРаботалиСотрудники. В модуле справочника Сотрудники отключить добавление записи в этот регистр для нового сотрудника, организация потом установится документом приема. Доработать пару модулей, т.к. часть функций не передает параметр ВЫБРАТЬ РАЗРЕШЕННЫЕ = Истина, и в дальнейшем запросы дают ошибку(по ходу тестирования найдете эти функции).
Делайте доступ на уровне филиалов, да придется дорабатывать, но это будет работать надежней и быстрее. Дорабатывать нужно т.к. в большинстве регистров измерение ГоловнаяОрганизация, а не Организация. Плюс при создании сотрудника еще не известно в какую организацию пойдет сотрудник (у сотрудника нет реквизита организация, можно выбрать лишь головную организацию), поэтому пользователи с ограничениями филиалов(организаций) без доработки не смогут создавать сотрудников.
Итого: Нужно добавить свои роли, там настроить права на некоторые регистры, где либо убрать правила RLS, либо изменить с головной организации на организацию. Для справочника сотрудники в RLS разрешить отображение сотрудников у которых нет записи в РС ОрганизацииВКоторыхРаботалиСотрудники. В модуле справочника Сотрудники отключить добавление записи в этот регистр для нового сотрудника, организация потом установится документом приема. Доработать пару модулей, т.к. часть функций не передает параметр ВЫБРАТЬ РАЗРЕШЕННЫЕ = Истина, и в дальнейшем запросы дают ошибку(по ходу тестирования найдете эти функции).
В качестве примера:
В справочнике Сотрудники смотрели в форме списка произвольный запрос?
При всем уважении, команда ЗУП-а "пилит" его 4-ре года, но он все так же на
сотрудниках 5К+ тормозит.
Более того, в ранних версиях на форме обновление этого списка вызывалось два раза
при открытии, что было вроде исправлено после отправки срочной "телеграммы".
Этот справочник по сути наиболее востребован пользователя, но его оптимизация - увы.
Кроме этой ложки дегтя и еще пары-тройки в общем и целом ЗУП 3.1. неплох.
В справочнике Сотрудники смотрели в форме списка произвольный запрос?
При всем уважении, команда ЗУП-а "пилит" его 4-ре года, но он все так же на
сотрудниках 5К+ тормозит.
Более того, в ранних версиях на форме обновление этого списка вызывалось два раза
при открытии, что было вроде исправлено после отправки срочной "телеграммы".
Этот справочник по сути наиболее востребован пользователя, но его оптимизация - увы.
Кроме этой ложки дегтя и еще пары-тройки в общем и целом ЗУП 3.1. неплох.
(7) Редакция SQL не бесплатная. К сожалению, нет технической возможности разместить на ssd дисках
(10) Да, на мой взгляд лучше убрать "Доступ с точностью до физлиц", нежели связываться с РИБ. В любом случае, решение не лежит на поверхности. Про заморочки с организациями/головными организациями не знал
(11) Можно попробовать, но это решит часть проблем
(10) Да, на мой взгляд лучше убрать "Доступ с точностью до физлиц", нежели связываться с РИБ. В любом случае, решение не лежит на поверхности. Про заморочки с организациями/головными организациями не знал
(11) Можно попробовать, но это решит часть проблем
(12)
Не претендую на истину, но все же предположу, что ваша возьня с программной оптимизацией конфигурации, настройками СУБД, РИБами и т.д. не даст такого роста производительности, как расположение БД на ssd-дисках.
нет технической возможности разместить на ssd дисках
Не претендую на истину, но все же предположу, что ваша возьня с программной оптимизацией конфигурации, настройками СУБД, РИБами и т.д. не даст такого роста производительности, как расположение БД на ssd-дисках.
По РИБу не думали про такой вариант:
1. Создать распределенную из N узлов не разделяя - полные копии.
2. В каждой работает свой филиал или несколько - зависит от нагрузки.
3. Зарплату считать в главной.
В таком случае все будут видеть все но только с задержкой связанной с синхронизацией данных( обменом)
Обмены будут скорее всего долгими т.к. постоянно будут регистры наверное полностью передаваться.
1. Создать распределенную из N узлов не разделяя - полные копии.
2. В каждой работает свой филиал или несколько - зависит от нагрузки.
3. Зарплату считать в главной.
В таком случае все будут видеть все но только с задержкой связанной с синхронизацией данных( обменом)
Обмены будут скорее всего долгими т.к. постоянно будут регистры наверное полностью передаваться.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот