Re: 7.31 performance problem
Hi!
This are coming from the 7.24 enviroment.
> > 3077 1381517314 cb36b000 1130496 636 M 134 4
> > 6 1381517315 cb47f000 1130496 636 M 131 7
> > 7 1381517316 cb593000 1130496 636 M 131 7
This are coming from the 7.31 enviroment.
> > 11 1381517317 cc125000 33554432 1128 V 4091 5
> > 12 1381517318 ce1be000 33554432 1128 V 3996 100
> > 13 1381517319 d01be000 33554432 1128 V 3426 670
> > 14 1381517320 d21be000 33554432 1128 V 993 3103
> > Total: - - 306610176 - - 33521 3907
> >
> > 296112 Kbytes
> >
> Too many virtual memory segments. If this is constanly happening you
> need to grab more virual shared memory on start up.
>
> Long checkpoints. You can probably decrease them by increasing your
> LRU's and lowering your LRU_MIN/MAX. If you are interested in looking
> into this, mention it, and I am sure further discussion will occur.
Yes, we have to change those values and see what happends.
> > MT global info:
> > sessions threads vps lngspins
> > 186 243 42 28
>
> long spins are generally a pretty bad sign, right now I will attribute
> them to the fact that you are encountering the buffer prioritization
> bug.
> >
> > sched calls thread switches yield 0 yield n yield
> > forever
> > total: 625400582 1175793815 29233311 10131255
> 46991488
> > per sec: 81659 15697 73088 28 205
> >
> <SNIP>
> >
> > onstat -P |tail -5> >
> > Percentages:
> > Data 5.85
> > Btree 92.21
> > Other 1.94
> >
> >
>
> This is the big one. As Obnoxio posted, unless you just built an
> index, this is a symptom which points to an LRU prioritization bug.
> I would follow his directions on how to remedy it, and then monitor
> onstat -P periodically to make sure the Btree percentage is not getting
> very high.>
> Hope this helps,
> Will
Thanks for you help.
KT