-none- 2007-09-05 - By Zhu,Chao
Back
To those who replied to my earlier post and insterested:
We resolved the issue with two solutions:
1. upgrade to solaris 10. The LF behavior goes back to earlier version.
--this makes the individual latch get as fast as 9205 version.
2. or, set _large_pool_min_alloc = 64k. This does the magic even though
database still running on solaris 8. --this greatly reduced the latch
allocation#. so the issue is gone.
On 8/6/07, Zhu,Chao <zhuchao@(protected)> wrote:
>
> maybe not many people use MTS recently due to nearly-free RAM. But when
> connection# goes real high, you still have to, and we are such a user.
> We experienced huge "latch:shared pool" contention in 10.2 MTS
> environment, while on 9i it was fine. And we *guess* it is mainly from
> sort/hash, which will allocate memory/deallocate from large pool, and
> large pool is managed by shared pool latch.
> From statspack, the top functions that called shared pool latch is:
> kghalo, and kghfre.
> Also we are running with sort-area-size. no work-area-size-policy auto
> (though 10g start to support that).
> Anyone has experience with MTS/shared pool latch?
>
>
> --
> Regards
> Zhu Chao
> www.cnoug.org
>
--
Regards
Zhu Chao
www.cnoug.org
To those who replied to my earlier post and insterested:<br>We resolved the
issue with two solutions:<br>1. upgrade to solaris 10. The LF behavior goes
back to earlier version. --this makes the individual latch get as fast as 9205
version.
<br>2. or, set _large_pool_min_alloc = 64k. This does the magic even though
database still running on solaris 8. --this greatly reduced the latch
allocation#. so the issue is gone. <br><br><div><span class="gmail_quote">
On 8/6/07, <b class="gmail_sendername">Zhu,Chao</b> <<a href="mailto:zhuchao
@(protected)">zhuchao@(protected)</a>> wrote:</span><blockquote class="gmail
_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0
.8ex; padding-left: 1ex;">
maybe not many people use MTS recently due to nearly-free RAM. But when
connection# goes real high, you still have to, and we are such a user.<br>We
experienced huge "<span id="st" name="st" class="st">latch</span>:<span id
="st" name="st" class="st">
shared</span> <span id="st" name="st" class="st">pool</span>" contention
in 10.2 MTS environment, while on 9i it was fine. And we *guess* it is mainly
from sort/hash, which will allocate memory/deallocate from large
<span id="st" name="st" class="st">pool</span>, and large <span id="st" name=
"st" class="st">pool</span> is managed by <span id="st" name="st" class="st"
>shared</span> <span id="st" name="st" class="st">pool</span> <span id="st" name
="st" class="st">
latch</span>.
<br>From statspack, the top functions that called <span id="st" name="st" class
="st">shared</span> <span id="st" name="st" class="st">pool</span> <span id="st"
name="st" class="st">latch</span> is: kghalo, and kghfre.<br>
Also we are running with sort-area-size. no work-area-size-policy auto (though
10g start to support that).<br>Anyone has experience with MTS/<span id="st"
name="st" class="st">shared</span> <span id="st" name="st" class="st">
pool</span> <span id="st" name="st" class="st">latch</span>?
<br><span class="sg"><br clear="all"><br>-- <br>Regards<br>Zhu Chao<br><a href=
"http://www.cnoug.org" target="_blank" onclick="return top.js.OpenExtLink(window
,event,this)">www.cnoug.org</a><br>
</span></blockquote></div><br><br clear="all"><br>-- <br>Regards<br>Zhu Chao<br
><a href="http://www.cnoug.org">www.cnoug.org</a><br>
|
|
