You are not logged in.

#1 2016-10-18 02:49:10

webdawg
Member
Registered: 2010-12-28
Posts: 62

HVM domU - Slow disk Access - 100% CPU - XenServer 7

Hello,

I have a bunch of debian VMS that are PVHVM and I see none of the issues I am about to discribe here.

I have a few HVM Archlinux instances on XenServer 7 latest and I get horrible disk access times:

dd if=/dev/zero of=test bs=1M count=1024
^C18+0 records in
18+0 records out
18874368 bytes (19 MB, 18 MiB) copied, 6.73338 s, 2.8 MB/s

I see nothing like this on the domU Debian Jessie issues and it looks like after looking at the kernel config that the XEN PVHVM stuff is enabled basically the same way in Debian and Archlinux.  IE the config parms basically match.

I noticed that debian does not have this:

CONFIG_XEN_EFI=y
CONFIG_XEN_AUTO_XLATE=y
CONFIG_XEN_ACPI=y
CONFIG_XEN_SYMS=y
CONFIG_XEN_HAVE_VPMU=y

The reason I recognized this performance problem is that when I went to start up my Xen HVM Archlinux instance, it would take forever to boot.

Looking at xentop I saw that the CPU for that domU was at 99.9%.

Every time I do a dd, the CPU in xentop for that domU jumps and stays at 99.9%.

I have went as far as to install linux-lts and test that and then even for the hell of it added:

MODULES="xen-blkfront xen-fbfront xen-netfront xen-kbdfront"

to mkinitcpio.conf

I tried this because I figured that something was not loading, a part of the PVHVM system or something that supports disk I/O but it seems like I am wrong.

If anyone can make any recommendations on this, that would be great.

I checked to see if the Archlinux domU was loading the xen pv stuff by editing /etc/default/grub and putting "GRUB_CMDLINE_LINUX=loglevel=9".  (https://xen-orchestra.com/blog/debian-pvhvm-vs-pv/) and the "Netfront and the Xen platform PCI driver have been compiled for this kernel" comes up.

This box is a pure Intel system w/ a super micro board and Xeon procs:  model name    : Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz

All of the virtualization stuff has been enabled.

Please help.  I have a multipass.

Last edited by webdawg (2016-10-18 02:49:30)

Offline

#2 2016-10-18 21:20:11

webdawg
Member
Registered: 2010-12-28
Posts: 62

Re: HVM domU - Slow disk Access - 100% CPU - XenServer 7

So far this brings the speed up:

*http://serverfault.com/questions/502158/how-to-get-more-i-o-performance-from-citrix-xenserver#502171
echo    1       >       /sys/block/$dev/queue/nomerges

Offline

#3 2016-10-18 22:05:23

webdawg
Member
Registered: 2010-12-28
Posts: 62

Re: HVM domU - Slow disk Access - 100% CPU - XenServer 7

So the last comment lowered the cpu usage.  It looks like a lot of the queue tunables are non functional in the newer kernels.

https://bugzilla.novell.com/show_bug.cgi?id=911337

It has been replaced with mq.

BUT

I am going to keep going and look more and more into this until I get some speed out of these machines but it looks like I can get the same speed as the debian boxes and remove the %99.9 percent CPU with this:

echo 1 > /sys/block/xvda/queue/add_random

This is the fix so far (it is actually how the debian domU's are tuned), I am going to keep comparing tunables and whatever else I can find.

I do not know if this is a bug or feature because To prevent the I/O on your SSD or HDD from contributing to the entropy pool you can echo 0 into /sys/block/xvda/queue/add_random

So by echoing 1...it is actually doing more really, but I do not know if there is some type of issue with xen expecting IO to move the entropy of the actual system so it could wait I guess?

Last edited by webdawg (2016-10-19 02:02:13)

Offline

#4 2016-10-24 20:54:36

webdawg
Member
Registered: 2010-12-28
Posts: 62

Re: HVM domU - Slow disk Access - 100% CPU - XenServer 7

If anyone could chime in letting me know if they have a XenServer 7 instance and an PVHVM archlinux install running, that would be great!

I have been looking into this for about a week now with no luck.

None of the above fixes actually work.  Editing queue settings do nothing.

oflag=direct does the trick w/ dd but I do not know why.

Last edited by webdawg (2016-10-24 20:57:50)

Offline

Board footer

Powered by FluxBB