【案例概述】

案例關鍵字：AIX；條帶化；隊列深度；參數調優

系統的底層設計十分重要，很多IT系統建設項目往往只關注項目上層應用開發及上線而忽略了系統底層的規劃與設計，如底層存儲架構設計及參數設置的合理性，這將直接影響上層應用IO性能而導致不可逆的應用瓶頸，往往需要推倒系統后重來才能根本解決問題，下面我們用一個案例來簡要說明一下。

【案例還原】

小L是某醫院資深運維工程師，最近他正在為他所在醫院的某個新上線的系統“捉急”。該系統最近應用一直報卡、慢，特別是業務高峰期，應用反應特別慢，某些操作可能要數十秒乃至分鐘級才能有反饋，極大影響了業務。經過查詢分析后發現，該系統的磁盤IO持續為100%，那為什么IO會如此高？讓我們深入剖析一下。

該院該系統使用的操作系統是AIX 6.1，配套的存儲是XIV，該系統從XIV分配了4個lun ，AIX操作系統識別為hdisk2、hdisk3、hdisk4、hdisk5，并將這4塊hdisk一起分配給了一個oradata的vg，而這個vg分配了lv_data的lv給數據庫作為數據文件的容器，通過nmon監控發現，4塊hdisk的磁盤，只有hdisk2為100%，而其它hdisk為空閑較多，那為什么磁盤工作的時候沒有平衡負載呢？翻看回原來該系統的實施文檔發現，當時創建lv的時候用的命令如下：

經查發現，原來創建lv的時候未加入-s的參數，未對lv進行條帶化，故導致磁盤hdisk無法真正負載工作所致。而且經查詢，磁盤參數的關鍵參數隊列深度queue_depth為默認值1，詳詢該項目當時的實施工程師小W，得到的回復是“因為存儲XIV是全局打散的，已經底層做過條帶化，無需在系統層面再做條帶化，故而沒有加-s參數，至于磁盤隊列深度參數，一般是默認的不修改”。

小L也是認死理的，經過數據庫和系統的全面分析，認定肯定是lv條帶化及磁盤隊列深度參數設置出了問題，故而在XIV重新分配了測試的lun。小L對比了做條帶化和不做條帶化的IO區別以及修改隊列參數值和不修改隊列參數值的區別，很明顯，做過條帶化以及把隊列深度值修改為256的IO性能有質的飛越，這也讓小L更有底氣。最后小L重新部署了環境，在創建lv的時候加入了-s 1M的參數對lv進行條帶化，并且修改磁盤隊列深度參數queue_depth為256，并在上面重新遷移數據庫后，業務恢復正常。

【案例總結】

1.關鍵的底層架構一定要進行合理設計，一些關鍵底層參數可以在系統上線前進行測試,使得底層物理架構環境最優化，免去推倒重來的麻煩；

2.系統項目實施的時候，一定要留存項目實施的所有關鍵文檔，方便在出問題的時候，對一些關鍵操作進行查詢，保障在出問題的時刻能最快速的進行處理；

3.項目實施人員技術良莠不齊，很多實施人員的經驗也不足，故在項目實施階段，應特別關注核心流程核心操作的進展，對事關項目骨干的架構應開會討論，集思廣益，對一些產品如存儲等的特點要刨根問底，避免實施過程中的想當然。