1. 程式人生 > >磁碟IO過高 處理辦法

磁碟IO過高 處理辦法

主要命令:echo deadline > /sys/block/sda/queue/scheduler

注:以下的內容僅是提供參考,如果磁碟IO確實比較大的話,是資料庫,可以進行讀寫分離或者分庫操作,減小磁碟壓力,檔案的話,可以利用raid來減輕壓力

一)I/O排程程式的總結:

1)當向裝置寫入資料塊或是從裝置讀出資料塊時,請求都被安置在一個佇列中等待完成.
2)每個塊裝置都有它自己的佇列.
3)I/O排程程式負責維護這些佇列的順序,以更有效地利用介質.I/O排程程式將無序的I/O操作變為有序的I/O操作.
4)核心必須首先確定佇列中一共有多少個請求,然後才開始進行排程.

二)I/O排程的4種演算法

1)CFQ(完全公平排隊I/O排程程式)

特點:
在最新的核心版本和發行版中,都選擇CFQ做為預設的I/O排程器,對於通用的伺服器也是最好的選擇.
CFQ試圖均勻地分佈對I/O頻寬的訪問,避免程序被餓死並實現較低的延遲,是deadline和as排程器的折中.
CFQ對於多媒體應用(video,audio)和桌面系統是最好的選擇.
CFQ賦予I/O請求一個優先順序,而I/O優先順序請求獨立於程序優先順序,高優先順序的程序的讀寫不能自動地繼承高的I/O優先順序.


工作原理:
CFQ為每個程序/執行緒,單獨建立一個佇列來管理該程序所產生的請求,也就是說每個程序一個佇列,各佇列之間的排程使用時間片來排程,
以此來保證每個程序都能被很好的分配到I/O頻寬.I/O排程器每次執行一個程序的4次請求.


2)NOOP(電梯式排程程式)

特點:
在Linux2.4或更早的版本的排程程式,那時只有這一種I/O排程演算法.
NOOP實現了一個簡單的FIFO佇列,它像電梯的工作主法一樣對I/O請求進行組織,當有一個新的請求到來時,它將請求合併到最近的請求之後,以此來保證請求同一介質.
NOOP傾向餓死讀而利於寫.
NOOP對於快閃記憶體裝置,RAM,嵌入式系統是最好的選擇.

電梯演算法餓死讀請求的解釋:
因為寫請求比讀請求更容易.
寫請求通過檔案系統cache,不需要等一次寫完成,就可以開始下一次寫操作,寫請求通過合併,堆積到I/O佇列中.
讀請求需要等到它前面所有的讀操作完成,才能進行下一次讀操作.在讀操作之間有幾毫秒時間,而寫請求在這之間就到來,餓死了後面的讀請求.

3)Deadline(截止時間排程程式)

特點:
通過時間以及硬碟區域進行分類,這個分類和合並要求類似於noop的排程程式.
Deadline確保了在一個截止時間內服務請求,這個截止時間是可調整的,而預設讀期限短於寫期限.這樣就防止了寫操作因為不能被讀取而餓死的現象.
Deadline對資料庫環境(ORACLE RAC,MYSQL等)是最好的選擇.


4)AS(預料I/O排程程式)

特點:
本質上與Deadline一樣,但在最後一次讀操作後,要等待6ms,才能繼續進行對其它I/O請求進行排程.
可以從應用程式中預訂一個新的讀請求,改進讀操作的執行,但以一些寫操作為代價.
它會在每個6ms中插入新的I/O操作,而會將一些小寫入流合併成一個大寫入流,用寫入延時換取最大的寫入吞吐量.
AS適合於寫入較多的環境,比如檔案伺服器
AS對資料庫環境表現很差.

三)I/O排程方法的檢視與設定

1)檢視當前系統的I/O排程方法:

[[email protected] tmp]# cat /sys/block/sda/queue/scheduler 
noop anticipatory deadline [cfq]

2)臨地更改I/O排程方法:
例如:想更改到noop電梯排程演算法:
echo noop > /sys/block/sda/queue/scheduler

3)想永久的更改I/O排程方法:
修改核心引導引數,加入elevator=排程程式名
[[email protected] tmp]# vi /boot/grub/menu.lst
更改到如下內容:
kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet

重啟之後,檢視排程方法:
[[email protected] ~]# cat /sys/block/sda/queue/scheduler 
noop anticipatory [deadline] cfq 
已經是deadline了


四)I/O排程程式的測試

本次測試分為只讀,只寫,讀寫同時進行.
分別對單個檔案600MB,每次讀寫2M,共讀寫300次.

1)測試磁碟讀:
[[email protected] tmp]# echo deadline > /sys/block/sda/queue/scheduler 
[[email protected] tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.81189 seconds, 92.4 MB/s

real    0m6.833s
user    0m0.001s
sys     0m4.556s
[[email protected] tmp]# echo noop > /sys/block/sda/queue/scheduler 
[[email protected] tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.61902 seconds, 95.1 MB/s

real    0m6.645s
user    0m0.002s
sys     0m4.540s
[[email protected] tmp]# echo anticipatory > /sys/block/sda/queue/scheduler 
[[email protected] tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 8.00389 seconds, 78.6 MB/s

real    0m8.021s
user    0m0.002s
sys     0m4.586s
[[email protected] tmp]# echo cfq > /sys/block/sda/queue/scheduler 
[[email protected] tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 29.8 seconds, 21.1 MB/s

real    0m29.826s
user    0m0.002s
sys     0m28.606s
結果:
第一 noop:用了6.61902秒,速度為95.1MB/s
第二 deadline:用了6.81189秒,速度為92.4MB/s
第三 anticipatory:用了8.00389秒,速度為78.6MB/s
第四 cfq:用了29.8秒,速度為21.1MB/s


2)測試寫磁碟:
[[email protected] tmp]# echo cfq > /sys/block/sda/queue/scheduler 
[[email protected] tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.93058 seconds, 90.8 MB/s

real    0m7.002s
user    0m0.001s
sys     0m3.525s
[[email protected] tmp]# echo anticipatory > /sys/block/sda/queue/scheduler 
[[email protected] tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.79441 seconds, 92.6 MB/s

real    0m6.964s
user    0m0.003s
sys     0m3.489s
[[email protected] tmp]# echo noop > /sys/block/sda/queue/scheduler 
[[email protected] tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 9.49418 seconds, 66.3 MB/s

real    0m9.855s
user    0m0.002s
sys     0m4.075s
[[email protected] tmp]# echo deadline > /sys/block/sda/queue/scheduler 
[[email protected] tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.84128 seconds, 92.0 MB/s

real    0m6.937s
user    0m0.002s
sys     0m3.447s

測試結果:
第一 anticipatory,用了6.79441秒,速度為92.6MB/s
第二 deadline,用了6.84128秒,速度為92.0MB/s
第三 cfq,用了6.93058秒,速度為90.8MB/s
第四 noop,用了9.49418秒,速度為66.3MB/s


3)測試同時讀/寫

[[email protected] tmp]# echo deadline > /sys/block/sda/queue/scheduler 
[[email protected] tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 15.1331 seconds, 41.6 MB/s
[[email protected] tmp]# echo cfq > /sys/block/sda/queue/scheduler 
[[email protected] tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 36.9544 seconds, 17.0 MB/s
[[email protected] tmp]# echo anticipatory > /sys/block/sda/queue/scheduler 
[[email protected] tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 23.3617 seconds, 26.9 MB/s
[[email protected] tmp]# echo noop > /sys/block/sda/queue/scheduler 
[[email protected] tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 17.508 seconds, 35.9 MB/s

測試結果:
第一 deadline,用了15.1331秒,速度為41.6MB/s
第二 noop,用了17.508秒,速度為35.9MB/s
第三 anticipatory,用了23.3617秒,速度為26.9MS/s
第四 cfq,用了36.9544秒,速度為17.0MB/s

五)ionice

ionice可以更改任務的型別和優先順序,不過只有cfq排程程式可以用ionice.
有三個例子說明ionice的功能:
採用cfq的實時排程,優先順序為7
ionice -c1 -n7  -ptime dd if=/dev/sda1 f=/tmp/test bs=2M count=300&
採用預設的磁碟I/O排程,優先順序為3
ionice -c2 -n3  -ptime dd if=/dev/sda1 f=/tmp/test bs=2M count=300&
採用空閒的磁碟排程,優先順序為0
ionice -c3 -n0  -ptime dd if=/dev/sda1 f=/tmp/test bs=2M count=300&

ionice的三種排程方法,實時排程最高,其次是預設的I/O排程,最後是空閒的磁碟排程.
ionice的磁碟排程優先順序有8種,最高是0,最低是7.
注意,磁碟排程的優先順序與程序nice的優先順序沒有關係.
一個是針對程序I/O的優先順序,一個是針對程序CPU的優先順序.


相關推薦

磁碟IO 處理辦法

主要命令:echo deadline > /sys/block/sda/queue/scheduler 注:以下的內容僅是提供參考,如果磁碟IO確實比較大的話,是資料庫,可以進行讀寫分離或者分庫操作,減小磁碟壓力,檔案的話,可以利用raid來減輕壓力 一)I/O排程程式的總結: 1)當向裝置

記一次服務器IO處理過程

linux 服務器 緩沖區 io負載 記一次服務器IO過高處理過程 一、背景 在一次上線升級後,發現兩臺tomcat服務器的IOwait一直超過100ms,高峰時甚至超過300ms,檢查服務器發現CPU負載,內存的使用率都不高。問題可能出現在硬盤讀寫,而且那塊硬盤除了寫日誌外,沒有其他

Mysql 磁碟IO

今天在spotlight上看到磁碟IO過高的報警,登入伺服器檢視具體磁碟IO情況: [root@hbwb-008 ~]# iostat -dxk 1 磁碟util%使用率100%。首先懷疑是慢查詢語句導致,檢視MYSQL慢查詢情況: mysql&g

Linux磁碟滿了以及負載解決辦法

原文地址:http://blog.csdn.net/zheshijieyouwo/article/details/769448451. 磁碟滿了如果一臺機器磁碟滿了,首先我們需要確定其位置,命令為 df(或者df -h) //顯示結果 Filesystem 512-bl

Linux中Cache內存占用解決辦法

格式化 left ack 當前 區別 專業 技術分享 表示 進行 在Linux系統中,我們經常用free命令來查看系統內存的使用狀態。在一個RHEL6的系統上,free命令的顯示內容大概是這樣一個狀態: 這裏的默認顯示單位是kb,我的服務器是128G內存,所以數字顯得

tomcat占用cpu解決辦法

title 情況 處理 顯示 pri grep tar jstack 16進制 在工作中經常遇到tomcat占用cpu居高不下,針對這種情況有以下處理辦法進行排查。 jps --> 查看java的進程 top -Hp pid --> 根據jps得到的進程

nohup命令導致log檔案處理辦法

問題描述:用nohup命令會在當前的目錄產生一個nohup.out的日誌檔案!時間長了特別的佔磁碟空間! 處理辦法: 1.關閉當前的服務,rm -rf 直接刪掉,啟動服務。 2.echo ‘’ > nohup.out     清空檔案內容

解決Linux buffer/cache記憶體佔用辦法

-------原文地址 https://www.cnblogs.com/rocky-AGE-24/p/7629500.html --------本文只是搬運 在Linux系統中,我們經常用free命令來檢視系統記憶體的使用狀態。在一個RHEL6的系統上,fr

ORA-01653報錯解決方法(表空間使用率處理

建立oracle表時遇見以下報錯:ORA-01653: unable to extend table JT_AUDIT.CFG_AUSYS_AUDIT_PROC by 128 in tablespace AUDIT_TABLESPACE從報錯資訊來看,應該是oracle表空間

Linux中buff/cache記憶體佔用解決辦法

如何回收cache? Linux核心會在記憶體將要耗盡的時候,觸發記憶體回收的工作,以便釋放出記憶體給急需記憶體的程序使用。一般情況下,這個操作中主要的記憶體釋放都來自於對buffer/cache的釋放。尤其是被使用更多的cache空間。既然它主要用來做快

Linux中Cache記憶體佔用解決辦法

在Linux系統中,我們經常用free命令來檢視系統記憶體的使用狀態。在一個RHEL6的系統上,free命令的顯示內容大概是這樣一個狀態: 這裡的預設顯示單位是kb,我的伺服器是128G記憶體,所以數字顯得比較大。這個命令幾乎是每一個使用過Linux的人必會的命令,但越是這樣的命令,似乎真正明白的人越少(

記一次專案執行cpu處理

第一次處理這種問題,新手不懂的從何下手走了不少彎路,記錄一下,以後借鑑. 對於cpu執行過高的問題,首先要列印堆疊資訊,和執行緒執行cpu使用情況:    1.列印堆疊資訊:       先通過top -c找到自己的執行緒對應的id值:          jstac

Oracle 佔用cpu處理辦法

問題描述: 今天上午10點多,公司網路斷了一會,過了大約十來分鐘,網工處理好了,可資料庫這下子可撐不住了,開啟linux top查看了一下CPU百分百了,這可能是因為緩衝在客戶端的資料一下子全傳上來了導致資料庫壓力過大,可以前沒有出現過這種問題,於是進行了分析和處理,以下為

linux kjournald 程序IO處理辦法

案例: 開發部門反映該伺服器(Mysql)ssh登入時響應慢,甚至無響應,登入失敗。 分析: 初步判斷是記憶體不足或者高io導致,分別用top和free命令查看了,記憶體沒問題。然後鎖定磁碟IO,程序追蹤。 由於不知道哪個程序產生的高的IO操作,所以先追蹤下是哪個程序的I

css中固定寬div與不固定寬div垂直居中的處理辦法

分配 css代碼 http min har 空間 -i dex round 固定高寬div垂直居中 如上圖,固定高寬的很簡單,寫法如下: 1 position: absolute; 2 left: 50%; 3 top: 50%; 4 width:200px;

磁盤IO和線程切換性能壓測案例分析

cnblogs 左右 系統 stp tex clas ++ class tap 案例現象: 壓力測試的時候,發現A請求壓力80tps後,cpu占用就非常高了(24核的機器,每個cpu占用率全面飆到80%以上),且設置的檢查點沒有任何報錯。 1、top命令如下: 2、

文件系統inodes使用率問題處理

所有 郵件 傳輸 crond 文件 顯示 pool --delete 避免 運維過程中經常碰見文件系統inodes使用率過高導致文件系統不可寫的問題,常見場景如下 1、Oracle產生的審計文件,特別是DG備庫或者審計設置為OS時 2、crontab產生大量郵件,導致/v

SQL Server效能優化案例分享(1)——CPU持續——CPU使用率的常見原因及處理方向

本系列屬於 SQL Server效能優化案例分享 專題     部分內容借用《SQL Server 2012實施與管理實戰指南》P592,如果SQL Server錯誤日誌裡面並沒有17883/17884這類錯誤,但是SQ

記憶體佔用,快取不釋放導致宕機處理方案

故障現象: 1、某分行部署的某臺伺服器記憶體佔用過高,導致宕機; 2、程式碼層面檢查暫未發現問題,伺服器硬重啟持續一段時間後(3-5天)再次佔滿。 發現問題: 趕往現場後進行檢查,當時是一切正常的,今有DB2程序佔用18%,在正常範圍內; 在crontab 中發現有兩個指

MySQL案例:一次單核CPU佔用問題的處理

客戶現場反饋,top的檢查結果中,一個CPU的佔用一直是100%。實際上現場有4個CPU,而且這個伺服器是mysql專屬伺服器。 我的第一反應是io_thread一類的引數設定有問題,檢查以後發現read和write的thread設定都是4,這和CPU數一致,因此可以斷定這並不是單顆CPU佔用過高的問題。