Re: MEMORY ISSUE

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

 



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




--
Nilesh Vaghela
ElectroMech
Redhat Channel Partner and Training Partner
74, Nalanda Complex, Satellite Rd, Ahmedabad
25, The Emperor, Fatehgunj, Baroda.
www.electromech.info
--
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