[rhelv6-list] Performance issues with RHEL6 (iowait)

[Matthias Saou]

John Haxby wrote :

> The disks will be sda and sdb regardless of whether they're connected as
> PATA or SATA.  If I was to guess from the information you provided earlier,
> I'd say they're connected as PATA.   This being the case, you need to dive
> into the BIOS and turn legacy access (or whatever it's called) off and turn
> AHCI on.
> 
> You can tell which you're using, though, by looking at the output of dmesg |
> egrep 'scsi|ata[0-9]':
> 
> scsi0 : ahci
> scsi1 : ahci
> scsi2 : ahci
> ata1: SATA max UDMA/133 abar m2048 at 0xf6dfb800 port 0xf6dfb900 irq 43
> ata2: DUMMY
> ata3: SATA max UDMA/133 abar m2048 at 0xf6dfb800 port 0xf6dfba00 irq 43
> ata_piix 0000:00:1f.1: version 2.13
> ata_piix 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> ata_piix 0000:00:1f.1: setting latency timer to 64
> scsi3 : ata_piix
> scsi4 : ata_piix
> ata4: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x6fa0 irq 14
> ata5: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x6fa8 irq 15
> ata5: port disabled. ignoring.
> ata4.00: ATA-6: ST980815A, 3.ADE, max UDMA/100
> ata4.00: 156301488 sectors, multi 8: LBA48
> ata4.00: configured for UDMA/100
> ata3: SATA link down (SStatus 0 SControl 300)
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: ATA-8: FUJITSU MHY2120BH, 0085000B, max UDMA/100
> ata1.00: 234441648 sectors, multi 8: LBA48 NCQ (depth 31/32), AA
> ata1.00: configured for UDMA/100
> 
> 
> That's actually my latop which has a SATA disk (ST980815A) and a PATA disk
> (MHY2120BH).  The former is (if you work back through the info) attached to
> an ahci controller, the latter to an ata_piix controller.  I think your
> controllers were using ata_piix drivers which suggests that the BIOS is
> being "kind" and presenting you with backwards compatible and slow drivers.
> 
> I think my BIOS has all kinds of dire warnings about how your system won't
> boot if your switch to AHCI after you've installed an operating system.  By
> which, of course, it means Windows which can't cope with the change.

Thanks for all of those details. I mostly know about all this already,
but not only do I not have access to the BIOS (this is one of those
servers where hardware is managed by the hosting company on a large
scale, any OS is reinstallable remotely at any time, so it makes sense
for them to set BIOS defaults which will work with any OS), but the
issue I'm seeing is not just I/O being slow. It's I/O being blocked
entirely. A simple "ls" can sometimes take tens of seconds when the
system is idle. At other times, I do manage to see disks peak at
multi-10MB/s read or write speeds. Weird... I was just really hoping
someone had already seen this problem with RHEL6, since otherwise it
might indicate a hardware issue.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 14 (Laughlin) - Linux kernel 2.6.35.10-72.fc14.x86_64
Load : 0.01 0.02 0.06