Проблемы с производительностью системы

[MIkeFW]

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

Например, у нас при одновременной активной работе 150-ти
пользователей, система виснет (MS SQL загружается на 100%
и появляются "мертвые" блокировки). И это при трех аосах с 4x700 ксеонами.

Поэтому, хотелось бы усышать мнение, по двум вопросам:

- Какой на ваш взгляд предельный уровень производительности системы (сколько она может тянуть пользователей при данной конфигурации)?

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

[slava]

почему же не поднимался,
еще как поднимался
http://www.axforum.info/forums/showt...=&threadid=467
или
http://www.axforum.info/forums/showt...=&threadid=407

[Falcon]

Dear MikeFW!

Согласен с Вами, производительности действительно уделяется не так много внимания здесь. Быть может потому, что тема эта вечная, и решают ее "по месту", исходя из конкретных условий. К сожалению, до сей поры нет единых рекомендаций, как увеличить производительность той или иной системы (не обязательно NA), если имеется сервер с N процессорами каждый по M мегагерц, с объемом ОЗУ Q мега/гигабайт и т.п. Если бы все было "так просто" - сисадмином мог работать человек с квалификацией "продвинутый пользователь", а теме производительности не посвящалось бы столько статей и публикаций.

Могу заметить, что мой личный опыт показывает: производительность системы можно увеличить в десятки и даже сотни раз, не меняя абсолютно ничего в "аппаратной" части (не увеличивая ОЗУ, мегагегрцы и т.п.) - а лишь изменением "двух-трех" ключевых параметров сервера БД. Важно лишь знать, каких именно, в какую сторону и насколько Имено этому я лично и мои (бывшие) коллеги посвящали не одну бессонную ночь

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

Так что, как говорится, вызывайте специалистов - они разберутся на месте.

Есть, правда, один общий совет - хотя и не берусь обозначать его как панацею. Смените саму СУБД: NA ведь еще и под Oracle работает. Не исключено, что Ваша конфигурация "не по зубам" MS SQL - и никакими параметризациями тут не обойтись. Все-таки 150 юзеров для сервера уровня "рабочих групп" - а именно таковым, строго говоря, является MS SQL - это многовато. Хотя, само по себе количество пользователей не является жестким ограничением - было бы неплохо также расшифровать, что такое "активная работа". Сколько % пользователей работают с одними и теми же таблицами; какого рода запросы задает каждый их (скажем, если 149 человек "активно" вколачивают бухгалтерские проводки, а 150-й строит отчет по заработной плате со 176474 уровнями сортировки и группировки - то, по идее, друг другу они особо не должны мешать).

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

Успехов,

[Warlock]

Я лично вижу два варианта чисто сисадминского варианта увеличения производительности:

1) Сменить на сервере баз данных ОС с Windows на Solars 8. На голый Solaris, без рюшечек и CDE, консольный. Учитывая особенности multithread ядра и одной из лучших SMP моделей, на двухпроцессорной машине процентов на сорок-пятьдесят подъем производительности гарантирован.

2) При большом количестве пользователей работа Oracle превращается в серьезную задачу. Под серьезную задачу принято использовать серьезные машины, использующие RISC-архитектуру. В варианте минимум можно попробовать завести весь rock-n-roll на SunBlade 1000, оснащенном двумя UltraSPARC III. Обойдется такая машинка тысяч в 15-18. Можно схитрить и купить на eBay Sun Enterprise 450. В двухголовом варианте со всем счастьем, включая доставку FedEx и таможню, обойдется эта машина твсяч в 10.

[Falcon]

Угу...
А потом еще Оракл минимум тысяч в 15 выйдет (а на рисковую тачку, боюсь, все 25 - Оракл Корп тоже хитрый, у него цены на риск и нериск платформы разные )

Короче, попал парень

[Warlock]

Все определяется серьезностью задачи. В описанном выше случае (когда на продакшене стоят три 4-х процессорные машины) очень большой прирост производительности можно получить, просто заменив винды на правильно отстроенный Solaris. SMP у виндов, мягко говоря, не блистает. К тому же немало ресурсов поедается невыгружаемым GUI, что для серверной машины суть непозволительная роскошь. Так что, Solaris is the way.

[Falcon]

Zitat:

Solaris is the way

... равно как и HP UX, Alpha Tru64 UNIX, да и старушка UNIXWARE тоже в общем ничего

А еще можно купить опупенный мегапроцессорный ин-тель - сервер и установить на нее фришную Линуксу

[Warlock]

HP-UX-а нет для платформы x86, в отличие от Solaris. Линукс же - студенческая игрушка, и пытаться сделать на нем что-то стабильное, по меньшей мере рисковано. К тому же реализация SMP у него хуже, нежели у изначально мультипроцессорного Solaris, у FreeBSD вообще SMP как таково отсутствует. Так что единственная альтернатива в этом случае - это Solaris.

[Falcon]

Zitat:

Так что единственная альтернатива в этом случае - это Solaris

Ох, чудится мне в этих словах ангажированность - если не явная, то по крайней мере плохозавуалированная.

"Единственных вариантов" - не бывает в природе.

"HP-UX-а нет для платформы x86" - Вы вроде про риски начали говорить, причем тут x86?

"Линукс же - студенческая игрушка, и пытаться сделать на нем что-то стабильное, по меньшей мере рисковано." Не желаю защищать Линукс, просто ради объективности: сегодня правительство ФРГ подписалось на его использование у себя в структурах. Круто для "студенческой игрушки", не правда ли?

"К тому же реализация SMP у него хуже, нежели у изначально мультипроцессорного Solaris, у FreeBSD вообще SMP как таково отсутствует." А как все же насчет UW и T64U - тоже ведь "изначально мультипроцессорные"? Или они просто в Вашу логику не вписываются?

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

[AY]

Уважаемый MIkeFW,
прежде всего, попытайтесь решить проблемы модифицированной функциональности Аксапты.

У нас была подобная головная боль (например, массовое выписывание кредит-нот по заказам вешало Аксапту на 10-15 мин.) с блокированием процессов, запариванием сиквел-сервера и сушением вёсел АОСами.

Всё оказалось просто: после внесения поставщиком внедрения модификаций образовались некорректные запросы к базе, которые производили поиск без использования индексов (режим TableScan). Например, по таблице CUSTINVOICETRANS, после года активного использования логистических модулей

С помощью средств мониторинга SQL-запросов Аксапты были произведены замеры производительности и внесены изменения в структуру индексов системы. Так, например, время исполнения запроса по CUSTINVOICETRANS уменьшилось с 2864 мс до 47 мс.

Если у Вас будут вопросы по оптимизации быстродействия, пишите.

Всего наилучшего,
AY.

[MIkeFW]

Уважаемый AY,

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

С наилучшими пожеланиями,
MikeFW

[macklakov]

Уважаемые дамы и господа, кто нибудь проверял, Index Hint дает ускорение запроса или нет? Дело в том, что он отсутствует даже в методах find очень многих таблиц, не говоря уже о массе других selecto'в :-(
Заранее благодарен

[SimPai]

Абсолютно согласен с AY.

Прежде чем говорить о замене оборудования и ОС необходимо проверить корректность работы программного обеспечения. В данном случае в первую очередь правильность запросов к БД и во вторую - оптимизированность кода. Это сложнее чем поменять сервер, но эффект будет намного больше.

Для любителей менять железо рекомендую проанализировать загрузку элементов системы. Вероятнее всего, что у сервера БД будут перегружены диски, а у AOS - процессор. Соответственно менять надо не всю систему, а только отдельные её части.

Удачи.

[macklakov]

Попробуйте обработать счет в 30 строк, замерьте время, а после этого 3 счета по 10 строк и просуммируйте время на их обработку. Теперь сравните полученные значения. У нас, на двуслойке, время различается на порядок.

Кстати, на groups.yahoo.com в tadorna-axapta есть довольно интересное обсуждение, по быстродействию:
http://groups.yahoo.com/group/tadorn...a/message/1812
Человек говорит:
...I have optimized a invoice run FROM over 100 hours TO about 8-12 hours...

А ему такой ответ от Columbus IT Partner NL:
...My point is that there is a limit where you can solve performance
problems with only software adjustments. Most of the time it is
solving errors (wrong or -no- indexes, etc). Getting out all double
read etc. will help you ONLY SOME PERCENTS...

1000% это some? Похоже я совсем не знаю английского :-(

[AlGol]

Применение index hint в запросах считаю скорее вредным.
Попадались случаи, когда при применении hintа MS SQL генерил неоптимальный план запроса, что лечилось простым удалением index hint из запроса.

[AY]

Для MikeFW:

Уважаемый MikeFW,
Вы можете написать мне (я временно снял запрет на получение писем)

С уважением,
AY.

[Hoper_I]

нужен комплексный подход -
шерстить и оборудование, и приложение.
Правильные индексы это конечно супер, но чудес к сожалению не бывает.
Трактор звать надо...