一次HIS系統卡頓原因排查過程分享

一、問題描述

8月20日11點左右，接到某三甲醫院資訊科工程師反饋HIS、CIS明顯示卡頓。

二、問題排查

1、 資料庫伺服器排查

資料庫伺服器總記憶體172G, 分配到資料庫記憶體150G，當前使用記憶體數量112G，記憶體使用＜分配記憶體，記憶體充足。

資料庫指標引數頁預期壽命（Page Life Expectancy ） 20秒左右，遠低於應有的頁面預期壽命11250s（150G/4G*300s=11250s）。

一個小tip：Page Life Expectancy 指記憶體頁面在記憶體中停留的平均時間，是記憶體壓力判斷的一個重要參考值。 過去系統受32bit限制，記憶體只有4G，Page Life Expectancy的頁預期壽命是300s。現在伺服器系統是64bit，伺服器記憶體遠大於4G，頁面預期壽命計算公式是伺服器記憶體大小/4G*300秒。比如服務記憶體是64G，分配給Sql Server最大記憶體（上述Max Server Memory）是60G，那麼PLE的參考值就是60/4*300=4500S，大概是75分鐘，也就是說，最低限度是每75分鐘，記憶體中的資料跟磁碟做一次完整的交換。

（記憶體充足?）

（指標引數頁20s左右?）

2、 SQL指標引數

SQL Server的指標引數每秒超時鎖請求數（Lock Timeouts/sec_rate） 超出閾值。鎖等待時間是一個程式花費在等待另一個程式釋放鎖的時間。每秒超時鎖請求數理想狀態0，從下圖可一看到超時鎖偶爾會達到1000個以上，說明SQL Server資料庫有資源瓶頸。

3、 磁碟響應值

業務卡慢時出現磁碟響應值和磁碟佇列值都很高。正常磁碟響應應該在50毫秒以內、磁碟佇列在1以內。

4、 資料庫服務版本

當前資料庫伺服器的版本是SQL SERVER 2012 SP1商業智慧版，伺服器物理CPU是32核，但商業智慧版最多隻能用到16核CPU。

三、問題分析

透過資料庫伺服器指標引數分析可見：

1、 快取有壓力

導致記憶體和磁碟之間的資料頁面交換非常頻繁，導致IO讀寫量增大。

2、 磁碟本身存在IO瓶頸，這使情況變得更糟

歸根到底要看SQL語句是不是能夠進一步最佳化。儘量減少造成大量的物理讀寫。

3、 資料庫版本限制CPU資源分配，需要版本升級。

四、處理措施及建議

1、檢查磁碟效能響應時間高的原因，伺服器本身磁碟是否存在其它大的讀寫，比如CDP磁碟映象。

2、檢查伺服器虛擬排程是否正常，排查記憶體快取問題。

3、升級資料庫伺服器序列號為Microsoft SQL Server Enterprise: Core-based Licensing (64-bit),保證資料庫伺服器能用到全部CPU。

4、將tempdb資料庫移到D盤，當前資料庫檔案存在C盤，可用空間不多，會存在異常導致磁碟用完的風險。

5、最佳化SQL SERVER查詢慢的指令碼，連結伺服器大表查詢增加查詢限制。介面查詢建議改成標準的介面不要直接連結伺服器查詢檢視。

宣告：文案&圖片為原創內容，轉載請註明。

聯絡我們：電話 400-828-1855。