Re: MEMORY ISSUE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx> 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@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list





--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

[Index of Archives]     [CentOS]     [Kernel Development]     [PAM]     [Fedora Users]     [Red Hat Development]     [Big List of Linux Books]     [Linux Admin]     [Gimp]     [Asterisk PBX]     [Yosemite News]     [Red Hat Crash Utility]


  Powered by Linux