И снова... о производительности...

[AKIS-Falcon]

Кто о чем - а вшивый все про свою баню...

Здравствуйте все! Рад всех слышать и видеть в добром здравии после долгого (моего) отсутствия.

Итак.
Аксапта - тормозит. Отставить хохот и улюлюкание - я серьезно. Сервера - оба-два, и тот который ДэБэ, и тот что Аппликейшн - просто уууууу какие шустрые. Памяти, процессоров, гигов на хардах - всего навалом. Соединены гигабитом. И все равно - периодически случается, что открытие формы Заказов на Продажу занимает несколько десятков секунд... Что, разумеется, не нравится операторам.
Стоит задача - убЫстрить и ускОрить.
Лезем на сайт www.mazzy.ru в раздел "повышение производительности" - спасибо Сергею за то, что разжевал для нас, грешных чайников. Делаем все как там написано. Выясняем: затык - в дисковых операциях.
Дальше там советуется разделить базу данных, переложить наиболее тяжелые таблицы на отдельные дисковые подсистемы. Этого я делать не-хо-чу. Посему: алкаю других советов, не требующих столь серьезной хирургии.
Дорогие коллеги, предваряя ваши выступления, хочу сказать: да, я знаю, что это надо исследовать, измерять и пр., что так сразу не скажешь, что нужно приглашать специалистов по сиквелу и тому подобное. Это все хорошо но... ну не верю я, что нет простого способа сделать так, чтобы 14 Гигабайтная Аксаптовая база, сидящая на 2-процессорном 3ГГц сервере с 3 Гб оперативки, и управляемая аналогичным сервером приложений - чтобы все это работало чуть пошустрее, чем 1С на 286-х машинах. Должен быть такой способ! Тем более что - вот странно - сервера мы поменяли не так давно, база за это время выросла незначительно - и я бы не сказал, что на старых серваках она работала значительно медленнее. Я бы даже сказал: на старых серваках, которые были раз в 5 медленнее по всяким мегафлопсам - Аскаптовая скорость была та же самая!
Именно поэтому - очень буду благодарен, ежели кто найдет 5 минут свободного времени и поделится накопленной мудростью по данному вопросу.

[Ned]

Тип дискового массива?
Версия MDACа?

[AKIS-Falcon]

> Тип дискового массива?

Пятый RAID, база и транзакшн лог на РАЗНЫХ дисковых массивах.

> Версия MDACа?
2000.85.1022.00
Ну в смысле 2.8

На всякий случай еще - сиквел сервер пропатчен до третьего "а" сервис-пака включительно...

[AKIS-Falcon]

Забыл сказать
ОГРОМНОЕ СПАСИБО!!!!

[raz]

http://www.sql.ru/articles/Publications.shtml#1-5
http://www.microsoft.com/sql/techinf...lity.asp#build

ЗЫ. Украдено тут http://sql.ru/forum/actualthread.asp...e7%e0%f6%e8%ff

[AKIS-Falcon]

Спасибо.
Я про эти ссылки в курсе, и постепенно реализую то, что там советуется.
Но дело все же не в этом. Наверное, я плохо объяснил... Попробую привести аналогию.

Представьте, есть у вас автомобиль. Ездит, худо-бедно. Вы решили на нем поменять движок. Новый двигун по своим характеристикам превосходит старый в несколько раз. Поменяли. Все сделали как положено, все параметры выставили и пр. Сели проверить. Вроде ездит но... прироста мощности вы не ощущаете. То есть ВООБЩЕ не ощущаете! Хотя по идее он должен был бы появиться, даже БЕЗ тонкой настройки движка.
Вот у меня ситуация такая же. Если бы производительность постепенно падала по мере роста базы данных - тут понятно, нужно смотреть все параметры по порядку. Но у меня-то она осталась прежней (практически) при переносе софта на гораздо более мощное железо. Что, в принципе, ситуевина довольно странная. Ведь, в теории, что может быть:
а) При переносе на новое железо были потеряны какие-то тюнинговые параметры сиквел сервера, позволявшие ему неплохо шуршать даже в условиях ограниченных ресурсов. Допускаю такое, но - разница в производительности будет измеряться максимум десятками процентов. У меня же новый сервак В РАЗЫ мощнее старого, т.е. реально разница в производительности тоже В РАЗЫ.
б) Сиквел серверу в принципе по барабану, какие у нового сервака процы, скока памяти и т.п. Что-то более существенное (что????) мешает ему разгоняться

Других причин я не вижу. База - та же самая, примерно того же размера (повторюсь, рост за эти месяцы незначительный, единицы процентов). Аппликейшн тоже не изменилось, запросы генерит те же самые...

Принимая во внимание все вышесказанное, я и пытаюсь найти ту самую "большую кнопку ТУРБО". Почти на 100% уверен, что она есть, и что кто-то до меня уже сталкивался с аналогичной проблемой.

[Wamr]

некоторые варианты, которые встрачались в практике:
- в настройках SQL остались ограничения на размер используемой памяти
- сетевые запросы между серверами бегают через общую сеть, а не напрямую между серваками

[LCh]

По статистике Microsoft, 90% причин торможения баз - всё же индексы.

Кроме них существенно влияет на производительность перечисление конкретных полей для выборки вместо выбора всех записей, и использование NOLOCK. Тем более, что 1Гб между серверами не поможет, если при открытии формы или отчёта выбираются все поля таблиц, и до клиентов требуется тянуть мегабайты.

Возможно, на медленном сервере все запросы выполнялись медленно. Затем, часть *нормальных* запросов на новом сервер стали выполнятся быстро, но заведомо плохие запросы по прежнему ставят сервер в тупик (блокировки тоже следует учесть, sp_who2). Советую всё же рассмотреть такой вариант.

Ещё вариант - на мощный сервер перетянули построение OLAP.

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

Именно на формы влияет кэширование таблиц.

[raz]

Надо майнтейнс план настроить, настроить сбор статистики и оптимизацию.

[xonix]

Так я не понял..
Если элементарно смотреть загрузку сервера БД в момент "подвисания", то у кого будет 100%, у проца или у дисковой подсистемы? Грубо, так сказать..
Мне кааца, что всё упирается в скорость дисковой подсистемы....

Это при условии, что задача звучит так:
Новый сервер быстрее, чем предыдущий. Соответственно, система должна работать быстрее. Однако "быстрее" не происходит.

[Vadik]

Цитата:

Изначально опубликовано AKIS-Falcon
Дорогие коллеги, предваряя ваши выступления, хочу сказать: да, я знаю, что это надо исследовать, измерять и пр., что так сразу не скажешь, что нужно приглашать специалистов по сиквелу и тому подобное.

можно никого не приглашать

но тогда смотреть показатели perfmon-а, собирать статистики, ловить "плохие" запросы, думать - придется самим

"волшебной кнопки" таки нет

хотите, чтобы это сделали другие - публикуйте показатели perfmon-а, результаты sp_configure, свойства БД, свойства и настройки железяк, настройки в конфигурационной утилите

это так, для начала

P.S. случаем не второе пришествие юникода?

[AKIS-Falcon]

Цитата:

Если элементарно смотреть загрузку сервера БД в момент "подвисания", то у кого будет 100%, у проца или у дисковой подсистемы? Грубо, так сказать..

Вы абсолютно правы, судя по тому что показывает перфоманс монитор - затык именно в дисковых операциях. Процессорных ресурсов тратится совсем чуть, памяти примерно 50% от имеющейся max...

[xonix]

2 AKIS-Falcon
Отсюда напрашивается ответ: Сиквелу действительно пофиг, сколько вы будете наращивать память и процы. В терминологии вашего примера: при замене двигателя есть ограничения в системе подачи топлива. Т.о. дажу супер-пупер двигатель не будет давать необходимую мощность (пример абстрактный )

Теперь советы (кудаж без них)....
1. Почему вы считаете разнесение таблиц по "файловым группам" (в оракловой терминологии TABLESPASES ) хирургической операцией?
Хотябы попробовать для начала вынести индексы в отдельную группу на отдельный диск..
2. Мониторить запросы (в течение часа, например) и смотреть, кто больше всего "ест времени". Если найдутся такие суперкритичные запросы - вываливайте их сюда, будем думать вместе.
3. Нарастить скорость дисковой системы опять-таки железом. Т.е. сделать не RAID 5, а не помню какой РАИД, но смысл - STRIPE-SET. И вообще, в зависимости от финансов пытаться максимально ускорить диски. Как "крайний случай" - HP Storage Area Network, цена примерно 250К зелени за 2 Тб на борту, 5 портов.Скорость - улёт )

[xonix]

2 Falcon
Кстати, а ОС где лежит? Где её "подкачка"?
Где лежат временные файлы сиквела (где он сортировку там делает и прочую хрень)?

[savel]

Цитата:

я и пытаюсь найти ту самую "большую кнопку ТУРБО". Почти на 100% уверен, что она есть, и что кто-то до меня уже сталкивался с аналогичной проблемой.

А я для себя нашёл такую кнопку! Не отказываясь от того, что "тонкую" настройку нужно делать.
Раз звучит ,что:

Цитата:

открытие формы Заказов на Продажу занимает несколько десятков секунд...

Смотрим в форму заказов. По каким полям установлены фильтры при открытии заказа. Есть ли соответствующий индекс?
Или у заджойненых таблиц, есть ли соответствующие индексы.
Помогало в 85% случаев.

[Sergik]

Совет AKIS-Falcon: RAID лучше десятого уровня, в сравнении с 5 он гораздо лучше работает на запись. И дисков конечно чем больше - тем лучше для производительности.

[AKIS-Falcon]

Цитата:

Теперь советы (кудаж без них)....
1. Почему вы считаете разнесение таблиц по "файловым группам" (в оракловой терминологии TABLESPASES ) хирургической операцией?
Хотябы попробовать для начала вынести индексы в отдельную группу на отдельный диск..
2. Мониторить запросы (в течение часа, например) и смотреть, кто больше всего "ест времени". Если найдутся такие суперкритичные запросы - вываливайте их сюда, будем думать вместе.
3. Нарастить скорость дисковой системы опять-таки железом. Т.е. сделать не RAID 5, а не помню какой РАИД, но смысл - STRIPE-SET. И вообще, в зависимости от финансов пытаться максимально ускорить диски. Как "крайний случай" - HP Storage Area Network, цена примерно 250К зелени за 2 Тб на борту, 5 портов.Скорость - улёт )

Xonix, спасибо за советы!

Я не хочу заниматься "разнесением таблиц по разным дискам", потому что у меня просто нет "еще одного диска. Т.е., либо все сносить и переконфигурить, либо попытаться выцыганить у начальства деньги на покупку еще дисков. Представляете себе, каково это, когда мы только-только вложили $XXXXX и XXX часов в переоснащение - перед этим начальство было уверяемо ВСЕМИ, в т.ч. Майкрософтом и ИБМ-ом (чьи сервера), что мы ну прям точно почувствуем разницу... А теперь выясняиццца, что надо еще мало-мало денежек... А ежели не помогёт?

Мониторить запросы - мониторю уже, повторю, ничего ЭКСТРАординарного. Да, есть вещи, которые неплохо бы оптимизировать... Некоторые из них совсем простые, вплоть до того что убрать кастомизацию... Но как объяснить, например, что при простом открытии формы Заказы на продажу - залипание чуть не на полминуты. Ну есть у нас порядка 40 тыс заказов в системе - разве это много? И при этом никаких, подчеркиваю, ни-ка-ких серьезных кастомизаций в методах init, executequery, active - ничего, чтобы теоретически могло вызывать такую большую задержку.

- может, логи сервачные подрезать пора
- ничего на серваке больше не крутится

[Vadik]

Цитата:

Изначально опубликовано AKIS-Falcon
Но как объяснить, например, что при простом открытии формы Заказы на продажу - залипание чуть не на полминуты.

ну вот, пошла конкретика

и что - при этом в "журнале трассировки операторов SQL" ничего не появляется?

что за форма? SalesTable? (в русских метках "Заказов на продажу" нет)

если SalesTable - кластерный индекс по SalesId - на SalesTable и SalesLine

только в нерабочее время и с проверкой сначала на тестовой базе

160 тысяч заказов, P4-2800/1GB - "Заказы" открываются не более двух секунд

[Sergik]

В данном случае полностью отсутсвует подход к оптимизации производительности.

Во-первых, необходимо было первоначально найти причины падения производительности
В-вторых, уже следуют решения: или программная оптимизация или аппаратная, или и то и другое.

Взять так просто без расчета характеристик новый сервачок - ну...