Qemu+libvirt+kvm 在虚拟机中性能明显滞后

Qemu+libvirt+kvm 在虚拟机中性能明显滞后

我正在对我们的新 VM 主机(带有硬件 RAID 的 Dell PowerEdge R415)的性能不佳进行故障排除。

我们有大约 20 个虚拟机像这样运行:

qemu-system-x86_64 \
  -enable-kvm \
  -name rc.stb.mezzanine -S \
  -machine pc-0.12,accel=kvm,usb=off \
  -m 2048 \
  -realtime mlock=off \
  -smp 2,sockets=2,cores=1,threads=1 \
  -uuid 493d519c-8bb5-2cf8-c037-1094a3c48a7a \
  -no-user-config \
  -nodefaults \
  -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rc.stb.monitor,server,nowait \
  -mon chardev=charmonitor,id=monitor,mode=control \
  -rtc base=utc \
  -no-shutdown \
  -boot strict=on \ 
  -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
  -drive file=/dev/vg-raid/lv-rc,if=none,id=drive-virtio-disk0,format=raw \
  -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \
  -drive file=/var/lib/libvirt/images/ubuntu-14.04-server-amd64.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw \
  -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 \
  -netdev tap,fd=32,id=hostnet0 \
  -device e1000,netdev=hostnet0,id=net0,mac=52:54:df:26:15:e9,bus=pci.0,addr=0x3 \
  -chardev pty,id=charserial0 \
  -device isa-serial,chardev=charserial0,id=serial0 \
  -vnc 127.0.0.1:1 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \
  -device ES1370,id=sound0,bus=pci.0,addr=0x4 \
  -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

VM 主机使用完全原装的 Ubuntu 14.04 LTS 设置,在 libvirt+qemu 前面有一个桥接接口。

问题基本上是虚拟机偶尔会出现“延迟”。用户会遇到严重的性能问题。有时几乎察觉不到,但有时单个虚拟机可能难以及时响应 ping,如下所示(经过测试VM Host 以消除任何与网络相关的问题)。

root@vm-host-1:~# ping rc
PING rc (192.168.200.7) 56(84) bytes of data.
64 bytes from rc (192.168.200.7): icmp_seq=1 ttl=64 time=0.202 ms
64 bytes from rc (192.168.200.7): icmp_seq=2 ttl=64 time=0.214 ms
64 bytes from rc (192.168.200.7): icmp_seq=3 ttl=64 time=0.241 ms
64 bytes from rc (192.168.200.7): icmp_seq=4 ttl=64 time=0.276 ms
64 bytes from rc (192.168.200.7): icmp_seq=5 ttl=64 time=0.249 ms
64 bytes from rc (192.168.200.7): icmp_seq=6 ttl=64 time=0.228 ms
64 bytes from rc (192.168.200.7): icmp_seq=7 ttl=64 time=0.198 ms
64 bytes from rc (192.168.200.7): icmp_seq=8 ttl=64 time=3207 ms
64 bytes from rc (192.168.200.7): icmp_seq=9 ttl=64 time=2207 ms
64 bytes from rc (192.168.200.7): icmp_seq=10 ttl=64 time=1203 ms
64 bytes from rc (192.168.200.7): icmp_seq=11 ttl=64 time=203 ms
64 bytes from rc (192.168.200.7): icmp_seq=12 ttl=64 time=0.240 ms
64 bytes from rc (192.168.200.7): icmp_seq=13 ttl=64 time=0.271 ms
64 bytes from rc (192.168.200.7): icmp_seq=14 ttl=64 time=0.279 ms
^C
--- rc.mezzanine ping statistics ---
14 packets transmitted, 14 received, 0% packet loss, time 13007ms
rtt min/avg/max/mdev = 0.198/487.488/3207.376/975.558 ms, pipe 4

在各个虚拟机上运行的本地命令有时也会很慢,例如,运行“ls”通常需要一瞬间,但有时却需要一两秒。显然有些地方不太正常。

我已经追踪这个问题好几天了。VM 主机的磁盘状况良好,内存使用情况也不错,从以下情况可以看出:

virt-top 10:24:10 - x86_64 12/12CPU 3000MHz 64401MB
20 domains, 20 active, 20 running, 0 sleeping, 0 paused, 0 inactive D:0 O:0 X:0
CPU: 0.0%  Mem: 28800 MB (28800 MB by guests)

root@vm-host-1:~# free -m
             total       used       free     shared    buffers     cached
Mem:         64401      57458       6943          0      32229        338
-/+ buffers/cache:      24889      39511
Swap:         7628        276       7352

该服务器完全有能力运行这么多的虚拟机,尤其是考虑到它们不是高负载虚拟机 - 而是大部分处于空闲状态。

解决此问题的步骤是什么?我怀疑其中一个虚拟机出现问题,导致连锁反应影响所有虚拟机,但由于问题偶尔发生,我尚未确定是哪个虚拟机。

VM 主机硬件本身非常健康 - 并且在没有 VM 的情况下运行时也不会出现任何问题,所以我怀疑这是一个 qemu/libvirt/kvm 问题 - 也许是由行为不当的 VM 触发的。

板顶输出:

 Active / Total Objects (% used)    : 17042162 / 17322929 (98.4%)
 Active / Total Slabs (% used)      : 365122 / 365122 (100.0%)
 Active / Total Caches (% used)     : 69 / 125 (55.2%)
 Active / Total Size (% used)       : 1616671.38K / 1677331.17K (96.4%)
 Minimum / Average / Maximum Object : 0.01K / 0.10K / 14.94K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
9326928 9219652  98%    0.10K 239152       39    956608K buffer_head
6821888 6821559  99%    0.06K 106592       64    426368K kmalloc-64
465375 369738  79%    0.05K   5475       85     21900K shared_policy_node
260689 230992  88%    0.55K   4577       57    146464K radix_tree_node
 65280  63353  97%    0.03K    510      128      2040K kmalloc-32
 46494  45631  98%    0.19K   1107       42      8856K dentry
 45936  23865  51%    0.96K   1392       33     44544K ext4_inode_cache
 44136  43827  99%    0.11K   1226       36      4904K sysfs_dir_cache
 29148  21588  74%    0.19K    694       42      5552K kmalloc-192
 22784  18513  81%    0.02K     89      256       356K kmalloc-16
 19890  19447  97%    0.04K    195      102       780K Acpi-Namespace
 19712  19320  98%    0.50K    616       32      9856K kmalloc-512
 16744  15338  91%    0.57K    299       56      9568K inode_cache
 16320  16015  98%    0.04K    160      102       640K ext4_extent_status
 15216  14690  96%    0.16K    317       48      2536K kvm_mmu_page_header
 12288  12288 100%    0.01K     24      512        96K kmalloc-8
 12160  11114  91%    0.06K    190       64       760K anon_vma
  7776   5722  73%    0.25K    244       32      1952K kmalloc-256
  7056   7056 100%    0.09K    168       42       672K kmalloc-96
  5920   4759  80%    0.12K    185       32       740K kmalloc-128
  5050   4757  94%    0.63K    101       50      3232K proc_inode_cache
  4940   4046  81%    0.30K     95       52      1520K nf_conntrack_ffffffff81cd9b00
  3852   3780  98%    0.11K    107       36       428K jbd2_journal_head
  3744   2911  77%    2.00K    234       16      7488K kmalloc-2048
  3696   3696 100%    0.07K     66       56       264K ext4_io_end
  3296   2975  90%    1.00K    103       32      3296K kmalloc-1024

答案1

我们陷入了同一个问题。

由 Ubuntu 14.04 内核引起漏洞

解决方案#1:将内核更新至 3.13.0-33.58(或更新版本)

解决方案 #2: 禁用 KSM

答案2

-设备e1000,netdev = hostnet0

这个。在尝试其他任何操作之前,请先切换到 virtio_net。

第二步:尝试通过ethtool -K关闭 TSO、LSO、LRO 来调整 NIC 卸载设置,看看是否得到不同的结果。

第三步:尝试不同的发行版。Ubuntu 因 KVM 相关错误而臭名昭著,因此请切换到 CentOS 甚至 Fedora 进行测试。

相关内容