❶ 磁碟IO性能值多少為正常
磁碟有兩個重要的參數： Seek time和Rotational latency。正常的I/O計數為：①1000/(Seek time+Rotational latency)*0.75，在此范圍內屬正常。
❷ 如何提升磁碟io
1. 文件越多讀取越慢：如果可以的話，將多個小文件合並成一個文件。
2. 讀寫次數越多讀取越慢：一次多讀一些數據到內存。
3. 將讀寫操作分配到不同的硬碟上。
4. 磁碟RAID0比RAID5讀寫速度快很多。
❸ 9217-4i4e 磁碟io不足
解答如下:
磁碟io性能不足 千次閱讀 2018-05-22 15:38:49
密集讀寫磁碟io成為短板，程序運行過慢。
主硬碟是掛載新硬碟性能4倍。
主硬碟比較小，掛載硬碟大。
在主硬碟上進行讀寫操作，基礎數據定時移動到掛載硬碟上。
主要用到的命令
磁碟io性能觀測：iostat -d -k 1 10
❹ 什麼是磁碟I/O性能
就是硬碟讀寫的速度。
❺ windows下如何查看磁碟IO性能
磁碟有兩個重要的參數： Seek time、 Rotational latency。正常的I/O計數為：①1000/(Seek time+Rotational latency)*0.75，在此范圍內屬正常。當達到85％的I/O計數以上時則基本認為已經存在I/O瓶勁。理論情況下，磁碟的隨機讀計數為125、順序讀計數為225。對於數據文件而言是隨機讀寫，日誌文件是順序讀寫。因此，數據文件建議存放於RAID5上，而日誌文件存放於RAID10或RAID1中。
❻ 集群瓶頸為什麼是磁碟io
具體問題具體分析，舉例來說明為什麼磁碟IO成瓶頸資料庫的性能急速下降了。
為什麼當磁碟IO成瓶頸之後, 資料庫的性能不是達到飽和的平衡狀態，而是急劇下降。為什麼資料庫的性能有非常明顯的分界點，原因是什麼？
相信大部分做資料庫運維的朋友，都遇到這種情況。 資料庫在前一天性能表現的相當穩定，資料庫的響應時間也很正常，但就在今天，在業務人員反饋業務流量沒有任何上升的情況下，資料庫的變得不穩定了，有時候一個最簡單的insert操作， 需要幾十秒，但99%的insert卻又可以在幾毫秒完成，這又是為什麼了？
dba此時心中有無限的疑惑，到底是什麼原因呢? 磁碟IO性能變差了？還是業務運維人員反饋的流量壓根就不對？ 還是資料庫內部出問題？昨天不是還好好的嗎？
當資料庫出現響應時間不穩定的時候，我們在操作系統上會看到磁碟的利用率會比較高，如果觀察仔細一點，還可以看到，存在一些讀的IO. 資料庫伺服器如果存在大量的寫IO,性能一般都是正常跟穩定的，但只要存在少量的讀IO,則性能開始出現抖動，存在大量的讀IO時（排除配備非常高速磁碟的機器），對於在線交易的資料庫系統來說，大概性能就雪崩了。為什麼操作系統上看到的磁碟讀IO跟寫IO所帶來的性能差距這么大呢？
如果親之前沒有注意到上述的現象，親對上述的結論也是懷疑。但請看下面的分解。
在寫這個文章之前，作者閱讀了大量跟的IO相關的代碼，如非同步IO線程的相關的，innodb_buffer池相關的，以及跟讀數據塊最相關的核心函數buf_page_get_gen函數以及其調用的相關子函數。為了將文章寫得通俗點，看起來不那麼累，因此不再一行一行的將代碼解析寫出來。
咱們先來提問題。buf_page_get_gen函數的作用是從Buffer bool裡面讀數據頁，可能存在以下幾種情況。
提問. 數據頁不在buffer bool 裡面該怎麼辦？
回答：去讀文件，將文件中的數據頁載入到buffer pool裡面。下面是函數buffer_read_page的函數，作用是將物理數據頁載入到buffer pool, 圖片中顯示
buffer_read_page函數棧的頂層是pread64(),調用了操作系統的讀函數。
通過解析buf_wait_for_read函數的下層函數，我們知道其實通過首先自旋加鎖pin的方式，超過設定的自旋次數之後，進入等待，等待IO完成被喚醒。這樣節省不停自旋pin時消耗的cpu,但需要付出被喚起時的開銷。
再繼續擴展問題： 如果會話線程A 經過物理IO將數據頁1001讀入buffer之後，他需要修改這個頁，而在會話線程A之後的其他的同樣需要訪問數據頁1001的會話線程，即使在數據頁1001被入讀buffer pool之後，將仍然處於等待中。因為在數據頁上讀取或者更新的時候，同樣需要上鎖，這樣才能保證數據頁並發讀取/更新的一致性。
由此可見，當一個高並發的系統，出現了熱點數據頁需要從磁碟上載入到buffer pool中時，造成的延遲，是難以想像的。因此排在等待熱點頁隊列最後的會話線程最後才得到需要的頁，響應時間也就越長，這就是造成了一個簡單的sql需要執行幾十秒的原因。
再回頭來看上面的問題，mysql資料庫出現性能下降時，可以看到操作系統有讀IO。 原因是，在資料庫對數據頁的更改，是在內存中的，然後通過檢查點線程進行非同步寫盤，這個非同步的寫操作是不堵塞執行sql的會話線程的。所以，即使看到操作系統上有大量的寫IO，資料庫的性能也是很平穩的。但當用戶線程需要查找的數據頁不在buffer pool中時，則會從磁碟上讀取，在一個熱點數據頁不是非常多的情況下，我們設置足夠大的innodb_buffer_pool的size, 基本可以緩存所有的數據頁，因此一般都不會出現缺頁的情況，也就是在操作系統上基本看不到讀的IO。 當出現讀的IO時，原因時在執行buf_read_page_low函數，從磁碟上讀取數據頁到buffer pool, 則資料庫的性能則開始下降，當出現大量的讀IO，資料庫的性能會非常差。
❼ 磁碟io請求過高造成的io瓶頸怎麼解決
具體問題具體分析，舉例來說明為什麼磁碟IO成瓶頸資料庫的性能急速下降了。
為什麼當磁碟IO成瓶頸之後, 資料庫的性能不是達到飽和的平衡狀態，而是急劇下降。為什麼資料庫的性能有非常明顯的分界點，原因是什麼？
相信大部分做資料庫運維的朋友，都遇到這種情況。 資料庫在前一天性能表現的相當穩定，資料庫的響應時間也很正常，但就在今天，在業務人員反饋業務流量沒有任何上升的情況下，資料庫的變得不穩定了，有時候一個最簡單的insert操作， 需要幾十秒，但99%的insert卻又可以在幾毫秒完成，這又是為什麼了？
dba此時心中有無限的疑惑，到底是什麼原因呢? 磁碟IO性能變差了？還是業務運維人員反饋的流量壓根就不對？ 還是資料庫內部出問題？昨天不是還好好的嗎？
當資料庫出現響應時間不穩定的時候，我們在操作系統上會看到磁碟的利用率會比較高，如果觀察仔細一點，還可以看到，存在一些讀的IO. 資料庫伺服器如果存在大量的寫IO,性能一般都是正常跟穩定的，但只要存在少量的讀IO,則性能開始出現抖動，存在大量的讀IO時（排除配備非常高速磁碟的機器），對於在線交易的資料庫系統來說，大概性能就雪崩了。為什麼操作系統上看到的磁碟讀IO跟寫IO所帶來的性能差距這么大呢？
如果親之前沒有注意到上述的現象，親對上述的結論也是懷疑。但請看下面的分解。
在寫這個文章之前，作者閱讀了大量跟的IO相關的代碼，如非同步IO線程的相關的，innodb_buffer池相關的，以及跟讀數據塊最相關的核心函數buf_page_get_gen函數以及其調用的相關子函數。為了將文章寫得通俗點，看起來不那麼累，因此不再一行一行的將代碼解析寫出來。
咱們先來提問題。buf_page_get_gen函數的作用是從Buffer bool裡面讀數據頁，可能存在以下幾種情況。
提問. 數據頁不在buffer bool 裡面該怎麼辦？
回答：去讀文件，將文件中的數據頁載入到buffer pool裡面。下面是函數buffer_read_page的函數，作用是將物理數據頁載入到buffer pool, 圖片中顯示
buffer_read_page函數棧的頂層是pread64(),調用了操作系統的讀函數。
通過解析buf_wait_for_read函數的下層函數，我們知道其實通過首先自旋加鎖pin的方式，超過設定的自旋次數之後，進入等待，等待IO完成被喚醒。這樣節省不停自旋pin時消耗的cpu,但需要付出被喚起時的開銷。
再繼續擴展問題： 如果會話線程A 經過物理IO將數據頁1001讀入buffer之後，他需要修改這個頁，而在會話線程A之後的其他的同樣需要訪問數據頁1001的會話線程，即使在數據頁1001被入讀buffer pool之後，將仍然處於等待中。因為在數據頁上讀取或者更新的時候，同樣需要上鎖，這樣才能保證數據頁並發讀取/更新的一致性。
由此可見，當一個高並發的系統，出現了熱點數據頁需要從磁碟上載入到buffer pool中時，造成的延遲，是難以想像的。因此排在等待熱點頁隊列最後的會話線程最後才得到需要的頁，響應時間也就越長，這就是造成了一個簡單的sql需要執行幾十秒的原因。
再回頭來看上面的問題，mysql資料庫出現性能下降時，可以看到操作系統有讀IO。 原因是，在資料庫對數據頁的更改，是在內存中的，然後通過檢查點線程進行非同步寫盤，這個非同步的寫操作是不堵塞執行sql的會話線程的。所以，即使看到操作系統上有大量的寫IO，資料庫的性能也是很平穩的。但當用戶線程需要查找的數據頁不在buffer pool中時，則會從磁碟上讀取，在一個熱點數據頁不是非常多的情況下，我們設置足夠大的innodb_buffer_pool的size, 基本可以緩存所有的數據頁，因此一般都不會出現缺頁的情況，也就是在操作系統上基本看不到讀的IO。 當出現讀的IO時，原因時在執行buf_read_page_low函數，從磁碟上讀取數據頁到buffer pool, 則資料庫的性能則開始下降，當出現大量的讀IO，資料庫的性能會非常差。
❽ 如何提高Linux伺服器磁碟io性能
您好，很高興為您解答。
在現有文件系統下進行優化：
linux內核和各個文件系統採用了幾個優化方案來提升磁碟訪問速度。但這些優化方案需要在我們的伺服器設計中進行配合才能得到充分發揮。
文件系統緩存
linux內核會將大部分空閑內存交給虛擬文件系統，來作為文件緩存，叫做page cache。在內存不足時，這部分內存會採用lru演算法進行淘汰。通過free命令查看內存，顯示為cached的部分就是文件緩存了。
如何針對性優化：
lru並不是一個優秀淘汰演算法，lru最大的優勢是普適性好，在各種使用場景下都能起到一定的效果。如果能找到當前使用場景下，文件被訪問的統計特徵，針 對性的寫一個淘汰演算法，可以大幅提升文件緩存的命中率。對於http正向代理來說，一個好的淘汰演算法可以用1GB內存達到lru演算法100GB內存的緩存 效果。如果不打算寫一個新的淘汰演算法，一般不需要在應用層再搭一個文件cache程序來做緩存。
最小分配：
當文件擴大，需要分配磁碟空間時，大部分文件系統不會僅僅只分配當前需要的磁碟空間，而是會多分配一些磁碟空間。這樣下次文件擴大時就可以使用已經分配好的空間，而不會頻繁的去分配新空間。
例如ext3下，每次分配磁碟空間時，最小是分配8KB。
最小分配的副作用是會浪費一些磁碟空間（分配了但是又沒有使用）
如何針對性優化：
我們在reiserfs下將最小分配空間從8KB改大到128K後提升了30%的磁碟io性能。如果當前使用場景下小文件很多，把預分配改大就會浪費很多 磁碟空間，所以這個數值要根據當前使用場景來設定。似乎要直接改源代碼才能生效，不太記得了，09年的時候改的，有興趣的同學自己google吧。
io訪問調度：
在同時有多個io訪問時，linux內核可以對這些io訪問按LBA進行合並和排序，這樣磁頭在移動時，可以「順便」讀出移動過程中的數據。
SATA等磁碟甚至在磁碟中內置了io排序來進一步提升性能，一般需要在主板中進行配置才能啟動磁碟內置io排序。linux的io排序是根據LBA進行的，但LBA是一個一維線性地址，無法完全反應出二維的圓形磁碟，所以磁碟的內置io排序能達到更好的效果。
如何針對性優化：
io訪問調度能大幅提升io性能，前提是應用層同時發起了足夠的io訪問供linux去調度。
怎樣才能從應用層同時向內核發起多個io訪問呢？
方案一是用aio_read非同步發起多個文件讀寫請求。
方案二是使用磁碟線程池同時發起多個文件讀寫請求。
對我們的http正向代理來說，採用16個線程讀寫磁碟可以將性能提升到2.5倍左右。具體開多少個線程/進程，可以根據具體使用場景來決定。
小提示：
將文件句柄設置為非阻塞時，進程還是會睡眠等待磁碟io，非阻塞對於文件讀寫是不生效的。在正常情況下，讀文件只會引入十幾毫秒睡眠，所以不太明顯；而在磁碟io極大時，讀文件會引起十秒以上的進程睡眠。
預讀取：
linux內核可以預測我們「將來的讀請求」並提前將數據讀取出來。通過預讀取可以減少讀io的次數，並且減小讀請求的延時。
如何針對性優化：
預讀取的預測准確率是有限的，與其依賴預讀取，不如我們直接開一個較大的緩沖區，一次性將文件讀出來再慢慢處理；盡量不要開一個較小的緩沖區，循環讀文件/處理文件。
雖然說「預讀取」和「延遲分配」能起到類似的作用，但是我們自己擴大讀寫緩沖區效果要更好。
延遲分配：
當文件擴大，需要分配磁碟空間時，可以不立即進行分配，而是暫存在內存中，將多次分配磁碟空間的請求聚合在一起後，再進行一次性分配。
延遲分配的目的也是減少分配次數，從而減少文件不連續。
延遲分配的副作用有幾個：
1、如果應用程序每次寫數據後都通過fsync等介面進行強制刷新，延遲分配將不起作用
2、延遲分配有可能間歇性引入一個較大的磁碟IO延時（因為要一次性向磁碟寫入較多數據）
只有少數新文件系統支持這個特性
如何針對性優化：
如果不是對安全性（是否允許丟失）要求極高的數據，可以直接在應用程序里緩存起來，積累到一定大小再寫入，效果比文件系統的延遲分配更好。如果對安全性要求極高，建議經常用fsync強制刷新。
在線磁碟碎片整理：
Ext4提供了一款碎片整理工具，叫e4defrag，主要包含三個功能：
1、讓每個文件連續存儲
2、盡量讓每個目錄下的文件連續存儲
3、通過整理空閑磁碟空間，讓接下來的分配更不容易產生碎片
如何針對性優化：
「讓每個目錄下的文件連續存儲」是一個極有價值的功能。
傳統的做法是通過拼接圖片來將這10張圖片合並到一張大圖中，再由前端將大圖切成10張小圖。
有了e4defrag後，可以將需連續訪問的文件放在同一個文件夾下，再定期使用e4defrag進行磁碟整理。
實現自己的文件系統：
在大部分伺服器上，不需要支持「修改文件」這個功能。一旦文件創建好，就不能再做修改操作，只支持讀取和刪除。在這個前提下，我們可以消滅所有文件碎片，把磁碟io效率提升到理論極限。
有一個公式可以衡量磁碟io的效率：
磁碟利用率 = 傳輸時間/（平均尋道時間+傳輸時間）
如若滿意，請點擊回答右側【採納答案】，如若還有問題，請點擊【追問】
~ O(∩_∩)O~
❾ 如何讓CentOS伺服器磁碟io性能翻倍
如何讓CentOS伺服器磁碟io性能翻倍
這一期我們來看一下有哪些辦法可以減少linux下的文件碎片。主要是針對磁碟長期滿負荷運轉的使用場景（例如http代理伺服器）；另外有一個小技巧，針對互聯網圖片伺服器，可以將io性能提升數倍。如果為伺服器訂制一個專用文件系統，可以完全解決文件碎片的問題，將磁碟io的性能發揮至極限。對於我們的代理伺服器，相當於把io性能提升到3-5倍。
在現有文件系統下進行優化linux內核和各個文件系統採用了幾個優化方案來提升磁碟訪問速度。但這些優化方案需要在我們的伺服器設計中進行配合才能得到充分發揮。
文件系統緩存linux內核會將大部分空閑內存交給虛擬文件系統，來作為文件緩存，叫做page cache。在內存不足時，這部分內存會採用lru演算法進行淘汰。通過free命令查看內存，顯示為cached的部分就是文件緩存了。
如果能找到當前使用場景下，文件被訪問的統計特徵，針對性的寫一個淘汰演算法，可以大幅提升文件緩存的命中率。對於http正向代理來說，一個好的淘汰演算法可以用1GB內存達到lru演算法100GB內存的緩存效果。如果不打算寫一個新的淘汰演算法，一般不需要在應用層再搭一個文件cache程序來做緩存。
最小分配
最小分配的副作用是會浪費一些磁碟空間（分配了但是又沒有使用）
如果當前使用場景下小文件很多，把預分配改大就會浪費很多磁碟空間，所以這個數值要根據當前使用場景來設定。似乎要直接改源代碼才能生效，不太記得了，09年的時候改的，有興趣的同學自己google吧。
io訪問調度
如何針對性優化：io訪問調度能大幅提升io性能，前提是應用層同時發起了足夠的io訪問供linux去調度。怎樣才能從應用層同時向內核發起多個io訪問呢？方案一是用aio_read非同步發起多個文件讀寫請求。
小提示：將文件句柄設置為非阻塞時，進程還是會睡眠等待磁碟io，非阻塞對於文件讀寫是不生效的。在正常情況下，讀文件只會引入十幾毫秒睡眠，所以不太明顯；而在磁碟io極大時，讀文件會引起十秒以上的進程睡眠。詳見內核源代碼do_generic_file_read會調用lock_page_killable進入睡眠，但是不會判斷句柄的非阻塞標志。
預讀取linux內核可以預測我們「將來的讀請求」並提前將數據讀取出來。通過預讀取可以減少讀io的次數，並且減小讀請求的延時。
當文件擴大，需要分配磁碟空間時，可以不立即進行分配，而是暫存在內存中，將多次分配磁碟空間的請求聚合在一起後，再進行一次性分配。
延遲分配的副作用有幾個：1 如果應用程序每次寫數據後都通過fsync等介面進行強制刷新，延遲分配將不起作用2 延遲分配有可能間歇性引入一個較大的磁碟IO延時（因為要一次性向磁碟寫入較多數據）
如何針對性優化：
「讓每個目錄下的文件連續存儲」是一個極有價值的功能。假設一個網頁上有10張圖片，這10張圖片雖然存在10個文件中，但其實是幾乎同時被用戶訪問的。如果能讓這10張圖片存儲在連續的磁碟空間中，就能把io性能提升10倍（一次尋道就可以讀10個文件了）傳統的做法是通過拼接圖片來將這10張圖片合並到一張大圖中，再由前端將大圖切成10張小圖。有了e4defrag後，可以將需連續訪問的文件放在同一個文件夾下，再定期使用e4defrag進行磁碟整理。
實現自己的文件系統我們曾經寫過一款專用文件系統，針對代理伺服器，將磁碟io性能提升到3-5倍。在大部分伺服器上，不需要支持「修改文件」這個功能。一旦文件創建好，就不能再做修改操作，只支持讀取和刪除。在這個前提下，我們可以消滅所有文件碎片，把磁碟io效率提升到理論極限。
大於16MB的文件，伺服器創建文件時告訴文件系統分配16MB磁碟空間。後續每次擴大文件大小時，要麼是16MB，要麼就是文件終結。不允許在文件未終結的情況下分配非16MB的空間。讀寫文件時，每次讀寫16MB或者直到文件末尾。
在我們的文件系統中，小文件完全無碎片，一次尋道就能搞定一個文件，達到了理論上最佳的性能。大文件每次磁頭定位讀寫16MB，性能沒有達到100%，但已經相當好了。有一個公式可以衡量磁碟io的效率：磁碟利用率 = 傳輸時間/（平均尋道時間+傳輸時間）對我們當時採用的磁碟來說（1T 7200轉sata)，16MB連續讀寫已經可以達到98%以上的磁碟利用率。
❿ elasticsearch怎麼提高磁碟性能io
性能測試
在一個節點的一個分片，不設置副本，測試性能
在完全默認設置上記錄性能數據，作為測試的基準線
確保性能測試持續30分鍾以上以確認長時間的性能；短時間的測試可能不會碰到segment合並和GC，無法確認這些因素的影響
每次基於默認基準線更改一個參數，如果性能有提升就保留設置，並基於此設置做後續的測試
bulk使用建議
每個請求大小建議在5-15MB，逐步增大測試,當接收到EsRejectedExecutionException，就說明已經到達節點的瓶頸了，就需要減少並發或者升級硬體增加節點
當寫入數據時，確保bulk請求時輪詢訪問所有節點，不要發送所有請求到一個結點導致這一個節點要在內存存儲所有請求的數據去處理
優化磁碟IO
使用SSD
使用RAID 0，不用鏡像備份，用replicas保證數據正確性，增大磁碟IO
使用多個磁碟給Elasticsearch訪問，通過在path.data中添加
不使用遠程存儲，如NFS／SMB／CIFS；延時將成為性能瓶頸
段合並
段合並是很消耗計算資源和磁碟IO的操作，特別是出現比較大的段合並。
當出現段合並的速度落後於索引寫入的速度，Elasticsearch為了避免出現堆積的段數量爆發，會降低單個線程的索引寫入速度，並且會在INFO的log里記錄「now throttling indexing「
Elasticsearch默認比較保守，不想讓搜索的性能被後台的段合並影響，默認的段合並速率限制比較低，默認是20MB/s，但如果使用的是SSD，可以考慮把這個參數設置到100-200MB/s
PUT /_cluster/settings
{
"persistent" : {
"indices.store.throttle.max_bytes_per_sec" : "100mb"
}
}123456123456
如果你只是用bulk導入數據而不關注查詢性能，可以關閉合並的閾值
PUT /_cluster/settings
{
"transient" : {
"indices.store.throttle.type" : "none"
}
}123456123456
然後在導入完數據之後恢復成「merge」來恢復這個閾值設置
如果是機械硬碟，你需要增加下面的配置到elasticsearch.yml中
index.merge.scheler.max_thread_count: 111
機械硬碟的並發IO性能較差，我們需要減少每個索引並發訪問磁碟的線程數，這個設置會有max_thread_count＋2個線程並發訪問磁碟
如果是SSD可以忽略這個參數，默認線程數是Math.min(3, Runtime.getRuntime().availableProcessors() / 2)，對於SSD來說沒有問題。
可以增大index.translog.flush_threshold_size參數，默認是200M，可以增大到如1GB。增大這個參數可以允許translog在flush前存放更大的段(segment);更大的段的創建會減少flush的頻率，並且更大的段合並越少，會減少磁碟IO，索引性能更高。