如果您的Linux服務器出現故障,您的第一步通常是在終端中使用top命令來檢查平均負載。
但是,有時會top
命令顯示非常高的平均負載,即使CPU的us
和CPU的id
的度數比較低也是如此。
如果CPU單核的負載超過1,但CPU顯示大約70%空閑。這種情況的常見原因之一是磁盤 I/O瓶頸。
什么是I/O等待瓶頸
存儲I/O是物理磁盤或其他存儲,例如磁盤或SSD。輸入/輸出(或寫入/讀取)的操作。
如果CPU需要在磁盤上等待讀取或寫入數據,則涉及磁盤I/O的請求會顯著變慢。I/O Wait是CPU必須等待存儲設備的時間百分比。
在Linux服務器可以使用一些終端命令行工具,例如top、atop和iotop來確認磁盤I/O是否正在降低應用程序性能。
top 命令平均負載與等待時間wa
當您運行top
命令,您將首先瀏覽右上角檢查平均負載。在這種情況下,它非常高。
接下來,我們很可能會瀏覽頂部附近的CPU和內存,然后是%CPU
和%MEM
列,以了解哪些進程使用的資源最多。
在top
,您還需要查看wa
,它幾乎一直是0.0%。值始終高于1%可能表示您的存儲設備速度太慢,無法跟上IO的請求。
值得注意的是,top命令頂部%Cpu(s)
行的wa
是多個核心wa的平均值,可以按1
鍵來展開視圖,查看每個CPU核心wa
值。
完成此操作后,我們看到某些CPU內核的%wa
時間高達 60%。所以我們知道有一個主要的瓶頸,接下來我們來確認一下這個磁盤瓶頸。
atop 命令監控DSK(存儲)I/O 統計信息
接下來,使用atop
,我們看到存儲設備DSK行的busy
的值在90%到100%。這是一個嚴重的瓶頸。在Web服務導致結果就是HTTP請求被阻塞,直到磁盤I/O可以趕上。
在atop
,按d
鍵盤查看正在使用磁盤I/O的進程。這里我們看到MySQL、Nginx、PHP-FPM,這些都是web服務核心進程。
要降低web服務磁盤IO,可以考慮將Nginx或Apache、MySQL和PHP-FPM的訪問日志和錯誤日志不要過于頻繁地寫入磁盤。
并且避免將緩存(例如Nginx 緩存)存儲在磁盤。高并發流量環境。除了LEMP服務之外。
還要注意flush-8:0(一個PHP緩存問題)和jbd2/sda5-8(跟蹤到訪問/內核日志)及其進程。
此時,如果可以,你應該在Linux服務器上執行一個快速SSD基準測試,以了解磁盤IO的速度。
運行命令dd if=/dev/zero of=diskbench bs=1M count=1024 conv=fdatasync
。
dd if=/dev/zero of=diskbench bs=1M count=1024 conv=fdatasync
1073741824 bytes (1.1 GB) copied, 46.0156 s, 23.3 MB/s
盡管可以減少讀/寫,但磁盤I/O非常慢。如果MySQL的my.cnf的max_connections設置太高。
就會導致MySQL連接和查詢堆積并增長到超出可用服務器RAM的范圍。它就會發展到Linux內核OOM殺死MySQL的地步。
通常MySQL最大的連接數等于最大分配內存除以每個線程緩沖區的大小。
iotop 命令實時監控磁盤讀/寫
iotop
命令監控Linux內核輸出的I/O使用信息。它顯示系統進程或線程的當前I/O使用情況,運行命令iotop -oPa
。
iotop -oPa
iotop
命令-o
選項僅顯示正在執行I/O的進程或線程,而不是顯示所有進程或線程。這可以通過按o
鍵 動態切換。
-P
選項僅顯示進程。通常iotop
命令顯示所有線程。-a
選項顯示累積的I/O而不是帶寬。
在這種模式下,iotop
命令顯示自iotop
命令啟動以來完成的I/O進程的數量。
查看DISK WRITE
列,這些數字不是很大。合理平均速度的存儲設備不會忙于一些內核日志記錄和磁盤緩存。
但是在低于25 MB/s的寫入速度時,磁盤IO就會被Nginx緩存、內核日志、訪問日志等操作使用最大化。要解決這類問題,是用性能更好的存儲設備替換現有的設備。
-
Linux
+關注
關注
87文章
11230瀏覽量
208935 -
服務器
+關注
關注
12文章
9024瀏覽量
85187 -
磁盤
+關注
關注
1文章
367瀏覽量
25178
發布評論請先 登錄
相關推薦
評論