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進程優先級的手段是值得嘗試的。