С переходом более-менее разобрались, стали задумываться о масле на хлебушек.

ЗУП3 работает в файловом варианте на терминальном сервере на RAID1. Пользователей: 4. И это просто тормоза из ряда вон. Свод на 200 человек формируется за 9 сек., не считая ожиданий менюшек.

Перенес базу на SQL-сервер, получил те же 9 сек. И это не укладывается в голове. Недавно переносили КА 2.4 на SQL и она стала работать ощутимо быстрее. А здесь нулевая реакция.

При повторном формировании свода на SQL-сервере время не сокращается, а в файловом варианте сокращается до 5 сек.

Что этому управляемому интерфейсу ЗУП3 не хватает для счастья?

(0) Индексы на стороне SQL обновляли?
Редакция какая?

(1) точнее версия, 3.1.7?

А с чего вы, сударь, решили, что при переходе на клиент-сервер у вас чтото ускорится?

(2) 3.1.5.313, пока на этой сидим;
(3) По аналогии с КА 2.4. Там перенесли и все стало хорошо, причем, само-собой.

(0) Если программа работает быстро, это несолидно, уважать не будут. Оставьте все, как есть.

(5) Плачуть, вопрошають, сморят как на спасителя...

(6) Не верь женскому коварству. Сделаешь ЗУП 3 быстрее - не останется времени на чай и печеньки, угадай, кого назначат виновным?

(0) 9 сек на формирование отчета - это много? Ерунда какая-то.

(8) +1

может, 9 мин?

Проверил на 500, свод за 11 секунд. Но сервер совсем дубовый.

(8) Для сравнения на ЗУП 2.5 тот же свод <1 сек. Но это не только свод разница ощущается просто при работе с программой. Возникает ощущение, что или ты где-то не докрутил, или 1С не туда свернули.

(11) Файл, SQL? Сколько человек?

(0) Вы не сможете. Забейте.

(1) Прямо индексы не обновлял, но переформировывал несколько раз отчет. Это считается?

(14) ...
Коль искра сильных разгорится в нас,
Мы разрешим судьбы головоломки,
И жизнь прекрасной сделать без прекрас,
Сумеем мы, достойные потомки.

http://www.stihi.ru/2017/11/19/11261

(0) Тут у меня в соседней ветке такая же проблема :)
Какой сервер лучше использовать для УФ?

(13) SQL, всего сейчас в разных базах сидит 643 пользователя. Всего по организации 500 сотрудников в ЗиК ГУ.
ЦП SQL загружен на 80%, диски донные, если скажу какие - засмеют. Новые СХД не закупают.

(17) Апач, интересно... Клиент-серверный вариант ему уступает, вроде как прослоек меньше?

(18) Получается, SQL показывает сопоставимую производительность с файловым вариантом, дела...

(0) Дык, вы для интереса посмотрите, как этот самый свод формируется? Недавно обсуждали в теме про сложность конфигураций. Там гирлянда процедур и пакетов запросов.

(20) А кто сказал что будет быстрее? Файловая 640 человек потянет?

(22) Имеется в виду, что у меня 9 сек. в SQL, у вас 11 сек. Т.е. примерно равно. И файловая теже 9 сек., т.е. не понятно что делать дальше.

(14) Вы немного подробней расскажите. Ускорить можно, но это прям дебри-дебри, но можно. Или как не долбись лбом о стену, даже штукатура не осыпется?

(24) В ЗУП 3 скорость формирования отчетов - наименьшая проблема в текущем положении дел.

(21) Согласен. Они добавили новый слой процедур, но можно ли как-то повлиять его работу?

(25) :)

(23) Нашел клиентскую базу 3.1.5, развернул только что в файловом режиме.
Сотрудников 909, время формирования отчета 5 сек.

(28) Ночные, вредность, доплата за профуровень?

(29) Начнем с самого начала, вы структуру какую используете? Стандартную или выводите подразделения\сотрудников?

(26) Возможно все, только вот целесообразно ли... Я немного покопался с расчетной ведомостью (это вариант того же отчета с другой структурой) и написал свою на основе имеющейся для ЗУП 2.5. Возможно, в каких-то случаях можно обойтись без этого, но тогда скорее всего достаточно будет настройки своего варианта отчета.

(30) Полный свод, все подразделения, по одной организации за месяц. Типовой вариант отчета.

Возможно, возникло некоторое недопонимание. Ускорить свод не цель. Цель - ускорить всю ЗУП3. Тормозит не только свод и все остальные отчеты, документы, и пр. Приходится ждать после нажатия на кнопку сформировать, формы открываются так, как будто в процессе открытия решают задачу сходимости в n-мерном пространстве, ну а запуск конфигурации это особенное наслаждение для мазохиста.

(33)
Я бы проверил итоги (в пользовательском режиме) и индексы БД.
Включил APDEX, смотрел по проблемным участкам планы запроса. Сделал опрос пользователей что особо доставляет неудобств.
Пересмотрел настройки видов расчета, на инфостате была статья по их перенастройке, скорость вроде в несколько раз возросла.

(34) Спасибо.

Твердотельники помогают ускорить управляемые формы?

Для начала надо сделать тест Гилева, сообщить оценку.

(34) ... и ускорил формирование отчета на 1 секунду!!!

Ничего этому ЗУПу не поможет.

(36) Да, помогает. Особенно если база локально и ты один, ЗУП тогда более менее крутится.

(40) Ну это из серии "а кому то жемчуг мелкий". База на 11 тыс сотров - нормально работает, вполне приемлемо

(37) В тесте Гилева файловая в 4 раза быстрее SQL... :)

(38) С отчетом-то понятно. На первых версиях ЗУП/ЗиК ГУ (3.1.4 вроде) больничный на 1 человек мог рассчитываться на хорошем железе по 18-30 минут.

Есть косяки, например в порядке измерений регистра сведений "ПлановыйФОТ" (основной запрос "ВыборкаНачисленийНаДатыИзмененияИсточниковВторичныхДанных" не попадает в индекс), надо выставить примерно следующим образом:
Сотрудник, Начисление, ГоловнаяОрганизация, ДокументОснование, ФизическоеЛицо, ДатаОкончания, Год

Вместо:
Сотрудник, ДатаОкончания, Начисление, ФизическоеЛицо, ДокументОснование, ГоловнаяОрганизация, Год.

+(43) Плюс есть тьма запросов, где идет левое соединение к табличным частям документа. Выносишь получение данных ТЧ во временную таблицу и потом делаешь соединение с ней и запрос отрабатывает в 5-10 раз быстрее.

(44) Поправьте меня, если ошибаюсь. Ускорение за счет применения индекса достигается путем исключения цикла в цикле при умножении таблиц. При этом первый (внешний) цикл будет в любом случае, а внутренний, только по элементам на которые укажет индекс из присоединяемой таблицы.

Почему перенос ТЧ во временную таблицу дает ускорение, ведь умножение левое и первому циклу, циклу по ТЧ документа быть в любом случае, и нет разницы будет индекс у левой ТЧ или нет?

(0) Терпите. В 1с пришли "веб-программисты", а для них задержка меньше полминуты допустима.

(45) Надо голый запрос на MSSQL глянуть, похоже оптимизатор запросов так себя ведет.

Нашел только вот это:

Сложные запросы, использующие большое количество соединений
Раздел:    Соединения в запросе
Причина: Увеличивается время поиска оптимального плана запроса. Может быть не найден оптимальный план запроса за отведенное время.
Варианты решений: Пересмотреть запрос, постараться уйти
Разделить запрос на части, помещая каждую из них во временную таблицу
Критичность: Важно

Не знаю насчет ЗУПа, но в БП3 при переводе базы в режим клиент-сервер отчеты начинают запускаться через асинхронное фоновое задание с периодическим опросом состояния выполнения. Как следствие, отчеты формируются дольше (плюс время на инициализацию ФЗ, плюс квант первого опроса 2 секунды, плюс нарастание этого кванта, если не выполнился сразу). Вот была бы в 1с подписка на уведомления - было бы намного красивее.

(5), (14) Начинаешь понимать, что простые советы оказываются самыми мудрыми. Не можешь повлиять на проблему, измени свое отношение к ней.

На моей практике самым первым кандидатом на кривой план запроса шел параллелизм.
Вторым - устаревшая статистика.
Сложных запросов в ней не было. Были неоптимальные запросы, но никак не сложные.

+ (47) Там еще запросы вида:

|ПОМЕСТИТЬ ВТПоказатели
|ИЗ
|    Документ.ИзменениеОплатыТруда.Показатели КАК ИзменениеОплатыТрудаПоказатели
|        ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ИзменениеОплатыТруда.Начисления КАК ИзменениеОплатыТрудаНачисления
|        ПО ИзменениеОплатыТрудаПоказатели.Ссылка = ИзменениеОплатыТрудаНачисления.Ссылка
|        И ИзменениеОплатыТрудаПоказатели.ИдентификаторСтрокиВидаРасчета = ИзменениеОплатыТрудаНачисления.ИдентификаторСтрокиВидаРасчета
|        ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ИзменениеОплатыТруда КАК ИзменениеОплатыТруда
|        ПО ИзменениеОплатыТрудаПоказатели.Ссылка = ИзменениеОплатыТруда.Ссылка
|ГДЕ
|    ИзменениеОплатыТруда.Ссылка = &Ссылка

Т.е. сперва идет соединение табличных частей документа без отбора и в конце отбираются данные по текущему документу.

(51) sql нормально это прожевывает.

Хотя, не уверен, надо проверить.

(50) Интересно как себя покажет Слон (postgresql). Как известно в многопоток он не умеет. Есть ли среди нас люди, у которых он развернут, сравнить как отработает что-то похожее на (51) .

(51) Оптимизатор sql сам решает, как он будет выполнять запрос. Для этого используется статистика. Можно перехватить профайлером и посмотреть план.

(51) Это внутреннее соединение здесь есть возможность сократить как первый (внешний) цикл, так и второй. И "правильный" sql будет строить индекс индексов. В этом случае наличие индексов у внешней таблицы, безусловно, важно.

(53) Сейчас занимаюсь переносом 50 организаций. Делал замеры, на подобных вещах жутко тормозило.
Безобразие нашел в 2-3 документах, перетащил во временные таблицы + изменил порядок в регистре сведений.
Было: 680 минут (одна организация)
Стало: 296 минут.

(54), (55), (56) Вы мне сейчас все про теорию, я на практике поправил таким образом. Насчет статистики не знаю как ее обновлять во время переноса данных из предыдущей редакции, постоянно дергать вроде не есть хорошо?

+ (57) Ради интереса сегодня-завтра разверну копию, приведу индексы и тд в порядок и посмотрю профайлером что не так.

(57) О том и речь. Действительно, закидываете в ВТ, прикручиваете индекс, и внутреннее соединение работает быстрее.

(0) насчет свода - попробуйте итоговый запрос который исполняется в СКД выполнить в консоли запросов.
На некоторых отчетах (в частности оптимизировал ЗПкультура) время выполнения в консоли быстрее в разы. Тут, я думаю, дело в СКД - не любит оно большие гирлянды.

(0) проверьте настройки сортировки представления) сотрудников,  можно попробовать выбрать вывод только ФИО.

(57) По сколько сотрудников в организации в среднем?

(0) на скуле темпы пользователя под которым сервер 1с крутится  попробуй на ССД или РАМ диск кинуть. У нас отчеты БП3 в разы быстрее стали формироваться.

(63)+ и темпдб на ССД

(64) И каталог аппдата 1с - туда же. Ибо там кэш метаданных.

(0) "ЗУП3 работает в файловом варианте на терминальном сервере на RAID1. Пользователей: 4"
Памяти на сервере - 8 Гб ?

(54) "Широкоизвестный факт" от службы ОБС?  Нормально слон все умеет.

(62) первые 10 крупных от 500 до 700. Остальные по нисходящей до 190.
Но попросили делать полный перенос со всей кадровой историей, поэтому переносимый объем увеличивается раза 3.

(63), (64), (65) Спасибо!

(66) RAM: 32 Gb, доступно 9 Gb. Свободный остаток после того, как все пользователи загрузятся. ЗУП3 на рейде одна, все остальное на скуле.

(67) Имелось в виду postgresql и многопоточность в рамках одного запроса. Читал статью, где-то в 2015г., там утверждали, что не могЁт.

(71) грубо говоря, в рамках одного уже готового запроса и мс-скуль тоже не умеет разделять один процесс на разные потоки.

(71) Тот который от 1С по умолчанию не мог.
У слона все оптимизации по умолчанию в принципе выключены. В 2015 слон не мог нормально CROSS JOIN да
и JOIN временных таблиц  с физическими параллелить не мог. С тех пор  много чего поправили. Сейчас слон работает нормально. Но с физическими таблицами join делать все равно не стоит.

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

(72) Даже 1С научился потоки уже разделять. Сколько потоков в итоге будут использовать  компилятор/оптимизатор/ридер - это тебе даже сами авторы СУБД сказать не смогут.

(74) Процессы и потоки как-бы при старте сервера заводятся на разных процессорах. Они не запросом порождаются. Процесс просто разбрасывает по ним задачки.

(75) это в каком месте 1С разделяет процессы потоки? механизм этого разделения можете озвучить?

(75) Поставь MaxDOP = 1 и ты точно будешь знать, сколько потоков у тебя будет использовать скуль на один запрос

(76) уже теплее :-)
Т.е. в принципе пофиг, как это работает на уровне СУБД, умеет СУБД крутить разные потоки одного процесса на разных ядрах или не умеет. Важно, что в готовом исполняемом из типовой(!) конфигурации ОДНОПОТОЧНОМ коде от 1С множества потоков не сгенирится.

(77) CreateThread() / fork().  8.3.12 таки научился в потоках работать. Смотрел по htop.  

(79) SQL запрос и код 1С в разных контекстах будут исполняться. И в моем случае на другой ноде вообще :-)

(80) // И в моем случае на другой ноде вообще :-)

ВОТ!!! Еще теплее! Так что самый первый рецепт для ускорения скульной 1С-ки Илья таки не выполнил, скорей всего. Я имею ввиду, что нужно было не только тест Гилева найти, но также инструкцию по настройке 1С кластера

(81) Тест Гилева показывает очень средние попугаи. Узких мест не ловит.

(82) Главное, чтоб обязательно не читали никаких инструкций нигде, а только на мисте в прямом общении узнавали сакральные нечто

(81), (83) Спасибо за критику, буду выполнять этот первый рецепт для ускорения скульной 1С-ки.

Развернул ЗУП3 на диска в оперативной памяти (RAM), видимо, эту производительность можно считать эталонной. Показатели следующие:

Запуск после ввода пароля: 16 сек.;
Свод, типовой вариант:

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

(85) +
Свод, типовой вариант: 5 сек., 4 сек., 4 сек.

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

(83), (86) Как вы считаете возможно дотянуться до показателей из (85)+(87) при выполнении оптимизаций сервера 1С и MSSQL?

(88) Да можно. Запусти в отладчике "Измерение производительности" для двух вариантов. Посмотри в каком месте тормозит, тормоза форм списков при открытии - это довольно странно. Платформа какая?

(52), (55), (59)
Сравнил скорость, действительно если статистика и индексы в порядке - разницы никакой, MSSQL отработал корректно.
Получается, проблема актуальна только во время переноса данных из старых редакций.

Ради интереса проверил аналогичные операции на файловой базе, там 70% времени уходит на запрос, который исправлял путем вынесения во временные таблицы.

(71) Статья 2016-го года, утверждается, что может https://habr.com/post/305662/
10-й может еще больше https://habr.com/company/postgrespro/blog/352144/

(91) Кстати сегодня как раз вышла 8.3.13 c официальной поддержкой 10-ки. И наконец без патчей, а на полностью стандартном слоне.

(92) Где инфа про "полностью стандартный слон"? Ссылка на десятку или на 1Сный, или на ПостгреПро. С ПостгреПро 10.ч и последние 8.3.12 работают

(93) https://releases.1c.ru/version_files?nick=AddCompPostgre&ver=10.3-2.1C

>>С ПостгреПро 10.ч и последние 8.3.12 работают

Официально не работают. Я не любитель совсем уж бета-версий.

Извиняюсь за отсутствие, только вернулся от руководства. Установили новые приоритеты и поставили "сверх" срочные задачи. Со временем сделаю все необходимые тесты и отпишусь.

(95) Я еще в (14) все вам рассказал.

(96) И я "все понял", еще раз спасибо. Тут в (89) обещают производительность сопоставимую с RAM-базой, если все хорошо настроить на скуле. Надо попробовать, а вдруг выгорит.

(92) В исходных текстах(по ссылке в (94)) патчи с доработками 1С как лежали, так и лежат. И при сборке их также надо применять к оригинальной версии.

Как там у автора темы с ускорением работы в ЗУП, что-нибудь получилось?

(98) Автор пока прокачивает скил, читает о тесте Гилева и роет интернеты в поисках всевозможных оптимизаций скуля, которых у нас еще нет. В свободное от работы время, естественно.

Чуть позже продолжим приключения.

(99)+ Нас с коллегами опьяняет мысль не заморачиваться со скулем, а тупо купить NVMe SSD, порадоваться за несколько возросшую производительность, а во всем остальном, что не ускорилось обвинять вендора (1С).