在現場發現自己負責程式中資料載入很慢,於是將對應的SQL拿出來放到達夢客戶端執行,發現一天中的大部分時間都很慢,只有在早上9點多左右的時候會比較快,快的時候在一秒之內,慢的時候有時達到十幾分鍾,甚至直接報報錯,如下圖1所示: 圖1 對應的SQL該加的索引也都有,資料表也根據月份進行了分割槽,何況在執行快的時候在0.6秒左右也還可以,於是想是不是其它原因導致執行變慢了,於是有了以下的探索。 V$SESSIONS檢視查詢找對該SQL的sess_id:

select sess_id,sql_text 
from V$SESSIONS 
where state = 'ACTIVE';

找出對應SQL的sess_id後,根據再進行V$SESSIONS檢視(語句級資源監控)查詢該SQL語句的sess_id,SQL語句如下:

select S.* 
from V$SQL_STAT S 
INNER JOIN V$SESSIONS SE ON S.SESSID = SE.SESS_ID 
WHERE S.SESSID = '139454492043355';

結果如下圖2所示: 圖2 IO_WAIT_TIME即I/O等待時間是857846毫秒,14分鐘多,也就是說SQL執行中的時間基本上都浪費在I/O等待中了。 這是從檢視監控方面得出的結論,接下來從連線DM伺服器查詢伺服器的效能來進行檢視。 通過iostat -d -x -k 1 10 命令查詢(查詢磁碟使用情況的詳細資訊,以KB為單位,每秒重新整理一次,共重新整理10次),截圖部分如下圖3所示: 圖3 輸出資訊的含義如果有興趣大家可以在網上進行查詢,以下主要介紹await、svctm、%util三個指標: await： 每一個IO請求的處理的平均時間（單位是毫秒）。此處理解為IO的響應時間，一般地系統IO響應時間應該低於5ms，如果大於10ms就比較大了。這個時間包括了佇列時間和服務時間，也就是說，一般情況下，await大於svctm，它們的差值越小，則說明佇列時間越短，反之差值越大，佇列時間越長，說明系統出了問題。 svctm ：表示平均每次裝置I/O操作的服務時間（以毫秒為單位）。如果svctm的值與await很接近，表示幾乎沒有I/O等待，磁碟效能很好，如果await的值遠高於svctm的值，則表示I/O佇列等待太長， 系統上執行的應用程式將變慢。 %util： 在統計時間內所有處理IO時間，除以總共統計時間。例如，如果統計間隔1秒，該裝置有0.6秒在處理IO，而0.4秒閒置，那麼該裝置的%util = 0.6/1 = 60%，所以該引數暗示了裝置的繁忙程度。一般地，如果該引數是100%表示裝置已經接近滿負荷運行了（當然如果是多磁碟，即使%util是100%，因為磁碟的併發能力，所以磁碟使用未必就到了瓶頸）。 通過以上兩個方面可基本判定磁碟I/O等待時間過長,裝置已經接近滿負荷運行了,此時與與SQL優化已經沒多大關係了。 接下來看達夢庫服務的記憶體佔用情況與伺服器的記憶體剩餘情況,如下圖4和圖5所示: 圖4 由上圖4可以看出DM服務佔用的CPU使用率是138%,記憶體使用率是76.1%,佔用的記憶體大小為25076020KB即將近24G。 接下來通過top -H -p 20589(達夢服務PID號)來進行查詢。 圖5 由上圖5可以看出伺服器的實體記憶體共約32G,大部分已被使用,只剩下兩百多兆的實體記憶體空間空閒。 開啟達夢效能監視工具monitor.exe,如下圖6和圖7所示: 圖6 圖7 由上圖6中的第二張圖可以看出CPU經常屬於滿荷負載狀態,從圖7的記憶體配置嚮導對話方塊職工可以看出資料庫伺服器的實體記憶體空閒的只剩下283兆;從圖6第一張圖看資料庫記憶體的使用大約不到2G多一些,這點和根據從V$MEM_POOL(顯示所有的記憶體池資訊)查詢進行側面驗證,SQL如下所示:

SELECT SUM(total_size) as totalS,sum(data_size) as data_sizeS,count(1) as countS
FROM V$MEM_POOL 
 

執行結果如下圖8所示: 圖8 其中TOTAL_SIZE欄位為當前總大小,以位元組為單位;DATA_SIZE為當前分配出去的資料佔用大小,以位元組為單位.DATA_SIZES值大約為2G多,兩者相差不大。 通過以上的分析可以得出該SQL慢的原因主要是裝置已經滿負荷執行,I/O等待時間過長所導致。此處一方面的解決辦法是加大記憶體或建立叢集進行主從同步,讀寫分離,更重要的是要查詢佔用記憶體過大的SQL,對其進行優化,畢竟記憶體的擴充是有盡頭的，不可能無限制擴充,讀寫分離也只是減輕了一部分負擔,隨著服務執行時間的日積月累,這種問題還會繼續出現!