тюнинг под SQL

Коллеги, меня всегда чрезвычайно радует информация "с полей", максимально прикладная.
Сейчас меня порадовал камрад zubastiy который делится своими наработками по тюнингу настроек ВМ\VI под SQL - деградация производительности при виртуализации SQL2000.

Скопипастю:

Оптимизация дисковой системы.

Выравнивание разделов - http://www.vm4.ru/2009/03/vmfs-alignment.html

При установке по умолчанию sql складывает temp.db на диск C:\ бла бла
в том случае если системый раздел лежит на vmdk, а база на RDM - следует перенести temp.db на RDM

Либо, если для базы используете VMDK (небольшая нагрузка на дисковую)- тип диска следует сделать EagerZeroedThick (подробнее зачем это нужно - http://communities.vmware.com//thread/204046?tstart=0)
Если делать диски по умолчанию, в случае роста базы, логов - можно поиметь просадку производительности по дисковой. В принципе решаемо резерваций места силами самого sql


Настройки ESXi

Резервация оперативной памяти (можно не делать, если на хосте нет memory overcommit)
Назначение высокого значения дисковой шары (самый актуальный параметр для производительности 1С + sql2000 в большинстве типовых операций это быстродействие дисковой системы)
Резервация ядер процессоров (в том случае если будет использоваться не все ядра на хосте) - запретить выполнение любых операций кроме самой виртуалки, в том случае если этого не сделать, в этих ядрах могут выполнятся другие виртуалки и работать процессы самого ESXi (обслуживающие процессы) имеет смысл только в том случае если у виртуалки постоянно загружены процы и требуется выжать все что можно )


И помним про накопление статистики sql! Зачастую при миграции sql сервера на виртуальное железо, не смотря на более высокую производительность железок в следствии отсутствия статистики получаем результаты значительно хуже чем на старом железе (даже при виртуализации старого сервера - статистика накоплена для предыдущего железа).

Как я понял, чуть ли не главным было:

выставление шар на диск, резервация памяти (свопфайл для виртуалки все равно создается, но равен 0) принесла свои результаты
по всем тестам 1-2 процента деградации производительности.

Ну и к вопросу механизмов по работе с памятью:

очень порадовал memory sharing при 1535 оперативки выданной sql - memory saving был в районе 800 mb
виртуализации sql силами ESX - быть )

UPD из комментариев.

главное - совокупность изменений )

"выравнивание" партиций дало общий прирост производительности, 2-3 процента дисковой для приложения.

шара, как я понял, дает приоритет дисковому траффику гостевой машины относительно нужд самого гипервизора, что повышает скорость отклика при рандомных операциях чтения/записи - немаловажный фактор при работе SQL
при линейном чтении-записи значение шары в моем случае не играло роли.

ну и по мелочи.
к примеру, при активном использовании SQL сервером временных таблиц узким местом было расположение tempdb - VMDK проигрывает по скорости отклика RDM

резервация ядер проца под виртуалку позволила получить memory sharing (по дефолту включен для всех виртуалок) без пенальти по процессорной мощности, процесс занимающийся обслуживанием memory sharing работал в других, менее загруженных ядрах, на втором проце, что дало еще немного производительности по процессору во время пиковой загрузки vCPU

увеличение глубины очереди в ESXi до 64 дало прирост при построении монструозных отчетов.