Hi all:

Vital Stats, Sun 4500 with 6-400mhz cpus, 6GB ram, Solaris 2.6. 
Running Oracle Apps 11.5.5 on 8.1.7.1.

getting consistently high numbers in the my wait queue.  Paging looks
ok, swap looks ok, processors don't appear to be overly busy and disk
i/o looks good too.  Below is an excerpt of vmstat and then iostat
both on 2sec intervals.

Any suggestions would be appreciated.

TIA
Pete's

 procs     memory            page            disk          faults     
cpu
 r b w   swap  free  re  mf pi po fr de sr m0 m1 m3 m4   in   sy   cs
us sy id
 1 1 12 8669048 95256 157 141 1772 2848 3584 62688 95 1 1 1 1 2442
12519 5859 56 8 36
 1 0 12 8665392 95984 75 1521 1016 2884 3848 95528 136 1 1 0 1 2519
10041 5837 55 11 34
 1 0 12 8661864 95072 101 2034 3084 1376 5652 85976 586 0 0 3 0 2236
12874 4414 63 13 24
 0 1 12 8661088 99144 64 584 1848 700 776 85976 10 0 0 0 0 1785 8391
3263 56 7 37
 0 1 12 8665720 99800 9  31 1520 0 0 69648 0 0 0  3  0 1732 6033 3076
49  6 45
 0 0 12 8665336 96752 1  22 1560 8 8 56424 0 0 0  0  0 1402 4837 2152
40  4 56
 0 0 12 8661912 97032 16 1796 2172 216 2704 77384 349 2 2 1 2 1649
8124 3065 46 7 46
 0 0 12 8660024 95368 62 25 1016 500 1264 62688 110 0 0 0 0 1204 4216
1644 45 3 52
 0 0 12 8659624 95496 3  62 420 84 428 50784 48 0 0 0 0 1171 6146 1536
59 2 39


      tty          md0           md1           md3           md4      
   cpu
 tin tout kps tps serv  kps tps serv  kps tps serv  kps tps serv  us
sy wt id
   0   84   5   1    8    5   1   12    8   1    9    5   1   13  56 
8 11 26
   0  161   4   1    2    4   1    6   64   0   21    4   1    6  55
10 11 23
   0   84   0   0    0    0   0    0  264   3   10    0   0    0  62
14  8 16
   0   84   0   0    0    0   0    0    0   0    0    0   0    0  57 
8 13 23
   0   81   0   0    0    0   0    0   24   3    4    0   0    0  49 
6 15 31
   0   80   0   0    0    0   0    0    0   0    0    0   0    0  40 
4 13 43
   0   80   9   2    4    9   2    7  128   1   14    9   2    7  46 
7 15 32
   0   82   0   0    0    0   0    0   60   0    8    0   0    0  45 
3  5 47
   0   82   0   0    0    0   0    0    0   0    0    0   0    0  59 
2  2 38

Pete's <empete2000@yahoo.com> wrote:
> Vital Stats, Sun 4500 with 6-400mhz cpus, 6GB ram, Solaris 2.6. 
> Running Oracle Apps 11.5.5 on 8.1.7.1.

In order of importance :
* Upgrade to Solaris 9 (or at least 8) which will give you _far_ better
performance (especially for memory) than Solaris 2.6 (not to mention a
OS which is still being actively supported, unlike Solaris 2.6 support
which is fairly passive at the moment)

* If you can't upgrade (and did I mention that you _really_ should?) then
at least turn on priority_paging if it's not already on. Search
groups.google.com for details on what this is and how to do it.

> getting consistently high numbers in the my wait queue.  Paging looks

Solaris 2.6 has a really wacky way of calculating wait times. Upgrading
to Solaris 8/9 will fix this.

> ok, swap looks ok, processors don't appear to be overly busy and disk
> i/o looks good too.  Below is an excerpt of vmstat and then iostat
> both on 2sec intervals.

You haven't mentioned if Priority Paging is on, but if it's not (and if
the output you've included is typical) then you're prolly short on
memory. Turning on Priority Paging may fix this, or you may need some
more memory.

  Scott

Pete's <empete2000@yahoo.com> wrote:

> getting consistently high numbers in the my wait queue.  Paging looks
> ok, swap looks ok, processors don't appear to be overly busy and disk
> i/o looks good too.  Below is an excerpt of vmstat and then iostat
> both on 2sec intervals.

The 'w' column is for 'swapped' processes, the 'b' column is for
'blocked on resource' processes.  I'm not sure which one you're
referring to by a 'wait queue'.

Having a non-zero 'w' column generally means that at some point in the
past, the machine was seriously RAM deprived, and began swapping out
(rather than simply paging) executables.  Unless the swapped out
processes need to run, they will stay there.  The system may have
recovered to the point that RAM is no longer in shortage, but the 'w'
numbers will stay positive.  This is no longer an indication of a
problem.

>  0 0 12 8661912 97032 16 1796 2172 216 2704 77384 349 2 2 1 2 1649
> 8124 3065 46 7 46
>  0 0 12 8660024 95368 62 25 1016 500 1264 62688 110 0 0 0 0 1204 4216
> 1644 45 3 52
>  0 0 12 8659624 95496 3  62 420 84 428 50784 48 0 0 0 0 1171 6146 1536
> 59 2 39

-- 
Darren Dunham                                           ddunham@taos.com
Unix System Administrator                    Taos - The SysAdmin Company
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

> 
> "Darren Dunham" <ddunham@redwood.taos.com> wrote in message
> news:QPO1b.4469$QZ3.1151@newssvr27.news.prodigy.com...
>> Pete's <empete2000@yahoo.com> wrote:
>>
>> > getting consistently high numbers in the my wait queue.  Paging looks
>> > ok, swap looks ok, processors don't appear to be overly busy and disk
>> > i/o looks good too.  Below is an excerpt of vmstat and then iostat
>> > both on 2sec intervals.
>>
>> The 'w' column is for 'swapped' processes, the 'b' column is for
>> 'blocked on resource' processes.  I'm not sure which one you're
>> referring to by a 'wait queue'.
>>
>> Having a non-zero 'w' column generally means that at some point in the
>> past, the machine was seriously RAM deprived, and began swapping out
>> (rather than simply paging) executables.  Unless the swapped out
>> processes need to run, they will stay there.  The system may have
>> recovered to the point that RAM is no longer in shortage, but the 'w'
>> numbers will stay positive.  This is no longer an indication of a
>> problem.
>>
>> >  0 0 12 8661912 97032 16 1796 2172 216 2704 77384 349 2 2 1 2 1649
>> > 8124 3065 46 7 46
>> >  0 0 12 8660024 95368 62 25 1016 500 1264 62688 110 0 0 0 0 1204 4216
>> > 1644 45 3 52
>> >  0 0 12 8659624 95496 3  62 420 84 428 50784 48 0 0 0 0 1171 6146 1536
>> > 59 2 39

Approximately 8/27/03 17:36, Jose Arroyo uttered for posterity:
> Although presence of nonzero value for w-field does not have to be
something
> to be concerned of in some cases, when we look a bit closer on the 3 lines
> of vmstat (I was unable to find the original posting) we find some
traces of
> possible memory shortage:
>
> - page scanner active; free memory has reached most likely lotsfree value
> which is by default 1/64th of total physical memory
> - pageout activity
>
> If the demand of memory is continous then it is very likely that we are
> dealing with a system which is regularly swapping out processes.
> If Pete is unable to diminish the memory resource consumption then I guess
> an increase of memory would be appropriate if vmstat shows continously
data
> alike.
>
> Regards,
> JAM
>

  Threading back, this is Solaris 2.6.  I wonder if setting the
  priority paging flag would help....
  [NOTE: Do *not* set this flag in Solaris 8 or higher, see
   Sunsolve for why not...]

  Don't recall what particular patch released the priority_paging
  flag in Solaris 2.6, a sunsolve search on "priority_paging" yields
  pretty good write ups.  The flag won't be effective if heavy file
  I/O is done on files with a umask that sets the execute bit.

  It helped us a bit... and cuts cpu load a bit.

set priority_paging=1
set slowscan=500
set maxpgio=1024

> > Regards,
> > JAM
> >
> 
>   Threading back, this is Solaris 2.6.  I wonder if setting the
>   priority paging flag would help....
>   [NOTE: Do *not* set this flag in Solaris 8 or higher, see
>    Sunsolve for why not...]
> 
>   Don't recall what particular patch released the priority_paging
>   flag in Solaris 2.6, a sunsolve search on "priority_paging" yields
>   pretty good write ups.  The flag won't be effective if heavy file
>   I/O is done on files with a umask that sets the execute bit.
> 
>   It helped us a bit... and cuts cpu load a bit.
> 
> set priority_paging=1
> set slowscan=500
> set maxpgio=1024

Thanks all for your replies, it's been helpful.  I've played with the
priority_paging on this server and have seen the scan rate increase
dramatically during backups of databases.  But, pagin & pageouts seen
to have decreased and free memory has increased.  Not to spend much
more time on this, this server is scheduled for decommissioning in the
next few weeks.

Thanks,
Pete's