KDB和Oracle的效能pk小記

jeanron100發表於2015-08-30
在偶然的機會聽到了KDB,然後帶著好奇和新鮮感體驗了一把這個傳說中和Oracle 相似度達到99%的資料庫。
其中一部分的驅動力在於這個活動的獎品很豐厚,參加活動後可以拿到一個iwatch,確實是很划算的一個活動。
而對於KDB的認識,也是在對比調優中認識到的,其實結果還是大大超出我的預期。
首先來簡單說一下背景,我們一共十來個人,分成兩隊,紅隊和藍隊,然後紅隊調優Oracle,藍隊調優KDB,然後使用benchmark在同樣的加壓條件下的tpcc值作為參考來對比Oracle和KDB
乍一看Oracle這邊的人很佔便宜,至少調優的基準和方式方法感覺都是熟悉的,不用過多的花時間在熟悉KDB上面,而對於KDB這部分,其實我覺得還是佔有一定的優勢,因為兩隊都有專門的人來提供額外的資訊諮詢,原廠在這方面其實更有說服力,更有經驗,支援力度更大,這個調優的玄妙之處就在於我們除錯的Oracle系統是一個效能很差的一個環境,裡面其實還是埋了不少的機關,需要在有限的時間裡把tpcc的值跑上去。
所以分組之後大家簡單做了分工,最開始我的腦海中的調優思路是核心調優,引數調優,檔案調優,sql調優
結果一上來開始還是有些著急,其實大家的思路最後都是花更多的時間在資料庫引數調優上了。
我本來準備先檢視hugepage準備先檢視一下,看沒有調優的空間,結果一看aix的小機環境,配置不同,x86上的方式就不管用了,於是就果斷放棄了,這個部分還是要好好補補。
大家抓取效能瓶頸的時候基本大致的一致是sga的部分,結果一時忽略了其實undo的部分是個硬傷,結果回過頭來,調整的時候對方的tpcc已經遠遠領先我們了。這個時候我們所做的調優基本就是設定commit_write為nowait方式,然後調整sga_max_size,sga_target,然後一邊開始準備線上調整redo的大小,把原本的redo 50M的日誌檔案加大到百兆,
抓取的addm報告中更多的是sql語句的調優建議,所以暫時沒有深究。
所以第一階段和第二階段的調優對比效果還是不理想的。
這一輪下來,大家計程車氣也受到了影響,我們認真梳理了一下,在引數的調整上有幾個層次,
隱含引數
我發現在資料庫引數中埋了一個炸彈,就是把一個隱含引數給啟用了,引數是_fast_cursor_reexecute而這個引數的預設值是false,所以簡單評估之後就把這個值恢復了預設的值
在sga的調整上給了30G的sga,但是檢視記憶體元件的使用情況,shared pool被壓縮到了不到2G,在200多G的記憶體條件下,就把shared_pool的大小設定保持在10G以上,
pga的部分也進行了調整,把pga的大小進行為了一定的調整。
open_cursors的值太低,在1000個併發的條件下,當時的值是300,所以跑不上去,session_cached_cursors的值也比較低,做了小幅度的調整
audit_trail的部分是DB,其實這個部分暫時還沒有這個需求,在這種情況下審計部分的開銷就不必要了,果斷去除,設定為none
對於非同步io的設定,filesystemio_options設定為setall,嘗試啟用非同步io和direct io
還有一個坑就是sql_trace給開啟了,果斷禁用。
對於sql cursor的解析方式,大家還是建議改為similar,這部分也修改了。
在曹組系統級,大家把原有的CPU超執行緒設定給取消了。原來是4個,改為了預設的2個。
等大體這幾個部分完成之後,再去跑分,發現和KDB組的成績很接近了,一段時間還暫時超過了他們,這個時候才感覺到了一絲動力。
繼續調整,抓取的awr報告顯示還是存在一定的併發瓶頸,有一些row lock contention,在這個時候我檢視了相關的幾個表的ini_trans,還是原來的預設值,就簡單進行了調整,把ini_trans調大。
後面的部分,在這個基礎上再進行調優,大家就相對比較謹慎了,大家糾結比較多的一個地方就是redo的大小,甚至考慮要把它設定為一個極大的值,根據監控的情況,在過去的一個小時內redo切換次數在7次左右,還是可以進行小幅度的調整即可,不過後來大家大膽嘗試的把redo設定為一個極大的值,效果反而還是不夠理想,所以就果斷放棄了。後面的更多精力就沒有放在sql語句上,等到發現的時候時間已經不夠了,發現其中一個效能瓶頸在於一個slelect max(xxx) from xxx的查詢,其實完全可以在關注更多的細節,比如收集統計資訊,比如檢視index的設定情況,對面的KDB組還甚至考慮了對錶進行重新分割槽,這些細節的調整還是有很大的作用的,非常值得肯定。這些額外的細節和加分點也著實為KDB的tpcc貢獻了一部分分數。
最後Oracle和KDB的第三輪跑分結果比較相似,tpcc都在近9萬,KDB略微要高一些,浪潮團隊的之前的測試結果也基本和這個差不多,瞭解了KDB和其它資料庫的對比測試,跑分的差距還是很大的,KDB的效能還是很高。對於這次最佳化精力我的總結還是在粒度和細節上功夫下的不夠,在調優的方法和方式上,還是需要先從整體再到細節部分,不忽略每一個部分潛在的可能的效能問題。逐步深入,調優的改進之處就會更加有條理。
這種調優方式對我的感觸還是很大,因為這種對比pk的方式感受更加直觀,對我們分析問題和解決問題是一個非常真實的案例。沒有了基準和對比的參考,我們調優的幅度和動力就不會完全發揮出來。看來這種pk的方式可以多推廣推廣,也非常感謝浪潮本著開放的態度來組織這次活動,無論熟悉還是不熟悉KDB的朋友都會有一些認識和了解,因為時間關係,在叢集,容災,管理方式上還沒有進行深入的測試,不過相信結果應該也不賴,相信他們的技術團隊在這次活動之後,也經受了很大的壓力和考驗,可以好好休息一下了。再次感謝。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-1786927/,如需轉載,請註明出處,否則將追究法律責任。

相關文章