Tweaking AX

[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 по физически другому каналу
= если возможно, то сделайте этот отдельный канал максимально быстрым