系統技術非業餘研究 » iotop統計linux下per程序的IO活動
Linux下的IO統計工具如iostat, nmon等大多數是隻能統計到per裝置的讀寫情況, 如果你想知道每個程序是如何使用IO的就比較麻煩.
當然如果你會systemtap, 或者blktrace這些事情難不到你, 但是沒專用工具總不是很舒服的. 幸運的是Linux 2.6.20核心以後提供了基於每個程序的IO記賬功能,所以就有了類似iotop這樣方便的工具.
Iotop is a Python program with a top like UI used to show of behalf of which process is the I/O going on.
在RHEL6或者ubuntu下使用就非常簡單, 我簡單的演示下ubuntu10下使用:
安裝先:
$ apt-get install iotop
直接執行就好:
$iotop
截圖如下:
它還支援累加方式顯示IO情況,挺方便的,具體參考man iotop
玩的開心.
Post Footer automatically generated by wp-posturl plugin for wordpress.
No related posts.
相關推薦
系統技術非業餘研究 » iotop統計linux下per程序的IO活動
Linux下的IO統計工具如iostat, nmon等大多數是隻能統計到per裝置的讀寫情況, 如果你想知道每個程序是如何使用IO的就比較麻煩. 當然如果你會systemtap, 或者blktrace這些事情難不到你, 但是沒專用工具總不是很舒服的. 幸運的是Linux 2.6.20核心以後提供了
系統技術非業餘研究 » nmon（Linux下很好用的效能監測工具）介紹
The nmon tool is designed for AIX and Linux performance specialists to use for monitoring and analyzing performance data, including: * CPU utiliz
系統技術非業餘研究 » Shell Break模式下 ‘o’ 檢視port訊息
這是未公開的一個特性, 很方便檢視Erlang內部的port使用狀態. 演示下: [email protected]:~# erl Erlang R13B04 (erts-5.7.5) [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel
系統技術非業餘研究 » 網路棧記憶體不足引發程序掛起問題
我們知道TCP socket有傳送緩衝區和接收緩衝區，這二個緩衝區都可以透過setsockopt設定SO_SNDBUF，SO_RCVBUF來修改，但是這些值設多大呢？這些值和協議棧的記憶體控制相關的值什麼關係呢？ 我們來解釋下： $ sysctl net|grep mem net.core.wme
系統技術非業餘研究 » Understanding Linux CPU Load 資料彙總
最近關注線上CPU load的人挺多，很多人覺得load太高系統就有問題，就想各種辦法來折騰。其實在我看來load只是系統CPU執行佇列的在執行程序數的近似值, 如下圖： 對於Unix發展的初期，機器的效能比較差，CPU核數也少，參考意義比較大。現在的機器都是非常強悍的，CPU，記憶體，IO各個
系統技術非業餘研究 » Linux下新系統呼叫sync_file_range
我們在做資料庫程式或者IO密集型的程式的時候，通常在更新的時候，比如說資料庫程式，希望更新有一定的安全性，我們會在更新操作結束的時候呼叫fsync或者fdatasync來flush資料到持久裝置去。而且通常是以頁面為單位，16K一次或者4K一次。 安全性保證了，但是效能就有很大的損害。而且我們更新
系統技術非業餘研究 » Linux檔案預讀分析以及評估對系統的影響
Linux系統很重要的一個性能提升點就是它的Pagecache， 因為記憶體比IO快太多了，所以大家都想進辦法來利用這個cache。 檔案系統也不例外，為了達到高效能，檔案讀取通常採用預讀來預測使用者的行為，把使用者可能需要的資料預先讀取到cache去，達到高效能的目的。 Linux各個發行版re
系統技術非業餘研究 » Linux快取記憶體使用率調查
Linux的快取記憶體pagecache對效能的影響至關重要，但是實際系統中我們的利用率如何呢，特別是具體到每個裝置的利用情況。 從下圖我們可以很清楚的看到： 我們知道IO請求由vfs發起，經過pagecache快取，擋不住的就落實到io裝置去，那麼統計這個利用率就很簡單。 我們只要知道擋不住的
系統技術非業餘研究 » disktop per裝置per應用層面的IO讀寫統計
我們在調優IO 密集型的應用是通常需要知道IO的使用情況. 但是iostat只能知道系統全域性的,iotop只能知道每個應用的, 我們有時候需要細化到每個應用對每個裝置的使用情況. 比如說mysql資料庫我們通常把日誌和資料分開到不同的裝置, 那我們需要知道資料讀寫多少,日誌讀寫多少,分開的瞭解.
系統技術非業餘研究 » Linux下方便的socket讀寫檢視器（socktop）
晚上 雕樑 說要找個工具來調查下unix域套接字的傳送和接受情況，比如說A程式是否送出，B程式是否接收到，他找了tcpdump ,wireshark什麼的，貌似都不支援。 這時候還是偉大的systemtap來救助了。 因為所有的socket通訊都是通過socket介面來的，任何family的通訊
系統技術非業餘研究 » Linux下誰在消耗我們的cache
Linux下對檔案的訪問和裝置的訪問通常會被cache起來加快訪問速度，這個是系統的預設行為。 而cache需要耗費我們的記憶體，雖然這個記憶體最後可以通過echo 3>/proc/sys/vm/drop_caches這樣的命令來主動釋放。但是有時候我們還是需要理解誰消耗了我們的記憶體。 我
系統技術非業餘研究 » Linux系統記憶體相關資訊獲取
大型的伺服器，特別是資料庫伺服器的主要瓶頸主要在記憶體，CPU，以及IO上。CPU是可再生資源，不夠用等等就有了；記憶體和土地一樣是不可再生資源，被佔用了，後續的使用必須等到該資源釋放.而IO也非常依賴於記憶體的使用情況,故記憶體的倒騰效率會大大影響伺服器的效率,那麼瞭解伺服器記憶體的使用情況就非
系統技術非業餘研究 » 洞悉Linux系統軟硬體配置
我們在做伺服器的時候，老大扔給你一臺機器，要你在上面開發。通常伺服器軟體是非常依賴於系統的軟硬體的，軟體通常是要緊貼硬體的特性，如果我們不能瞭解機器的硬體，我們就無法高效的開發。 比如說想知道Linux的系統的版本，CPU有幾個，記憶體多少大， 機器什麼型號，Raid卡什麼型號，硬碟有幾個，檔案系
系統技術非業餘研究 » Linux下誰在切換我們的程序
我們在做Linux伺服器的時候經常會需要知道誰在做程序切換，什麼原因需要做程序切換。 因為程序切換的代價很高，我給出一個LMbench測試出來的數字： Context switching – times in microseconds – smaller is better ———————————
系統技術非業餘研究 » 用systemtap來修改下linux核心變數的值
我們在探索linux核心的時候，經常需要調整下變數的值，看它對系統的影響。如果這個值沒有透過/proc來修改的話，那隻能編譯核心。這個步驟是非常繁瑣的。現在我們有systemtap這個利器來幫忙了。 演示如下： 我們通過修改過 extern int sysctl_tcp_fin_timeout;的
系統技術非業餘研究 » Linux下pstack的實現
Linux下有時候我們需要知道一個程序在做什麼，比如說程式不正常的時候，他到底在幹嗎？最直接的方法就是打印出他所有執行緒的呼叫棧，這樣我們從棧再配合程式程式碼就知道程式在幹嗎了。 Linux下這個工具叫做pstack. 使用方法是 # pstack Usage: pstack <proce
系統技術非業餘研究 » Linux下試驗大頁面對映（MAP_HUGETLB）
Linux對大頁面記憶體的引入對減少TLB的失效效果不錯，特別是記憶體大而密集型的程式，比如說在資料庫中的使用。innodb引擎就支援大頁面記憶體，具體使用可參見 這裡。 大頁面更詳細的資料可以參考： Documentation/vm/hugetlbpage.txt 過去使用大頁面記憶體主要透過h
系統技術非業餘研究 » latencytop深度瞭解你的Linux系統的延遲
我們在系統調優或者定位問題的時候，經常會發現多執行緒程式的效率很低，但是又不知道問題出在哪裡，就知道上下文切換很多，但是為什麼上下文切換，是誰導致切換，我們就不知道了。上下文切換可以用dstat這樣的工具檢視，比如： $dstat ----total-cpu-usage---- -dsk/tot
系統技術非業餘研究 » itop更方便的瞭解Linux下中斷情況
乘著公司搬家的功夫,寫點東西! 在作網路程式的時候, 經常需要了解interrupts和軟中斷的平衡情況, 需要知道每秒有多少中斷髮生,發生在哪個cpu上. Linux下中斷來源可以從 /proc/interrupts 中瞭解到: $ cat /proc/interrupts
系統技術非業餘研究 » Iostat看不到裝置統計資訊的原因分析
最近在把玩些高速的SSD和nvram裝置的時候，發現iostat無法統計到這些裝置的資訊，很是奇怪，於是分析和總結了一把，挺有意思的。 現象描述如下： # uname -a Linux dr4000 2.6.32-131.17.1.el6.x86_64 #1 SMP Wed Oct 5 17:1