Вход | Регистрация


Информационные технологии :: Администрирование

Ускорить ЗУП3. Ой, тормозит

Ускорить ЗУП3. Ой, тормозит
Я
   1CIlya
 
24.09.18 - 13:52
С переходом более-менее разобрались, стали задумываться о масле на хлебушек.

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

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

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

Что этому управляемому интерфейсу ЗУП3 не хватает для счастья?
 
 
   timurhv
 
1 - 24.09.18 - 13:56
(0) Индексы на стороне SQL обновляли?
Редакция какая?
   timurhv
 
2 - 24.09.18 - 13:56
(1) точнее версия, 3.1.7?
   Amra
 
3 - 24.09.18 - 13:56
А с чего вы, сударь, решили, что при переходе на клиент-сервер у вас чтото ускорится?
   1CIlya
 
4 - 24.09.18 - 13:59
(2) 3.1.5.313, пока на этой сидим;
(3) По аналогии с КА 2.4. Там перенесли и все стало хорошо, причем, само-собой.
   SleepyHead
 
5 - 24.09.18 - 14:01
(0) Если программа работает быстро, это несолидно, уважать не будут. Оставьте все, как есть.
   1CIlya
 
6 - 24.09.18 - 14:02
(5) Плачуть, вопрошають, сморят как на спасителя...
   SleepyHead
 
7 - 24.09.18 - 14:04
(6) Не верь женскому коварству. Сделаешь ЗУП 3 быстрее - не останется времени на чай и печеньки, угадай, кого назначат виновным?
   NorthWind
 
8 - 24.09.18 - 14:06
(0) 9 сек на формирование отчета - это много? Ерунда какая-то.
   1Сергей
 
9 - 24.09.18 - 14:06
(8) +1
   NorthWind
 
10 - 24.09.18 - 14:06
может, 9 мин?
 
 Рекламное место пустует
   timurhv
 
11 - 24.09.18 - 14:07
Проверил на 500, свод за 11 секунд. Но сервер совсем дубовый.
   1CIlya
 
12 - 24.09.18 - 14:10
(8) Для сравнения на ЗУП 2.5 тот же свод <1 сек. Но это не только свод разница ощущается просто при работе с программой. Возникает ощущение, что или ты где-то не докрутил, или 1С не туда свернули.
   1CIlya
 
13 - 24.09.18 - 14:11
(11) Файл, SQL? Сколько человек?
   H A D G E H O G s
 
14 - 24.09.18 - 14:14
(0) Вы не сможете. Забейте.
   1CIlya
 
15 - 24.09.18 - 14:14
(1) Прямо индексы не обновлял, но переформировывал несколько раз отчет. Это считается?
   1CIlya
 
16 - 24.09.18 - 14:16
(14) ...
Коль искра сильных разгорится в нас,
Мы разрешим судьбы головоломки,
И жизнь прекрасной сделать без прекрас,
Сумеем мы, достойные потомки.

http://www.stihi.ru/2017/11/19/11261
   Builder
 
17 - 24.09.18 - 14:24
(0) Тут у меня в соседней ветке такая же проблема :)
Какой сервер лучше использовать для УФ?
   timurhv
 
18 - 24.09.18 - 14:27
(13) SQL, всего сейчас в разных базах сидит 643 пользователя. Всего по организации 500 сотрудников в ЗиК ГУ.
ЦП SQL загружен на 80%, диски донные, если скажу какие - засмеют. Новые СХД не закупают.
   1CIlya
 
19 - 24.09.18 - 14:27
(17) Апач, интересно... Клиент-серверный вариант ему уступает, вроде как прослоек меньше?
   1CIlya
 
20 - 24.09.18 - 14:30
(18) Получается, SQL показывает сопоставимую производительность с файловым вариантом, дела...
   d4rkmesa
 
21 - 24.09.18 - 14:30
(0) Дык, вы для интереса посмотрите, как этот самый свод формируется? Недавно обсуждали в теме про сложность конфигураций. Там гирлянда процедур и пакетов запросов.
   timurhv
 
22 - 24.09.18 - 14:30
(20) А кто сказал что будет быстрее? Файловая 640 человек потянет?
   1CIlya
 
23 - 24.09.18 - 14:33
(22) Имеется в виду, что у меня 9 сек. в SQL, у вас 11 сек. Т.е. примерно равно. И файловая теже 9 сек., т.е. не понятно что делать дальше.
   1CIlya
 
24 - 24.09.18 - 14:35
(14) Вы немного подробней расскажите. Ускорить можно, но это прям дебри-дебри, но можно. Или как не долбись лбом о стену, даже штукатура не осыпется?
   timurhv
 
25 - 24.09.18 - 14:40
(24) В ЗУП 3 скорость формирования отчетов - наименьшая проблема в текущем положении дел.
   1CIlya
 
26 - 24.09.18 - 14:44
(21) Согласен. Они добавили новый слой процедур, но можно ли как-то повлиять его работу?
   1CIlya
 
27 - 24.09.18 - 14:44
(25) :)
   timurhv
 
28 - 24.09.18 - 14:45
(23) Нашел клиентскую базу 3.1.5, развернул только что в файловом режиме.
Сотрудников 909, время формирования отчета 5 сек.
   1CIlya
 
29 - 24.09.18 - 14:47
(28) Ночные, вредность, доплата за профуровень?
   timurhv
 
30 - 24.09.18 - 14:50
(29) Начнем с самого начала, вы структуру какую используете? Стандартную или выводите подразделения\сотрудников?
   d4rkmesa
 
31 - 24.09.18 - 14:52
(26) Возможно все, только вот целесообразно ли... Я немного покопался с расчетной ведомостью (это вариант того же отчета с другой структурой) и написал свою на основе имеющейся для ЗУП 2.5. Возможно, в каких-то случаях можно обойтись без этого, но тогда скорее всего достаточно будет настройки своего варианта отчета.
   1CIlya
 
32 - 24.09.18 - 14:52
(30) Полный свод, все подразделения, по одной организации за месяц. Типовой вариант отчета.
   1CIlya
 
33 - 24.09.18 - 14:56
Возможно, возникло некоторое недопонимание. Ускорить свод не цель. Цель - ускорить всю ЗУП3. Тормозит не только свод и все остальные отчеты, документы, и пр. Приходится ждать после нажатия на кнопку сформировать, формы открываются так, как будто в процессе открытия решают задачу сходимости в n-мерном пространстве, ну а запуск конфигурации это особенное наслаждение для мазохиста.
 
 
   timurhv
 
34 - 24.09.18 - 15:00
(33)
Я бы проверил итоги (в пользовательском режиме) и индексы БД.
Включил APDEX, смотрел по проблемным участкам планы запроса. Сделал опрос пользователей что особо доставляет неудобств.
Пересмотрел настройки видов расчета, на инфостате была статья по их перенастройке, скорость вроде в несколько раз возросла.
   1CIlya
 
35 - 24.09.18 - 15:04
(34) Спасибо.
   1CIlya
 
36 - 24.09.18 - 15:04
Твердотельники помогают ускорить управляемые формы?
   Access granted
 
37 - 24.09.18 - 15:37
Для начала надо сделать тест Гилева, сообщить оценку.
   Skylark
 
38 - 24.09.18 - 15:45
(34) ... и ускорил формирование отчета на 1 секунду!!!
   Skylark
 
39 - 24.09.18 - 15:45
Ничего этому ЗУПу не поможет.
   Builder
 
40 - 24.09.18 - 16:13
(36) Да, помогает. Особенно если база локально и ты один, ЗУП тогда более менее крутится.
   Amra
 
41 - 24.09.18 - 17:35
(40) Ну это из серии "а кому то жемчуг мелкий". База на 11 тыс сотров - нормально работает, вполне приемлемо
   blutang
 
42 - 24.09.18 - 17:49
(37) В тесте Гилева файловая в 4 раза быстрее SQL... :)
   timurhv
 
43 - 24.09.18 - 17:59
(38) С отчетом-то понятно. На первых версиях ЗУП/ЗиК ГУ (3.1.4 вроде) больничный на 1 человек мог рассчитываться на хорошем железе по 18-30 минут.

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

Вместо:
Сотрудник, ДатаОкончания, Начисление, ФизическоеЛицо, ДокументОснование, ГоловнаяОрганизация, Год.
   timurhv
 
44 - 24.09.18 - 18:02
+(43) Плюс есть тьма запросов, где идет левое соединение к табличным частям документа. Выносишь получение данных ТЧ во временную таблицу и потом делаешь соединение с ней и запрос отрабатывает в 5-10 раз быстрее.
   1CIlya
 
45 - 24.09.18 - 18:11
(44) Поправьте меня, если ошибаюсь. Ускорение за счет применения индекса достигается путем исключения цикла в цикле при умножении таблиц. При этом первый (внешний) цикл будет в любом случае, а внутренний, только по элементам на которые укажет индекс из присоединяемой таблицы.

Почему перенос ТЧ во временную таблицу дает ускорение, ведь умножение левое и первому циклу, циклу по ТЧ документа быть в любом случае, и нет разницы будет индекс у левой ТЧ или нет?
   Провинциальный 1сник
 
46 - 24.09.18 - 18:17
(0) Терпите. В 1с пришли "веб-программисты", а для них задержка меньше полминуты допустима.
   timurhv
 
47 - 24.09.18 - 18:20
(45) Надо голый запрос на MSSQL глянуть, похоже оптимизатор запросов так себя ведет.

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

Сложные запросы, использующие большое количество соединений
Раздел:    Соединения в запросе
Причина: Увеличивается время поиска оптимального плана запроса. Может быть не найден оптимальный план запроса за отведенное время.
Варианты решений: Пересмотреть запрос, постараться уйти
Разделить запрос на части, помещая каждую из них во временную таблицу
Критичность: Важно
   Провинциальный 1сник
 
48 - 24.09.18 - 18:21
Не знаю насчет ЗУПа, но в БП3 при переводе базы в режим клиент-сервер отчеты начинают запускаться через асинхронное фоновое задание с периодическим опросом состояния выполнения. Как следствие, отчеты формируются дольше (плюс время на инициализацию ФЗ, плюс квант первого опроса 2 секунды, плюс нарастание этого кванта, если не выполнился сразу). Вот была бы в 1с подписка на уведомления - было бы намного красивее.
   1CIlya
 
49 - 24.09.18 - 18:22
(5), (14) Начинаешь понимать, что простые советы оказываются самыми мудрыми. Не можешь повлиять на проблему, измени свое отношение к ней.
 
 Рекламное место пустует
   H A D G E H O G s
 
50 - 24.09.18 - 18:23
На моей практике самым первым кандидатом на кривой план запроса шел параллелизм.
Вторым - устаревшая статистика.
Сложных запросов в ней не было. Были неоптимальные запросы, но никак не сложные.
   timurhv
 
51 - 24.09.18 - 18:24
+ (47) Там еще запросы вида:

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

Т.е. сперва идет соединение табличных частей документа без отбора и в конце отбираются данные по текущему документу.
   H A D G E H O G s
 
52 - 24.09.18 - 18:26
(51) sql нормально это прожевывает.
   H A D G E H O G s
 
53 - 24.09.18 - 18:26
Хотя, не уверен, надо проверить.
   1CIlya
 
54 - 24.09.18 - 18:27
(50) Интересно как себя покажет Слон (postgresql). Как известно в многопоток он не умеет. Есть ли среди нас люди, у которых он развернут, сравнить как отработает что-то похожее на (51) .
   Провинциальный 1сник
 
55 - 24.09.18 - 18:29
(51) Оптимизатор sql сам решает, как он будет выполнять запрос. Для этого используется статистика. Можно перехватить профайлером и посмотреть план.
   1CIlya
 
56 - 24.09.18 - 18:31
(51) Это внутреннее соединение здесь есть возможность сократить как первый (внешний) цикл, так и второй. И "правильный" sql будет строить индекс индексов. В этом случае наличие индексов у внешней таблицы, безусловно, важно.
   timurhv
 
57 - 24.09.18 - 18:34
(53) Сейчас занимаюсь переносом 50 организаций. Делал замеры, на подобных вещах жутко тормозило.
Безобразие нашел в 2-3 документах, перетащил во временные таблицы + изменил порядок в регистре сведений.
Было: 680 минут (одна организация)
Стало: 296 минут.

(54), (55), (56) Вы мне сейчас все про теорию, я на практике поправил таким образом. Насчет статистики не знаю как ее обновлять во время переноса данных из предыдущей редакции, постоянно дергать вроде не есть хорошо?
   timurhv
 
58 - 24.09.18 - 18:36
+ (57) Ради интереса сегодня-завтра разверну копию, приведу индексы и тд в порядок и посмотрю профайлером что не так.
   1CIlya
 
59 - 24.09.18 - 18:36
(57) О том и речь. Действительно, закидываете в ВТ, прикручиваете индекс, и внутреннее соединение работает быстрее.
   FireAlex
 
60 - 24.09.18 - 19:00
(0) насчет свода - попробуйте итоговый запрос который исполняется в СКД выполнить в консоли запросов.
На некоторых отчетах (в частности оптимизировал ЗПкультура) время выполнения в консоли быстрее в разы. Тут, я думаю, дело в СКД - не любит оно большие гирлянды.
   mmmarat
 
61 - 24.09.18 - 20:24
(0) проверьте настройки сортировки представления) сотрудников,  можно попробовать выбрать вывод только ФИО.
   Amra
 
62 - 24.09.18 - 20:33
(57) По сколько сотрудников в организации в среднем?
   Fram
 
63 - 24.09.18 - 20:41
(0) на скуле темпы пользователя под которым сервер 1с крутится  попробуй на ССД или РАМ диск кинуть. У нас отчеты БП3 в разы быстрее стали формироваться.
   Fram
 
64 - 24.09.18 - 20:42
(63)+ и темпдб на ССД
   Провинциальный 1сник
 
65 - 24.09.18 - 20:57
(64) И каталог аппдата 1с - туда же. Ибо там кэш метаданных.
   Rovan
 
66 - 24.09.18 - 21:03
(0) "ЗУП3 работает в файловом варианте на терминальном сервере на RAID1. Пользователей: 4"
Памяти на сервере - 8 Гб ?
   tesseract
 
67 - 24.09.18 - 22:23
(54) "Широкоизвестный факт" от службы ОБС?  Нормально слон все умеет.
   timurhv
 
68 - 24.09.18 - 23:10
(62) первые 10 крупных от 500 до 700. Остальные по нисходящей до 190.
Но попросили делать полный перенос со всей кадровой историей, поэтому переносимый объем увеличивается раза 3.
   1CIlya
 
69 - 25.09.18 - 10:03
(63), (64), (65) Спасибо!
   1CIlya
 
70 - 25.09.18 - 10:06
(66) RAM: 32 Gb, доступно 9 Gb. Свободный остаток после того, как все пользователи загрузятся. ЗУП3 на рейде одна, все остальное на скуле.
   1CIlya
 
71 - 25.09.18 - 10:13
(67) Имелось в виду postgresql и многопоточность в рамках одного запроса. Читал статью, где-то в 2015г., там утверждали, что не могЁт.
   Фрэнки
 
72 - 25.09.18 - 10:23
(71) грубо говоря, в рамках одного уже готового запроса и мс-скуль тоже не умеет разделять один процесс на разные потоки.
   tesseract
 
73 - 25.09.18 - 10:23
(71) Тот который от 1С по умолчанию не мог.
У слона все оптимизации по умолчанию в принципе выключены. В 2015 слон не мог нормально CROSS JOIN да
и JOIN временных таблиц  с физическими параллелить не мог. С тех пор  много чего поправили. Сейчас слон работает нормально. Но с физическими таблицами join делать все равно не стоит.
   Фрэнки
 
74 - 25.09.18 - 10:25
(71) и второе, даже если происходит разделение одного процесса на разные потоки, то на уровне самой системы (операционки) это еще не означает, что другой поток того же процесса сумеет уползти на другое ядро, а тем более, на другой процессор.
   tesseract
 
75 - 25.09.18 - 10:25
(72) Даже 1С научился потоки уже разделять. Сколько потоков в итоге будут использовать  компилятор/оптимизатор/ридер - это тебе даже сами авторы СУБД сказать не смогут.
   tesseract
 
76 - 25.09.18 - 10:27
(74) Процессы и потоки как-бы при старте сервера заводятся на разных процессорах. Они не запросом порождаются. Процесс просто разбрасывает по ним задачки.
   Фрэнки
 
77 - 25.09.18 - 10:27
(75) это в каком месте 1С разделяет процессы потоки? механизм этого разделения можете озвучить?
   Cool_Profi
 
78 - 25.09.18 - 10:28
(75) Поставь MaxDOP = 1 и ты точно будешь знать, сколько потоков у тебя будет использовать скуль на один запрос
   Фрэнки
 
79 - 25.09.18 - 10:30
(76) уже теплее :-)
Т.е. в принципе пофиг, как это работает на уровне СУБД, умеет СУБД крутить разные потоки одного процесса на разных ядрах или не умеет. Важно, что в готовом исполняемом из типовой(!) конфигурации ОДНОПОТОЧНОМ коде от 1С множества потоков не сгенирится.
   tesseract
 
80 - 25.09.18 - 10:32
(77) CreateThread() / fork().  8.3.12 таки научился в потоках работать. Смотрел по htop.  

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

ВОТ!!! Еще теплее! Так что самый первый рецепт для ускорения скульной 1С-ки Илья таки не выполнил, скорей всего. Я имею ввиду, что нужно было не только тест Гилева найти, но также инструкцию по настройке 1С кластера
   tesseract
 
82 - 25.09.18 - 10:39
(81) Тест Гилева показывает очень средние попугаи. Узких мест не ловит.
   Фрэнки
 
83 - 25.09.18 - 10:42
(82) Главное, чтоб обязательно не читали никаких инструкций нигде, а только на мисте в прямом общении узнавали сакральные нечто
   1CIlya
 
84 - 25.09.18 - 10:45
(81), (83) Спасибо за критику, буду выполнять этот первый рецепт для ускорения скульной 1С-ки.
   1CIlya
 
85 - 25.09.18 - 10:52
Развернул ЗУП3 на диска в оперативной памяти (RAM), видимо, эту производительность можно считать эталонной. Показатели следующие:

Запуск после ввода пароля: 16 сек.;
Свод, типовой вариант:
   tesseract
 
86 - 25.09.18 - 10:55
(83) Документацию по платформе читать вообще не нужно. Нужно найти обработку, которая сразу все сделает хорошо и никакого профайлера в 1С конечно нет, это грязные слухи.
   1CIlya
 
87 - 25.09.18 - 10:55
(85) +
Свод, типовой вариант: 5 сек., 4 сек., 4 сек.

Немного шустрей интерфейс стал работать, но формы списков как тормозили при открытии, так и тормозят.
   1CIlya
 
88 - 25.09.18 - 11:01
(83), (86) Как вы считаете возможно дотянуться до показателей из (85)+(87) при выполнении оптимизаций сервера 1С и MSSQL?
   tesseract
 
89 - 25.09.18 - 11:04
(88) Да можно. Запусти в отладчике "Измерение производительности" для двух вариантов. Посмотри в каком месте тормозит, тормоза форм списков при открытии - это довольно странно. Платформа какая?
   timurhv
 
90 - 25.09.18 - 11:31
(52), (55), (59)
Сравнил скорость, действительно если статистика и индексы в порядке - разницы никакой, MSSQL отработал корректно.
Получается, проблема актуальна только во время переноса данных из старых редакций.

Ради интереса проверил аналогичные операции на файловой базе, там 70% времени уходит на запрос, который исправлял путем вынесения во временные таблицы.
   ansh15
 
91 - 25.09.18 - 11:32
(71) Статья 2016-го года, утверждается, что может https://habr.com/post/305662/
10-й может еще больше https://habr.com/company/postgrespro/blog/352144/
   tesseract
 
92 - 25.09.18 - 11:34
(91) Кстати сегодня как раз вышла 8.3.13 c официальной поддержкой 10-ки. И наконец без патчей, а на полностью стандартном слоне.
   Amra
 
93 - 25.09.18 - 11:43
(92) Где инфа про "полностью стандартный слон"? Ссылка на десятку или на 1Сный, или на ПостгреПро. С ПостгреПро 10.ч и последние 8.3.12 работают
   tesseract
 
94 - 25.09.18 - 11:54
(93) https://releases.1c.ru/version_files?nick=AddCompPostgre&ver=10.3-2.1C

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

Официально не работают. Я не любитель совсем уж бета-версий.
   1CIlya
 
95 - 25.09.18 - 14:03
Извиняюсь за отсутствие, только вернулся от руководства. Установили новые приоритеты и поставили "сверх" срочные задачи. Со временем сделаю все необходимые тесты и отпишусь.
   H A D G E H O G s
 
96 - 25.09.18 - 14:11
(95) Я еще в (14) все вам рассказал.
   1CIlya
 
97 - 25.09.18 - 14:17
(96) И я "все понял", еще раз спасибо. Тут в (89) обещают производительность сопоставимую с RAM-базой, если все хорошо настроить на скуле. Надо попробовать, а вдруг выгорит.
   ansh15
 
98 - 27.09.18 - 11:00
(92) В исходных текстах(по ссылке в (94)) патчи с доработками 1С как лежали, так и лежат. И при сборке их также надо применять к оригинальной версии.

Как там у автора темы с ускорением работы в ЗУП, что-нибудь получилось?
   1CIlya
 
99 - 27.09.18 - 11:16
(98) Автор пока прокачивает скил, читает о тесте Гилева и роет интернеты в поисках всевозможных оптимизаций скуля, которых у нас еще нет. В свободное от работы время, естественно.

Чуть позже продолжим приключения.
   1CIlya
 
100 - 27.09.18 - 11:21
(99)+ Нас с коллегами опьяняет мысль не заморачиваться со скулем, а тупо купить NVMe SSD, порадоваться за несколько возросшую производительность, а во всем остальном, что не ускорилось обвинять вендора (1С).


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует