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

Оптимальная конфигурация ядра и патчи для хоста KVM

У меня есть сервер (однопроцессорный Nehalem с 24 ГБ ОЗУ), действующий в основном как узел KVM, содержащий кучу серверов Windows и несколько (без тиковых) экземпляров Linux.

Я обычно компилирую свои ядра рабочего стола с вытеснением с таймером 1000 Гц без тиков, используя планировщик ЦП BFS (через набор исправлений CK) и планировщик дисков BFQ. На серверах я делаю все ванильное с 100 Гц без тиков, используя CFQ и без принудительного прерывания.

Однако у меня нет времени или навыков для проведения сравнительного анализа, поэтому я ищу информацию об оптимальных настройках для ядра KVM. Выиграет ли пропускная способность виртуальных машин от ядра с частотой 1000 Гц?

И будет ли использование планировщика BFS плохой идеей? Я слышал, что это может принести пользу и однопроцессорным серверам. Я также подумываю использовать планировщик дисков BFQ с опция low_latency отключен.

Может ли кто-нибудь указать мне здесь правильное направление? Я как бы новичок, когда речь идет о низкоуровневых системных вещах. :-)

Начнем с того, что «канонический» справочник по настройке гипервизора KVM по-прежнему остается отличным Лучшие практики для KVM который я предлагаю вам пройти по пунктам.

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

  • Использовать драйверы virtio в гостевых системах Windows. Вы уже должны это делать; в противном случае это даст вам очень заметное ускорение. Гости Linux должны автоматически использовать virtio при установке, хотя, если вы виртуализируете очень старые системы Linux, дважды проверьте их.

  • Дамп BFS. это было разработан для нагрузок на настольные ПК с малой задержкой на оборудовании низкого уровня и его автор признает, что он «не масштабируется до массивного оборудования». Не внушает доверия.

  • Дамп BFQ / CFQ. Практически каждый получает максимальную производительность с крайний срок Планировщик ввода-вывода, и хотя вам следует протестировать его, вы, скорее всего, не станете исключением.

  • Удостовериться слияние одной и той же страницы ядра работает, и настройте его соответствующим образом. Это может значительно снизить требования к памяти для вашего гипервизора, особенно когда несколько гостей работают с одной и той же ОС.

  • При использовании локального хранилища используйте необработанные блочные устройства, такие как логические тома LVM, а не файлы изображений. Это удаляет слой абстракции от дискового ввода-вывода.

В руководстве IBM, о котором я упоминал ранее, есть много других вещей, но они должны дать вам максимальную отдачу от вложенных средств.

По моему опыту, такие дистрибутивы, как RHEL, достаточно хорошо откалиброваны для обеспечения хорошей производительности KVM-машин, и все тесты выполняются на них. Если вы хотите выжать дополнительные проценты производительности, вам нужно смотреть выше в стеке - на virtio-scsi и data-plane (для производительности диска) или 802.1Qbg / h для дополнительной производительности сети.