KVM에서 32비트 Linux 가상 머신을 실행하고 있습니다. 호스트 시스템은 LAN에 연결된 64비트 Linux 시스템입니다. KVM 시스템에서 LAN에 있는 서버로 scp를 사용하여 파일을 전송하려고 시도하면 기가비트 이더넷을 통해 약 500kB/s라는 끔찍한 성능이 제공됩니다. 예상 비율의 약 1%입니다. 어떤 제안이 있으십니까?
답변1
사용을 고려해보세요비르티오. (느린) 하드웨어를 에뮬레이트할 필요 없이 VM과 호스트 간의 직접 연결을 허용합니다. 이를 통해 높은 네트워크 성능 향상을 측정했습니다.
예를 들어 kvm 명령줄 매개변수 "-net nic,model=virtio"를 사용하여 virtio 네트워크 장치를 활성화할 수 있습니다.
virtio 블록 장치를 사용하는 경우 새 장치 이름은 "vda1" 등이 되지만 현재 Linux 배포판은 UUID에 따라 파티션을 감지하므로 이는 문제가 되지 않습니다.
답변2
게스트 내부의 Disk I/O 성능 문제일 수 있습니다. 디스크 이미지를 사용하는 경우 더 나은 성능을 얻으려면 몇 가지 단계가 적용됩니다.
cache먼저, 게스트의 디스크 구성 옵션을 시험해 봐야 합니다 .
기본적으로 Writethrough 캐싱은 모든 블록 장치에 사용됩니다. 즉, 호스트 페이지 캐시는 데이터를 읽고 쓰는 데 사용되지만 스토리지 하위 시스템에서 데이터가 작성된 것으로 보고된 경우에만 쓰기 알림이 게스트에게 전송됩니다.
쓰기 저장 캐싱은 데이터가 호스트 페이지 캐시에 존재하는 즉시 데이터 쓰기가 완료된 것으로 보고합니다. 호스트를 신뢰하는 한 안전합니다. 호스트가 충돌하거나 전원이 꺼지면 게스트에서 데이터 손상이 발생할 수 있습니다. -snapshot 옵션을 사용하면 기본적으로 쓰기 저장 캐싱이 사용됩니다.
캐시=없음을 사용하면 호스트 페이지를 완전히 피할 수 있습니다. 이렇게 하면 게스트 메모리에 직접 디스크 IO를 시도합니다. QEMU는 여전히 데이터의 내부 복사를 수행할 수 있습니다.
일부 블록 드라이버는 캐시=연속 쓰기로 인해 성능이 좋지 않습니다. 특히 qcow2가 그렇습니다. 정확성보다 성능이 더 중요한 경우 qcow2와 함께 캐시=쓰기 저장을 사용해야 합니다. 기본적으로 qcow2 디스크 이미지에 대해 명시적 캐싱이 지정되지 않은 경우 캐시=쓰기 저장이 사용됩니다. 다른 모든 디스크 유형의 경우 캐시=writethrough가 기본값입니다.
그런 다음 커널의 엘리베이터 옵션도 가지고 놀아야 합니다. elevator=noopgrub 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 커널은 모두 I/O를 최적화하려고 시도하며 이는 게스트에게는 그 어떤 것보다 더 나쁜 경향이 있습니다(게스트는 이 작업을 호스트에 맡겨야 합니다).