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

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

2 Solutions collect form web for “Плохая производительность сети от виртуальной машины KVM”

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

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

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

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

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

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

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

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

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

Затем вам также придется поиграть с лифтовой elevator=noop ядра: вам нужно будет добавить 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-ядро пытаются оптимизировать ввод-вывод, и он, как правило, хуже, чем что-либо для гостя (гость должен оставить эту задачу на хосте).

  • Используйте сетевой адаптер виртуальных машин в качестве сетевого адаптера по умолчанию
  • Debian 8 устанавливается в гостевой системе QEMU / KVM из-за ошибок ext4-fs / "только для чтения файлов"
  • SELinux вмешивается в совместное использование файлов хоста / гостевого компьютера с использованием KVM
  • Почему qemu-kvm необходим в Debian Wheezy при запуске qemu с опцией «-enable-kvm»?
  • Настройка теста Samba только с одним физическим ящиком
  • Что такое устройство фреймбуфера и требуется ли получить более высокое разрешение?
  • ошибка виртуализации: методы установки "не могут быть указаны для гостей контейнера"
  • Почему в пуле хранения нет потерянного + найденного каталога?
  • KVM - список снимков в порядке их создания
  • Как перенести все страницы памяти процесса с одного узла NUMA на другой узел NUMA?
  • Использование KSM в OpenVZ
  • Linux и Unix - лучшая ОС в мире.