Tweaking AX

[Evgeniy2020]

Здравствуйте,

Тема вопроса повышение быстродействия системы.
Есть компания, она растет, количество пользователей растет, база тоже растет.

вопрос какие существуют возможности по аппаратному увеличению производительности системы?

1. Например на сервере MS SQL использовать SSD диски (они вроде быстрее работают чем обычные магнитные), стоит ли использовать RAID на основе SSD?

2. насколько я понимаю 32 битные версии Аксапты могут видеть только до 4 ГБ оперативной памяти. Стоит ли на АОС ставить больше чем 4 Гб?

3. По поводу MS SQL Server то его можно ставить на 64 битную ОС,
и там можно наращивать память. Вопрос если уже стоит машина
с 32 Гб ОЗУ и в системном мониторе 6 процессоров.

стоит ли скажем при размере базы в 55 ГБ переходить на 64 ГБ ОЗУ
даст ли это существенный пирост скорости?

4. По поводу сети, есть ли смысл между АОС и MS SQL Server ставить Gigabit Ethernet? или даже 10 Gbit Ethernet?
стоит ли ключевых пользователей подключать к такому Гигабитному ethernet или это не даст увеличение производительности системы?

я встречал на Аксапте базы и 300 GB хотя трудноывто представить сервер, на котором это должно работать эффективно, особенно отчеты за весь период.

можно ли еще как то увеличивать быстродействие не уменьшая базы данных?
и вообще какие способы наиболее эффективны

[lev]

уже не раз обсуждалось. к примеру вот тут

[mazzy]

Quote:

Originally Posted by Evgeniy2020

Тема вопроса повышение быстродействия системы.
Есть компания, она растет, количество пользователей растет, база тоже растет.

вопрос какие существуют возможности по аппаратному увеличению производительности системы?

Что-то сегодня день тяжелый.
Я конечно понимаю, что "не бывает плохих вопросов, бывают только плохие ответы".

Но что из уже существующего вы видели?
например,
http://axapta.mazzy.ru/lib/querytuning/ (для современных аксапт нужно искать по ключевому слову TraceParser)
http://axapta.mazzy.ru/lib/axapta_itanium/
http://axapta.mazzy.ru/lib/axapta_benchmark/

И про какую версию Аксапты вы спрашиваете?

Quote:

Originally Posted by Evgeniy2020

1. Например на сервере MS SQL использовать SSD диски (они вроде быстрее работают чем обычные магнитные), стоит ли использовать RAID на основе SSD?

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

Quote:

Originally Posted by Evgeniy2020

2. насколько я понимаю 32 битные версии Аксапты могут видеть только до 4 ГБ оперативной памяти. Стоит ли на АОС ставить больше чем 4 Гб?

Для 32битной - не стоит.
Если у вас ax2009, то просто используйте 64битную. для нее вполне стоит.

Quote:

Originally Posted by Evgeniy2020

3. По поводу MS SQL Server то его можно ставить на 64 битную ОС,
и там можно наращивать память. Вопрос если уже стоит машина
с 32 Гб ОЗУ и в системном мониторе 6 процессоров.

стоит ли скажем при размере базы в 55 ГБ переходить на 64 ГБ ОЗУ
даст ли это существенный пирост скорости?

нет. займитесь индексами.

обратите внимание, что никогда не стоит задача "загрузить всю базу в ОЗУ"
всегда стоит задача "загрузить самые часто испольуемые индексы в ОЗУ (в кэш)"

Есть даже показатель (счетчик) "Cache Hit Ratio". Рекомендуется, что он должен быть не менее 95%. По этому поводу нужно читать руководства и ресурсы по самому SQL.

Quote:

Originally Posted by Evgeniy2020

4. По поводу сети, есть ли смысл между АОС и MS SQL Server ставить Gigabit Ethernet? или даже 10 Gbit Ethernet?

Да, если показатель (счетчик) "Network utilization %" превышает некий предельный уровень. Для начала используйте уровень 30%. Реальное значение сильно зависит от топологии вашей сети (например, этот канал используется только для AOS и SQL? или на этом канале находятся и обычные пользвотели?)

Про утилизацию читайте доку по сетям и ресурсы по ним же.

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

Quote:

Originally Posted by Evgeniy2020

стоит ли ключевых пользователей подключать к такому Гигабитному ethernet или это не даст увеличение производительности системы?

Если система написана правильно (в соответствии с рекомендациями Best Practice), то не нужно. Мало того, подключение пользователей к каналу AOS-SQL здорово снизит критический пороговый уровень утилизации сети.

Если же у вас много кастомизаций, причем таблицы дергаются в формах, то гигабитный канал вам не поможет Не поможет и 10гигабитный, и 100гигабитный. Нужно переписывать запросы.

Quote:

Originally Posted by Evgeniy2020

я встречал на Аксапте базы и 300 GB хотя трудноывто представить сервер, на котором это должно работать эффективно, особенно отчеты за весь период.

Сервер представить легко. Он же не берет все данные сразу. Он же с индексами работает.

Кроме того:
1. не нужно делать отчеты "за весь период". См. http://axapta.mazzy.ru/lib/inventsumdate/
то, что делает локализация и буржуйские разработчики в последних версиях системы для получения отчетов "от начала времен" - вредительство. Не делайте так.

2.
когда говорите "база 300Гб", то четко разделяйте размер данных и размер лога.
Я тоже видел базы, у которых Recovery Mode находится в режиме Full и не бэкапируются. Там данные занимали гиг 20, а остальные сотни гигабайт - transaction log.

Надеюсь, что это не ваш случай.
Тогда вам обязательно надо познакомиться с http://axapta.mazzy.ru/lib/dbgrowthsolution/
дело в том, что база данных Аксапты содержит очень много логов, которые нужно чистить.
Очень часто об этом "забывают".

Quote:

Originally Posted by Evgeniy2020

можно ли еще как то увеличивать быстродействие не уменьшая базы данных?
и вообще какие способы наиболее эффективны

Займитесь индексами.

Шаг номер 0: посмотрите в счетчики и узнайте сколько Full Scan'ов у вас выполняется. Добавляя индексы, снизьте это количество по крайней мере в 100 раз (а лучше доведите до 0).

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

[lev]

Quote:

Originally Posted by Evgeniy2020

...
я встречал на Аксапте базы и 300 GB хотя трудноывто представить сервер, на котором это должно работать эффективно, особенно отчеты за весь период....

вспомнилось, на предыдущем месте работы, на момент моего ухода база была почти 1Тб работали на SQL2005, и ничего, все работало
да конечно, по началу было много проблем но:
первое что сильно нам облегчило жизнь это появление ОЧЕНЬ ГРАМОТНОГО админа SQL
потом периодически возникали проблемы с производительностью, но они решались с помощью построения индексов и исправления корявого кода (про что и говорит mazzy).

P.S. Точно не помню, но по моему оперативки на серваке было 64Гб. ОС 32битная.

[egorych]

Ух и многа букав mazzy написал!
Со многим соглашусь, но свои 2 копейки вставлю:
1 коп. - Про сеть. Перевод канала AOS-SQL на 1/10Gbit выйгрыш даст вне зависимости от "Network utilization %" - на то есть чисто физические причины. Рассказывать долго - просто поверь. Но выйгрыш может быть и незаметен, если в коде все перепахано очумелыми ручками.
2 коп. - Про индексы. Рекомендуемое кол-во индексов на таблице <= 5 шт. Иначе - надо править консерваторию.
И вообще - золотое правило 80/20 еще никто не отменял. Т.е. 80% прироста производительности даст рефакторинг кода.

[oip]

По моему опыту, проблемы с быстродействием Аксапты в большинстве случаев абсолютно не связаны с физическими характеристиками серверов, каналов данных и тому подобных вещах. Чаще всего дело в кривом коде, неправильных и/или недостающих индексах, и в общей неухоженности базы.

Пример из жизни: некоторое время назад занимался аудитом и оптимизацией работы одной аксаптовской базы с которой вообще невозможно было работать. Оказалось, что в этой базе таблица INVENTSUMLOGTTS занимает около 30(!) гигабайт (почти 100 миллионов записей!) при 80 Гб оставшеся базы. Надеюсь, никому тут не надо пояснять, что это за таблица и как она используется?

Quote:

2344 мс на EXECUTE (prepare, bind, attributes, etc):

INSERT INTO INVENTSUMLOGTTS (TTSID,ITEMID,INVENTDIMID,COSTAMOUNTPHYSICAL,POSTEDVALUE,QTY,STATUSISSUE,STATUSRECEIPT...
VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)

Как только с этим разобрались, а потом добавили в ключевые места недостающие индексы, Аксапта, конечно, сразу не залетала, но производительность увеличилась существенно.

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

[maximka]

Quote:

Originally Posted by egorych

И вообще - золотое правило 80/20 еще никто не отменял. Т.е. 80% прироста производительности даст рефакторинг кода.

А что делать если запрос
http://itband.ru/2009/07/sql-server-...dex/#more-1872
выдает 100 индексов с "преимуществом индекса" от 90.000.000 до 10.000 ?

[mazzy]

Quote:

Originally Posted by egorych

1 коп. - Про сеть. Перевод канала AOS-SQL на 1/10Gbit выйгрыш даст вне зависимости от "Network utilization %" - на то есть чисто физические причины. Рассказывать долго - просто поверь. Но выйгрыш может быть и незаметен, если в коде все перепахано очумелыми ручками.

Чой-то сегодня все темы связаны с ERP-системы — мэйнстрим или тупиковая ветвь?

как технический специалист - согласен. тоже готов рассказывать долго.

как простой человек, распоряжающийся бюджетами, я категорически против такого совета. Что значит "выйгрыш может быть и незаметен"? Ведь замена 10Мб на 1Гб вряд ли ограничится заменой двух карточек. Придется менять... хмм... (сознательно употребляю пользовательскую терминологию) "марширутизаторы" и хм... прочее сетевое оборудование. Вполне возможно, что у них проблемы с самими кабелями и придется перепрокладывать сеть...

И вот человек подписался под бюджетом на "между АОС и MS SQL Server ставить Gigabit Ethernet". А в результате "выйгрыш может быть и незаметен".

В общем, если уж и заниматься терапией на форуме, то либо давайте очень сильно оговаривать возможные побочные эффекты. Либо давайте рекомендовать только то, что гарантировано не навредит.

[mazzy]

Quote:

Originally Posted by oip

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

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

например, http://axapta.mazzy.ru/lib/axapta_itanium/
в результате они отменили третью смену на предприятии - стали успевать в две смены.

но когда вопрос стоит на уровне "есть ли смысл между АОС и MS SQL Server ставить Gigabit Ethernet? или даже 10 Gbit Ethernet?"
то начинать надо не с железа.

[egorych]

Quote:

Originally Posted by mazzy

..Либо давайте рекомендовать только то, что гарантировано не навредит.

Ну гигабит между серверами не навредит 100% !

[Evgeniy2020]

Кстати просмотрел несколько линков по производительности,
почти во многих из них (в том числе МС ных)
стоит Gigabit ethernet сеть между АОС и MS SQL Server,
хотя даже у Gigabit ethernet реальная скорость около
120 - 200 мегабайт в секунду.

а если несколько пользователей строят серьезные отчеты за весь период,
а часть поьзоватеей работает с другими данными,
то на 50 - 70 пользователей может быть не так уж и много 120 мегабайт в секунду
при реальной скорости в 120 мегабайт в секунду на 70 пользователей,
получается что то около 1,7 мегабайта данных в секунду между АОС и MS SQL Server.

а при простом ethernet 100 мегабит то вообще маловато.
да и время доставки пакета с данными тоже разное естественно.
наверно надо мерить трафик по каналу AOS - MS SQL

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

[mazzy]

Quote:

Originally Posted by egorych

Ну гигабит между серверами не навредит 100% !

согласен.
но я сильно подозреваю, что вы подразумеваете разные вещи под "между серверами". Сильно подозреваю, что в исходном вопросе "между серверами" может подразумевать "к этому каналу подключены и другие пользователи. возможно, с карточками только на 10Мбит".

[mazzy]

Quote:

Originally Posted by Evgeniy2020

стоит Gigabit ethernet сеть между АОС и MS SQL Server,
хотя даже у Gigabit ethernet реальная скорость около
120 - 200 мегабайт в секунду.

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

Evgeniy2020, не видел этого сообщения когда писал свое.
Давайте таки определимся.

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

[egorych]

Quote:

Originally Posted by Evgeniy2020

Кстати просмотрел несколько линков по производительности,
почти во многих из них (в том числе МС ных)
стоит Gigabit ethernet сеть между АОС и MS SQL Server,
хотя даже у Gigabit ethernet реальная скорость около
120 - 200 мегабайт в секунду.

Что-то не нак тут! 200М -> 1.6Gbit многовато, не находите?
Тут вопрос не в скорости (она не намного выше чем при 100Мбит сети), а в пропускной способности канала.
Это как когда ленинградку в шереметьево закрыли наполовину - для 10 маши скорость бы не изменилась, а 100 уже ждут!!!

[Evgeniy2020]

to Mazzy:

Quote:

Evgeniy2020, не видел этого сообщения когда писал свое.
Давайте таки определимся.

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

как я понимаю свой пост , я задал вопрос твикинге то есть об наилучшей эффективной организации сети и оборудования для получения максимально эффективного выигрыша производительности. Таким образом если мы убедимся что лучше использовать отдельный (выделенный) физический скоростной канал AOS - MS SQL, то дальше дадим команду построить/перестроить сеть именно в таком виде.

напирмер из одного указанного линка
http://axapta.mazzy.ru/lib/axapta_be...ark_scheme.jpg



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

to Egorych:
значит все таки 120 мегабайт в секунду в лучшем случае, а если там зарыться в коэффициент данные/служебные данные фреймов (tcp/ip)
то скорость данных наверно еще меньше чем 120.



кстати понравились материалы
Welcome -- Ax Database Configuration Checklist
http://blogs.msdn.com/b/axperf/archi...st-part-1.aspx
http://blogs.msdn.com/b/axperf/archi...st-part-2.aspx

SQL Server 2005, 2008: Создание недостающих индексов
http://itband.ru/2009/07/sql-server-...dex/#more-1872

[mazzy]

Quote:

Originally Posted by Evgeniy2020

Таким образом если мы убедимся что лучше использовать отдельный (выделенный) физический скоростной канал AOS - MS SQL, то дальше дадим команду построить/перестроить сеть именно в таком виде.

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

по (убыванию) приоритетов:
= прежде всего займитесь Table scan'ами
= займитесь индексами
= займитесь запросами, чтобы они не гоняли данные к клиенту (основной трафик должен идти между SQL и AOS, к клиентам должен идти минимально необходимый для работы трафик)
= ...
= много оптимизаций, не затрагивающих железо
= ...
= выделите отдельный канал для AOS-SQL, пользователи должны подключаться к AOS по физически другому каналу
= если возможно, то сделайте этот отдельный канал максимально быстрым