MEMORY ISSUE

nilesh vaghela nileshj.vaghela at gmail.com
Thu Mar 8 04:46:39 UTC 2007


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
>



-- 
Nilesh Vaghela
ElectroMech
Redhat Channel Partner and Training Partner
74, Nalanda Complex, Satellite Rd, Ahmedabad
25, The Emperor, Fatehgunj, Baroda.
www.electromech.info



More information about the redhat-list mailing list