生產上資料庫大量的latch free 導致的CPU資源耗盡的問題的解決，latchfree

生產上資料庫大量的latch free 導致的CPU資源耗盡的問題的解決，latchfree

中午的時候，我們生產上的某個資料庫，cpu一直居高不下

通過如下的sql語句，我們查看當時資料庫的等待，爭用的情況：

select s.SID,       s.SERIAL#,       'kill -9 ' || p.SPID,       s.MACHINE,       s.OSUSER,       s.PROGRAM,       s.USERNAME,       s.last_call_et,       a.SQL_ID,       s.LOGON_TIME,       a.SQL_TEXT,       a.SQL_FULLTEXT,       w.EVENT,       a.DISK_READS,       a.BUFFER_GETS  from v$process p, v$session s, v$sqlarea a, v$session_wait w where p.ADDR = s.PADDR   and s.SQL_ID = a.sql_id   and s.sid = w.SID   and s.STATUS = 'ACTIVE' order by s.last_call_et desc;

從event可以看到，是latch 的爭用導致的原因

通過如果的sql，查看是什麼樣的latch

select * from v$session_wait where event  like 'latch free'; 

P2就是 這個latch的name，通過v$latchname這個視圖就可以知道哪個具體的latch

1:45:55 PM SQL> select * from v$latchname where latch#=164;     LATCH# NAME                                                                   HASH---------- ---------------------------------------------------------------- ----------       164 simulator hash latch                                             2233208730

查看latch的曆史情況

2:11:59 PM SQL> select name,gets,misses,sleeps from v$latch where sleeps >0 order by sleeps desc; NAME                                                                   GETS     MISSES     SLEEPS---------------------------------------------------------------- ---------- ---------- ----------simulator hash latch                                             4827860212  135426899   10890947cache buffers chains                                             1619822817 2850976006    4747728gc element                                                       4660052091   25748270     175073resmgr:schema config                                               91872524     153968      95708ges resource hash list                                            174151449    1070556      55459Real-time plan statistics latch                                    40953155     651496      44527call allocation                                                     3301878     265908      43501row cache objects                                                 336300485    4970324      19366

這個simulator hash latch已經是顯著的latch部分

eagle在他的網站上有篇文章講到了關於simulator這個

http://www.eygle.com/archives/2011/11/simulator_lru_latch.html

simulator意為類比，也就是說當Oracle在記憶體中進行資料區塊處理時，實際上還會在預先分配的Buffer中進行相關資訊記錄，如DBA資訊，當資料區塊被老化之後，下次讀取時，如果請求的資料在Simulator記憶體中存在，則認為繼續緩衝該資料區塊是有意義的，通過監控並類比統計這些操作，並對計算結果加權運算，就可以實現對於記憶體的調整建議。
在類比過程中，也是通過Latch來實現的，相關的Latch就有 simulator lru latch 、 simulator hash latch等.

就Buffer Cache而言，如果系統中該類爭用嚴重，則可以考慮關閉db_cache_advice，消除這部分內部操作對於效能的影響。
以下是一個相關BUG，在該Bug中，由於DB_CACHE_ADVICE的開啟導致了嚴重的simulator lru latch的競爭：

Bug 5918642  Heavy latch contention with DB_CACHE_ADVICE on This note gives a brief overview of bug 5918642. 
 The content was last updated on: 01-APR-2008
  Click here for details of each of the sections below.
Affects:

Product (Component)	Oracle Server (Rdbms)
Range of versions believed to be affected	Versions < 11.2
Versions confirmed as being affected	10.2.0.3
Platforms affected	Generic (all / most platforms affected)

Fixed:

This issue is fixed in

11.2 (Future Release) 10.2.0.4 (Server Patch Set) 11.1.0.7 (Server Patch Set)

Symptoms:	Related To:
Latch Contention Waits for "latch free"	Performance Monitoring DB_CACHE_ADVICE

Description

High simulator lru latch contention can occur when db_cache_advice isset to ON if there is a large buffer cache.Workaround:  Set db_cache_advice to OFF

當然，這個只是治標不治本的做法，這個是顯現的表象的問題，根源的問題還是這個sql語句有問題

當一個資料區塊讀入到sga中時，該塊的塊頭(buffer header)會放置在一個hash bucket的鏈表(hash chain)中。該記憶體結構由一系列cache buffers chains子latch保護（又名hash latch或者cbc latch）。對Buffer cache中的塊，要select或者update、insert,delete等，都得先獲得cache buffers chains子latch，以保證對chain的排他訪問。若在過程中發生爭用，就會等待latch:cache buffers chains事件。

產生原因： 1. 低效率的SQL語句（主要體現在邏輯讀過高） 在某些環境中，應用程式開啟執行相同的低效率SQL語句的多個並發會話，這些SQL語句都設法得到相同的資料集，每次執行都帶有高 BUFFER_GETS(邏輯讀取)的SQL語句是主要的原因。相反，較小的邏輯讀意味著較少的latch get操作，從而減少鎖存器爭用並改善效能。注意v$sql中BUFFER_GETS/EXECUTIONS大的語句。 2.Hot block 當多個會話重複訪問一個或多個由同一個子cache buffers chains鎖存器保護的塊時，熱塊就會產生。當多個會話爭用cache buffers chains子鎖存器時，就會出現這個等待事件。有時就算調優了SQL，但多個會話同時執行此SQL，那怕只是掃描特定少數塊，也是也會出現HOT BLOCK的。

SELECT P935.SEQUENCEID,       null FA_SEQUENCEID,       P935.ORDERID,       P935.ORGORDERID,       P935.PRODUCTNAME,       P935.PRODUCTNUM,       P935.ORDERTIME,       P935.LASTUPDATETIME,       P935.ORDERSTATUS,       P935.MEMO,       935 orderCode,       P935.PAYERACCTCODE,       P935.PAYERACCTTYPE,       P935.PAYEEACCTCODE PLATACCTCODE,       P935.PAYEEACCTTYPE PLATACCTTYPE,       P936.PAYEEACCTCODE,       P936.PAYEEACCTTYPE,       EXT935.PAYER_DISPLAYNAME,       EXT935.PAYER_NAME,       EXT935.PAYER_IDC,       EXT935.PAYER_MEMBERTYPE,       EXT936.PAYER_DISPLAYNAME PLAT_DISPLAYNAME,       EXT936.SUBMITNAME PLAT_NAME,       EXT936.PAYER_IDC PLAT_IDC,       EXT936.PAYER_MEMBERTYPE PLAT_MEMBERTYPE,       EXT936.PAYEE_DISPLAYNAME,       EXT936.PAYEE_NAME,       EXT936.PAYEE_IDC,       EXT936.PAYEE_MEMBERTYPE,       P935.PAYEEDISPLAYNAME WEBSITENAME,       CASE         WHEN (SELECT count(*)                 FROM PAYMENTORDER P936                WHERE P936.Ordercode = 936                  and P936.Orderstatus = 0                  AND <span style="color:#ff0000;">P936.Relatedsequenceid = P935.SEQUENCEID</span>) > 0 THEN          0         ELSE          1       END AS SHARINGRESULT,       CASE D935.Dealcode         WHEN 210 then          14         else          D935.DEALTYPE       end PAYMETHOD,       D935.DEALAMOUNT,       G935.EXT1,       G935.Ext2,       G935.PAYERCONTACTTYPE,       G935.PAYERCONTACT,       NVL(D935.PAYEEFEE, 0) PAYEEFEE,       NVL(D935.PAYERFEE, 0) PAYERFEE,       nvl(MS936.PAYEEFEE, 0) PLATFORMFEE,       P935.VERSION  FROM PAYMENTORDER          P935,       PAYMENTORDER          P936,       DEAL                  D935,       GATEWAYORDER          G935,       MSGATEWAYSHARINGORDER MS936,       PAYMENTORDEREXT       EXT935,       PAYMENTORDEREXT       EXT936 WHERE P936.ORDERCODE = 936   AND P935.ORDERCODE = 935   AND P936.RELATEDSEQUENCEID = to_char(P935.SEQUENCEID)   AND P935.SEQUENCEID = G935.SEQUENCEID(+)   AND P935.SEQUENCEID = D935.ORDERSEQID(+)   AND P935.SEQUENCEID = EXT935.ORDERSEQID(+)   AND P936.SEQUENCEID = EXT936.ORDERSEQID(+)   AND P936.SEQUENCEID = MS936.SEQUENCEID(+)   AND MS936.SHARINGTYPE = 1   AND P935.SEQUENCEID = :1UNIONSELECT P938.SEQUENCEID,       P935.SEQUENCEID FA_SEQUENCEID,       P938.ORDERID,       P938.ORGORDERID,       P935.PRODUCTNAME,       P935.PRODUCTNUM,       P938.ORDERTIME,       P938.LASTUPDATETIME,       P938.ORDERSTATUS,       P938.MEMO,       938 orderCode,       P938.PAYERACCTCODE,       P938.PAYERACCTTYPE,       P938.PAYEEACCTCODE PLATACCTCODE,       P938.PAYEEACCTTYPE PLATACCTTYPE,       P938.PAYEEACCTCODE,       P938.PAYEEACCTTYPE,       EXT938.PAYER_DISPLAYNAME,       EXT938.PAYER_NAME,       EXT938.PAYER_IDC,       EXT938.PAYER_MEMBERTYPE,       EXT938.PAYEE_DISPLAYNAME PLAT_DISPLAYNAME,       EXT938.SUBMITNAME PLAT_NAME,       EXT938.PAYEE_IDC PLAT_IDC,       EXT938.PAYEE_MEMBERTYPE PLAT_MEMBERTYPE,       EXT938.PAYEE_DISPLAYNAME,       EXT938.PAYEE_NAME,       EXT938.PAYEE_IDC,       EXT938.PAYEE_MEMBERTYPE,       P935.PAYEEDISPLAYNAME WEBSITENAME,       null SHARINGRESULT,       D938.DEALTYPE PAYMETHOD,       D938.DEALAMOUNT,       G935.EXT1,       G935.Ext2,       G935.PAYERCONTACTTYPE,       G935.PAYERCONTACT,       NVL(D938.PAYEEFEE, 0) PAYEEFEE,       NVL(D938.PAYERFEE, 0) PAYERFEE,       0 PLATFORMFEE,       P935.VERSION  FROM PAYMENTORDER    P935,       PAYMENTORDER    P938,       DEAL            D938,       GATEWAYORDER    G935,       PAYMENTORDEREXT EXT938 WHERE P935.ORDERCODE = 935   AND P938.ORDERCODE = 938   AND P938.RELATEDSEQUENCEID = to_char(P935.SEQUENCEID)   AND P935.SEQUENCEID = G935.SEQUENCEID(+)   AND P938.SEQUENCEID = D938.ORDERSEQID(+)   AND P938.SEQUENCEID = EXT938.ORDERSEQID(+)   AND P935.SEQUENCEID = :2

分析上面的sql，上面標紅的地方，等號左邊是varchar2的資料類型，括弧右邊是number的資料類型，會導致資料類型的隱式轉換，造成極大的效能影響

聯絡研發，修改了sql語句，問題解決

網站的CPU資源佔用過大導致網站開不了了怎辦

以下是方案1：
現象：機器正在調試或允許IIS時,被異常中斷服務(比如停電)，然後再次IIS運行頁面時，CPU資源佔用100%，即使重新啟動也無效。
原因：發生中斷時，IIS會寫異常日誌，但是此時寫入了亂碼，造成IIS一直寫日誌的死迴圈，耗盡了系統資源。找到系統路徑\System32\Logfiles\W3SVC1 下當天的錯誤記錄檔檔案，即可看到以上內容。
解決：刪除 系統路徑\System32\Logfiles\W3SVC1 下當天的錯誤記錄檔檔案，如：ex060904.log，然後重新啟動IIS即可。以下是方案2：
環境：win2003server+IIs+ASP+MSSQL
現象：每隔一段時間（不定，有時幾分鐘，有時半小時）出現一次網站開啟非常緩慢，甚至有時會出現逾時打不開網站，此時查看伺服器端的進程，CPU佔用率達到100%，其中w3wp佔用70~80%，SQL佔用20~30%。所有伺服器端的操作也變得緩慢
初期解決方案：每次現象出現時，立即登入伺服器直接結束w3wp進程或重啟IIS服務，平均每天約十次操作，由於伺服器存放於遠程機房，所有操作都是遠端控制進行，有時會因此出現遠程無法串連登入的情況，只能通過電話通知機房管理員重啟伺服器解決，此過程導致使用者抱怨不斷
經過網上查閱資料，發現此類現象多數由於網頁代碼不合理所致，以下情況會導致此類現象發生：
1、代碼中多處使用application、seesion等伺服器緩衝，導致伺服器資料過度佔用；
2、代碼有不合理文法，死迴圈等；
3、資料庫損壞，尤其是ACCESS資料庫；
4、裝過多第三方軟體或外掛程式，與IIS或網頁功能代碼衝突。
第一階段排查：根據查閱到的參考資料逐項分析
1、伺服器上所有站台碼均為公司設計人員自行編寫，可證實並無過多調用伺服器緩衝文法（排除）
2、代碼是否存在不合理文法（不確定）
3、根據情況來看，IIS進程佔用率升高時，SQL佔用率同時升高，應為SQL資料庫的網站，根據現象判斷，庫或表應該正常，估計是資料方面可能有誤；（不確定）
4、伺服器端除了基本的系統服務，防殺毒及網站運作必備服務之外，並無多餘第三方軟體，機率不大（排除）。

經過以上分析判斷，將不確定項連起來得出的結論是：某個採用了SQL資料庫的網站網頁代碼存在不合理文法，導致IIS和SQL進程CPU佔用率過高。

第二階段排查：
確定範圍，接著繼續把範圍縮小。
由於伺服器上採用SQL資料庫的網站並不多，便於建立獨立進程ID來觀察，將所有採用SQL資料庫的網站在IIS管理器中分別建立獨立的應用程式集區，然後通過CMD介面輸入：iisapp -a 命今查看並記錄下各IIS池的進程ID號，通過多次現象重現時的觀察，有個IIS進程ID是導致此次問題的罪魁禍首。
以下是方案3：
在IIS6下，經常出現w3wp.exe的記憶體及CPU佔用不能及時釋放，從而導致伺服器響應速度很慢。

解決記憶體佔用過多，可以做以下配置：
1、在IIS中對每個網站進行單獨的應用程式集區配置。即互相之間不影響。
2、設定應用程式集區的回收時間，預設為1720小時，可以根據情況修改。再設定當記憶體佔用超過多少（如500M），就自動回收記憶體。

解決CPU佔用過多：
1、在IIS中對每個網站進行單獨的應用程式集區配置。即互相之間不影響。
2、設定應用程式集區的CPU監視，不超過25%（伺服器為4CPU），每分鐘重新整理，超過限制時關閉。

根據w3wp取得......餘下全文>>
 
CPU%100的問題

經常用電腦的朋友一定沒有少碰到藍屏，那張冰涼的藍面孔真的很令人討厭。那麼藍屏到底是怎麼產生的呢？

我們可以從軟、硬兩方面來解釋藍屏現象產生的原因。從硬體方面來說，超頻過度是導致藍屏的一個主要原因。過度超頻，由於進行了超載運算，造成內部運算過多，使CPU過熱，從而導致系統運算錯誤。如果既想超頻，又不想出現藍屏，只有做好散熱措施了，換個強力風扇，再加上一些矽膠之類的散熱材料會好許多。另外，適量超頻或乾脆不超頻也是解決的辦法之一。要穩定還是要更高的速度就看你自己的抉擇了。

如果記憶體條發生物理損壞或者記憶體與其它硬體不相容，也會產生藍屏。此時的解決辦法只有換記憶體這一個方法了。

如果你留意過，你會發現光碟機在讀盤時被非正常開啟也會導致藍屏。這個問題不影響系統正常動作，只要再彈入光碟片或按ESC鍵就可以。

由於硬體產生藍屏的另外一個常見原因是系統硬體衝突所致。實踐中經常遇到的是音效卡或顯示卡的設定衝突。在“控制台”→“系統”→“裝置管理”中檢查是否存在帶有黃色問號或驚嘆號的裝置，如存在可試著先將其刪除，並重新啟動電腦，由Windows自動調整，一般可以解決問題。若還不行，可手工進行調整或升級相應的驅動程式。

劣質零組件是電腦出現藍屏現象的另外一個罪魁禍首。少數不法商人在給顧客組裝相容機時，使用品質低劣的主板、記憶體，有的甚至出售冒牌主板和舊的CPU、記憶體，這樣就會使機器在運行時很不穩定，發生死機也就在所難免。因此，使用者購機時應該有這方面的戒心，可請比較熟悉的朋友協助挑選，並可以用一些較新的工具軟體測試電腦，長時間連續考機(如72小時)，以及爭取盡量長的保修時間等。

從軟體方面看，遭到病毒或駭客攻擊、註冊表中存在錯誤或損壞、啟動時載入程式過多、版本衝突、虛擬記憶體不足造成系統多任務運算錯誤、動態連結程式庫檔案丟失、過多的字型檔、載入的計劃任務過多、系統資源產生衝突或資源耗盡都會產生藍屏。另外，產生軟硬體衝突也很容易出現藍屏。明白了藍屏出現的“軟”原因，就可對症下藥了。

一、先來看看消滅藍屏的怪招。

Windows出錯時會出現藍屏，大家對此可能都已經習以為常了，但可不可以不是“藍”屏，比方說換為“紅”屏、“綠”屏可以不？當然可以！方法如下：

1.首先要出現藍屏錯誤畫面：你只要從A盤或光碟機複製一個檔案到你的硬碟上（注意這個檔案不能太小），在複製過程中將磁碟片或光碟片取出來，Windows馬上就會變臉——藍屏立即就會出現，這時按Esc回到Windows狀態。

2.點擊“開始”→“運行”，在彈出的對話方塊中輸入msconfig.exe，斷行符號，就會調出系統配置公用程式。現在，點擊其中的“System.ini”標籤。

3.找到[386Enh]項，點擊“建立”，在其下新增一字串“MessageBackColor=”（注意輸入時沒有引號），等號後面是16進位數字0～F，可以隨意填，它是用來表示錯誤畫面的背景顏色。

4.同樣的方法，在[386Enh]下再新增一字串“MessageTextColor=”（注意輸入時沒有引號），等號後面是16進位數字0～F，可以隨意填，它是用來表示錯誤畫面的文字顏色。

5.現在，重新啟動電腦，來做個實驗看成功沒有：重複步驟1，看看是不是已經告別藍屏了？大功告成！

說明：本方法並沒有真正改變脆弱地Windows的穩定性，只是通過我們的勞動，改變了Windows出錯時畫面的背景顏色和文字顏色。從這個角度來說，這也算是一種DIY行為哦。

二、及時關閉暫時不用的程式

一些程式即使過後要用，也可先關閉以節省資源。......餘下全文>>