14.04.2010, 10:52 | #1 |
Участник
|
Оптимизация SQL сервера под Аксапту.
Аксапта 3.0 sp 5
Кто занимался этим вопросом, подскажите. Есть ли смысл скажем в перенесении больших таблиц (таких как InventTrans, LedgerTrans ) в отдельный BD файл, на уровне SQL сервера (SQL 2005). Ну или может кто ещё что посоветует? PS. Странно, но поиск по сайту ничего толкового не дал..
__________________
PS. Сложно приехать в Москву, но ещё сложнее уехать отсюда. |
|
14.04.2010, 11:12 | #2 |
NavAx
|
производительность
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 |
Участник
|
В первой статье идет рекомендация переключить сервер в режим 'max degree of parallelism' = 1,
Я переключил, однако производительность у меня от этого упала.. Правда проверял я довольно упрощёно, запускал паралельно 3 разных отчета.. Может это должно сказать при более серьезной нагрузке сервера (сервак 16 процов, сервер 2003 ent 64, Sp2). Может я конечно выбрал не удачные примеры.. Кто тестировал эту опцию более серьезно поделитесь плиз инфой..
__________________
PS. Сложно приехать в Москву, но ещё сложнее уехать отсюда. Последний раз редактировалось 3oppo; 14.04.2010 в 16:06. |
|
14.04.2010, 16:28 | #4 |
Moderator
|
Цитата:
Сообщение от 3oppo
В первой статье идет рекомендация переключить сервер в режим 'max degree of parallelism' = 1,
Я переключил, однако производительность у меня от этого упала.. Правда проверял я довольно упрощёно, запускал паралельно 3 разных отчета.. Может это должно сказать при более серьезной нагрузке сервера (сервак 16 процов, сервер 2003 ent 64, Sp2). Может я конечно выбрал не удачные примеры.. Кто тестировал эту опцию более серьезно поделитесь плиз инфой.. То что у вас отчеты стали медленнее работать - как раз нормально, так и должно быть. Просто вопрос в том - что вы хотите ускорить, повседневную работу пользователей или какие-то тяжелые отчеты которые раз в неделю пускаются? Кстати - по хорошему тяжелые отчеты вообще лучше либо на OLAP-сервере крутить, либо настроить второй SQL-сервер для отчетности и регулярно переносить туда данные через log shipping, скажем. |
|
|
За это сообщение автора поблагодарили: 3oppo (1). |
14.04.2010, 16:35 | #5 |
Участник
|
Да теперь ясно, действительно запускал сложные отчеты..
Еще вопрос, кто нить делал Распределение базы по разным дисковым массивам как хотели люди сделать из одноименной статьи? И стоит ли вообще с этим заморачиваться?
__________________
PS. Сложно приехать в Москву, но ещё сложнее уехать отсюда. |
|
14.04.2010, 16:50 | #6 |
Модератор
|
Цитата:
Цитата:
Поскольку в стандартной Аксапте процентов 95 нагрузки это как раз простые запросы
Цитата:
Еще вопрос, кто нить делал Распределение базы по разным дисковым массивам как хотели люди сделать из одноименной статьи? И стоит ли вообще с этим заморачиваться?
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: gl00mie (3). |
14.04.2010, 17:02 | #7 |
Moderator
|
Цитата:
И смысл статьи как раз не в том чтобы выдать рекомендации по максимальному тюнингу SQL Server, а в том чтобы выдать некие усредненные рекомендации, при которой Аксапта более или менее прилично (пусть и не супероптимально) работать будет. Как показывает опыт, процентов 60 инстолляций не соответствуют даже этим довольно простым best practice. Цитата:
"Распределение" все делают - это сродни протиранию стекол и пинанию колес в машине. Полезный выхлоп от этого шаманства стремится к нулю (если только количество физических дисков на СХД не измеряется сотнями)
|
|
14.04.2010, 19:35 | #8 |
Участник
|
Я бы поискал bottleneck перед принятием решения об оптимизации.
|
|
14.04.2010, 20:13 | #9 |
Модератор
|
Цитата:
Сообщение от fed
Ну если уж мы в интимные технические детали полезли, то при принятии решения о распараллеливании запроса SQL Server в том числе смотрит на число файлгрупп/файлов в таблицах, участвующих в запросе. Честно говоря не помню досконально, от чего именно это зависит, но раскидывание таблиц по физическим дискам как раз позволяет несколько ускорить запросы выполняющиеся в параллельном режиме
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 |
Участник
|
Цитата:
Сообщение от 3oppo
Еще вопрос, кто нить делал Распределение базы по разным дисковым массивам как хотели люди сделать из одноименной статьи? И стоит ли вообще с этим заморачиваться?
1. Есть 2 и более контроллеров массивов (НЕ каналов одного контроллера). 2. Жесткий дефицит дискового пространства, т.е. имеется один небольшой шустрый массив на который уже или в скором времени база не будет помещаться и большой и медленный. |
|
15.04.2010, 10:38 | #11 |
Участник
|
Цитата:
Ведь у многих младших-средних СХД (а что-то мне подсказывает, что инсталляции Аксапты чаще делаются на них) будет ограничение по количеству дисков в одной RAID группе. И из СХД на 50 дисков мы получим все равно несколько RAID по 12-16 дисков в каждом. Вопрос о распределении встает в полный рост ( Хотя есть еще вариант - средствами windows из двух RAID сделать страйп. Но насколько это будет надежно/производительно? Кто-нибудь пробовал? Последний раз редактировалось alxm; 15.04.2010 в 10:44. |
|
15.04.2010, 10:52 | #12 |
Участник
|
Софтовый рейд - инструмент для совсем бедных и ожидать от него лучшей производительности, чем от железного не стоит. Если нет железного, для MS SQL лучше наделать несколько файлов (не путать с файловыми группами !) по числу выделенных винтов, он сам неплохо разбирается как это все оптимизировать.
PS. Кесарю - кесарево. Слесарю - слесарево |
|
15.04.2010, 11:06 | #13 |
Участник
|
|
|
15.04.2010, 11:33 | #14 |
Участник
|
|
|
15.04.2010, 23:37 | #16 |
Модератор
|
Цитата:
Сообщение от alxm
Звучит грустно. Может все-таки десятками дисков?
Ведь у многих младших-средних СХД (а что-то мне подсказывает, что инсталляции Аксапты чаще делаются на них) будет ограничение по количеству дисков в одной RAID группе. И из СХД на 50 дисков мы получим все равно несколько RAID по 12-16 дисков в каждом Что касается внутреннего устройства сиквела - мне кажется, ссылки на разъяснения от достаточно авторитетных (по крайней мере для меня ) товарищей я привел. Что касается СХД.. Ограничения (скорее рекомендации вендора) на максимальное количество физических дисков в одной raid группе определяются соображениями не производительности, а удобства администрирования и надежности (с увеличением количества дисков в группе повышается вероятность выхода из строя одиночного диска, увеличивается время ее ребилда и т.д.). Так что в случае 50 дисков вопрос "делать или не делать несколько raid групп" просто не стоИт - да, у нас БУДЕТ несколько raid групп. Как мы презентуем их системе и сиквелу (отдельными LUN-ами, объединим в один meta LUN средствами СХД или в один том средствами ОС) - на производительности СХД это скорее всего не скажется никак, не факт что этих 50 дисков хватит чтобы загрузить даже один storage processor Цитата:
Сообщение от Alexius
Софтовый рейд - инструмент для совсем бедных и ожидать от него лучшей производительности, чем от железного не стоит
Цитата:
Если нет железного, для MS SQL лучше наделать несколько файлов (не путать с файловыми группами !) по числу выделенных винтов, он сам неплохо разбирается как это все оптимизировать
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
22.04.2010, 10:42 | #17 |
Участник
|
Цитата:
Сообщение от 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 |
Участник
|
Да, ещё насчёт статистик. Можно их обновлять и вручную для отдельных таблиц с большим числом вставок/изменений, можно и отложенные автостатистики делать, можно для всех таблиц регулярно делать ручное обновление статистик (с отключёнными автостатистиками). Здесь нужно разбираться конкретно в каждом случае.
|
|
22.04.2010, 10:56 | #19 |
Участник
|
Забыл. Прежде чем разносить отдельные таблицы, всё-таки убедиться, что на уровне SQL-сервера физически разнесены данные, логи и tempdb...
|
|
22.04.2010, 12:43 | #20 |
Участник
|
Можно свои 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, оптимизация, полезное, производительность |
|
|