Производительность гостевого диска Windows Server 2019 Hyper-V

Производительность гостевого диска Windows Server 2019 Hyper-V

У меня есть сайт, на котором запущено очень чувствительное к вводу-выводу приложение (Accredo Saturn); это пакет бухгалтерского учета/CRM, написанный на Delphi с локальной базой данных в виде плоского файла.

По разным историческим причинам сайт работал на терминальном сервере Windows Server 2008 R2, работающем под управлением Server 2012 R2 Hyper-V на Proliant DL380 G9, а в качестве контроллера домена использовался старый DL380 G7 с SBS 2011 (Exchange уже давно работает на Office 365).

Теперь я обновил их до нового DL380 G10 с Server 2019. Хост и контроллер домена работают на 6x 600 ГБ 10k SAS в RAID10 (хост на своем собственном разделе, один большой раздел для всего остального) на P408i-p, с сервером удаленного рабочего стола на 4x 480 ГБ смешанного использования SATA SSD в RAID10 на P408i-a. На сервере установлено 2x Xeon 4210 и 64 ГБ памяти. Данные для этого программного обеспечения находятся на VHDX на массиве SSD, смонтированном непосредственно на сервере удаленного рабочего стола.

У них 18 пользователей, все из которых используют сервер удаленного рабочего стола для этой программы, а 8 пользователей колл-центра также используют агента телефонной системы Unify. Один или двое используют Edge. Я намеревался немного переборщить с характеристиками, потому что этот клиент привередлив к скорости, и, как я уже говорил, программное обеспечение привередливо!

Клиент жаловался на медленную скорость работы программного обеспечения. Я протестировал и обнаружил, что операция, которая раньше занимала 5 секунд, теперь занимает до 15. Старая виртуальная машина 2008 R2 на том же оборудовании работает так же, как и всегда, так что это похоже на что-то связанное с гостем.

Я запустил diskspd без вошедших пользователей (-c100b -b4K -o32 -F8 -T1b -s8b -W60 -d60 -Sh) и вижу похожие IOPS чтения и пропускную способность на обеих виртуальных машинах, но с некоторыми большими различиями в потоках на новой виртуальной машине 2019 года. Я вижу около 531,41 Мбит/с и 136 тыс. IOPS на гостях, но два потока упали до 1,9 Мбит/с на виртуальной машине 2019 года. Старая виртуальная машина сидит на 520,44 Мбит/с, но стабильно около 72-76 на поток, за исключением одного потока, упавшего до 3,75. Всего было 133 тыс. IOPS. Это на массиве SSD.

Для сравнения, массив SSD на чистом металле с теми же параметрами обеспечивает мне 999 Мбит/с, стабильно 124–125 Мбит/с на поток и в общей сложности 255 тыс. операций ввода-вывода в секунду.

Я несколько дней изучал это. Я пробовал запись в реестре, чтобы отключить балансировщик нагрузки ввода-вывода, но безрезультатно — не уверен, применимо ли это к 2019 году. Я пробовал как фиксированные, так и динамические VHDX — даже менял тома данных между серверами (это его собственный VHDX). Пробовал динамическую и статическую память. Пробовал включать и отключать NUMA.

Я в отчаянии, ведь у меня есть расстроенный клиент, который завтра запускает свой колл-центр на год на старой виртуальной машине!

Модель R2 2008 года — это виртуальная машина поколения 1 и версии 5, а модель 2019 года — это виртуальная машина поколения 2 и версии 9.

Буду признателен за любые подсказки по восстановлению IOPS этих миссий!

Это мой первый пост, поэтому прошу прощения, если я не включил достаточно важной или конкретной информации.

решение1

на 6x 600 ГБ 10k SAS в RAID10

Вместо Raid 1 из двух высокопроизводительных SSD, который дает вам в 50 раз больше операций ввода-вывода?

В общем случае: КУПИТЕ SSD.

Сверху используйте SSD-накопитель статического размера.

Хотя вы и не МОЖЕТЕ сделать большего — ваши цифры кажутся безумными. 200 тыс. операций ввода-вывода в секунду говорят об удивительно паршивом программировании.

решение2

Это не является доказательством того, что проблема с производительностью связана с хранилищем.

Подробно проанализируйте медленный рабочий процесс приложения.

  • Какие пути кода это занимает? Профилируйте, сколько времени занимает каждая функция.

  • Какие запросы к базе данных он выполняет?

  • Сколько записей данных задействовано и какого размера?

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

Вероятно, вам понадобится помощь поставщика программного обеспечения, чтобы заглянуть так глубоко. Настаивайте на подробном профилировании и видимости того типа, который вы получили бы от пакета мониторинга производительности приложений.

Ограничения ресурсов, таких как ЦП, память, IOPS, пропускная способность сети, могут быть причиной медленной работы. И это метрики для измерения. Однако также возможно, что стек этого приложения на этой ОС не будет работать быстрее, даже если вы нагрузите его оборудованием. Единственный способ узнать — изолировать то, что на самом деле работает медленно.

решение3

Я только что заметил это, когда пришел сюда, чтобы исследовать другую проблему. Проблема была решена, и была связана с TSFairShare Disk. Отключение этого решило проблему - оказывается, это проблема многих приложений, использующих базу данных на уровне файлов.

Мы нашли решение, зарытое в форуме Microsoft Dynamics GP. Подробности фактического исправления приведены здесь -https://www.ryslander.com/disable-fair-sharing-in-windows-server/- для таких приложений, как GP и используемое нами приложение (Accredo), необходимо отключить только FSSDisk - все остальные мы оставили как есть.

Я заметил, что в Server 2022 эта функция по умолчанию снова отключена.

Связанный контент