Re: lsps shows high values but system appears to be fine On Apr 23, 10:52 pm, Hajo Ehlers <serv...@metamodul.com> wrote:
> On Apr 23, 5:28 pm, "steven_nospam at Yahoo! Canada"
>
>
>
> <steven_nos...@yahoo.ca> wrote:
> > I have several systems that run AIX 5L and Informix databases on them.
> > Most of these systems show values I would expect on a system. However,
> > one seems to give me some weird values in the lsps command.
>
> > Here are the details:
>
> > System Model: IBM,9131-52A
> > Number Of Processors: 4
> > Processor Clock Speed: 1648 MHz
> > CPU Type: 64-bit
> > Kernel Type: 64-bit
> > Memory Size: 7936 MB
> > Good Memory Size: 7936 MB
>
> > Informix Version 9.40 FC7
>
> > # oslevel -s
> > 5200-10-00-0000
>
> > # lsps -a
> > Page Space Physical Volume Volume Group Size %Used Active
> > Auto Type
> > paging00 hdisk3 datavg 6400MB 37 yes
> > yes lv
> > hd6 hdisk5 rootvg 6656MB 100 yes
> > yes lv
>
> > # lsps -s
> > Total Paging Space Percent Used
> > 13056MB 69%
>
> > # vmstat 10 10
> > System Configuration: lcpu=4 mem=7936MB
> > kthr memory page faults cpu
> > ----- ----------- ------------------------ ------------ -----------
> > r b avm fre re pi po fr sr cy in sy cs us sy id wa
> > 1 1 2715508 79451 0 10 10 335 776 0 786 16640 5220 7 2 90
> > 2
> > 1 0 2715519 79440 0 0 0 0 0 0 601 11137 3835 7 1 92
> > 0
> > 1 0 2715520 79411 0 0 0 0 0 0 641 34843 12786 24 2 74
> > 0
> > 1 0 2715529 79401 0 0 0 0 0 0 606 4249 1631 2 0 97 0
> > 1 0 2715673 79242 0 0 0 0 0 0 648 17652 6941 11 1 88
> > 0
> > 1 0 2716015 78898 0 0 0 0 0 0 643 17268 6116 11 1 88
> > 0
> > 2 0 2716193 78742 0 0 0 0 0 0 697 22620 8057 14 1 85
> > 0
> > 2 0 2717113 77816 0 0 0 0 0 0 809 25793 9227 16 1 83
> > 0
> > 5 0 2716951 77872 0 1 0 0 0 0 777 26851 4535 12 3 84
> > 0
> > 0 0 2716921 77902 0 0 0 0 0 0 593 4828 1846 3 0 97 0
>
> > # vmstat -v
> > 2031616 memory pages
> > 1952077 lruable pages
> > 73804 free pages
> > 1 memory pools
> > 333094 pinned pages
> > 80.1 maxpin percentage
> > 20.0 minperm percentage
> > 80.0 maxperm percentage
> > 57.1 numperm percentage
> > 1114800 file pages
> > 0.0 compressed percentage
> > 0 compressed pages
> > 57.7 numclient percentage
> > 80.0 maxclient percentage
> > 1127373 client pages
> > 0 remote pageouts scheduled
> > 5943302 pending disk I/Os blocked with no pbuf
> > 25321 paging space I/Os blocked with no psbuf
> > 2740 filesystem I/Os blocked with no fsbuf
> > 0 client filesystem I/Os blocked with no fsbuf
> > 1436111 external pager filesystem I/Os blocked with no
> > fsbuf
>
> > # lsattr -El aio0
> > autoconfig available STATE to be configured at system restart True
> > fastpath enable State of fast path True
> > kprocprio 39 Server PRIORITY True
> > maxreqs 4096 Maximum number of REQUESTS True
> > maxservers 50 MAXIMUM number of servers per cpu True
> > minservers 10 MINIMUM number of servers True
>
> > The Informix databases are operating on raw LVs and so there should
> > not be a double-caching issue that I have heard mentioned. I have
> > other databases on other servers with less memory and those do not
> > seem to be causing high paging activity.
>
> > The users are not complaining about slow performance or any noticeable
> > issues, so just wondering if anyone may have a suggestion as to
> > whether this is a problem, and if there are any settings I should be
> > looking at that could tell me why this system has decided to use a
> > significant portion of its paging space for no apparent reason.
>
> > Thanks in advance.
>
> > Steve
>
> 1)
> Fromhttp://www.ibm.com/developerworks/views/aix/libraryview.jsp?search_by...
>
> Part 3
>
> Paging allocation type:
> - deferred page space allocation
> - late page space allocation
> - early page space allocation.
>
> The default policy of AIX is deferred page space allocation.
>
> 2)
> For some reason your system is using pretty much file cache. Could be
> NFS, log files and what the heck i know but it looks like the
> computational pages get page out. So check for busy filesystem.
>
> In case the paging rate is low the system is working as designed ;-)
>
> hth
> Hajo
A high % size of paging space in lsps could be partly due to the fact
that at various points of time comp pages have been paged out to
paging space. This is because about 57% of the memory is filled with
file pages which have been protected due to their high repage rates
and numperm being between minperm and maxperm.
Now unless paging space garbage collection is enabled, space in the
paging space is reserved (and shows up in lsps as used) even if the
page is brought to RAM again unless the process stops and releases
memory. (as per perf management guide)
Secondly, does having almost double the paging space (of the amount of
RAM) really helps?
Also what is the lru_file_repage parameter set to?
-Ashok Sangra |