Оптимизация SQL сервера под Аксапту. - DAX: Администрирование

3oppo · 14.04.2010, 10:52

Аксапта 3.0 sp 5

Кто занимался этим вопросом, подскажите. Есть ли смысл скажем в перенесении больших таблиц (таких как InventTrans, LedgerTrans ) в отдельный BD файл, на уровне SQL сервера (SQL 2005).
Ну или может кто ещё что посоветует?

PS. Странно, но поиск по сайту ничего толкового не дал..

raz · 14.04.2010, 11:12

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

http://blogs.msdn.com/axperf/archive...st-part-1.aspx

http://blogs.msdn.com/axperf/archive...st-part-2.aspx

Начните с выравнивания кодов влево.

3oppo · 14.04.2010, 16:04

В первой статье идет рекомендация переключить сервер в режим 'max degree of parallelism' = 1,
Я переключил, однако производительность у меня от этого упала.. Правда проверял я довольно упрощёно, запускал паралельно 3 разных отчета.. Может это должно сказать при более серьезной нагрузке сервера (сервак 16 процов, сервер 2003 ent 64, Sp2).
Может я конечно выбрал не удачные примеры.. Кто тестировал эту опцию более серьезно поделитесь плиз инфой..

**fed** · 14.04.2010, 16:28

Цитата:

Сообщение от 3oppo

В первой статье идет рекомендация переключить сервер в режим 'max degree of parallelism' = 1,
Я переключил, однако производительность у меня от этого упала.. Правда проверял я довольно упрощёно, запускал паралельно 3 разных отчета.. Может это должно сказать при более серьезной нагрузке сервера (сервак 16 процов, сервер 2003 ent 64, Sp2).
Может я конечно выбрал не удачные примеры.. Кто тестировал эту опцию более серьезно поделитесь плиз инфой..

В общем - Degree of Parellelism позволяет включить возможность распараллелить исполнения запросов на несколько процессоров (если указано 0 - то на все процессора, если 1 - то ничего не распараллеливается). Реальный выигрыш от распараллеливания случается только на достаточно сложных и больших запросах (особенно если в них много таблиц джойниться). В то же время, если запрос на уровне - join двух таблиц с простым условием и сортировкой - распараллеленная версия запроса работает медленнее чем однопроцессорная. Поскольку в стандартной Аксапте процентов 95 нагрузки это как раз простые запросы, то MAXDOP рекомендуется установить в 1, чтобы SQL не пытался по ошибке распараллеливать то, что распараллеливать не нужно.
То что у вас отчеты стали медленнее работать - как раз нормально, так и должно быть. Просто вопрос в том - что вы хотите ускорить, повседневную работу пользователей или какие-то тяжелые отчеты которые раз в неделю пускаются?

Кстати - по хорошему тяжелые отчеты вообще лучше либо на OLAP-сервере крутить, либо настроить второй SQL-сервер для отчетности и регулярно переносить туда данные через log shipping, скажем.

**Vadik** · 14.04.2010, 16:50

Цитата:

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

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

Не должно быть такого, если нормально 'cost threshold for parallelism' настроен

Цитата:

Поскольку в стандартной Аксапте процентов 95 нагрузки это как раз простые запросы

Какой процент инсталляций аксапты в России можно считать стандартными? Можно ли считать локализованную (EE) аксапту стандартной?

Цитата:

Еще вопрос, кто нить делал Распределение базы по разным дисковым массивам как хотели люди сделать из одноименной статьи? И стоит ли вообще с этим заморачиваться?

"Распределение" все делают - это сродни протиранию стекол и пинанию колес в машине. Полезный выхлоп от этого шаманства стремится к нулю (если только количество физических дисков на СХД не измеряется сотнями)

**fed** · 14.04.2010, 17:02

Цитата:

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

Не должно быть такого, если нормально 'cost threshold for parallelism' настроен

Какой процент инсталляций аксапты в России можно считать стандартными? Можно ли считать локализованную (EE) аксапту стандартной?

Знаешь - если человек знает что такое cost threshold for parallelism - то он вряд ли статью с блога читать будет

И смысл статьи как раз не в том чтобы выдать рекомендации по максимальному тюнингу SQL Server, а в том чтобы выдать некие усредненные рекомендации, при которой Аксапта более или менее прилично (пусть и не супероптимально) работать будет. Как показывает опыт, процентов 60 инстолляций не соответствуют даже этим довольно простым best practice.

Цитата:

"Распределение" все делают - это сродни протиранию стекол и пинанию колес в машине. Полезный выхлоп от этого шаманства стремится к нулю (если только количество физических дисков на СХД не измеряется сотнями)

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

**Vadik** · 14.04.2010, 20:13

Цитата:

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

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

Ну, если уж лезть в интимные технические детали, то чистыми руками (опираясь на информацию от бывших и действующих участников SQL Server team)

SQL Server Urban Legends Discussed - SQL Server Uses One Thread Per Data File
Paul Randal SQL Server DBA myth a day: Tempdb should always have one data file per processor core

alxm · 15.04.2010, 10:38

Цитата:

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

"Распределение" все делают - это сродни протиранию стекол и пинанию колес в машине. Полезный выхлоп от этого шаманства стремится к нулю (если только количество физических дисков на СХД не измеряется сотнями)

Звучит грустно. Может все-таки десятками дисков?
Ведь у многих младших-средних СХД (а что-то мне подсказывает, что инсталляции Аксапты чаще делаются на них) будет ограничение по количеству дисков в одной RAID группе. И из СХД на 50 дисков мы получим все равно несколько RAID по 12-16 дисков в каждом.
Вопрос о распределении встает в полный рост (

Хотя есть еще вариант - средствами windows из двух RAID сделать страйп.
Но насколько это будет надежно/производительно?
Кто-нибудь пробовал?

Alexius · 15.04.2010, 10:52

Цитата:

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

Хотя есть еще вариант - средствами windows из двух RAID сделать страйп.

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

PS. Кесарю - кесарево. Слесарю - слесарево

**Vadik** · 15.04.2010, 23:37

Цитата:

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

Звучит грустно. Может все-таки десятками дисков?
Ведь у многих младших-средних СХД (а что-то мне подсказывает, что инсталляции Аксапты чаще делаются на них) будет ограничение по количеству дисков в одной RAID группе. И из СХД на 50 дисков мы получим все равно несколько RAID по 12-16 дисков в каждом

Давайте, как говорится, отделять мух от котлет...
Что касается внутреннего устройства сиквела - мне кажется, ссылки на разъяснения от достаточно авторитетных (по крайней мере для меня

) товарищей я привел.
Что касается СХД.. Ограничения (скорее рекомендации вендора) на максимальное количество физических дисков в одной raid группе определяются соображениями не производительности, а удобства администрирования и надежности (с увеличением количества дисков в группе повышается вероятность выхода из строя одиночного диска, увеличивается время ее ребилда и т.д.). Так что в случае 50 дисков вопрос "делать или не делать несколько raid групп" просто не стоИт - да, у нас БУДЕТ несколько raid групп. Как мы презентуем их системе и сиквелу (отдельными LUN-ами, объединим в один meta LUN средствами СХД или в один том средствами ОС) - на производительности СХД это скорее всего не скажется никак, не факт что этих 50 дисков хватит чтобы загрузить даже один storage processor

Цитата:

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

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

Вы сильно удивитесь, если узнаете, что midrange SAN - они как бы не совсем "железные" - там внутри стоят как правило процессоры на одно поколение младше или аналогичные тем, что используются в серверах ? А старичок CX300 (по слухам) вообще на специальной версии Windows XP работает

? Так что объединение нескольких LUN-ов с SAN в софтовый raid - вполне себе легальный и жизнеспособный вариант

Цитата:

Если нет железного, для MS SQL лучше наделать несколько файлов (не путать с файловыми группами !) по числу выделенных винтов, он сам неплохо разбирается как это все оптимизировать

Если нет железного, надо его выбивать из начальства, пока не поздно

3oppo · 14.04.2010, 16:35

Да теперь ясно, действительно запускал сложные отчеты..
Еще вопрос, кто нить делал Распределение базы по разным дисковым массивам как хотели люди сделать из одноименной статьи? И стоит ли вообще с этим заморачиваться?

Alexius · 15.04.2010, 09:11

Цитата:

Сообщение от 3oppo

Еще вопрос, кто нить делал Распределение базы по разным дисковым массивам как хотели люди сделать из одноименной статьи? И стоит ли вообще с этим заморачиваться?

Да делал, но это имеет смысл на мой взгляд в двух случаях:
1. Есть 2 и более контроллеров массивов (НЕ каналов одного контроллера).
2. Жесткий дефицит дискового пространства, т.е. имеется один небольшой шустрый массив на который уже или в скором времени база не будет помещаться и большой и медленный.

Morpheus · 14.04.2010, 19:35

Я бы поискал bottleneck перед принятием решения об оптимизации.

**Poleax** · 15.04.2010, 12:05

Цитата:

Сообщение от 3oppo

Оптимизация SQL сервера под Аксапту.

Microsoft Dynamics AX 2009 White Paper: Planning Database Configuration

**Poleax** · 03.08.2010, 14:08

Цитата:

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

Microsoft Dynamics AX 2009 White Paper: Planning Database Configuration

1) Еще немного по оптимизации сервера баз данных SQL Server 2008 и Dynamics Ax 2009
Top Tips for Maximizing the Performance & Scalability of Dynamics AX 2009 systems on SQL Server 2008

2) Dilip's blog on MICROSOFT DYNAMICS AX (Troubleshoot Dynamics AX Performance with SQL Profiler )

egorych · 22.04.2010, 12:43

Можно свои 5 коп. вставить?
с 2004 по 2008 года наша косяпта работала на MSSQL 2000/2005. За этот период было перепробовано много разных вариантов железной конфигурации дисков, в результате было выявлено -
1. разделение лога и базы по разным дискам имеет смысл при условии большой базы - ну в террабайт хотя-бы.
2. тоже самое касается выделения таблиц в файловые группы + к этому зависат сильно от железа - если можете положить ФГ на отдельный ФИЗИЧЕСКИЙ RAID, то можно пробовать, если нет - пустое.
3. очень желательно выделить tempdb в отдельный массив на RAID0 хотя-бы. не обязательно супер быстрые диски.
4. разделять диски на несколько массивов имеет смысл при количестве дисков больше ну штук 30. Т.е. если взять 1 RAID10 в 20 дисков или 2 по 10, то 1 будет лучше! Опять-же зависит еще сильно от контроллера.
В крайней конфигурации у меня был RAID10 из 8 15К дисков на нем лежала база ~200Г и лог ~50Г на 1 диске + еще RAID0 из 2 дисков под tempdb + зеркало для системы - все работало быстро, очередей особо не наблюдалось.
Ну где-то так.

Alexius · 22.04.2010, 13:35

Цитата:

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

3. очень желательно выделить tempdb в отдельный массив на RAID0 хотя-бы. не обязательно супер быстрые диски.

Использовать RAID-0 под tempdb можно если не критично время простоя системы при выходе из строя жесткого диска в нем.

egorych · 22.04.2010, 13:55

Цитата:

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

Использовать RAID-0 под tempdb можно если не критично время простоя системы при выходе из строя жесткого диска в нем.

Пересоздать temp много времени не нужно - ну минут 5 вместе с рестартом. В общем этот вопрос - на усмотрение.
Еще по temp - нужно создать доп. файлы для tempdb - по числу процессоров в сервере - будут меньше очереди на temp.

gl00mie · 22.04.2010, 14:10

Цитата:

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

нужно создать доп. файлы для tempdb - по числу процессоров в сервере - будут меньше очереди на temp.

Этот вопрос обсуждается по ссылкам из 9-го сообщения в этой самой теме.

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
Dynamics AX: Dynamics AX 2009 & SQL Server 2008	Blog bot	DAX Blogs	0	10.06.2008 21:08
Dynamics AX: SQL Server, Heart of Dynamics AX	Blog bot	DAX Blogs	0	13.07.2007 18:00
mazzy: Об альтернативном программировании SQL-сервера в Dynamics AX	Blog bot	DAX Blogs	1	19.01.2007 10:15
aEremenko: Диагностика проблем при установке Microsoft Dynamics Ax 4.0 на Microsoft SQL Server 2005	Blog bot	DAX Blogs	0	28.10.2006 16:01
Введение в Аксапту	Роман Кошелев	DAX: Прочие вопросы	0	18.12.2001 14:00