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

[gl00mie]

Цитата:

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

Захожу на сайт https://lcs.dynamics.com ,но к сожалению TOOLS c диагностикой, как демонстрируется в презентации нет.

В LCS нужно сначала создать "проект", указать в нем корректную версию системы, и в рамках этого проекта станут доступны дополнительные инструменты, включая диагностику.

[skuull]

Цитата:

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

У нас в проекте внедрения DAX 2012 СХД было перестроено с RAID 5 на RAID 10. Определенный эффект данной перестройке массивов СХД был получен.

Но вот перевод SQL-сервера (MS SQL 2012) с виртуальных машин на физические эффекта никакого не дало.

Но больший эффект по увеличению производительности дало разбиение sql-базы TempDB на части, количество которых равно числу выделенных процессоров для SQL-сервера. Прирост производительности в целом систем AOS+SQL был получен от 15-20%, на некоторых формах и более.

Есть также дополнительный инструмент Microsoft Dynamics Lifecycle Services – анализатор инфраструктуры DAX для решения проблем с производительностью, размещен – https://lcs.dynamics.com.
Видео презентация по его работе – https://www.youtube.com/watch?v=vopziR-rU4g.

Вот еще список чего можно сденлать https://blogs.msdn.microsoft.com/axi...t-for-go-live/

[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