![]() |
#1 |
Ехидна
|
И снова... о производительности...
Кто о чем - а вшивый все про свою баню...
Здравствуйте все! Рад всех слышать и видеть в добром здравии после долгого (моего) отсутствия. Итак. Аксапта - тормозит. Отставить хохот и улюлюкание - я серьезно. Сервера - оба-два, и тот который ДэБэ, и тот что Аппликейшн - просто уууууу какие шустрые. Памяти, процессоров, гигов на хардах - всего навалом. Соединены гигабитом. И все равно - периодически случается, что открытие формы Заказов на Продажу занимает несколько десятков секунд... Что, разумеется, не нравится операторам. Стоит задача - убЫстрить и ускОрить. Лезем на сайт www.mazzy.ru в раздел "повышение производительности" - спасибо Сергею за то, что разжевал для нас, грешных чайников. Делаем все как там написано. Выясняем: затык - в дисковых операциях. Дальше там советуется разделить базу данных, переложить наиболее тяжелые таблицы на отдельные дисковые подсистемы. Этого я делать не-хо-чу. Посему: алкаю других советов, не требующих столь серьезной хирургии. Дорогие коллеги, предваряя ваши выступления, хочу сказать: да, я знаю, что это надо исследовать, измерять и пр., что так сразу не скажешь, что нужно приглашать специалистов по сиквелу и тому подобное. Это все хорошо но... ну не верю я, что нет простого способа сделать так, чтобы 14 Гигабайтная Аксаптовая база, сидящая на 2-процессорном 3ГГц сервере с 3 Гб оперативки, и управляемая аналогичным сервером приложений - чтобы все это работало чуть пошустрее, чем 1С на 286-х машинах. Должен быть такой способ! Тем более что - вот странно - сервера мы поменяли не так давно, база за это время выросла незначительно - и я бы не сказал, что на старых серваках она работала значительно медленнее. Я бы даже сказал: на старых серваках, которые были раз в 5 медленнее по всяким мегафлопсам - Аскаптовая скорость была та же самая! Именно поэтому - очень буду благодарен, ежели кто найдет 5 минут свободного времени и поделится накопленной мудростью по данному вопросу.
__________________
Strictly IMHO and nothing personal. Сугубо мое персональное мнение, безотносительно к личности оппонента. |
|
![]() |
#2 |
Lean Six Sigma
|
Тип дискового массива?
Версия MDACа? |
|
![]() |
#3 |
Ехидна
|
> Тип дискового массива?
Пятый RAID, база и транзакшн лог на РАЗНЫХ дисковых массивах. > Версия MDACа? 2000.85.1022.00 Ну в смысле 2.8 ![]() На всякий случай еще - сиквел сервер пропатчен до третьего "а" сервис-пака включительно...
__________________
Strictly IMHO and nothing personal. Сугубо мое персональное мнение, безотносительно к личности оппонента. |
|
![]() |
#4 |
Ехидна
|
Забыл сказать
ОГРОМНОЕ СПАСИБО!!!!
__________________
Strictly IMHO and nothing personal. Сугубо мое персональное мнение, безотносительно к личности оппонента. |
|
![]() |
#6 |
Ехидна
|
Спасибо.
Я про эти ссылки в курсе, и постепенно реализую то, что там советуется. Но дело все же не в этом. Наверное, я плохо объяснил... Попробую привести аналогию. Представьте, есть у вас автомобиль. Ездит, худо-бедно. Вы решили на нем поменять движок. Новый двигун по своим характеристикам превосходит старый в несколько раз. Поменяли. Все сделали как положено, все параметры выставили и пр. Сели проверить. Вроде ездит но... прироста мощности вы не ощущаете. То есть ВООБЩЕ не ощущаете! Хотя по идее он должен был бы появиться, даже БЕЗ тонкой настройки движка. Вот у меня ситуация такая же. Если бы производительность постепенно падала по мере роста базы данных - тут понятно, нужно смотреть все параметры по порядку. Но у меня-то она осталась прежней (практически) при переносе софта на гораздо более мощное железо. Что, в принципе, ситуевина довольно странная. Ведь, в теории, что может быть: а) При переносе на новое железо были потеряны какие-то тюнинговые параметры сиквел сервера, позволявшие ему неплохо шуршать даже в условиях ограниченных ресурсов. Допускаю такое, но - разница в производительности будет измеряться максимум десятками процентов. У меня же новый сервак В РАЗЫ мощнее старого, т.е. реально разница в производительности тоже В РАЗЫ. б) Сиквел серверу в принципе по барабану, какие у нового сервака процы, скока памяти и т.п. Что-то более существенное (что????) мешает ему разгоняться Других причин я не вижу. База - та же самая, примерно того же размера (повторюсь, рост за эти месяцы незначительный, единицы процентов). Аппликейшн тоже не изменилось, запросы генерит те же самые... Принимая во внимание все вышесказанное, я и пытаюсь найти ту самую "большую кнопку ТУРБО". Почти на 100% уверен, что она есть, и что кто-то до меня уже сталкивался с аналогичной проблемой.
__________________
Strictly IMHO and nothing personal. Сугубо мое персональное мнение, безотносительно к личности оппонента. |
|
![]() |
#7 |
----------------
|
некоторые варианты, которые встрачались в практике:
- в настройках SQL остались ограничения на размер используемой памяти - сетевые запросы между серверами бегают через общую сеть, а не напрямую между серваками |
|
![]() |
#8 |
Участник
|
По статистике Microsoft, 90% причин торможения баз - всё же индексы.
Кроме них существенно влияет на производительность перечисление конкретных полей для выборки вместо выбора всех записей, и использование NOLOCK. Тем более, что 1Гб между серверами не поможет, если при открытии формы или отчёта выбираются все поля таблиц, и до клиентов требуется тянуть мегабайты. Возможно, на медленном сервере все запросы выполнялись медленно. Затем, часть *нормальных* запросов на новом сервер стали выполнятся быстро, но заведомо плохие запросы по прежнему ставят сервер в тупик (блокировки тоже следует учесть, sp_who2). Советую всё же рассмотреть такой вариант. Ещё вариант - на мощный сервер перетянули построение OLAP. Настройки сервера тоже следует взглянуть. Особенно параметр, определяющий использование параллельного выполнения запросов. Очень маленькое значение убивает сервер. Именно на формы влияет кэширование таблиц. |
|
![]() |
#9 |
NavAx
|
Надо майнтейнс план настроить, настроить сбор статистики и оптимизацию.
|
|
![]() |
#10 |
Участник
|
Так я не понял..
Если элементарно смотреть загрузку сервера БД в момент "подвисания", то у кого будет 100%, у проца или у дисковой подсистемы? Грубо, так сказать.. Мне кааца, что всё упирается в скорость дисковой подсистемы.... Это при условии, что задача звучит так: Новый сервер быстрее, чем предыдущий. Соответственно, система должна работать быстрее. Однако "быстрее" не происходит. |
|
![]() |
#11 |
Модератор
|
Re: И снова... о производительности...
Цитата:
Изначально опубликовано AKIS-Falcon
Дорогие коллеги, предваряя ваши выступления, хочу сказать: да, я знаю, что это надо исследовать, измерять и пр., что так сразу не скажешь, что нужно приглашать специалистов по сиквелу и тому подобное. но тогда смотреть показатели perfmon-а, собирать статистики, ловить "плохие" запросы, думать - придется самим "волшебной кнопки" таки нет ![]() хотите, чтобы это сделали другие - публикуйте показатели perfmon-а, результаты sp_configure, свойства БД, свойства и настройки железяк, настройки в конфигурационной утилите это так, для начала P.S. случаем не второе пришествие юникода? |
|
![]() |
#12 |
Ехидна
|
Цитата:
Если элементарно смотреть загрузку сервера БД в момент "подвисания", то у кого будет 100%, у проца или у дисковой подсистемы? Грубо, так сказать..
__________________
Strictly IMHO and nothing personal. Сугубо мое персональное мнение, безотносительно к личности оппонента. |
|
![]() |
#13 |
Участник
|
2 AKIS-Falcon
Отсюда напрашивается ответ: Сиквелу действительно пофиг, сколько вы будете наращивать память и процы. В терминологии вашего примера: при замене двигателя есть ограничения в системе подачи топлива. Т.о. дажу супер-пупер двигатель не будет давать необходимую мощность (пример абстрактный ![]() Теперь советы (кудаж без них).... 1. Почему вы считаете разнесение таблиц по "файловым группам" (в оракловой терминологии TABLESPASES ) хирургической операцией? Хотябы попробовать для начала вынести индексы в отдельную группу на отдельный диск.. 2. Мониторить запросы (в течение часа, например) и смотреть, кто больше всего "ест времени". Если найдутся такие суперкритичные запросы - вываливайте их сюда, будем думать вместе. 3. Нарастить скорость дисковой системы опять-таки железом. Т.е. сделать не RAID 5, а не помню какой РАИД, но смысл - STRIPE-SET. И вообще, в зависимости от финансов пытаться максимально ускорить диски. Как "крайний случай" - HP Storage Area Network, цена примерно 250К зелени за 2 Тб на борту, 5 портов.Скорость - улёт ![]() |
|
![]() |
#14 |
Участник
|
2 Falcon
Кстати, а ОС где лежит? Где её "подкачка"? Где лежат временные файлы сиквела (где он сортировку там делает и прочую хрень)? |
|
![]() |
#15 |
Участник
|
Цитата:
я и пытаюсь найти ту самую "большую кнопку ТУРБО". Почти на 100% уверен, что она есть, и что кто-то до меня уже сталкивался с аналогичной проблемой.
Раз звучит ,что: Цитата:
открытие формы Заказов на Продажу занимает несколько десятков секунд...
Или у заджойненых таблиц, есть ли соответствующие индексы. Помогало в 85% случаев. |
|
![]() |
#16 |
Участник
|
Совет AKIS-Falcon: RAID лучше десятого уровня, в сравнении с 5 он гораздо лучше работает на запись. И дисков конечно чем больше - тем лучше для производительности.
|
|
![]() |
#17 |
Ехидна
|
Цитата:
Теперь советы (кудаж без них)....
1. Почему вы считаете разнесение таблиц по "файловым группам" (в оракловой терминологии TABLESPASES ) хирургической операцией? Хотябы попробовать для начала вынести индексы в отдельную группу на отдельный диск.. 2. Мониторить запросы (в течение часа, например) и смотреть, кто больше всего "ест времени". Если найдутся такие суперкритичные запросы - вываливайте их сюда, будем думать вместе. 3. Нарастить скорость дисковой системы опять-таки железом. Т.е. сделать не RAID 5, а не помню какой РАИД, но смысл - STRIPE-SET. И вообще, в зависимости от финансов пытаться максимально ускорить диски. Как "крайний случай" - HP Storage Area Network, цена примерно 250К зелени за 2 Тб на борту, 5 портов.Скорость - улёт ) Я не хочу заниматься "разнесением таблиц по разным дискам", потому что у меня просто нет "еще одного диска. Т.е., либо все сносить и переконфигурить, либо попытаться выцыганить у начальства деньги на покупку еще дисков. Представляете себе, каково это, когда мы только-только вложили $XXXXX и XXX часов в переоснащение - перед этим начальство было уверяемо ВСЕМИ, в т.ч. Майкрософтом и ИБМ-ом (чьи сервера), что мы ну прям точно почувствуем разницу... А теперь выясняиццца, что надо еще мало-мало денежек... А ежели не помогёт? Мониторить запросы - мониторю уже, повторю, ничего ЭКСТРАординарного. Да, есть вещи, которые неплохо бы оптимизировать... Некоторые из них совсем простые, вплоть до того что убрать кастомизацию... Но как объяснить, например, что при простом открытии формы Заказы на продажу - залипание чуть не на полминуты. Ну есть у нас порядка 40 тыс заказов в системе - разве это много? И при этом никаких, подчеркиваю, ни-ка-ких серьезных кастомизаций в методах init, executequery, active - ничего, чтобы теоретически могло вызывать такую большую задержку.
__________________
Strictly IMHO and nothing personal. Сугубо мое персональное мнение, безотносительно к личности оппонента. |
|
![]() |
#18 |
Гость
|
- может, логи сервачные подрезать пора
- ничего на серваке больше не крутится |
|
![]() |
#19 |
Модератор
|
Цитата:
Изначально опубликовано AKIS-Falcon
Но как объяснить, например, что при простом открытии формы Заказы на продажу - залипание чуть не на полминуты. ![]() и что - при этом в "журнале трассировки операторов SQL" ничего не появляется? что за форма? SalesTable? (в русских метках "Заказов на продажу" нет) если SalesTable - кластерный индекс по SalesId - на SalesTable и SalesLine только в нерабочее время и с проверкой сначала на тестовой базе 160 тысяч заказов, P4-2800/1GB - "Заказы" открываются не более двух секунд |
|
![]() |
#20 |
Участник
|
В данном случае полностью отсутсвует подход к оптимизации производительности.
Во-первых, необходимо было первоначально найти причины падения производительности В-вторых, уже следуют решения: или программная оптимизация или аппаратная, или и то и другое. Взять так просто без расчета характеристик новый сервачок - ну... |
|
Теги |
оптимизация, производительность |
|
![]() |
||||
Тема | Ответов | |||
Анализ производительности | 4 | |||
aEremenko: Тестирование производительности в DAX 4.0 | 0 | |||
снова COM Connector | 11 | |||
Тест производительности | 0 | |||
Как использовать Анализ производительности | 3 |
Опции темы | Поиск в этой теме |
Опции просмотра | |
|