The Planet Forums > Big IoWait on dual xeon?

The Planet Forums > System Administration > Server Hardware

aitor

May 17 2006, 11:36 AM

I am getting frustrated from 3 months to now that server was going to be to stop at certain times, checking websites and removing few of they have not changed a lot.

After looking lot of things i see that the iowait has gone up again as i have it when i get the server a year ago.

QUOTE

19:34:42 up 35 min, 1 user, load average: 4.11, 3.33, 2.86
169 processes: 167 sleeping, 1 running, 1 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait idle
total 2.4% 0.0% 1.1% 0.0% 0.1% 86.6% 9.4%
cpu00 5.1% 0.0% 2.3% 0.3% 0.7% 73.8% 17.4%
cpu01 0.5% 0.0% 0.3% 0.0% 0.0% 99.0% 0.0%
cpu02 1.3% 0.0% 0.3% 0.0% 0.0% 80.5% 17.6%
cpu03 2.9% 0.0% 1.1% 0.0% 0.0% 92.9% 2.9%
Mem: 1034212k av, 939276k used, 94936k free, 0k shrd, 19768k buff
858520k active, 34104k inactive
Swap: 1052248k av, 15328k used, 1036920k free 267160k cached

any hint about this or if servermatrix has another kernel that has fixed this issue, last time they used one made by they. More than a year from that.

Matt2k

May 17 2006, 05:07 PM

I'm not a Linux guy, but isn't iowait a measurement of how long your system is spent waiting on disk access? This would indicate something in your system is doing a lot of disk thrashing. CPU won't help. Faster drives would, but that doesn't address the underlying issue.

aitor

May 17 2006, 05:14 PM

Yes IoWait is related to hd access. but when i get server looks as kernel sm was setting in it was wrong and they make one that fixes this issue.

After few months i get server going bad, i make a lot things to try to make more efficient but not result, each time it is going to have traffic it gets in bottle neck, and looking by putty i see that error happens again, i am not using big traffic 300 gb month and i have a dual xeon, I am thinking to change to a less server because i am thinking that it is kernel thing.

I hope that someone from sm could respond to this else i am going out.

Blue|Fusion

May 17 2006, 07:00 PM

What kernel are you running? (`uname -r`)
What's your average HDD speeds? (`hdparm -t /dev/hda /dev/hdb`)
Did you do any filesystem, disk, kernel, apache, or mysql optimizations?

aitor

May 18 2006, 12:38 AM

QUOTE

root@srv03 [/]# uname -r
2.6.3-sxeon-3w

root@srv03 [/]# hdparm -t /dev/hda /dev/hdb
/dev/hda: No such device or address

root@srv03 [/]# hdparm -t /dev/hda
/dev/hda: No such device or address

root@srv03 [/]# hdparm -t /dev/hdb
/dev/hdb: No such device or address

root@srv03 [/]# dmesg | grep hd
ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)

root@srv03 [/]# hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 134 MB in 3.14 seconds = 42.68 MB/sec

Did you do any filesystem, disk, kernel, apache, or mysql optimizations?
Only the optimizations that are made with cpanel, config, update etc.

aitor

May 18 2006, 08:05 AM

QUOTE

16:02:15 up 21:03, 1 user, load average: 13.41, 6.05, 3.28
248 processes: 245 sleeping, 1 running, 2 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait idle
total 3.9% 0.0% 1.2% 0.0% 0.2% 94.3% 0.0%
cpu00 4.0% 0.0% 0.7% 0.3% 1.1% 93.5% 0.0%
cpu01 3.5% 0.0% 0.1% 0.0% 0.0% 96.2% 0.0%
cpu02 3.8% 0.0% 3.3% 0.0% 0.0% 92.8% 0.0%
cpu03 4.4% 0.0% 0.7% 0.0% 0.0% 94.7% 0.0%

Beansprout

May 18 2006, 09:46 AM

How many requests are Apache and MySQL doing per second? Is there any excess activity in /var/log/messages and the firewall logs?

Thing with IDE drives is they don't do random accesses very well, so at high activity levels on a shared server you start to suffer.

I'd also recommend upgrading the RAM.

Blue|Fusion

May 18 2006, 03:19 PM

He has SCSI, so disregard the IDE stuff...

But, I'd recommend upgrading your kernel to the latest available and optimizing your services.

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.