1. 程式人生 > >記一次iotop分析磁碟佔用io問題

記一次iotop分析磁碟佔用io問題

問題描述    

                 某一臺伺服器上面 程式在每小時內偶爾丟包 排查伺服器所有效能瓶頸之後發現一個奇怪的問題 程式丟包前後 會有IO過高的情況 於是使用iotop命令排查是哪個程式偶爾佔用過高的磁碟IO

所用命令

                 iotop

相關引數 

    -o:只顯示有io操作的程序

    -b:批量顯示,無互動,主要用作記錄到檔案

    -n NUM:顯示NUM次,主要用於非互動式模式

    -d SEC:間隔SEC秒顯示一次

    -p PID:監控的程序pid

    -u USER:監控的程序使用者

排查方法

    iostat命令 只能看出每個碟符的IO情況 不能看到是具體哪個程序使用的IO 所以 我們需要使用iotop命令 但是這次的IO情況並不是一直出現 而是偶爾不規律出現 如果用肉眼去一直盯著終端看 顯然不可行 於是我們可以用iotop的-b引數 讓結果以非互動的方式輸出 這樣我們便可以用awk去處理 打印出我們需要的IO列以及相應的程序

命令

iotop -b | awk -F'%' '{if($(NF-1) > 0.2 && $(NF-1) ~ /[0-9]/ && $0 !~ /DISK/)printf "TIME: %s,IO:%s%,COMMAND:%s\n",strftime("%F %T"),$(NF-1),$NF}'

輸出結果

[[email protected] ~]# iotop -b | awk -F'%' '{if($(NF-1) > 0.2 && $(NF-1) ~ /[0-9]/ && $0 !~ /DISK/)printf "TIME: %s,IO:%s%,COMMAND:%s\n",strftime("%F %T"),$(NF-1),$NF}'
TIME: 2018-03-21 18:04:23,IO:  0.23 %,COMMAND: [kworker/0:2]
TIME: 2018-03-21 18:04:35,IO:  0.44 %,COMMAND: [kworker/0:2]
TIME: 2018-03-21 18:04:47,IO:  0.22 %,COMMAND: [kworker/0:2]
TIME: 2018-03-21 18:04:58,IO:  0.39 %,COMMAND: [kworker/0:2]
TIME: 2018-03-21 18:05:08,IO:  0.68 %,COMMAND: [kworker/0:2]
TIME: 2018-03-21 18:05:22,IO:  0.52 %,COMMAND: [kworker/0:2]
TIME: 2018-03-21 18:05:34,IO:  0.24 %,COMMAND: [kworker/0:2]
TIME: 2018-03-21 18:05:45,IO:  0.26 %,COMMAND: [kworker/0:2]

    輸出結果類似上面 這裡只是簡單舉個例子 打印出IO大於0.2%的程序 並根據客戶需求列印除相應的時間 這裡的時間列印 利用awk自己的函式 strftime()

相關推薦

iotop分析磁碟佔用io問題

問題描述                     某一臺伺服器上面 程式在每小時內偶爾丟包 排查伺服器所有效能瓶頸之後發現一個奇怪的問題 程式丟包前後 會有IO過高的情況 於是使用iotop命令排查是哪個程式偶爾佔用過高的磁碟IO所用命令                 io

Linux伺服器磁碟空間佔用,大檔案查詢

好久沒寫東西了,很久之前弄了個伺服器玩玩,寫了點東西在上面放著,一直在不停的抓資料,也就沒怎麼看,最近閒來無事登入後臺檢視,發現我的媽呀,伺服器磁碟快滿了 剛開始以為抓取的太多,資料庫資料膨脹佔用了,於是登入MySQL檢視,發現有20多萬條記錄,咋看似乎佔

原始碼分析

首先分析一段很短的程式碼  #include<iostream> #include<vector> using namespace std; vector<int> getdata(){ vector<int> v{2,3,4,5,6

生產環境CPU佔用飆高問題解決

1 問題來源與背景 問題背景,專案對外提供查詢航班艙位介面,對航信黑屏報文做正則解析返回。由於起初對正則不熟悉,對黑屏報文格式規律不清楚,導致寫了大量的長正則表示式,生產環境併發量上來(200/s),直

服務器IO過高處理過程

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

對java對象在內存中的分析

數據 ots 字節對齊 位數 數據位 64位 數組 內存大小 特殊 java 對象 占內存大小 計算方式 及 常用類型的占用 HotSpot的對齊方式為8字節對齊 ----計算公式:(對象頭 + 實例數據 + padding) % 8等於0且0 <= padding

OGG數據寫入HBase的丟失數據原因分析

hat xdg column 安裝 tint b- 主鍵 取余 bst 一、現象二、原因排查2.1 SparkStreaming程序排查2.2 Kafka數據驗證2.3 查看OGG源碼2.3.1 生成Kafka消息類2.3.2 Kafka配置類2.3.3 Kafka 消息發

lvs-tunnel模式的故障分析(SYN_REC)

過濾 oot som 一次 hose 不知道 也會 推理 min 一、測試環境 類型 IP 負載均衡器 eth0:10.20.73.20 VIP eth0:0 10.20.73.29 後端真實機 10.0.0.7(web01)、10.0.0.9(we

Java的內存泄露分析

新項目 引用 極限 out size exce -a 場景 tpc 當前環境 jdk == 1.8 httpasyncclient == 4.1.3 代碼地址 git 地址:https://github.com/jasonGeng88/java-network-prog

網上流量分析

words itl word 很多 release sctf 數據包 base 沒有 這是捕獲的黑客攻擊數據包,LateRain用戶的密碼在此次攻擊中泄露了,你能找到嗎? FLAG格式:SCTF{LateRain的明文密碼} LINK: http://pan.baidu.c

內存溢出的分析經歷——thrift帶給我的痛orz

一個bug 服務端 ide 參數 comment ces 結果 業務 改變 說在前面的話 朋友,你經歷過部署好的服務突然內存溢出嗎? 你經歷過沒有看過Java虛擬機,來解決內存溢出的痛苦嗎? 你經歷過一個BUG,百思不得其解,頭發一根一根脫落的煩惱嗎? 我知道,你有過! 但

Ceph日誌損壞的分析處理過程

Ceph 日誌 1、故障現象 今天下午看到群友在說一個問題,說ceph的某個osd處於down的狀態,我大概整理下他的處理過程 1、查看OSD的狀態2、查看日誌信息3、啟動對應的ceph-osd服務4、檢查集群健康狀態 2、日誌損壞了,如何讓osd重新上線 思路:重建日誌a、先把/var/lib/ce

常規的Mysql數據庫訪問的時間分析

客戶端 tcp三次握手 alt 時間 res src img gree 分析 背景:記一次常規的數據訪問的時間分析(插入操作) 1. TCP三次握手 SYN ---> <--- SYN,ACK ACK ---> 花費時間: 386.718-38

netty版本沖突,報java.lang.NoSuchMethodError: io.netty.util.internal.ObjectUtil.checkPositive的問題

verbose apache jar bject comm 依賴 art 問題解決 internal elasticsearch 5.6中使用TransportClient初始化拋異常 在引入elasticsearch5.6的transportclient包中,會引入net

NET Core 2.0在macOS 10.13出現的奇怪Build IO共享沖突問題

過程 賬戶 權限 arp 環境 定義 inux 編譯環境 做了 相信有些朋友喜歡直接把項目放在移動硬盤上進行工作,為了方便來回在多臺電腦或不同的操作系統平臺上來回碼磚,磁盤的格式基本都是exFAT的(喜歡在macOS上用NTFS或者FAT的都是大佬),在這裏我們不討論exF

伺服器掛掉,cpu佔用過大的問題

凌晨一點電話:咚咚咚 喂:伺服器掛掉了,你查檢視問題,然後處理下。 我:好的。 從日誌看幾乎所有的logic日誌全都掛掉,不再列印日誌,然後logic程序僵死,佔用cpu百分90多,有些可怕。 第一反應是邏輯迴圈問題。 因為是公司自己的框架採用lua編寫。

jdbc連線oracle資料庫佔用CPU過高的問題排查

    背景:     公司有一個通訊系統,主要是通訊資料到客戶端程式所指定的資料庫,目前支援sqlserver、mysql和oracle三種類型的資料庫,此篇主要記錄一次oracle資料庫佔用CPU飆高的問題。   &nbs

簡單的日誌分析

  題目檔案:https://files.cnblogs.com/files/nul1/access.log.tar 直接搜尋flag發現是一題關於二分法注入。 頁面為200的位元組大小為1765,所以可以通過讀取每行判斷是否有1765以及有沒有flag的關鍵字樣,進而提取值。 指令碼如

某App反編譯分析

每次尋找漏洞的時候,我都喜歡從抓包開始 噢噢,這裡有點尷尬~~請求和返回的資料都進行了加密處理,這波操作我挺喜歡的,證明人家公司的開發人員還是有點安全意識的,不過沒有關係,他有張良計,我有過牆梯,先反編譯一波看看,使用的工具是 jadx 很明顯,app用了360加固

MongoDB 佔用 CPU 過高問題的排查

1. 引言 今天檢視監控無意間突然發現自己的伺服器上,CPU 佔用率飆升到 100%,load 升到 10 以上,登入的響應已經達到半分鐘。 馬上執行 top,發現主要是 mongodb 佔用了大量