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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 20.05.2016, 10:34   #21  
oip is offline
oip
Axapta
Лучший по профессии 2014
 
2,564 / 1416 (53) ++++++++
Регистрация: 28.11.2005
Записей в блоге: 1
Цитата:
Сообщение от SergeyT Посмотреть сообщение
А вот какое оптимальное число ядер SQL-сервера необходимо для работы DAX 2012? У кого какие мнения?
Майкрософт на эту тему обычно отвечает так:

Цитата:
Database Server Sizing Tips
5K to 15K Lines Per Hour Per Core on Data base Server
....This can vary a lot based on::
........Parameter Settings being used
........Level of Customization
........Usage of additional functionality like databaselog and alerts etc
2 GB to 6 GB Memory for Each Core
Я обычно условно, для первоначальной оценки, ориентируют на одно ядро на каждые 10-15 тысяч строк в час, и 4 Gb памяти на ядро. Можно еще посмотреть для примера Microsoft Dynamics® AX 2012 “Day in the life” benchmark.
https://mbs.microsoft.com/downloads/...k%20Detail.pdf
__________________
С уважением,
Олег.

Последний раз редактировалось oip; 20.05.2016 в 10:58.
За это сообщение автора поблагодарили: Logger (1).
Старый 20.05.2016, 10:53   #22  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от SergeyT Посмотреть сообщение
В данном материале приводится следующая рекомендация: "Max Server memory should be calculated as followsExample:Max Server Memory should be set at 120.3 GB". По-моему, данная оценка размера Server Memory является все же завышенной.
Для большинства внедрений она заниженная
Цитата:
Сообщение от SergeyT Посмотреть сообщение
В свое время на конференции SQL Saturday года два назад по результатам опроса аудитории слушателей одного из докладов была получена следующая статистика: основная часть приложений в компаниях работает на 8-16 ядрах, (примерно 40-50% опрашиваемых), чуть менее - на 32 ядрах (примерно 20-30 % опрашиваемых), некоторые компании работают с приложениями на 64 ядрах. И единицы из числа опрашиваемых работали на 128 ядрах, и также единицы - на 4 ядрах процессоров на SQL-серверах. Приложения разные - от 1С в распределенной архитектуре, до других ERP-систем.
У меня вот SQLlite в приложении для личных финансов на телефоне работает на 2-х ядрах - это можно включить в вашу статистику?..
Цитата:
Сообщение от SergeyT Посмотреть сообщение
А вот какое оптимальное число ядер SQL-сервера необходимо для работы DAX 2012?
Нет оптимального единого для всех количества ядер, равно как и нет оптимального единого для всех размера памяти для СУБД, есть требования и ограничения каждого отдельного внедрения и методологии расчета оборудования под эти требования и ограничения.
Обычно нагрузка на систему измеряется в строках документов в час (количество интерактивных пользователей AX для СУБД не важно), соотв., есть требования бизнеса, бюджетные ограничения и опыт вендора, подкрепленный многочисленными тестами производительности. Исходя из них можно выделить такие требования, ограничения и особенности:
  • инсталляция должна обеспечить обработку такого-то числа строк документов в час, рассчитанного для данного конкретного внедрения, с учетом пиковых нагрузок
  • 1 среднее по больнице ядро СУБД может обработать около 15000 строк документов в час, согласно тестам производительности и основанным на них рекомендациям вендора. В тестах обычно фигурируют некие Xeon 2.4-2.67 ГГц, реже Opteron'ы. Рекомендации про 15000 строк на ядро отражены в Dynamics AX2012 Infrastructure Design Workshop.
  • обработка 1-й строки реального документа в системе (журнал ГК, складской журнал, заказ на продажу, производственный заказ, документ AIF, etc) дает разную нагрузку на СУБД, поэтому при расчете строк документов в час, используемых для оценки нагрузки в целом, строки реальных документов берутся с разными весовыми коэффициентами и затем суммируются
  • в последних тестах производительности вендор также стал прибавлять к числу строк документов в час шапки реальных документов
  • в реальной системе оценочное число ядер СУБД может быстро превысить лимит SQL Server Standard, получится, что нужна Enterprise-редакция, при этом обычно для АХ используют процессорные лицензии на СУБД, а не CAL. Процессорные лицензии на SQL Server Enterprise стоят очень дорого, поэтому тупо брать число строк документов, делить на 15000 и заказывать сервер БД с получившимся числом ядер может быть слишком накладно с т.з лицензий.
  • процессоры очень сильно отличаются по производительности на одно ядро. К примеру, какой-нибудь 4-хъядерный Xeon на 3.7 ГГц может быть более чем вдвое быстрее в расчете на ядро, чем 8-ядерный Xeon на 2.0 ГГц. Т.е. он может обработать такое же число строк документов в час при вдвое меньших затратах на процессорные лицензии SQL Server, так что при прочих равных может быть выгодно взять более шустрые процессоры с меньшим числом ядер.
  • в зависимости от требований по HA&DR может потребоваться иметь кластер из нескольких серверов БД, так что выбор процессоров может влиять на стоимость лицензий СУБД с мультипликатором 2 и более
Это лишь основные соображения по оценке количества ядер процессора SQL-сервера для "оптимальной" работы AX 2012...

Последний раз редактировалось gl00mie; 20.05.2016 в 10:58. Причина: typo
За это сообщение автора поблагодарили: Ivanhoe (5), SergeyT (1).
Старый 20.05.2016, 11:32   #23  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Что касается объема памяти для СУБД, я встречал 2 очень различающихся подхода:
  1. в памяти - только оперативные данные, вся основная нагрузка - на хранилище. Это подход вендора, который утверждает, что надо рассчитывать объем памяти тупо от числа процессорных ядер, а вот хранилище - от числа обрабатываемых строк документов в час. Типа IOPS'ы - это наше всё.
  2. в памяти - вся база целиком или как минимум активная часть, а хранилище должно лишь обеспечивать нужную скорость создания резервных копий. Это подход, учитывающий, что память сейчас относительно дешева, а быстрые (SSD) диски, да еще в RAID - дороги, поэтому постоянно гонять данные из памяти в хранилище и обратно никакого резона нет. При таком подходе объем памяти БД рассчитывается исходя из прогнозируемого объема базы в перспективе на год-два-сколько позволит бюджет.
Старый 20.05.2016, 15:54   #24  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
По выбору процессоров для СУБД - см. также статьи:
Старый 11.08.2020, 13:44   #25  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от gl00mie Посмотреть сообщение
[*]процессоры очень сильно отличаются по производительности на одно ядро. К примеру, какой-нибудь 4-хъядерный Xeon на 3.7 ГГц может быть более чем вдвое быстрее в расчете на ядро, чем 8-ядерный Xeon на 2.0 ГГц. Т.е. он может обработать такое же число строк документов в час при вдвое меньших затратах на процессорные лицензии SQL Server, так что при прочих равных может быть выгодно взять более шустрые процессоры с меньшим числом ядер.
Т.е. с ростом частоты на 50% производительность вырастает сильнее чем на 50% ?

Интересно, Денис, а есть какое-то объяснение за счет чего это получается ?
Первое что приходит в голову, при резких пиковых нагрузках пик приходится всего на несколько ядер в проце, в то время как остальные недозагружены, поэтому и получается что частота решает. И отклик у системы получается лучше на процах с большей частотой.

Т.е. для оценки мощности проца нельзя просто перемножать частоту ядер на их число. И за те же деньги выгоднее купить в 2 раза меньше ядер, но с 2 раза большей частотой (хотя получатся ли они за те же деньги - это вопрос)

Или
2. Производители процов / серверов просто не вытягивают охлаждение и когда в одном корпусе микросхемы при загрузке на 100 % греется вдвое большее число ядер то часть из них начинает троттлить ?

В случае когда идет синтетический тест, а не разовый пик, то все ядра проца загружены равномерно, поэтому скорее всего 2-я причина и играет роль.

Последний раз редактировалось Logger; 11.08.2020 в 13:51.
Теги
aos, r3, оптимизация, расчет мощности оборудования для аксапты, ax2012

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
AX 2009: зачем нужен балансировщик нагрузки, и как в кластере зайти на определенный AOS? gl00mie DAX: Администрирование 7 26.02.2015 16:38
axinthefield: Dynamics AX Event IDs Blog bot DAX Blogs 0 01.03.2011 22:11
emeadaxsupport: How does the Dynamics AX Setup detect existing AOS Instances? Blog bot DAX Blogs 0 06.07.2010 17:05
daxis: Troubleshooting blocked SPIDS in AOS Blog bot DAX Blogs 0 01.04.2009 18:05
Arijit Basu: AX 4 AOS Basics: [Level 100] Blog bot DAX Blogs 0 18.11.2007 14:30
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

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

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