（本文轉自“NCN新炬網路團隊部落格”）

在11.2.2.x版本TimesTen的實際運維中，經常會出現大量的”waiting for latch”的告警資訊，直到11.2.2.8.0以後版本，針對latch進行了改進，期待11.2.2.8.0以後版本能有所改善；由於TimesTen中，latch等待的種類較多，每一種latch等待，代表著不通的效能問題，為了方便的理解，分別梳理各種“waiting for latch”的意思及最佳化方法：

1、waiting for latch “Command Dependency”
告警waiting for latch “Command Dependency”是一個比較樂觀的告警資訊，因為該告警資訊一般是由於應用程式SQL未大量繫結變數語句引起，這個時候我們可以使用ttsqlcmdcacheinfo\2和ttsqlcmdcacheinfoget兩個Built獲取當前緩衝區的當前情況；
ttsqlcmdcacheinfo\2可以獲取到當前緩衝區的SQL，透過分析SQL來判斷應用是否使用繫結變數；ttsqlcmdcacheinfoget可以獲取當前緩衝區SQL的數量和過期可釋放的SQL的數量.
根據多個省的移動及電信計費系統運維的經驗，系統在緩衝區的SQL量不多，在100～500之間，如果大於這個值，需要詳細分析Command緩衝區，大多是因為應用未使用繫結變數引起。
該告警的解決方案只有透過應用繫結變數，消除硬解析，減少資源開銷；同時，這裡需要確認PrivateCommands引數是否設定，該引數預設是連線共享的，如果設定為1表示連線之間不進行共享，這樣繫結變數的SQL在不同連線之間也不能相互共享。
告警日誌例子：Warn: : 16600: 28199/1002670e0: ConnId=28 (java) waiting for latch “Command Dependency”(7724594584), Holder=1038 (Deadlock Detector) PID 16610, now 1 secs

2、waiting for latch “Heap[N] – Perm”
這個告警資訊大多時候是提示對OOL（out-of-line）欄位的更新過於頻繁，OOL一般都是長度大於255欄位，這種長度較大的欄位存放在TT中本來就是不推薦的，如果這樣的欄位還頻繁的更新，說明在架構設計階段沒有進行詳細的應用分析，解決方式就是減少對OOL欄位的更新頻率。
TimesTen對欄位的儲存分為in-line和out-line兩種，一般預設採用in-line的儲存方式，資料訪問直接訪問資料儲存地址；當欄位較大(比如：大於varchar2(255))，TimesTen將採用in-line儲存一個類似指標地址的方式，並採用out-line儲存實際資料，每次資料庫訪問透過先訪問指標地址，在透過指標讀取資料。
告警日誌例子： Warn: : 23373: 10118/0x27ff350: ConnId=N (ConnName) waiting for latch “Heap[7] – Perm”(27008), Holder=155 (ConnName) PID 10191, now 1016ms

3、waiting for latch “Log Strand Insertion[n]”
告警資訊資訊waiting for latch “Log Strand Insertion[n]“提示LogBuffer的並行度較小，建議調整LogBufParallelism並行度的大小；當然，這裡需要確認一下事務日誌檔案及事務日誌緩衝區的大小配置是否合理。
告警日誌例子：Warn: : 23373: 10118/0x28f8ad0: ConnId=N (ConnName) waiting for latch “Log Strand Insertion[0]“(8390890888), Holder=2038 (ConnName) PID 23379, now 1019ms

4、waiting for latch “Perm Block[n]“和”RefCnt[n]”
這兩個告警資訊，大多時候是因為熱行爭用（類似Oracle的熱快爭用）引起，包括熱行的頻繁讀或者更新過於頻繁。如果是Hash Index組織表，大部分時候由於Hash索引的PAGES引數配置不合理，可以調整PAGES引數緩解。
Hash索引的PAGES引數的計算可以參考：我的另外一篇博文《配置TimesTen記憶體資料庫Hash索引的PAGES引數》
告警日誌例子：Warn: : 23373: 24598/0x7f49700008c0: ConnId=N (ConnName) waiting for latch “Perm Block[160262936]“(160263032), Holder=5 (ConnName) PID 24598, now 1083ms
告警日誌例子：Warn: : 2998: 7350/0xb7ce90: ConnId=56 (ConnName) waiting for latch “Perm RefCnt[901158320]“(901158728), Holder=54 (ConnName) PID 27611, now 1067ms

5、waiting for latch “Index OWNER.TABLENAME”
索引爭用提示資訊，大多時候是由於索引的更新或索引掃描過於頻繁，這個錯誤在T-Tree索引中出現較為普遍，如果是T-Tree索引，這個版本引用了B+Tree索引，Oracle官方建議採用B+Tree索引代替T-Tree索引；如果是Hash Index大多時候是由於PAGES設定不合理引起的，可以使用ttcomputetabsizes計算表中的記錄數進行設定PAGES引數。
TimesTen索引效能測試對比可以參考：我的另外一篇博文《TimesTen索引讀取效率》 http://blog.itpub.net/24930246/viewspace-1414996/。
告警日誌例子：Warn: : 21823690: 27656286/1100db7f0: ConnId=111 (java) waiting for latch “Index ABM.IND_RATABLERESULATOR_ID”(2308680), Holder=211 (cdr_rating) PID 29229074, now 10 secs

6、waiting for latch”Lock Hash Bucket[3918]”
Bucket鎖爭用，這個告警一般都會同時伴隨著waiting for latch “Index OWNER.TABLENAME”或者waiting for latch “Command Dependency”提示告警資訊出現，一般都是由於PAGES引數設定不合理引起的；Bucket的數量是由於PAGES引數設定控制的，官方給出的Bucket的計算方式(PAGES*256)/20，我們可以根據應用更新的特點，適當將PAGES引數調整為稍微比count/256大，分散資料以減少Bucket爭用。
告警日誌例子：2015-01-01 09:40:04.98 Warn: : 21823690: 35651682/11017fbf0: ConnId=344 (dispatch) waiting for latch “Lock Hash Bucket[3918]“(128892388440), Holder=76 (ABM) PID 37683404, now 1 secs

7、waiting for latch “Heap[2] – Temp”
該告警資訊有可能是臨時記憶體空間分配較小，導致臨時排序空間不足，可以透過monitor監控Temp_Size的大小，或者透過dssize觀察Temp_Size高水位使用情況，如果是臨時記憶體空間分配不足，建議調整臨時記憶體空間大小；如果不是由於臨時空間分配不足，該告警資訊一般會伴隨著其他告警資訊同時存在，比如waiting for latch “Command Dependency”提示等，建議先解決waiting for latch “Command Dependency”提示再觀察。
2015-01-01 10:25:06.99 Warn: : 21823690: 25034798/1102b6e30: ConnId=361 (TUXBAL_I) waiting for latch “Heap[2] – Temp”(128849029072), Holder=646 (TUXBAL) PID 36569144, now 1 secs
TangYun(Tony.Tang)2015.01.28

－－－－－－－－－－－－－－－－End－－－－－－－－－－－－－－－－－－－－－－－－－－－

原文連結：

【新炬網路名師大講堂】理解TimesTen錯誤日誌資訊”waiting for latch”

相關文章