Your /proc/interrupts looks good and in any case, you have
unmaskirq = 0 (off)
which is also good.
multcount = 0 (off)
IO_support = 0 (default 16-bit)
using_dma = 0 (off)
which are all bad. From the top down, multicount should be 16. Its the number of sectors the driver moves to/from the disk in one IRQ. The more the better and 16 is the maximum supported.
IO_support is either 16 bit or 32 bit. 32 bit allows 32 bit transfers from the controller chip to main memory. When DMA is in use, this makes little difference but in PIO modeit provides just less thana factor of two increase in performance.
Lastly, using_dma moves the data transfer load off the CPU almost totally. The CPU loads the DMA controller registers and the DMA controller does the data transfer, freeing the CPU. This is worth about a 20x improvement in disk transfer rates.
With the information at hand, I cannot be sure that the kernel has not reverted to PIO because of DMA timeout errors although, given that multicount and IO_support are also sub optimal I suspect you are using the wrong kernel driver for your hardware.
As its a production server, I guess you do not want to reboot but the output of dmesg, provided its all of it from a reboot, will confirm that one way or the other.
Alternatively, post your
output so I can advise how your kernel should be configured for your hardware.
You may also attempt to turn on those features with hdparm. With the right kernel driver, its not needed but
hdparm -d1 /dev/hdc
will turn on DMA, provided you have the right driver in the kernel. I'll have to refer you to
for the other options but control of DMA will prove the point.