這篇blog是基於處理oracle資料庫效能問題的經驗寫就,它是對常見的效能問題做的總結,它的適用範圍: 高併發高負載的系統. 需要先申明的是: 對於所有的調優的方法,都是有適用範圍的; 所以下面提到的所有的內容,請” 批判性”閱讀.

1. OS swapping/paging 引發的資料庫concurrency方面的效能問題

Oracle資料庫在工作的時候, 對於latch/mutex這樣的輕量級的”鎖”,我們期望它是可以非常快的獲取/釋放的(這些操作都是對記憶體的操作,而記憶體的操作正常時候也確實都是很快的). 但是如果OS發生了大量的swapping/paging的情況下,那麼對記憶體的操作會變慢,那麼latch/mutex的操作就會變慢,在併發大的情況下就會發生hung/slow的情況.

引發swapping/paging的常見情況有:

a). 記憶體短缺

b). 記憶體並不短缺; 但短時間內, 有大量的新程式分配了很多記憶體

c). 複製大檔案/備份資料庫使得作業系統的高速檔案快取突然激增

對應的調優方式:

Lock SGA, 這樣SGA(相應的latch/mutex)就會被pin在記憶體裡而不受swapping的影響.

如果在SGA很大的情況下,同時使用large page(hugepage)技術,減少latch/mutex獲取/釋放的時間.

2. SGA resizing引發的資料庫效能問題

在AMM/ASMM記憶體自動管理的機制下, shared pool和buffer cache及其它幾個component可以根據需要自動調整大小,避免ora-4031的錯誤.但是在高併發的情況下,短時間內頻繁的resize的過程會使得一些記憶體操作(如latch/mutex的獲取釋放)的時間變長, 有很大機率觸發各種latch/mutex爭用. 而且如果shared pool被resize時減少的太多,那麼latch/mutex的爭用也會加劇.

引發這種問題的原因:

有些是因為bug; 但是從深層次的角度考慮,這種resize的操作不可避免的會對效能有影響,只是影響的程度不同罷了. 而且bug的fix也只是減緩這種操作的impact, 而不能完全避免這種影響.

推薦的調優方式:

1). 設定buffer cache和shared pool的值(在記憶體自動管理的情況下,這個值會作為最小值)

2). 設定resize的頻率不能少於16分鐘

alter system set "_memory_broker_stat_interval"=999;

Disable AMM/ASMM也可以作為一個方法,但是缺點是: 碰到ora-4031的機率會比自動記憶體管理大.

3. DDL引發的資料庫效能問題

這種情況只發生在高併發高負載的情況下.

對於一個使用頻繁的表做DDL (比如grant, 修改表定義, 收集統計資訊等等),那麼用到這個表的所有的SQL語句都會被invalidate掉;如果使用這個表的SQL語句很多並且執行頻率很快,那麼在短時間內需要hard parse 的 SQL語句就會很多. 這就變成了一種 “hardparse storm”, latch/mutex的爭用就不可避免, 還有library cache lock/row cache lock也會變多; 嚴重的時候資料庫就會slow/hung.

推薦的調優方式:

不要在負載高的時間段做DDL

案例：

記得有一次一個系統遇到嚴重的記憶體換頁，但是實體記憶體還是有很大的空閒。

後面查到的原因是，未對作業系統oracle做使用記憶體最大的配置
即未在/etc/security/limits.conf中配置
oracle hard memlock ×××
oracle soft memlock ×××
，導致oracle使用者只能使用預設的32k記憶體，從而當一些job啟動，跑一些統計分析的指令碼時，出現大量的記憶體換頁。

高併發高負載情況下常見的3種效能問題

相關文章