資源供給：併發性控制和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/，如需轉載，請註明出處，否則將追究法律責任。