Недавно мы установили новую машину с 8 двухъядерными процессорами, 20 ГБ ОЗУ и 3 дисками по 1 ТБ, установленными в какой-то RAID, в результате чего мы получили 2 диска по 1 ТБ, которые мы действительно можем использовать (я не аппаратный парень здесь). Он настроен как хост ESXi, и в нем настроено несколько тестовых сред. Текущие тесты выполняются в 64-разрядной версии Windows 2003 с 64-разрядной версией SQL Server 2005 Standard SP3. Судя по всем отчетам, эта система должна содержать среды, которые работают лучше, чем наша предыдущая установка, но при этом некоторые задачи выполняются намного хуже. Я нашел один конкретный сценарий SQL, который надежно работает очень медленно при определенных условиях, которые я не могу понять. Скрипт SQL представляет собой простую серию из 1700+ операторов UPDATE, которые начинаются следующим образом:
UPDATE SrfItem SET fkSrfItem = 5 WHERE id = 4
UPDATE SrfItem SET fkSrfItem = 8 WHERE id = 7
UPDATE SrfItem SET fkSrfItem = 10 WHERE id = 9
Я обнаружил, что если я выполню следующую процедуру в одной из этих виртуальных сред, выполнение сценария займет 9-12 секунд:
Та же процедура на моем рабочем столе выполнила шаг 3 менее чем за 1 секунду.
Но запуск скрипта в транзакции происходит быстро.
Что мне интересно, так это то, что он все еще работает медленно, даже после того, как я выполняю его в транзакции один раз и откатываю обратно
Я проводил тесты в виртуальной системе с 32-разрядной Windows 2003 и 32-разрядной версией SQL 2005 и далее, а также в виртуальной системе с 64-разрядной Windows 2008 и 64-разрядной версией SQL 2008. Я проводил тесты на физической системе с Windows 2003 и SQL 2005 и на физической системе с 64-разрядной Windows 7 и 64-разрядной версией SQL 2008 R2. Все виртуальные системы, которые я пробовал, демонстрируют эту медлительность и размещаются в новой среде ESXi. Не все физические системы демонстрируют эту медлительность.
Может ли кто-нибудь помочь мне понять, что здесь происходит? Я опасаюсь, что аналогичные проблемы с производительностью влияют на другие области, и мы должны перенастроить что-то в среде хоста или гостя. Единственное, о чем мы можем думать до сих пор, - это отключить гиперпоточность в BIOS хост-машины, чтобы она соответствовала конфигурации другой виртуальной среды и ее хоста, где мы не могли видеть медленное поведение (я не наблюдал за тестом на другая виртуальная среда и хост, где он не был медленным). Может ли это создать такую большую разницу в производительности?
Редактировать: После некоторого обзора моего вопроса и первого ответа я согласен с тем, что мне удалось продемонстрировать, вероятно, разницу в производительности задержки ввода-вывода между нашей физической и виртуальной средами. Я также понимаю, что мне следовало предоставить некоторые другие детали: эти образы используют тонкую подготовку и содержат два или три снимка состояния. Может ли это так сильно повлиять на статистику? Возникает вопрос: нормально ли, что эта статистика настолько сильно различается между виртуальными и физическими средами? Должен ли я оптимизировать это в среде или в конфигурации SQL, или это зависит от самого программного обеспечения, которое должно быть написано более оптимально для виртуальных систем с экстремальной задержкой ввода-вывода?
Клиент vSphere сообщает, что задержка записи на виртуальный диск составляет от 11 до 40 мс, в среднем 21 мс. Это полезная статистика? Это крайность?
Редактировать: Похоже, что у нашего оборудования (DL380 G6) есть проблемы с производительностью, как описано на http://laez.nl/vmware-bad-performance-on-hp-proliant-dl380-g6-with-esxi-3-5-u4/ и нам просто нужно сделать некоторую реконфигурацию, чтобы повысить производительность. Я приму ответ, который привел нас в правильном направлении к тому, что проблема заключалась в задержке ввода-вывода на диске.
Подводить итоги:
Мне кажется, что ваша проблема может быть переопределена следующим образом: «на реальном сервере я могу совершить 1700 коммитов менее чем за секунду, но на моем виртуальном сервере производительность упадет в десять раз».
В чем разница между 1700 обновлениями таблиц и 1700 фиксациями? Обновления таблиц полностью кэшируются и совершенно не зависят от дискового ввода-вывода. С коммитами все обстоит иначе. По самой природе транзакционных баз данных ядро базы данных должно быть чертовски уверено, что совершить был фактически сохранено на диск (сохраняется в файл журнала) еще до того, как начнется фиксация следующей транзакции. Таким образом, для каждого из этих 1700 коммитов он должен ждать весь цикл ввода-вывода. Подводя итог, в вашем сценарии задержка ввода-вывода играет очень важную роль и должна быть проанализирована (не путайте задержку со скоростью ввода-вывода или пропускной способностью в байтах; все эти три совершенно разные животные; они всегда настраивал отдельно).
Хороший план - протестировать хранилище с помощью IOMeter. Он зависает при запуске, потому что пытается заполнить весь ваш диск своим тестовым файлом. Просто подождите, пока размер файла не вырастет до значительного размера, и перезапустите IOMeter, он будет правильно работать с «неполным» тестовым файлом.
Ваши разъяснения проливают свет на проблему.
Пакет SATA RAID 5 с 3 дисками не является оптимальной конфигурацией дисков для производительности записи. Каждая операция ввода-вывода записи требует [до] 4 операций ввода-вывода диска (чтение текущего блока, чтение текущей четности, запись нового блока, запись новой четности). Фактически это превращает ваши три диска со скоростью вращения 7200 об / мин в диск, который работает больше как один привод со скоростью вращения 5400 об / мин, если предположить, что ваши базовые диски имеют скорость 7200 об / мин.
Во-вторых, вы говорите, что у вас есть несколько активных снимков на виртуальных машинах SQL. Моментальные снимки VMware ESXi влекут за собой нетривиальные накладные расходы - в зависимости от того, что вы делаете, накладные расходы ввода-вывода будут составлять 50–100% при наличии активных снимков. Это влияет как на чтение, так и на запись.
В-третьих, вы говорите, что используете тонкое обеспечение - это влияет на производительность ввода-вывода, но не так существенно, как два других.
Наконец, вы не говорите, есть ли какие-либо другие виртуальные машины, работающие на хосте ESXi - если они есть, очевидно, что они повлияют на общую производительность, особенно с настройкой диска RAID5 x 1 ТБ SATA.
Я не думаю, что ваше тестирование действительно настолько надежно, чтобы определить наличие проблемы с виртуализированной системой. Односекундный тест не дает достаточно времени, чтобы нагружать систему, чтобы выявить какие-либо реальные узкие места.
В виртуализированном мире и в SQL Server есть много движущихся частей. Я думаю, что здесь играет роль дисковый ввод-вывод, но также и оперативная память. ESX может отдавать и забирать оперативную память у гостя по запросу, и иногда ESX реагирует на несколько секунд, производя короткие паузы. Если сервер находится под определенной постоянной нагрузкой, ESX стабилизирует ОЗУ, но если тест короткий и разрывается, может потребоваться время, чтобы нарастить.
Прежде чем вы начнете выливать ребенка с водой для ванны, запустите более длительные тесты и отслеживайте с помощью ESX и проверьте использование ОЗУ, задержки дискового ввода-вывода, длину очереди ЦП и т. Д. Хороший тест займет от 30 до 60 секунд для запуска на физической машине. и я ожидаю, что виртуальная машина будет в пределах 150% от этого.