IBM小機+ORACLE資料庫迅猛提升事物數TPS的方法總結:近期一直在搞業務壓測,提升系統的交易處理能力。交易處理量從剛開始的三千到如今的接近一萬,也積累了一些最佳化方法,分享給各位。首先當然需要你的系統是處理大並發事務的,如果你的系統每秒TPS才一兩百,可能事務最佳化並不是主要的目的。這裡一共包含兩個部分的最佳化手段,第一部分是常規的最佳化手段,第二部分是稍微“邪門”點的最佳化手段。
大並發事務常規的最佳化手段:
1)REDO LOG 盤最佳化:如果是放在儲存,可以多拿出幾塊盤來做LOG 盤,最基本的常識盤要做成RAID 10,不能放RAID 5。根據你盤的情況,可以用6-12塊盤不等。這些 盤專門提供給REDO LOG用,剩餘的空間也不能提供給其他盤用,以免影響LOG 盤的IO。由於儲存一般都帶有CACHE,CACHE的大小根據高低中端的不同,儲存型號的不同而不同,儲存的CACHE可以說是儲存的靈魂,對於寫緩衝的效果非常明顯,極大的降低寫LOG盤的時間。
2)資料盤的IO要根據你系統的情況來,根據作業系統工具topas -D或iostat -DlRa 1 來看資料盤存不存在瓶頸,如果busy比較大,那麼需要繼續添加硬碟來提升IOPS。事務型的交易系統資料盤的繁忙主要是寫髒資料造成的可能你的情況跟我不一樣),一般對IOPS要求不高。這個要根據系統情況來定。IOPS不夠,可以考慮用SSD來提升IOPS,但是儲存對SSD的支援不太好,最好讓SSD的IO可以打散在儲存的多個光纖環路中。
3)ORACLE 的GROUP COMMIT是自動、預設的行為,這塊其實不用作最佳化也沒法做最佳化。
4)對關鍵業務表設定了CACHE屬性,保證事務的資料都在記憶體裡。這一塊的最佳化也非常重要,最佳化效果也非常明顯。ORACLE裡可以設定CACHE表。
當時壓測是基於P740的一個小機+V7000的一個中端儲存,做完以上最佳化,TPS可以達到6000。
非常規手段的最佳化:
1)由於P740隻有物理16core cpu,CPU使用率到了65%,LOAD 接近40。為了LGWR可以任意時刻擷取CUP資源,設定了_high_priority_processes 參數,保證LGWR可以隨時獲得CPU資源,不用排隊。
2)作業系統層級設定dscrctl -n -b -s 1 記憶體預讀,效果非常明顯,立即可以提升1000+的TPS
3)如果你是萬兆網卡,chdev -l hba0 -a cdli_queues=4 -P,加大網卡處理隊列,效果也非常明顯,可以提升1500+的TPS。事物數超大的系統,網卡往往是瓶頸,最佳化非常必要。及時你的3個千M網卡處理量還完全沒到瓶頸,可是使用萬兆網卡做了這個最佳化,還是非常的能看到立竿見影的下效果。
4)ORACLE的REDO LOG 塊大小設定為4K.11GR2的版本可以指定REDO LOG的塊大小,一般是磁碟的扇區大小512位元組。在我的版本11.2.0.3下修改會報錯,說修改值與實際扇區大小不匹配。通過修改隱含參數_disk_sector_size_override為true,可以強制改成功。修改的辦法是在alter database add log file xxxx blocksize 4096。如果拿PL/SQL壓測,採取commit write immediate wait方式提交,最佳化前後的差距接近4倍,非常驚人。但是拿我們的業務壓測,只是提升了1500+的TPS,也非常的不錯了。
經過上面4步的最佳化,TPS可以接近1W了。在此分享,希望對大家有協助,很多地方說的不詳細,有需要,可以聯絡我,進一步探討。
P740,16core 3.55GHZ的記憶體,32G CPU,3塊千M網卡BOND。
V7000 80G 的CACHE。12塊LOG 盤。足夠多的資料盤。
本文出自 “魏興華的DBA生活” 部落格,請務必保留此出處http://dwrose.blog.51cto.com/1067952/1102041