AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 14.04.2010, 10:52   #1  
3oppo is offline
3oppo
Участник
Аватар для 3oppo
 
222 / 32 (2) +++
Регистрация: 30.06.2005
Оптимизация SQL сервера под Аксапту.
Аксапта 3.0 sp 5

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

PS. Странно, но поиск по сайту ничего толкового не дал..
Старый 14.04.2010, 11:12   #2  
raz is offline
raz
NavAx
Аватар для raz
NavAx Club
Лучший по профессии 2014
Лучший по профессии 2009
 
1,494 / 1065 (38) ++++++++
Регистрация: 22.07.2003
Адрес: МО
производительность

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

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

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

Последний раз редактировалось raz; 14.04.2010 в 11:23.
За это сообщение автора поблагодарили: 3oppo (1), hated8 (1).
Старый 14.04.2010, 16:04   #3  
3oppo is offline
3oppo
Участник
Аватар для 3oppo
 
222 / 32 (2) +++
Регистрация: 30.06.2005
В первой статье идет рекомендация переключить сервер в режим 'max degree of parallelism' = 1,
Я переключил, однако производительность у меня от этого упала.. Правда проверял я довольно упрощёно, запускал паралельно 3 разных отчета.. Может это должно сказать при более серьезной нагрузке сервера (сервак 16 процов, сервер 2003 ent 64, Sp2).
Может я конечно выбрал не удачные примеры.. Кто тестировал эту опцию более серьезно поделитесь плиз инфой..

Последний раз редактировалось 3oppo; 14.04.2010 в 16:06.
Старый 14.04.2010, 16:28   #4  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,907 / 5716 (196) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от 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 (1).
Старый 14.04.2010, 16:35   #5  
3oppo is offline
3oppo
Участник
Аватар для 3oppo
 
222 / 32 (2) +++
Регистрация: 30.06.2005
Да теперь ясно, действительно запускал сложные отчеты..
Еще вопрос, кто нить делал Распределение базы по разным дисковым массивам как хотели люди сделать из одноименной статьи? И стоит ли вообще с этим заморачиваться?
Старый 14.04.2010, 16:50   #6  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от fed Посмотреть сообщение
То что у вас отчеты стали медленнее работать - как раз нормально, так и должно быть
Не должно быть такого, если нормально 'cost threshold for parallelism' настроен
Цитата:
Поскольку в стандартной Аксапте процентов 95 нагрузки это как раз простые запросы
Какой процент инсталляций аксапты в России можно считать стандартными? Можно ли считать локализованную (EE) аксапту стандартной?
Цитата:
Еще вопрос, кто нить делал Распределение базы по разным дисковым массивам как хотели люди сделать из одноименной статьи? И стоит ли вообще с этим заморачиваться?
"Распределение" все делают - это сродни протиранию стекол и пинанию колес в машине. Полезный выхлоп от этого шаманства стремится к нулю (если только количество физических дисков на СХД не измеряется сотнями)
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: gl00mie (3).
Старый 14.04.2010, 17:02   #7  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,907 / 5716 (196) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Vadik Посмотреть сообщение
Не должно быть такого, если нормально 'cost threshold for parallelism' настроен

Какой процент инсталляций аксапты в России можно считать стандартными? Можно ли считать локализованную (EE) аксапту стандартной?
Знаешь - если человек знает что такое cost threshold for parallelism - то он вряд ли статью с блога читать будет
И смысл статьи как раз не в том чтобы выдать рекомендации по максимальному тюнингу SQL Server, а в том чтобы выдать некие усредненные рекомендации, при которой Аксапта более или менее прилично (пусть и не супероптимально) работать будет. Как показывает опыт, процентов 60 инстолляций не соответствуют даже этим довольно простым best practice.
Цитата:
"Распределение" все делают - это сродни протиранию стекол и пинанию колес в машине. Полезный выхлоп от этого шаманства стремится к нулю (если только количество физических дисков на СХД не измеряется сотнями)
Ну если уж мы в интимные технические детали полезли, то при принятии решения о распараллеливании запроса SQL Server в том числе смотрит на число файлгрупп/файлов в таблицах, участвующих в запросе. Честно говоря не помню досконально, от чего именно это зависит, но раскидывание таблиц по физическим дискам как раз позволяет несколько ускорить запросы выполняющиеся в параллельном режиме.
Старый 14.04.2010, 19:35   #8  
Morpheus is offline
Morpheus
Участник
Аватар для Morpheus
Соотечественники
 
602 / 167 (7) ++++++
Регистрация: 30.03.2005
Адрес: Київ-København-Düsseldorf
Я бы поискал bottleneck перед принятием решения об оптимизации.
Старый 14.04.2010, 20:13   #9  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от 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
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: Logger (1), alex55 (1).
Старый 15.04.2010, 09:11   #10  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 248 (9) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от 3oppo Посмотреть сообщение
Еще вопрос, кто нить делал Распределение базы по разным дисковым массивам как хотели люди сделать из одноименной статьи? И стоит ли вообще с этим заморачиваться?
Да делал, но это имеет смысл на мой взгляд в двух случаях:
1. Есть 2 и более контроллеров массивов (НЕ каналов одного контроллера).
2. Жесткий дефицит дискового пространства, т.е. имеется один небольшой шустрый массив на который уже или в скором времени база не будет помещаться и большой и медленный.
Старый 15.04.2010, 10:38   #11  
alxm is offline
alxm
Участник
 
25 / 11 (1) +
Регистрация: 10.09.2007
Адрес: Новосибирск
Цитата:
Сообщение от Vadik Посмотреть сообщение
"Распределение" все делают - это сродни протиранию стекол и пинанию колес в машине. Полезный выхлоп от этого шаманства стремится к нулю (если только количество физических дисков на СХД не измеряется сотнями)
Звучит грустно. Может все-таки десятками дисков?
Ведь у многих младших-средних СХД (а что-то мне подсказывает, что инсталляции Аксапты чаще делаются на них) будет ограничение по количеству дисков в одной RAID группе. И из СХД на 50 дисков мы получим все равно несколько RAID по 12-16 дисков в каждом.
Вопрос о распределении встает в полный рост (

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

Последний раз редактировалось alxm; 15.04.2010 в 10:44.
Старый 15.04.2010, 10:52   #12  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 248 (9) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от alxm Посмотреть сообщение
Хотя есть еще вариант - средствами windows из двух RAID сделать страйп.
Софтовый рейд - инструмент для совсем бедных и ожидать от него лучшей производительности, чем от железного не стоит. Если нет железного, для MS SQL лучше наделать несколько файлов (не путать с файловыми группами !) по числу выделенных винтов, он сам неплохо разбирается как это все оптимизировать.

PS. Кесарю - кесарево. Слесарю - слесарево
Старый 15.04.2010, 11:06   #13  
alxm is offline
alxm
Участник
 
25 / 11 (1) +
Регистрация: 10.09.2007
Адрес: Новосибирск
Цитата:
Сообщение от Alexius Посмотреть сообщение
Если нет железного, для MS SQL лучше наделать несколько файлов
Обратите внимание - железный есть ) Но массив не на несколько сотен дисков, а два массива по 12 дисков. (В моем случае).
Старый 15.04.2010, 11:33   #14  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 248 (9) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от alxm Посмотреть сообщение
Обратите внимание - железный есть
Вопрос в чем ? Будет ли прирост производительности если сделать 2 файла ? На мой взгляд, если и будет, то незначительный. Если объединять в софтовый рейд боюсь можно и проиграть
Старый 15.04.2010, 12:05   #15  
Poleax is offline
Poleax
Модератор
Аватар для Poleax
MCP
MCBMSS
Злыдни
 
1,353 / 595 (22) +++++++
Регистрация: 17.02.2005
Адрес: msk
Записей в блоге: 34
Post
Цитата:
Сообщение от 3oppo Посмотреть сообщение
Оптимизация SQL сервера под Аксапту.
Microsoft Dynamics AX 2009 White Paper: Planning Database Configuration
Старый 15.04.2010, 23:37   #16  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от 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 лучше наделать несколько файлов (не путать с файловыми группами !) по числу выделенных винтов, он сам неплохо разбирается как это все оптимизировать
Если нет железного, надо его выбивать из начальства, пока не поздно
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: mazzy (2).
Старый 22.04.2010, 10:42   #17  
somebody is offline
somebody
Участник
 
128 / 30 (2) +++
Регистрация: 30.04.2003
Адрес: Москва
Цитата:
Сообщение от 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 - в конкретном случае надо смотреть очереди к дискам, навешивать другие счётчики, разбираться с ожиданиями. А может, причина проседания производительности - вообще сеть...
За это сообщение автора поблагодарили: mazzy (2), Logger (1).
Старый 22.04.2010, 10:53   #18  
somebody is offline
somebody
Участник
 
128 / 30 (2) +++
Регистрация: 30.04.2003
Адрес: Москва
Да, ещё насчёт статистик. Можно их обновлять и вручную для отдельных таблиц с большим числом вставок/изменений, можно и отложенные автостатистики делать, можно для всех таблиц регулярно делать ручное обновление статистик (с отключёнными автостатистиками). Здесь нужно разбираться конкретно в каждом случае.
Старый 22.04.2010, 10:56   #19  
somebody is offline
somebody
Участник
 
128 / 30 (2) +++
Регистрация: 30.04.2003
Адрес: Москва
Забыл. Прежде чем разносить отдельные таблицы, всё-таки убедиться, что на уровне SQL-сервера физически разнесены данные, логи и tempdb...
Старый 22.04.2010, 12:43   #20  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Можно свои 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 + зеркало для системы - все работало быстро, очередей особо не наблюдалось.
Ну где-то так.
За это сообщение автора поблагодарили: Vadik (1), Logger (1).
Теги
ax3.0, file group, raid, sql server, оптимизация, полезное, производительность

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
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

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 02:14.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.