kurthatlevik: Dynamics 365 for Finance and Operations

[trud]

Какой-то в целом безграмотный документ.
для SQL рекомендуют 2 GB to 4 GB memory for each core(это было вроде бы где-то в рекомендациях для SQL2000 или типа того, с тех пор довольно часто это тиражируют)
при этом в azure D13 выделяется 8GB на ядро. А для SQL в ажур рекомендуют G серию, где 16GB на ядро.
т.е. человек который это писал даже не удосужился посмотреть что собственно используют сейчас, просто скопипастил
не расписано что такое core - физическое или логическое, что за тип, опять же в Azure есть разные цены для обычных и Promo, для A и D ядер
для SQL хорошая фраза что рекомендуются SSD, а потом приписка что 2000 IOPS. т.е. обычный SSD показывает 50к и больше IOPS, к чему эта фраза про 2к

ну и да, хотелось бы видеть конфиг для 20-50 пользователей

еще конечно все эти документы ничего не стоят, пока не будет тестирования. у меня вот большие сомнения что все новомодные PowerBI отчеты заработают на сколь-нибудь больших объемах

[Vadik]

Цитата:

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

для SQL хорошая фраза что рекомендуются SSD, а потом приписка что 2000 IOPS. т.е. обычный SSD показывает 50к и больше IOPS, к чему эта фраза про 2к

Потому что типичный админ на стороне клиента выделит "аж целый терабайт, чтобы аксапта ну точно поместилась". И это будет thin provisioning, и не SSD А ты потом смотришь на дисковые очереди при 200 IOPS и ругаешься в голос, благо по-русски вокруг не понимают

[trud]

Цитата:

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

Потому что типичный админ на стороне клиента выделит "аж целый терабайт, чтобы аксапта ну точно поместилась". И это будет thin provisioning, и не SSD А ты потом смотришь на дисковые очереди при 200 IOPS и ругаешься в голос, благо по-русски вокруг не понимают

ну от того что выделят 2000IOPS, ситуация то легче не станет. т.е. это 5% от производительности 1 стандартного SSD диска. далее они скажут что у нас все по спецификации, это ваш код плохой, ай ай

[Vadik]

Цитата:

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

ну от того что выделят 2000IOPS, ситуация то легче не станет. т.е. это 5% от производительности 1 стандартного SSD диска

2000 IOPS это некий минимум который позволяет надеяться что выделят SSD либо некий достаточно продвинутый сторедж. Для моих клиентов на AX 2012 2000 IOPS в принципе хватает, если это 5% от теоретической пропускной способности некоего абстрактного диска, да пусть даже 1% - это я переживу. Не будет хватать - попросим (аргументированно) менеджмент добавить, админы сделают

[trud]

Цитата:

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

2000 IOPS это некий минимум который позволяет надеяться что выделят SSD либо некий достаточно продвинутый сторедж.

прикол то в том, что 2000IOPS(т.е. это 4 довольно средних диска) это никакой не продвинутый сторадж. в самых дешевых Azure машинах выделяют по 8к IOPS(16 дисков по 500), и на практике это довольно тормознуто
кстати еще вопрос который остался без ответа - какая нужна полоса в интернет. типа если у нас 10Мбит канал - сколько клиентов смогут одновременно работать.

[Vadik]

Цитата:

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

прикол то в том, что 2000IOPS(т.е. это 4 довольно средних диска)

"диски по 500" - это не физические диски а кусочки нарезанные от большого стореджа у которых IOPS-ы искуственно сверху зажаты (дают ли они 500 в устоявшемся режиме и в каком - вопрос). У обычного физического диска для random read-write 4KB - хорошо если 150. Плюс избыточность. Т.е. "не 4 средних диска" ни разу

Относитесь к цифре 2000 как к рекомендованному минимуму. Мне например регулярно приходится ругаться из-за того что админы выделяют какой-то шлак а официальных рекомендаций от вендора нет. Считаете что этого недостаточно ? Пожалуйста, требуйте хранилку на 100K IOPS - вендор этого не запрещает

[Ivanhoe]

Цитата:

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

кстати еще вопрос который остался без ответа - какая нужна полоса в интернет. типа если у нас 10Мбит канал - сколько клиентов смогут одновременно работать.

50 KBps per user

*Warning: Do not calculate bandwidth requirements from a client location by multiplying the number of users by the
minimum bandwidth requirements. The concurrent usage of a given location is very difficult to calculate. We suggest
using a real-life simulation against a non-production environment of Finance and Operations as the best gauge for
your specific case.