LOG FILE SYNC概述（第四篇）

LOG FILE SYNC調優

作為通用的log file sync的診斷、調優方法，一般可以透過診斷系統的IO延遲為多大，CPU資源是否充足來判斷哪裡出現了問題。

IO延遲的診斷、調優

糟糕的IO效能往往是log file sync過高的罪魁禍首，DBA應該儘量把重做日誌放在單獨的IO裝置上。雖然lgwr可以使用非同步IO，但是日誌檔案開啟的時候帶有DSYNC標誌，日誌必須被重新整理到磁碟，commit操作才能返回（如果主機有RAID卡，則要重新整理到RAID卡的CACHE中，如果使用的是儲存，則要重新整理到儲存的CACHE中）。可以透過log file parallel write這個後臺程式等待事件來輔助診斷log file sync等待時間過大的問題。如果log file parallel write等待時間過大，那麼你係統的IO很可能出現了問題，但是就像我前面提到的，log file parallel write過大也可能是由於需要寫入的日誌量過大導致的。最佳化IO的手段一般為：RAID的方式不要使用RAID5，最好為RAID10，如果使用PC本地盤，那麼關閉RAID卡的讀CACHE，全部用作寫CACHE，如果使用的是儲存，可以用2-4塊盤做raid10作為日誌的磁碟組，對於中高階儲存，一般儲存機頭的CACHE也比較大，IO效能基本能得到保障。

可以嘗試使用SSD來存放Oracle的重做日誌檔案，雖然業界不太推薦使用，但是隨著SSD對於寫放大演算法的最佳化、Wear leveling、Over-provisioning、GC策略的不斷成熟，DBA可以嘗試把重做日誌放在SSD裝置上來提升IO效能。使用SSD存放重做日誌的時，最好使用大廠商的SSD產品，如果預算沒問題推薦選擇SLC型別的SSD，並且在SSD盤上為日誌預留足夠多的空閒空間，因為對於SSD產品來說，預留空間越多，SSD的壽命也會越長，效能相對也會越好。

CPU資源的診斷、調優

如果CPU資源非常緊缺，Lgwr獲得不了CPU資源，會導致系統呼叫變慢，增加log file sync的等待時間，就像我們上面提到的，system call、訊號量、IO call都依賴著CPU資源。如果log file sync的時間與log file parallel write的時間差異過大，則可能系統的CPU資源出現了不足。solaris下還可以透過作業系統工具prstat來診斷lgwr程式的cpu排程延遲時間。其他平臺不能直接針對程式進行跟蹤診斷，可以透過系統LOAD，CPU使用率來輔助診斷，如CPU使用率超過百分之六十可能就會造成一定程度的排程延遲、CPU執行佇列超過邏輯CPU的CORE數就有排程延遲的風險等等。系統的CPU資源出現瓶頸是比較棘手的，因為換硬碟相對來說並不是件麻煩事，但是換CPU就不同了，其難度一般會比較大，最終可能的結果就是換主機。不過也有一些手段可以嘗試，例如調高LGWR的優先順序，可以透過資料庫引數_high_priority_processes進行，或者作業系統命令renice命令進行（前者可能更好點），如果系統CPU非常富足，也可以考慮用taskset等工具為Lgwr程式設定一個獨佔的CPU（core）。

調優應用

有時候更為有效的手段可能不是拼命的調優資料庫、調優硬體，比如：是不是可以合併事務，也就降低了LOG FILE SYNC的次數，變相的提高了系統事務的效率。但是為了提升系統的事務數，而去犧牲業務的完整性，需要仔細思考是不是需要這麼做，這樣做是不是有什麼風險。如果在不犧牲業務完整性的情況下，可以合併一些事務，那麼起的效果還是立竿見影的。

資料庫調優

l 透過減少事務的日誌量可以減輕lgwr的工作量，如：減少不必要欄位的更新,減少不必要的索引，不使用CLOB欄位等等。

l 減少日誌組內的member數量。一般生產環境都會為日誌組的每個member保留2份副本，儲存於不同的磁碟或者儲存上。如果有可能，可以減少日誌組內的member數量，減輕Lgwr的工作量。

l 像備庫傳送日誌採用非同步模式。

記憶體調優

在AIX下，如果開啟記憶體預讀，對於提升TPS也是非常的明顯 dscrctl -n -b -s 1 。還有要密切關注系統的記憶體使用狀況，如果系統出現SWAP,lgwr非常可能被paged out，也會導致lgwr響應非常慢。

上述提供了一些調優log file sync的思路，但是隨著系統併發事務數的增多，可能lgwr並不能足夠快的去通知大量等待提交的程式。雖然在這個時候，並沒有出現CPU資源出現不足，IO也足夠快了，但是lgwr工作起來還是慢。上面我已經提到了，在lgwr完成工作後需要通知等待提交的程式，告訴它們提交已經完成，可以幹其它事了。如果等待提交的程式過多，lgwr的工作就會越多，相應的延遲就會越大。而且如果有大量程式在等待log file sync，一旦lgwr寫完成，它將通知這些程式甦醒，使它們重新進入CPU執行佇列，這個情形下，由於lgwr已經工作了一段時間了（已經佔用了很多的CPU時間了），而前臺程式已經等待了一段時間了（等待LOG FILE SYNC)，根據作業系統的預設的排程策略，這種情況下，前臺程式將會有更高的優先順序獲取CPU資源，而lgwr將可能由於CPU資源突發式的緊張而沒有獲取到CPU資源，導致系統的事務數有抖動，突然有很大的降低。因此我前面所建議的調高LGWR程式優先順序的手段是值得嘗試的。