Всем привет, возник такой вопрос: платформа 8.3.6.2041, конфигурация: Зарплата и Управление Персоналом, редакция 2.5 (2.5.94.2). Сервер 1С предприятия и СУБД (Microsoft SQL 2012) установлены на одной машине, нагрузка на сервер минимальная,  расчеты зарплаты для одного сотрудника происходит по 30 секунд, просадка при выполнении запросов, все стандартно, в чем может быть дело?

Сначала надо определить, в чем именно проблема:
1. замер производительности
2. технологический журнал
3. средства мониторинга ОС


без этого ветка пустая, как бубен

(1)
замер производительности показал затык на запросе ВТРаботникиИНачисленияПлановыеНачисления
средства мониторинга ОС: Процессор 3%, Диск 7%, Сети 3%, Память 55%

Сервер Intel(R) Xeon(R) CPU E7-4820 2.00GHz 4 процессора 64 ядра, 512 ОЗУ, 50% отдано MSSQL

(2) переходи ко второму пункту

средства мониторинга ОС что показывают? Где очередь скапливается?

смысл был 8.3 на 2.5 ставить?обслуживание делается?

(3) А оперативки не маловато для Сервера?
Эт по любому сотруднику, или по какому то одному?
ТИИ на копии Пробовали?. лучше не стало?

(0) попробуйте провести документы под пользователем с полными правами.

(6)(7) все регламенты отключены, развернул тестовую базу, в нее ввел одного сотрудника, беру документ начисление зп пытаюсь заполнить документ по всем сотрудникам - заполняется 60 секунд, и это в базе в которой нет данных и один сотрудник, на этом же серваке крутиться база в которой в день проводиться и и записывается по 700 000 - 800 000 документов, и сервак не напрягаясь это все делает, как такое может быть...

(9) в словах "512 ОЗУ" ошибки нет?

(9) нет именно 512 гб озу

а ГБ, понятно.
в общем, смотри, какой запрос идет в СУБД и что происходит в это время с железом. Потом делай выводы

для ЗУП в SQL настроен прирост БД в 10%, режим восстановления Simple

512ГБ памяти и занято 55%?
А размер базы? Небось пару терабайтов занимает?

нет, размер этой баз 390 мб, размер всех баз которые крутятся на серваке не превышает 250 гб.

(13) ну ты же сказал, что регламенты отключены. и что ты хочешь?

ну и может у тебя max degree of parallelism не равен 1.

max degree 0

(16)я посмотрел регламенты, там нет тех которые бы ускорили заполнение документа(

(19) о каких идет речь?

(20)
ВыполнениеОбмена
ЗаданиеАвтономноеРешение
ЗаданиеОтложенныеДвижения
ОбновлениеИндексаППД
ПересчетИтоговРегистровНакопления
ПолучениеЭлектронныхСообщений
РасчетОстатковОтпусков
СинхронизацияДанных
СлияниеИндексаППД
СозданиеЗадачИсполнителям
УдалениеНеактуальнойИнформацииСинхронизации

в MSSQL регламенты по обновлению статистики, очистки проц кэша, дефраг. индексов включены, но факт в том что в базе нет данных, что бы она так висела

(22) Отлови план выполнения запроса на SQL сервере. Может там увидишь что-то что наведет на мысль.

(22) тогда ТЖ и планы

и поставь max degree of parallelism = 1. Ноль это значит что сервер самрешает как распаралеливать выполнение операций в плане.

(25)+ пальцем в небо конечно, но вдруг...

Глянул в УПП. В этом запросе ПлановыеНачисленияРаботниковОрганизаций соединяется левым соединением с самим собой и в условии соединения составное поле ВидРасчетаИзмерение. Да и с индексами у регистра почти никак.

как всегда задам вопрос - виртуалка????

и как всегда дам ссылку http://wiki.mista.ru/doku.php?id=it:analiz_sql_block

(25) не поможет

(28) нет не виртуалка

(29) а если не секрет откуда знаешь?

(29) 0 нужен для второй базы в которой идет именно работа с добавление в таблицы, по этому этот параметр я не могу поменять, 1 в данном случае когда мы работаем с аналитикой, т.е. отчеты.

(30) Сомнения у меня, что не виртуалка :)
Уж больно много ресурсов, что бы не соблазниться на виртуалки :)

(33) нет, это точно не вируталка 1000%

про кеш уже было?

sql не пытается обновления установить ежесекундно?

(35) про процедурный кэш, или вообще, о кстати про кэш 1с я и забыл, сейчас проверю

1. регламенты скуля настроены? обновление статистики как часто идет?
2. пробовал sys.dm_db_missing_index_group_stats и иже с ними?

что-то ещё про незакрытые транзакции слышал - скуль начинает дико тормозить

(25) это вредительство для восьмерки

https://technet.microsoft.com/ru-ru/magazine/jj128029.aspx

(38) регламенты MSSQL 5 утра каждый день обновление статистики, очистка проц кэша, дефрагментация индексов

(42) если обновление статистики идет не час - то можно и по чаще делать, я раз в час делаю, хотя зависит от базы...

короче остаётся варианта 3

1. кривой код 1с (например запрос в цикле), тут все понятно
2. блокировки, тут надо смотреть скрипт (28)
3. слабая архитектура базы (излишняя нормализация или недостаток индексов)

(44) еще данные кривые тоже могут

(45) в данных один человек, я его внес руками:), в SQL Profiler нашел запрос который занимает больше всего времени

а может дело в самой платформе, или в том что сервер работает на чистоте 2Гц на каждое ядро и 1С этого маловато

(47) попробуй на 8.2

(46) если нашел запрос - смотри его план, там будет стоимость операций, и скажи что там весит много.

а лучше выложи скрин графически в xml plan

в жопу все, автору обновиться на ЗУП 2.5.96.2

Проверить на актуальной или даже тестовой 8.3.7 уже было?

проблема решена, дело было КЭШ 1С, но как это могло так влиять на производительность ума не приложу...

всем спасибо большое!

а нет, рано радовался, буду анализировать запрос, все равно всем еще раз спасибо большое.

(47) Если бы был PostgreSQL, я бы не удивился, ЗиК БУ(читал и про ЗУП) на платформе 8.3.5-8.3.6 так себя и ведет. Но там и ошибка зарегистрирована(когда вылечат, неизвестно). На 8.2 все хорошо. Для MSSQL это странно...
Когда-то тестировал  E7-4870(4шт.) на предмет влияния гипертрединга на гигафлопсы, при отключенном HT гигафлопсов было больше.

(56) у меня постгрес есть один запрос (при изменении вида времени (буквой) в табеле) идет 20 секунд.

Чего делать? )

(57) ЗУП 2.5

(55) запрос типовой, чего там анализировать. значит что-то с данными

(59) Типовые запросы в ЗУПе написаны как попало.

(60) какие?

(57)->(51)

все стандартное работает стандартно посредственно )))

А вообще по поводу постгреса, есть смысл на винде на него переходить

я перешл потому что поиск хреново работал. Поиск стал работать лучше. Но проведение документов стало медленней, и появились некоторые запросы которые делаются очень долго.

перешел с файловой*

(27) Ага... есть такое. Мы сами индексы добавили. 2 года полет нормальный. Расчетчик перестал жаловаться на тормоза.