ORACLE TUNE THINKING (三) 操作系統優化

作者簡介：

----------------------------------------------------------------------

@ 孫顯鵬，海天起點oracle技術專家，十年從業經驗

@ 精通oracle內部原理，擅長調優和解決疑難問題

@ 致力于幫助客戶解決生產中的問題，提高生產效率。

@ 愛好：書法，周易，中醫。微信：sunyunyi_sun

@ 易曰：精義入神，以致用也！

@ 調優乃燮理陰陽何其難也！

----------------------------------------------------------------------

概述：

任何軟件都是運行在操作系統上，如果底層操作系統出現性能問題對運行在其上面的軟件影響是極大的。比如操作系統的IO架構存在問題或者物理內存嚴重不足導致應用IO讀寫延遲高，

大量換頁操作消耗更多的IO資源，高的IO延遲又影響了內存換頁操作，大量的上下文切換消耗CPU資源。不健康的操作系統上運行任何軟件都是效率低下的。ORACLE也不例外。我們主

要從三個大的方面對操作系統進行評估，CPU，MEM,IO。那么如何評估呢？那就需要數據，需要借助工具收集數據和量化數據。這里我們以nmon為例講述如何分析三大指標。

(關于nmon工具的安裝使用方法大家自己學習，因為我只能教給你思想，至于具體的操作還希望大家多動手練習。做什么事情都是一樣的，不能紙上談兵。我在培訓時候經常遇到

有的同學講自己聽的很明白了，可是實際遇到問題還是不會處理，技術一定要自己動手操作，不做實驗那是不行的)。

CPU部分：

01.png (73.59 KB, 下載次數: 252)

2018-7-31 17:14 上傳

這個圖是一天的系統負載采集圖

如果CPU使用率非常高，需要確定是誰導致了CPU高。需要關注cpu 平均使用率和最大使用率，是User%占比例高還是Sys%占比高還是Wait%占比高呢？

l SYS部分比例高那就需要確定是否硬件資源不足還是其他問題導致系統部分CPU過高。

l User部分高確定是哪個業務用戶高，比如oracle部分占比高，哪個進程的問題，結合oracle報告分析，latch問題？硬解析問題？還是目前硬件資源不足？

l Wait部分高一般來講可能存在大量等待IO操作，需要分析IO問題

IO部分：

02.png (267.64 KB, 下載次數: 229)

2018-7-31 17:14 上傳

IO 指標需要分析IOPS(每秒IO操作次數)和吞吐量(每秒的IO讀寫大小)。這兩個指標相互影響，如果IOPS高會導致吞吐量降低，反過來吞吐量很大IOPS就會降低。那么到底怎么樣才算合理呢？前提是不要超過IO系統的瓶頸，對于很繁忙的OLTP系統高的IOPS也許是正常的，對于OLAP系統需要高的吞吐量。這個是啟望值也是我們優化的目標。但是實際可能遇到復雜的問題，比如過度索引引起高IOPS，大量小文件操作引起高IOPS等導致系統IO繁忙不能高效工作。

圖表描述了整個系統IO運行狀況。首先解析下該圖：

藍色表示 每秒讀 單位：KB/S

橙色表示 每秒寫 單位：KB/S

黑色表示 每秒操作IO的次數單位：IO/S

21點到08點，系統讀寫較大，高峰值達到300KKB/S，這個值較高，說明IO吞吐量很大，該段時間系統在做備份操作。08點到20點，系統IO操作次數也就是IOPS很高，

當然高的IOPS導致低的吞吐量了。頻繁的小IO導致了大量的IO操作次數必然導致系統處理能力下降。經過分析發現系統需要上傳備份到其他系統，這應該是引起IOPS高的原因。

從下面oracle對IO的收集信息可以明確看到ORACLE對數據文件的操作IOPS貢獻很小：StatisticTotalper Secondper Trans

physical read total IO requests9,584,636666.0547.83

physical write total IO requests1,542,516107.197.70

ORACLE在工作時間貢獻的IOPS大約為900，那么從nmon系統層面看到了IOPS峰值達到了6600左右，這個值是非常高的。也就是說明系統層面引起了大量的io操作，

導致IO層面非常的繁忙，進而導致了oracle數據庫在請求IO時出現部分等待事件。

看看存在IO問題系統TOP 等待

03.png (21.64 KB, 下載次數: 222)

2018-7-31 17:14 上傳

ORALCE給出的經驗值平均IO等待時間20ms以下是合理的，當前大多數存儲是可以滿足該指標。上面采樣數據顯示IO等待太高。需結合操作系統IO數據和存儲廠商的分析數據深入

分析IO層面哪里存在瓶頸。

處理方法建議：

1：優化SQL，消除不必要IO操作。

2：條件允許下隔離生產庫的raid組。

3：購買SSD作為raid組單獨存放熱數據。

4：使用ASM技術。

5：優化磁盤訪問方式，比如只存儲數據在磁盤外道。

內存部分：

04.png (199.54 KB, 下載次數: 230)

2018-7-31 17:14 上傳

上圖描述了操作系統物理內存剩余大小，幾乎沒有可用物理內存供操作系統調用。那么沒有物理內存可用會發生什么？大多數操作系統的內存管理都是相似的，每個進程有自己的虛擬尋址空間，

當物理內存不足進程使用時，操作系統依據替換page算法將最近不使用的page交換出物理內存寫入磁盤(交換空間)，我們知道內存讀寫速度相對磁盤是非常快的，IO操作是系統代價最高操作。我們忽略page置換導致的上文切換繼而產生的CPU資源，只考慮IO性能，磁盤讀取數據代價是非常大的。系統目前物理可用內存幾乎為0，那么就導致了大量的使用交換空間，性能會急劇下降。AIX在換頁空間用完時會kill進程，這是非常嚴重的。

處理方法建議：

1：檢查系統參數是否合理設置，是否存在bug(特別是AIX系統)。

2：購買新內存。

3：降低SGA大小給操作系統預留足夠內存。

總結：

本章主要從三個重要指標講述了操作系統層面優化思路，講述了CPU,IO,內存三部分優化分析思路，提供了對應的優化方案。為什么操作系統優化列在優化最前面呢？

因為操作系統高效工作是保證運行在其上面軟件能高效運行的必要條件。有時候我們經常會忽略檢查操作系統是否配置合理，數據庫存在性能問題或者故障，就一門心思分析AWR、ASH。

就比如中醫治療外感同時內虛寒，這時候你不要管外感問題，應當首先調理內虛寒，內虛寒好了外感自然也就好了。治病有先后順序，外感病如果因為身體內部存虛寒你再怎么治療外感那是

不起作用的。同樣的底層操作系統出現問題了你只關注oracle數據庫的問題那是不會有什么效果的。你比如到客戶現場巡檢也好處理故障也好，第一首選應該檢查操作系統日志，確保底層

沒有故障，然后再看oracle相關指標。這都是經驗，大家一定要注意。當然了操作系統優化方法不只是這三個方面，比如很重要的參數調整，這個希望部署數據庫時依據oracle官方給出的

建議結合實際情況調整即可。其他細節方面比如io調度策略，大頁內存(透明大頁內存)，緩存解析，io隊列深度等等吧遇到問題依據oracle建議和各廠家建議調整。優化調整一定要有依據，

不能隨便自己想。

總結

以上是生活随笔為你收集整理的oracle读写队列深度,ORACLE TUNE THINKING (三) 操作系统优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。