Tweaking AX

[mazzy]

Цитата:

Сообщение от Evgeniy2020

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

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

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

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

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

Цитата:

Сообщение от Evgeniy2020

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

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

Цитата:

Сообщение от Evgeniy2020

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

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

Цитата:

Сообщение от Evgeniy2020

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

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

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

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

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

Цитата:

Сообщение от Evgeniy2020

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

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

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

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

Цитата:

Сообщение от Evgeniy2020

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

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

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

Цитата:

Сообщение от Evgeniy2020

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

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

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

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

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

Цитата:

Сообщение от Evgeniy2020

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

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

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

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

[oip]

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

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

Цитата:

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

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

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

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

[mazzy]

Цитата:

Сообщение от oip

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

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

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

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

[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]

Цитата:

Сообщение от Evgeniy2020

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

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

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

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

[egorych]

Цитата:

Сообщение от Evgeniy2020

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

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

[Evgeniy2020]

to Mazzy:

Цитата:

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]

Цитата:

Сообщение от Evgeniy2020

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

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

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