IBM v7000 儲存 pv引數queue_depth 為1 引起的IO問題
mos上一篇文章127
5596.
1
AWR報告顯示平均IO時間過長,因為年初換的儲存,
分析是儲存上存在問題。
作業系統上看topas
Topas Monitor for host: nc_database EVENTS/QUEUES FILE/TTY Tue Nov 25 15:51:32 2014 Interval: 2 Cswitch 4315 Readch 14.2M Syscall 17724 Writech 149.3K Kernel 2.3 |# | Reads 1075 Rawin 0 User 21.5 |####### | Writes 324 Ttyout 354 Wait 39.0 |########### | Forks 2 Igets 0 Idle 37.3 |########### | Execs 1 Namei 276 Runqueue 1.0 Dirblk 0 Network KBPS I-Pack O-Pack KB-In KB-Out Waitqueue 0. en0 241.0 372.5 332.1 79.3 161.7 lo0 0.1 1.0 1.0 0.0 0.0 PAGING MEMORY en1 0.0 0.0 0.0 0.0 0.0 Faults 3230 Real,MB 31616 Steals 0 % Comp 85.5 Disk Busy% KBPS TPS KB-Read KB-Writ PgspIn 0 % Noncomp 0. hdisk7 84.4 41.3K 668.7 41.3K 4.0 PgspOut 0 % Client 0. hdisk8 99.9 2.5K 295.6 2.3K 268.2 PageIn 0 hdisk6 0.5 386.0 5.5 8.0 378.0 PageOut 0 PAGING SPACE hdisk9 0.0 236.2 2.5 0.0 236.2 Sios 0 Size,MB 32768 hdisk10 0.0 0.0 0.0 0.0 0.0 % Used 3.3 hdisk11 0.0 0.0 0.0 0.0 0.0 NFS (calls/sec) % Free 97.7 hdisk 0 0 0.0 0.0 0.0 0.0 ServerV2 0 cd0 0.0 0.0 0.0 0.0 0.0 ClientV2 0 Press: hdisk4 0.0 0.0 0.0 0.0 0.0 ServerV3 0 "h" for help hdisk5 0.0 0.0 0.0 0.0 0.0 ClientV3 0 "q" to quit
queue_depth為1
參考----
設定queue_depth
在AIX環境中,正確設定FAStT 邏輯磁碟的佇列深度(queue_depth)對系統效能非常重要。 對於較大的FAStT配置,有許多卷和主機連線,這個設定對高可靠性來講就更加關鍵。佇列深度太大會導致檔案系統的丟失或主機當機。下面介紹瞭如何正確設定磁碟的佇列深度及其計算方法。
我們可以使用如下的公式來決定最大的佇列深度:
512 / (主機數 * 每個主機的LUN數 )
例如一個系統有4個主機, 每個有 32 LUNs (這是每個AIX主機的最大LUN數), 那麼最大佇列深度應該是4:
512 / ( 4 * 32 ) = 4
這時,你應該把hdiskX 的queue_depth 屬性設為如下:
#chdev -l hdiskX -a queue_depth=4 -P
可以使用iostat -D檢視
其中sqfull表示自系統啟動以來queue_deeth超出的次數
IBM工程師建議queue_depth的值在40-128之間
如何設定:
queue_depth引數會影響disk i/o效能,特別是在資料庫等i/o密集性應用中。適當調整設定此引數,會提高整體應用的效能。下面是在AIX 5.3,IBM ds4300上調整此引數的步驟及注意事項,記錄一下。
下面物理磁碟hdisk2是基於IBM儲存上的,做的raid 5,此盤屬於vg datavg中。
一,首先備份datavg.在生產環境作任何調整,一定要切記安全第一,備份是必不可少的。
#smit savevg
二,檢視所需修改的hdisk2上queue_depth的值。
#lsattr -El hdisk2|grep queue_depth
三,首先umount datavg上的檔案系統。
#umount /u2
四,vary off vg。
#varyoffvg datavg
五,刪除磁碟hdisk2.
#rmdev -l hdisk2
六,修改磁碟hdisk2 queue_depth引數.
#chdev -l hdisk2 -a queue_depth=16(此值為所需修改的具體queue_depth值) -P
七,增加磁碟hdisk2.
#mkdev -l hdisk2
八,vary on vg.
#varyonvg datavg
九,mount datavg上檔案系統
#mount /u2
十,最後檢視一下queue_depth引數是否修改成功。
#lsattr -El hdisk2|grep queue_depth
如上面檢視queue_depth值已變成所需值,則整個過程完成。如有條件,最好能重啟一下機器。應注意的是此值如設定不合理,可能會導致系統hang住,或當機現象。
本人曾親自踫到由於此值設定過大,導致系統出現異常,init程式始終佔用cpu在20%左右,
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29990276/viewspace-1346318/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- LMT下表儲存引數的使用
- mysql儲存過程的引數MySql儲存過程
- PHP 編譯引數儲存PHP編譯
- SAS 數值儲存方式和精度問題
- js中的儲存問題JS
- 華為雲物件儲存OBS,助力企業高效解決儲存問題物件
- v7000儲存硬碟離線如何恢復資料硬碟
- DataFrame儲存為hive表時的換行符問題Hive
- 如何解決M1 Mac使用photoshop液化、儲存為web格式黑屏的問題?MacWeb
- M1 Mac使用photoshop液化、儲存為web格式黑屏問題的處理方法MacWeb
- Redis儲存物件問題Redis物件
- 【答疑】物件儲存OSS常見問題解答(工具類1)物件
- LOG巨集的引數問題
- LMT和DMT下儲存引數的異同(轉)
- 記一個 Android 14 適配引發的Android 儲存許可權問題Android
- 【答疑】物件儲存OSS常見問題解答(諮詢類1)物件
- 二維陣列作為引數傳遞問題陣列
- Kylin儲存和查詢的分片問題
- mysql多次呼叫儲存過程的問題MySql儲存過程
- 由分號引起的問題
- 關係等級儲存問題
- V7000儲存兩塊硬碟掉線資料恢復成功案例硬碟資料恢復
- MySQL儲存過程的許可權問題MySql儲存過程
- iOS 靜態庫-因為CPU架構引起的小問題iOS架構
- go 如何呼叫 sqlserver 帶傳出引數的儲存過程GoSQLServer儲存過程
- jmeter使用問題——將介面返回變數儲存成csv檔案JMeter變數
- 儲存過程訪問其他使用者的表的問題儲存過程
- 儲存篇(1)
- 【Java小疑問】java變數儲存的位置(雜)Java變數
- vue 新增axios解決post傳引數為null問題VueiOSNull
- 解決MongoDB儲存時間時差的問題MongoDB
- 雲端儲存目前面臨的3個問題
- k8s使用emptyDir,hostPath,nfs,pv,pvc做儲存K8SNFS
- kubernetes儲存類與PV與PVC關係及實踐
- kubernetes實踐之二十五:儲存卷 PV&PVC
- 儲存過程vs.動態SQL:如何選用?PV儲存過程SQL
- 一個RESOURCE MANAGER引起的問題分析
- 故障分析 | show processlist 引起的效能問題
- 達夢儲存過程效能問題定位儲存過程