Низкая производительность сети виртуальной машины KVM

Низкая производительность сети виртуальной машины KVM

Я запускаю 32-битную виртуальную машину Linux на KVM. Хост-машина — это 64-битная машина Linux, подключенная к локальной сети. Попытка передать файлы с помощью scp с машины KVM на сервер в локальной сети дает ужасную производительность, около 500 кБ/с по гигабитному Ethernet. Около 1% от ожидаемой скорости. Есть предложения?

решение1

Рассмотрите возможность использованиявиртио. Он обеспечивает прямое соединение между виртуальной машиной и хостом без необходимости эмулировать (медленное) оборудование. Я измерил высокие улучшения производительности сети с его помощью.

Например, вы можете включить сетевое устройство virtio с помощью параметра командной строки kvm «-net nic,model=virtio».

Если вы используете блочные устройства virtio, обратите внимание, что новые имена устройств будут «vda1» и т. д., но это не должно быть проблемой, поскольку текущие дистрибутивы Linux определяют разделы по их UUID.

решение2

Это может быть проблема производительности Disk I/O внутри гостя. Если вы используете образ диска, несколько шагов применимы для улучшения производительности:

Сначала вам придется поиграться с cacheвариантами конфигурации дисков вашего гостя.

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

Кэширование обратной записи сообщит о завершении записи данных, как только данные появятся в кэше страницы хоста. Это безопасно, пока вы доверяете своему хосту. Если ваш хост выйдет из строя или отключится питание, то гость может столкнуться с повреждением данных. При использовании параметра -snapshot кэширование обратной записи используется по умолчанию.

Страницу хоста можно полностью обойти с помощью cache=none. Это попытается выполнить дисковый ввод-вывод непосредственно в гостевую память. QEMU все равно может выполнить внутреннее копирование данных.

Некоторые блочные драйверы плохо работают с cache=writethrough, особенно qcow2. Если производительность важнее правильности, cache=writeback следует использовать с qcow2. По умолчанию, если явное кэширование не указано для образа диска qcow2, будет использоваться cache=writeback. Для всех других типов дисков cache=writethrough является значением по умолчанию.

Затем вам также придется поиграться с опцией ядра elevator: вам придется добавить elevator=noopв командную строку grub linux следующее:

# Edit your /etc/default/grub.conf (on Debian-based distribution)
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=noop"

Более подробное объяснение этого можно найти по адресу:http://lonesysadmin.net/2008/02/21/elevatornoop/; но в нескольких словах, как ядро ​​Linux хоста, так и ядро ​​Linux гостя пытаются оптимизировать ввод-вывод, и это, как правило, хуже всего для гостя (гость должен предоставить эту задачу хосту).

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