资源供给：并发性控制和mutex之二

前面讲了mutex for cursor，个人认为mutex for cursor和library cache pin并没有太大的区别，mutex所强调的细粒度访问并没有在这里体现出来，无论是library cache pin还是cursor mutex都是基于细粒度的，区别只是在于library cache pin采用队列机制，而mutex采用CAS机制而已。CAS机制可以保证在cursor mutex pin上具有比较library cache pin更高的并发能力，shared mutex不会被exclusive mutex所阻断。
     也许对于前面的cursor mutex需要做个补充：cursor pin作用在execute cursor，cursor mutex一般作用在parse阶段。一般来说主要问题在于cursor pin，很少会出现cursor mutex的问题。

    在11.2之后Oracle提供library cache mutex能力，library cache latch被Oracle放弃了，完全采用了mutex处理。注意library cache pin并没有被完全放弃，在object上的pin依然采用library cache pin处理。
    目前没有时间对于library cache mutex去做研究处理，只能在这里进行猜测：
    如果library cache mutex完全采用mutex处理，library cache的数据结构将发生根本性的变化，Library Cache Hash Bucket机制将不会存在，简单的kv机制+mutex效率很高，但是内存消耗会加大。这个动作个人感觉过于激进，个人感觉目前依然会采用 library cache hash bucket机制处理，而仅仅是library cache latch被mutex替代而已。从这个而言，mutex并不会带来本质性的并发性能力提高，只是由原来exclusive latch(TAS机制）转变为现在CAS机制而已。具体而言，有兴趣的人可以简单的DUMP library cache就可以发现是否每个LIBRARY CACHE中的Object都mutex化，只要依然是原来的HASH Bucket和Handle Chain结构，本质上latch和mutex就不会有太大的变化。
    Oracle在parse过程中，需要频繁的获得library cache latch和释放library cache latch,现在library cache latch被取消了，是简单的被取代还是粒度变细了，这个问题最好让吕海波搞内核研究的人去执行，效率高，准确细致，我们做分析又累又不会有太好的结果。
   吕海波先生曾经简单测试过，mutex并没有比较latch提高太大的性能，甚至在CPU消耗上还有所升高，当时觉得不可思议，现在觉得完全是正常的。我 们假设mutex是比较latch更细粒度的锁，那么其要经历更多的get和release，也就是说基本而言，应该是消耗更多的CPU，甚至降低响应速 度来提高系统并发能力。覆盖更粗的粒度比较覆盖细粒度的方式来完成同样的方式必然是粗粒度的具有更高的效率，只是细粒度的具有更高的并发性。
    mutex的根本目标是利用多核的CPU，提高更高的并发能力而不是响应时间。可以想象，如果你只有一颗单核的CPU，也许latch机制具有更高的效率甚至更高的并发能力。

    mutex同latch一样是spinlock，既然是spinlock必然是一个高CPU消耗的行为。
    latch目前采用spin+post机制，9.2之前采用spin+sleep+spin+sleep....机制，spin+post机制可以显著的 降低latch无法获得所造成的高CPU消耗问题，如果大家有8.1.7的经验可以发现，在8i时代几乎任何大量latch free必然导致CPU消耗居高不下，而在10g时代，这个结果并不具备必然相关性，这就是post机制造成的差异。
    mutex，Oracle假设mutex的冲突很少，可以通过有线的spin机制来获得mutex。Oracle在11.2之前就是这样处理 的，mutex没有sleep机制，而是在简单的空指令休息之后继续spin，显然一旦mutex长期无法获得，必然导致CPU消耗居高不下。
    大家都知道，无论是latch还是mutex，spin都不会被计入等待时间，spin计入CPU Time。这种情况会给mutex的CPU消耗带来困扰，你几乎不会发现任何的cursor: pin mutex等待，但是CPU消耗居高不下。而当你发现cursor: pin s or cursor: pin s on wait x等事件的时候,CPU已经无法提供基本能力，也就是这类事件事实上会发生时CPU不足，只要CPU还可以获得，即使mutex冲突再厉害也不会体现出 来。
    在知道上述机制之后，大家在10.2~11.2之间版本的CPU Tuning就不能光看SQL优化了，必须要观察是否mutex造成了CPU高的问题，大家可以主要观察v$mutex_sleep和v$mutex_sleep_history视图来完成他。

    当然，后来Oracle认识到对于mutex的期待可能过于天真，提供了sleep机制，注意这里不是latch 9.2之后的post机制，而是9.2之前的spin + sleep机制。具体的在这里不展开论述了，Oracle提供了三种不同的mutex等待机制在不同场合下完成。灵活性，对，作为性能优化者最喜欢灵活 性，有灵活性才有他的生存空间呀。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/92650/viewspace-1063521/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/92650/viewspace-1063521/