Назад | Перейти на главную страницу

Является ли тест ввода-вывода для оборудования точной оценкой производительности виртуальной машины Windows в vSphere 5?

Мы поддерживаем корпоративное приложение, работающее на Windows Server 2008 R2. Один из наших клиентов решил установить на VMWare, и я обнаружил, что виртуальные машины относительно медленны по сравнению с оборудованием. Наша группа разработки продуктов сообщила, что многие виртуальные машины работают особенно медленно в тестах ввода-вывода, что влияет на производительность в производственной среде.

Я попробовал тест AttoSoft I / O и обнаружил, что для меньших блоков ввода-вывода (1-32K) виртуальная машина, на которую я смотрю, в 25 раз медленнее, чем оборудование, а для больших блоков ввода-вывода (1-8MB) это в 10 раз. помедленнее.

Это справедливый ориентир? Если нет, какие-нибудь предложения по честному тесту?

Ни тесты, ни большинство приложений, ни даже стек ввода-вывода не принимают во внимание временное дрожание, обычное для виртуальных машин. Это приводит к огромной неэффективности при работе с некоторыми видами нагрузок; особенно те, которые связаны с вводом-выводом.

Проблема в том, что некоторые определенные части стека ввода-вывода (например, ограничение равноправия TCP) должны измерять и сравнивать очень короткие промежутки времени; но на виртуальной машине приложение обычно получает время ЦП и ввода-вывода в ломтики. Это делает такие измерения слишком неточными. Система интерпретирует это как неустойчивый ввод-вывод и самооценку намного ниже, чем необходимо.

Современные стеки ввода-вывода постепенно улучшаются в этом, особенно при более длительных передачах (потому что тогда они могут применять некоторую статистику сглаживания), но это сильно влияет на короткие передачи.

Это могло бы объяснить ужасающие цифры, которые вы получаете (1/10 - 1/25), но очень трудно сказать, будет ли это результатом реального приложения. Если реальная нагрузка действительно аналогична и использует тот же стек, что и тест, тогда да, вы можете получить такую ​​производительность. Но если приложение должно выполнять значительную обработку одновременно с вводом-выводом, то плохая производительность может быть компенсирована гораздо лучшим разделением ЦП на большинство виртуальных машин.

Вы должны ожидать потерю около 5-10% производительности процессора, памяти, сети и дискового ввода-вывода в системе ESXi без участия оператора - это цена, которую мы платим за все замечательные вещи, которые приносит виртуализация. Тем не менее, то, что вы видите, намного ниже этих ожиданий, поэтому что-то не так.

Во-первых, знаете ли вы, используется ли вся инфраструктура совместимого оборудования? У них есть проверка совместимости ВОТ Чтобы вы могли проверить, очень часто мы видим, как люди, работающие со сбоями сервера, используют не одобренный HCL комплект и сталкиваются с проблемами. Во-вторых, действительно ли хранилище подходит для своей цели или они просто используют дешевые потребительские диски SATA? Установили ли они vmtools? делают ли они что-то внутри виртуальной машины, что может замедлить ввод-вывод, например RAIDing внутри виртуальной машины? Хосту приходится бороться за то, чтобы удовлетворить общий спрос на ресурсы? если они используют общее хранилище, это перегружено?

Как видите, есть что проверить, но вы правы в том, что здесь что-то не так, эти цифры сильно отличаются.

Это справедливая оценка текущего состояния вашего клиента виртуальная инфраструктура; особенно ограничения их общего хранилища. Однако эти результаты не обязательно применимы ко всем виртуализированным решениям ...

Вполне возможно создавать конфигурации VMware, производительность ввода-вывода которых равна или выше, чем у «голого железа». Похоже, у вас нет контроля над настройкой клиента. Есть ли у вас какие-либо подробности о том, какой тип хранилища используется? Возможно, спецификации сервера и сетевые детали?