高併發高負載狀況下常見的3種性能問題

這篇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啓動，跑一些統計分析的腳本時，出現大量的內存換頁。