MEMORY ISSUE
George Magklaras
georgios at biotek.uio.no
Thu Mar 8 11:55:54 UTC 2007
If your box starts swapping, I/O wait will be high as your disks are
(usually) saturated with the task of swapping stuff in and out of RAM
plus whatever non swap I/O you might be doing from other processes at
the time. Either that or a sign of a disk subsystem that cannot keep up
with the demand.
--
--
George Magklaras
Senior Computer Systems Engineer/UNIX Systems Administrator
EMBnet Technical Management Board
The Biotechnology Centre of Oslo,
University of Oslo
http://www.biotek.uio.no/
EMBnet Norway: http://www.biotek.uio.no/EMBNET/
nilesh vaghela wrote:
> Can Any body tell me if the iowait is always high than what should be taken
> care.
>
> Some time it show very high cup usage on iowait.
> 10:42:06 up 55 days, 18:48, 4 users, load average: 6.29, 4.27, 3.21
> 196 processes: 192 sleeping, 1 running, 3 zombie, 0 stopped
> CPU states: cpu user nice system irq softirq iowait idle
> total 76.2% 0.0% 14.8% 0.4% 0.4% 107.4% 0.0%
> cpu00 47.5% 0.0% 8.9% 0.1% 0.5% 42.7% 0.0%
> cpu01 28.8% 0.0% 5.9% 0.3% 0.0% 64.7% 0.0%
> Mem: 1024780k av, 1008684k used, 16096k free, 0k shrd, 44648k
> buff
> 748156k actv, 140440k in_d, 15288k in_c
> Swap: 1959888k av, 251836k used, 1708052k free 639356k ca
>
> On 3/7/07, George Magklaras <georgios at biotek.uio.no> wrote:
>>
>>
>> I agree that some of the memory (excluding swap utilization) is buffer
>> cached and it appears to be in use, however under normal conditions you
>> should not see your box going substantially into swap, unless you have
>> either a large number of processes with page faults (that force
>> processes in and out of swaps), or your overall amount of processes and
>> their memory requirements exceed the 16 Gigs you have.
>>
>> Your output below displays only part of the process table. You have 813
>> processes sleeping. A good thing to is to give us something like:
>>
>> 1)ps auxwww (watch out if you have any sensitive info on the command
>> line arguments that launch your processes) and also a:
>>
>> 2)cat /proc/meminfo
>>
>> and also while your system is swapping do a:
>>
>> 3)vmstat 1
>>
>> and gives us 5 of 7 lines of output, just to see the values of the 'r'
>> and 'b' columns.
>>
>> 4)Also kernel version (uname -a) would be nice.
>>
>> If you saturate the runtime queues by launching a number of running
>> processes a lot higher than the number of procs (from 3 if you see huge
>> values under column 'b' ), depending on how your kernel VM parameters
>> are set (normally Oracle admins tweak those) on /proc/sys/vm , the box
>> might swap out by force processes that are waiting for I/O (I don't know
>> if 132% of iowait is due to the swap itself or the swap itself is caused
>> by what I actually suspect).
>>
>> Bottom line: I suspect that the excessive swap might be either a result
>> of the number of Oracle threads or other processes, or a result of the
>> fact you need to adjust your VM settings and control more properly the
>> conditions of what goes in or out of RAM.
>>
>> BTW, why 16 Gigs of RAM and only 2 Gigs of swap? Should you not have
>> more swap space?
>>
>> GM
>>
>>
>> --
>> --
>> George Magklaras
>>
>> Senior Computer Systems Engineer/UNIX Systems Administrator
>> EMBnet Technical Management Board
>> The Biotechnology Centre of Oslo,
>> University of Oslo
>> http://www.biotek.uio.no/
>>
>> EMBnet Norway: http://www.biotek.uio.no/EMBNET/
>>
>>
>>
>>
>> Redouane N. wrote:
>> > Top Output :
>> >
>> > 12:07:58 up 1 day, 11:40, 114 users, load average: 5.07, 3.77, 2.84
>> > 816 processes: 813 sleeping, 3 running, 0 zombie, 0 stopped
>> > CPU states: cpu user nice system irq softirq iowait
>> idle
>> > total 82.4% 0.0% 192.8% 0.0% 21.6% 132.0%
>> 368.8%
>> > cpu00 10.4% 0.0% 24.2% 0.0% 1.3% 34.4%
>> 29.4%
>> > cpu01 20.1% 0.0% 29.7% 0.0% 4.2% 24.4%
>> 21.3%
>> > cpu02 6.9% 0.0% 25.4% 0.1% 2.1% 16.5%
>> 48.7%
>> > cpu03 14.1% 0.0% 24.2% 0.0% 3.4% 16.6%
>> 41.3%
>> > cpu04 8.7% 0.0% 24.8% 0.0% 3.6% 15.9%
>> 46.7%
>> > cpu05 8.7% 0.0% 23.6% 0.0% 2.1% 12.6%
>> 52.8%
>> > cpu06 7.5% 0.0% 22.3% 0.0% 2.1% 5.6%
>> 62.3%
>> > cpu07 5.8% 0.0% 18.6% 0.0% 3.1% 6.4%
>> 66.0%
>> > Mem: 16149860k av, 16058712k used, 91148k free, 0k shrd,
>> 59076k buff
>> > 8485704k actv, 5258288k in_d, 282060k in_c
>> > Swap: 2044072k av, 109996k used, 1934076k free
>> 13184616k cached
>> >
>> > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU
>> COMMAND
>> > 2976 oracle10 16 0 757M 757M 754M R 16.1 4.8 4:47 0
>> oracle
>> > 18834 oracle10 15 0 258M 257M 254M S 0.7 1.6 0:31 5
>> oracle
>> > 7642 oracle10 15 0 228M 226M 223M S 0.5 1.4 0:23 6
>> oracle
>> > 11895 oracle10 15 0 209M 208M 205M S 0.0 1.3 0:25 2
>> oracle
>> > 13743 oracle10 15 0 197M 188M 185M S 0.0 1.1 0:16 7
>> oracle
>> > 3026 oracle10 15 0 188M 186M 184M S 0.0 1.1 10:18 4
>> oracle
>> > 3090 oracle10 15 0 186M 185M 183M S 0.5 1.1 2:08 4
>> oracle
>> >
>> > Its strange!!!! Right Guys?!
>> >
>> > Regrads,
>> > Redouane N.
>>
>> --
>> redhat-list mailing list
>> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
>> https://www.redhat.com/mailman/listinfo/redhat-list
>>
>
>
>
More information about the redhat-list
mailing list