Даст ли дополнительный AOS прирост производительности?

[oip]

Цитата:

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

[gl00mie]

Цитата:

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

Что касается объема памяти для СУБД, я встречал 2 очень различающихся подхода:

1. в памяти - только оперативные данные, вся основная нагрузка - на хранилище. Это подход вендора, который утверждает, что надо рассчитывать объем памяти тупо от числа процессорных ядер, а вот хранилище - от числа обрабатываемых строк документов в час. Типа IOPS'ы - это наше всё.
2. в памяти - вся база целиком или как минимум активная часть, а хранилище должно лишь обеспечивать нужную скорость создания резервных копий. Это подход, учитывающий, что память сейчас относительно дешева, а быстрые (SSD) диски, да еще в RAID - дороги, поэтому постоянно гонять данные из памяти в хранилище и обратно никакого резона нет. При таком подходе объем памяти БД рассчитывается исходя из прогнозируемого объема базы в перспективе на год-два-сколько позволит бюджет.

[gl00mie]

По выбору процессоров для СУБД - см. также статьи:

• Selecting a Processor for SQL Server 2012
• Selecting a Processor for SQL Server 2014 – Part 1
• Selecting a Processor for SQL Server 2014 – Part 2

[Logger]

Цитата:

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

[*]процессоры очень сильно отличаются по производительности на одно ядро. К примеру, какой-нибудь 4-хъядерный Xeon на 3.7 ГГц может быть более чем вдвое быстрее в расчете на ядро, чем 8-ядерный Xeon на 2.0 ГГц. Т.е. он может обработать такое же число строк документов в час при вдвое меньших затратах на процессорные лицензии SQL Server, так что при прочих равных может быть выгодно взять более шустрые процессоры с меньшим числом ядер.

Т.е. с ростом частоты на 50% производительность вырастает сильнее чем на 50% ?

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

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

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

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