Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / О режимах выполнения отчетов / 15 сообщений из 15, страница 1 из 1
26.05.2010, 19:26
    #36651402
Rus000
Rus000
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
народ,

кто как решает вопрос с падение производительности каше при запуске ресурсоемких отчетов?
при наличии множества коннектов (300-900) запуск отчета убивает сервер напрочь :(

суть понятна - отчет часто делает фуллскан, активные вычисления, подкачку с диска всего икстента, что в свою очередь "вымывает" кэш.

пробуем бороться с этим по нескольким направлениям
1) отложенные отчеты по расписанию (ночью)
вариант имеет минусы что ночью выполняются прочие регламентные работы и запуск отчетов может влиять на их нормальное течение, плюс иной рах отчет может формировать более 8 ночных часов.

2) запуск отчетов в batch-режиме. Была ранее такая опция и описана была в доке. В версии 2009 все упоминания стерты кроме упоминания $ZU(68,25,n) но по ходу это не полноценная замена batch-режима. Может и осталась данная фича в версиях >2009

2) выделение сервера отчетов (shadow). Вариант хорош, но требует доп. сервера и прикладного разграничения ролей на доступ к отчетам - с основного запускать нельзя, на shadow-можно. Минус - переключение с сервер на сервер.


Кто какие варианты еще использует в работе?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.05.2010, 19:57
    #36651432
DAiMor
DAiMor
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
ну у нас есть большие отчеты, но как-то, по времени не сильно большие, до часа точно справляются
и людям работать не мешает
может вам железо на сервере обновить
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.05.2010, 21:19
    #36651562
Блок А.Н.
Блок А.Н.
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
Один отчет убивает сервер, который держит 300-900 активных коннектов?
Не верю! У нас наоборот проблема, не получается загрузить дисковую систему при малом количестве процессов (то есть сервер не загружен и процессы от этого не быстрее не хотят идти.)
Даже на 12ти дисковой системе 5 активных процессов чтения с диска не нагрузят ее даже наполовину, по крайней мере большая часть пользователей не заметит разницы.
Такое ощущение, что вы запустили терабайтную базу на SATA-шном диске.

По нашему опыту, переработка алгоритмов может ускорить работу отчетов в разы.
- проверка SQL планов
- построчный анализ узких мест через %SYS.MONLBL
- подготовка данных во время работы системы, создание промежуточных данных для отчетов с анализом их устаревания (я так понимаю, вы каждую ночь считаете одни и те же данные, большая часть которых не изменяется)
- переписывание на глобалы, если не получается создать оптимальные SQL
- полный отказ от объектов в массовых расчетах
ну и от $ZU(68,25,n) не отказывайтесь

С железом тоже все понятно
- больше размер кэша
- больше дисков в дисковом массиве
- более быстрые диски

Скажите, какой размер базы?
Какая дисковая система, сколько операций ввода-вывода идет в секунду, какая очередь диска?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.05.2010, 08:31
    #36651858
Rus000
Rus000
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
900 коннектов на 1 сервер считаю достаточно сильной нагрузкой, в первую очередь на процессор, что и показывает perfmon. Это может в итоге влиять и на скорость генерации отчета, при этом на дисковую подсистему нагрузка средняя .

понятно, что оптимизация скорости выполнения отчетов это приоритетная задача.

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

система написана с использованием объектного и sql-движка, база пока около 10G. Переход на глобалы вариант конечно хороший, но без недостатков в части кодирования и сопровождения.

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

Вопрос что делаем дальше в части оптимизации работы пользователей в части отчетов и как следствие других пользователей на которых косвенно влияет запуск этих отчетов?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.05.2010, 09:02
    #36651890
Ptn
Ptn
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
Rus000
2) запуск отчетов в batch-режиме. Была ранее такая опция и описана была в доке. В версии 2009 все упоминания стерты кроме упоминания $ZU(68,25,n) но по ходу это не полноценная замена batch-режима. Может и осталась данная фича в версиях >2009

Доку убрали, но оно работает.

Мы используем вместо $ZU(68,25,n) древение вызовы :
Код: plaintext
1.
do LOW^%PRIO

При этом еще и приоритет процесса в OS становиться самым низким, останется ли работать это в последующих версиях вопрос.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.05.2010, 09:08
    #36651900
servit
servit
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
Rus000,

Попробуйте использовать ECP .

Цитата из документации:
Код: plaintext
1.
2.
3.
The primary reasons to use ECP are: 
To provide greater scalability for applications, especially applications that are computationally-bound ( that is, they are limited 
by the number of available CPU cycles and not by I/O operations ).

PS: распараллеливание данных и кода по нескольким серверам должно заметно улучшить производительность системы.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.05.2010, 09:16
    #36651914
Rus000
Rus000
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
servit,

этот вариант мы смотри, но он скорее решает разгрузку процессора, не диска.

для отчетов пробуем отдельно выделенный сервер отчетов (shadow)

это понятные ходы. у меня был вопрос есть ли еще какие решения в практике.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.05.2010, 09:17
    #36651917
Rus000
Rus000
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
servit,

можете что-то сказать про batch-режим? он сейчас поддерживается в 2009 и выше?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.05.2010, 09:18
    #36651921
Rus000
Rus000
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
PtnRus000
2) запуск отчетов в batch-режиме. Была ранее такая опция и описана была в доке. В версии 2009 все упоминания стерты кроме упоминания $ZU(68,25,n) но по ходу это не полноценная замена batch-режима. Может и осталась данная фича в версиях >2009

Доку убрали, но оно работает.

Мы используем вместо $ZU(68,25,n) древение вызовы :
Код: plaintext
1.
do LOW^%PRIO

При этом еще и приоритет процесса в OS становиться самым низким, останется ли работать это в последующих версиях вопрос.

насколько я помню документацию batch-режим это не только низкий приоритет процесса в ОС, но и ограничение по использованию кэша (<25%)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.05.2010, 09:24
    #36651930
krvsa
krvsa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
Rus000Вопрос что делаем дальше в части оптимизации работы
Как вариант паралельно "рабочим" данным формировать данные для аналитики, которые будут формироваться неким фоновым процессом или вообще ночью...

Ведь отчет при работе с оперативними данными как правило все равно что-то считает/анализирует... А из аналитических типа просто должен брать. На дату... Либо в неком диапазоне... Или перечне...
Т.е. анализа меньше, чтения меньше. Отсюда и загрузка меньше.

В этом варианте можно придумать некое более удобное хранение т.с. "показателей", а не оперативных данных...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.05.2010, 09:27
    #36651933
Ptn
Ptn
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
Насколько я понимаю batch режим включаемый $zu(68,25,n) - это как раз ограничение по использованию кэша (<25%) - а вот приоритет процесса оно никак не регулирует.

Посмотрите исходник %PRIO -вот кусок

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
SET(str) ;set priority and batch mode based on what is in the str
 s $zt="SETMODEERR"
 n i,key,prio,batch
 f i= 1 : 1 :$l(str,",") s key=$p(str,",",i) d:key]""
 . i key="NORMAL" s prio=$s(($zversion( 1 )= 2 ): 7 , 1 : 0 )
 . e  i key="LOW" s prio=$s(($zversion( 1 )= 2 ): 2 , 1 :- 2 )
 . e  i key="HIGH" s prio=$s(($zversion( 1 )= 2 ): 13 , 1 : 2 )
 . e  i key="BATCH" s batch= 1 
 . e  i key="NOBATCH" s batch= 0 
 i $d(prio),$zu( 60 , 0 ,$s(($zversion( 1 )= 3 ):-prio-$ZU( 60 , 2 )+$V($ZU( 40 , 1 , 8 ),- 1 ,$ZU( 40 , 0 , 1 )), 1 :prio))
 i $d(batch),$zu( 68 , 25 ,batch)
 q
NORMAL ;
 d SET("NORMAL,NOBATCH")
 q
LOW ;
 ;d SET("LOW,BATCH")
 d SET($s(($zversion( 1 )= 1 ):"", 1 :"LOW,")_"BATCH")
 q
GETBATCH() Quit $S($ZU( 68 , 25 ):"BATCH", 1 :"NOBATCH")

Как видно приоритет $zu(60,0,x) и batch $zu(68,25,n) выставляются отдельно
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.05.2010, 09:49
    #36651974
Блок А.Н.
Блок А.Н.
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
900 коннектов это несомненно серьезная нагрузка (я так понимаю, одновременных),
но 10 ГБ - это же смешно :-)

У нас на 500Гб базе постоянно идет обсуждение производительности, так как в связи с ростом объемов замедляются расчеты отчетов, и некоторые перестали успевать расчитываться за ночь, но пока явно есть резерв оптимизации, причем в разы.

Кстати, у нас все отчеты сначала рассчитываются, а потом только выдаются.
То что отчет требуется 100 раз за день - это не так много. А считать его можно один раз и данные хранить.

10 ГБ базу можно поднять целиком в память и тем самым исключить диск как узкое место системы.
По процессорам - тоже сейчас многопроцессорные системы становятся доступнее.

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

На глобалы переходить полностью не надо, это не панацея. Промониторьте вашу систему с помощью
^PERFMON из области %SYS, чтобы понять, какие именно процессы грузят, затем в помощью %SYS.MONLBL посмотрите, какие именно места в программе. Как правило, 90% времени занимает несколько строк, их и можно переписывать на глобалы.
А объектный движек в массовых отчетах - это ОЧЕНЬ плохо, особенно, если вы открываете и работаете со сложными объектами.

Пользователей, возможно, нужно разруливать, чтобы не запускали все отчеты одновременно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.05.2010, 09:51
    #36651978
Rus000
Rus000
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
Ptn, теперь стало понятнее.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.05.2010, 09:53
    #36651981
servit
servit
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
Setting Job Priority
Rus000servit,
этот вариант мы смотри, но он скорее решает разгрузку процессора, не диска.

Если данные из одной или нескольких таблиц будут "размазаны" по разным дискам, то почему нет?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.05.2010, 12:30
    #36652486
Alexey Maslov
Alexey Maslov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
О режимах выполнения отчетов
Нехитрый анализ текста LOW^%PRIO показывает, что
она даже не пытается понижать приоритет под Виндой ($zversion(1)=2)

аналогично она поступает и с OpenVMS ($zversion(1)=1).
Windows NT своими корнями уходит в VMS, это как-то объясняет 1-ый пункт.

Полностью согласен с советами, что надо поискать узкое место. Почти уверен, что это окажется диск (почему? да просто почти всегда это так...). Бывает, что не все глобалы при формировании отчетов пишутся в CACHETEMP, что-то попадает и в рабочую базу (например, с целью сохранения результатов расчетов). Тогда может быть полезно отключение журналирования в отчетном процессе: DO DISABLE^%NOJRN
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / О режимах выполнения отчетов / 15 сообщений из 15, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]