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

[3oppo]

Аксапта 3.0 sp 5

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

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

[raz]

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

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

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

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

[3oppo]

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

[fed]

Цитата:

Сообщение от 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, скажем.

[3oppo]

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

[Vadik]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

[fed]

Цитата:

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

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

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

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

Цитата:

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

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

[Morpheus]

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

[Vadik]

Цитата:

Сообщение от 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

[Alexius]

Цитата:

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

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

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

[alxm]

Цитата:

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

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

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

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

[Alexius]

Цитата:

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

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

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

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

[alxm]

Цитата:

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

Если нет железного, для MS SQL лучше наделать несколько файлов

Обратите внимание - железный есть ) Но массив не на несколько сотен дисков, а два массива по 12 дисков. (В моем случае).

[Alexius]

Цитата:

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

Обратите внимание - железный есть

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

[Poleax]

Цитата:

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

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

Microsoft Dynamics AX 2009 White Paper: Planning Database Configuration

[Vadik]

Цитата:

Сообщение от 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 лучше наделать несколько файлов (не путать с файловыми группами !) по числу выделенных винтов, он сам неплохо разбирается как это все оптимизировать

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

[somebody]

Цитата:

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

Есть ли смысл скажем в перенесении больших таблиц (таких как InventTrans, LedgerTrans ) в отдельный BD файл, на уровне SQL сервера

делали, помогало.

Цитата:

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

Ну или может кто ещё что посоветует?

Вообще, если вопрос в производительности, может, сначала посмотреть на саму Аксапту и АОСы? А именно:
- формы с большим кол-вом строк - ограничить число строк фильтрами
- формы с дисплейными методами - перевести на временные таблицы
- lookup'ы с перекрытым Lookup - упростить
- раскидать пользователей по АОСам (кластер, но лучше развести работающих с разными данными (кэш АОСа!))

И уже потом по SQL-серверу:
- отследить профайлером самые нагружающие запросы и оптимизировать (в частности, с помощью дополнительных индексов)
- аналогично, отследить с помощью sys.dm_db_missing_index_group_stats, каких индексов не хватает
- с помощью sys.dm_db_index_usage_stats отследить неиспользуемые индексы (т. е. отсутствующие в этом представлении), на поддержание к-рых тратятся ресурсы
(2 предыдущих пункта лучше за большой период времени работы сервера без перезагрузок)
- получить статистику по блокировкам/deadlock'ам, отследить и устранить причины (часто причина в кодах, либо связано со следующим пунктом)
- минимизировать внешнее влияние на работу Аксапты (конкурирующие SQL-задания/SSIS-пакеты, пользователи, подключающиеся к таблицам БД напрямую)
- отдельный standby-сервер для отчётов и пользователей, подключающихся к таблицам БД напрямую
- отдельные дисковые массивы для самых нагруженных таблиц
- убрать возможное влияние резервного копирования, в т. ч. Windows, и антивирусов
- увеличить autogrow, отключить autoshrink, включить автостатистику, регулярно перестраивать важные индексы
- тестировать и применять к инсталляции SQL-сервера совместимые сервис-паки и CU.

И т. д...
А вообще по оптимизации SQL - в конкретном случае надо смотреть очереди к дискам, навешивать другие счётчики, разбираться с ожиданиями. А может, причина проседания производительности - вообще сеть...

[somebody]

Да, ещё насчёт статистик. Можно их обновлять и вручную для отдельных таблиц с большим числом вставок/изменений, можно и отложенные автостатистики делать, можно для всех таблиц регулярно делать ручное обновление статистик (с отключёнными автостатистиками). Здесь нужно разбираться конкретно в каждом случае.

[somebody]

Забыл. Прежде чем разносить отдельные таблицы, всё-таки убедиться, что на уровне SQL-сервера физически разнесены данные, логи и tempdb...

[egorych]

Можно свои 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 + зеркало для системы - все работало быстро, очередей особо не наблюдалось.
Ну где-то так.