Performance
Qemu+libvirt+kvm 在 VM 中的顯著性能滯後
我正在對我們的新 VM 主機（具有硬體 RAID 的戴爾 PowerEdge R415）性能不佳進行故障排除。
我們有大約 20 個 VM 像這樣執行：
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=0x6VM 主機使用完整的 Ubuntu 14.04 LTS 設置，在 libvirt+qemu 前面有一個橋接介面。
問題基本上是虛擬機正在經歷零星的“滯後”。使用者將其視為嚴重的性能問題。有時它幾乎不引人注意，但有時單個 VM 可能難以及時響應 ping，如下所示（從VM 主機測試以消除任何與網路相關的問題）。
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
我們陷入了同樣的問題。
由 Ubuntu 14.04 核心錯誤引起。
解決方案 #1：將核心更新到 3.13.0-33.58（或更高版本）
解決方案 #2： 禁用 KSM
-設備 e1000,netdev=hostnet0
這。在嘗試其他任何操作之前切換到 virtio_net。
第二步：嘗試使用
ethtool -K關閉 TSO、LSO、LRO 來使用 NIC 解除安裝設置，看看是否會得到不同的結果。第三步：嘗試不同的發行版。Ubuntu 因與 KVM 相關的錯誤而臭名昭著，因此切換到 CentOS 甚至 Fedora 作為測試。