PowerEdge 1950 Debian Etch Xen I/O blocking issue

[L.P.H. van Belle]

I dont know what raid controllers u uses, but for 3ware controllers

this is a known issue.
For example, 

# 3ware SATA II 9550SX Controller Settings - 
# echo cfq > /sys/block/sda/queue/scheduler \ 
# Set via Kernel option "elevator=xxx" (in /boot/grub/menu.lst) 
# These 3 below are set inside /etc/init.d/rc.local 
echo 128 > /sys/block/sda/queue/max_sectors_kb 
echo 512 > /sys/block/sda/queue/nr_requests 
blockdev --setra 16384 /dev/sda 

speeds up a lot on 3ware. 
maybe this also works for dell controllers.

Louis



>-----Oorspronkelijk bericht-----
>Van: linux-poweredge-bounces at dell.com 
>[mailto:linux-poweredge-bounces at dell.com] Namens James Pattie
>Verzonden: vrijdag 24 augustus 2007 22:50
>Aan: linux-poweredge at dell.com
>Onderwerp: PowerEdge 1950 Debian Etch Xen I/O blocking issue
>
>Hi Guys,
>
>Hopefully somebody else has seen this and can shed some light.
>
>I know it's not a supported os, but we are an all Debian shop and
>running Redhat isn't an option.
>
>The box is a PowerEdge 1950 1U w/ 2 QuadCore Xeon 2.33Ghz processors,
>8GB memory, perc 5/i with 2x750GB (7200rpm) SATAII drives in a raid-1
>scenario.
>
>We are currently running Debian Etch 32-bit, kernel 2.6.18-5-xen-686,
>xen hypervisor 3.0.3-1-i386-pae.  All the xen virtual machines are
>running Debian Etch and are on loop back mounted disk images.  We are
>not using LVM in this solution.
>
>The issues we are seeing are that anything that is disk intensive
>(regardless of being in dom0 or domU) causes the box to become
>unresponsive to user input (takes a couple seconds to a minute to
>respond to your console input or remote access input) and the I/O
>consistently "pauses" (for lack of a better description).  We are
>getting abysmal transfer rates on network rsyncs, scp's, netcats, plain
>tars from one loop back mounted filesystem to another, on separate
>partitions but both on the same virtual disk, etc..  There is not a
>specific pattern that I can say it only happens to this.  It 
>seems to be
>a generic offender.
>
>Things we have done to try and isolate the issue, besides lots of
>googling:
>
>1) limit the memory for dom0 to be a max of 2GB
>2) limit dom0 to only have a max of 2 cores assigned (we are only going
>to have a total of 6 virtual machines, so each would have 1 core
>assigned eventually)
>3) updated to latest available kernel that Etch provides, but still no
>improvement.  Looked at Debian Testing but they don't have xen 
>builds of
>the 2.6.21/22 kernels (not sure why yet).  Haven't yet tried 
>building my
>own updated kernel, but that is on my plate.
>4) checked the raid array settings.  Set read ahead to "Adaptive", and
>left write back mode enabled.
>5) pulled one of the disks out of the array and performance improved a
>little, but not to the point where we could say it was acceptable.
>6) booted with a non-xen kernel and had similar i/o problems, so it is
>either an issue with the 2.6.18 kernel or the raid array driver in use
>possibly?
>
>We are thinking of moving to a 64bit version of Debian Etch to see if
>that helps things, but it is going to take 5+ hours to copy the 200GB
>disk image off the server for our primary xen instance back to the
>original xen server running Debian Sarge and we can't have the box
>offline that long.  I would use the xen migration but don't have it
>configured.
>
>Any insight would be much appreciated.
>
>Thanks,
>
>James A. Pattie
>james.pattie at gpsinsight.com
>http://www.gpsinsight.com/ 
>
>_______________________________________________
>Linux-PowerEdge mailing list
>Linux-PowerEdge at dell.com
>http://lists.us.dell.com/mailman/listinfo/linux-poweredge
>Please read the FAQ at http://lists.us.dell.com/faq
>