查看linuxio

❶ linux怎樣查看那個進程佔用網路io

查看linux進程佔用埠步驟如下：

1. lsof -i 用以顯示符合條件的進程情況，lsof(list open files)是一個列出當前系統打開文件的工具。以root用戶來執行lsof -i命令，如下圖

   

   
   

   ❷ 如何找出Linux系統高IO的思路總結

   前言
   
   I/O Wait是一個需要使用高級的工具來debug問題原因，當然也有許多基本工具的高級用法。I/O wait的問題難以定位的原因是：因為我們有很多工具可以告訴你I/O 受限了，但是並沒有告訴你具體是哪個進程引起的。
   
   1. 如何確認，是否是I/O問題導致系統緩慢
   
   確認是否是I/O導致的系統緩慢我們可以使用多個命令，但是，最簡單的是unix的命令 top
   
   # top
   
   top - 14:31:20 up 35 min, 4 users, load average: 2.25, 1.74, 1.68
   
   Tasks: 71 total, 1 running, 70 sleeping, 0 stopped, 0 zombie
   
   Cpu(s): 2.3%us, 1.7%sy, 0.0%ni, 0.0%id, 96.0%wa, 0.0%hi, 0.0%si, 0.0%st
   
   Mem: 245440k total, 241004k used, 4436k free, 496k buffers
   
   Swap: 409596k total, 5436k used, 404160k free, 182812k cached
   
   從CPU這行，可以發現CPU的io wait；這里是96.0%。越高就代表CPU用於io wait的資源越多。
   
   2. 找出哪個磁碟正在被寫入
   
   上邊的top命令從一個整體上說明了I/O wait，但是並沒有說明是哪塊磁碟影響的，想知道是哪塊磁碟引發的問題，可以使用另外一個命令 iostat 命令
   
   $ iostat -x 2 5
   
   avg-cpu: %user %nice %system %iowait %steal %idle
   
     3.66 0.00 47.64 48.69 0.00 0.00
   
   Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
   
   sda 44.50 39.27 117.28 29.32 11220.94 13126.70 332.17 65.77 462.79 9.80 2274.71 7.60 111.41
   
   dm-0 0.00 0.00 83.25 9.95 10515.18 4295.29 317.84 57.01 648.54 16.73 5935.79 11.48 107.02
   
   dm-1 0.00 0.00 57.07 40.84 228.27 163.35 8.00 93.84 979.61 13.94 2329.08 10.93 107.02
   
   iostat 會每2秒更新一次，一共列印5次信息， -x 的選項是列印出擴展信息
   
   第一個iostat 報告會列印出系統最後一次啟動後的統計信息，這也就是說，在多數情況下，第一個列印出來的信息應該被忽略，剩下的報告，都是基於上一次間隔的時間。舉例子來說，這個命令會列印5次，第二次的報告是從第一次報告出來一個後的統計信息，第三次是基於第二次 ，依次類推
   
   所以，一定記住：第一個忽略！
   
   在上面的例子中，sda的%utilized 是111.41%，這個很好的說明了有進程正在寫入到sda磁碟中。
   
   除了%utilized 外，我們可以從iostat得到更加豐富的資源信息，例如每毫秒讀寫請求（rrqm/s & wrqm/s)），每秒讀寫的（(r/s & w/s)。在上邊的例子中，我們的項目看起來正在讀寫非常多的信息。這個對我們查找相應的進程非常有用。
   
   3. 找出導致高IO的進程
   
   # iotop
   
   Total DISK READ: 8.00 M/s | Total DISK WRITE: 20.36 M/s
   
     TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
   
   15758 be/4 root 7.99 M/s 8.01 M/s 0.00 % 61.97 % bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
   
   最簡單的方法就是用iotop找出哪個進程用了最多的存儲資源，從上面可以看到是bonnie++。
   
   iotop很好用，但是不是默認安裝的。
   
   如果沒有iotop，下面的方式也可以讓你有種方法縮小范圍，盡快找到是哪個進程。
   
   ps 命令對內存和CPU有一個統計，但是他沒有對磁碟I/O的統計，雖然他沒有顯示磁碟I/O，但是它顯示進行的狀態，我們可以用來知道一個進程是否正在等待I/O
   
   主要的進程狀態有：
   
   PROCESS STATE CODES
   
   D uninterruptible sleep (usually IO)
   
   R running or runnable (on run queue)
   
   S interruptible sleep (waiting for an event to complete)
   
   T stopped, either by a job control signal or because it is being traced.
   
   W paging (not valid since the 2.6.xx kernel)
   
   X dead (should never be seen)
   
   Z defunct ("zombie") process, terminated but not reaped by its parent.
   
   等待I/O的進程的狀態一般是「uninterruptible sleep」，或者「D」，我們可以很容易的查找到正在等待I/O的進程
   
   # for x in `seq 1 1 10`; do ps -eo state,pid,cmd | grep "^D"; echo "----"; sleep 5; done
   
   D 248 [jbd2/dm-0-8]
   
   D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
   
   ----
   
   D 22 [kswapd0]
   
   D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
   
   ----
   
   D 22 [kswapd0]
   
   D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
   
   ----
   
   D 22 [kswapd0]
   
   D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
   
   ----
   
   D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
   
   上邊的例子會循環的輸出狀態是D的進程，每5秒一次，一共10次
   
   從輸出我們可以知道 bonnie++ 的pid是16528 ，在waiting，bonnie++看起來就是我們想找到的進程，但是，只是從它的狀態，我們沒有辦法證明就是bonnie++引起的I/O等待。
   
   為了證明，我們可以可以查看/proc，每個進程目錄下都有一個叫io的文件，里邊保存這和iotop類似的信息。
   
   # cat /proc/16528/io
   
   rchar: 48752567
   
   wchar: 549961789
   
   syscr: 5967
   
   syscw: 67138
   
   read_bytes: 49020928
   
   write_bytes: 549961728
   
   cancelled_write_bytes: 0
   
   read_bytes和write_bytes是這個進程從磁碟讀寫的位元組，在這個例子中，bonnie++進程讀取了46M的數據並且寫入了524MB的數據到磁碟上。
   
   4. 找出哪個文件正在被大量寫入
   
   lsof 命令可以展示一個進程打開的所有文件。從這個列表中，我們可以找到哪個文件被寫入。
   
   # lsof -p 16528
   
   COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
   
   bonnie++ 16528 root cwd DIR 252,0 4096 130597 /tmp
   
   <truncated>
   
   bonnie++ 16528 root 8u REG 252,0 501219328 131869 /tmp/Bonnie.16528
   
   bonnie++ 16528 root 9u REG 252,0 501219328 131869 /tmp/Bonnie.16528
   
   bonnie++ 16528 root 10u REG 252,0 501219328 131869 /tmp/Bonnie.16528
   
   bonnie++ 16528 root 11u REG 252,0 501219328 131869 /tmp/Bonnie.16528
   
   bonnie++ 16528 root 12u REG 252,0 501219328 131869 <strong>/tmp/Bonnie.16528</strong>
   
   # df /tmp
   
   Filesystem 1K-blocks Used Available Use% Mounted on
   
   /dev/mapper/workstation-root 7667140 2628608 4653920 37% /
   
   # pvdisplay
   
     --- Physical volume ---
   
     PV Name /dev/sda5
   
     VG Name workstation
   
     PV Size 7.76 GiB / not usable 2.00 MiB
   
     Allocatable yes
   
     PE Size 4.00 MiB
   
     Total PE 1986
   
     Free PE 8
   
     Allocated PE 1978
   
     PV UUID CLbABb-GcLB-l5z3-TCj3-IOK3-SQ2p-RDPW5S
   
   使用pvdisplay可以看到，pv設備就是/dev/sda5,正是我們前面找到的sda。
   
   參考文檔：http://bencane.com/2012/08/06/troubleshooting-high-io-wait-in-linux/

   ❸ Linux如何查看與測試磁碟IO性能

   top命令的其他參數代表的含義詳見top命令詳解
   
   sar 命令是分析系統瓶頸的神器，可以用來查看 CPU 、內存、磁碟、網路等性能。
   
   sar 命令查看當前磁碟性能的命令為：

   ❹ linux 如何查看網路io

   netstat -an看佔用埠
   /sbin/ifconfig看多少個網卡，IP地址，路由信息等

   ❺ 如何查看Linux下進程的IO活動狀況 00 Hey，Linux

   前段時間，幾台測試伺服器的Web應用響應速度非常慢，系統負載也比較高，> 10， 但CPU和內存卻很閑，於是懷疑是磁碟的性能瓶頸,通過vmstat和iostat看到IO的讀寫量非常大，尤其是用iostat -x 1命令可以很直觀的看到IO的使用率一直在100%。
   但究竟是什麼進程導致的高IO呢，由於每台伺服器上都有JBoss和MySQL的存在，JBoss會不停的產生很多小的數據文件和生成文本資料庫的數據，而MySQL則會不停的從Master同步新的數據。因此我們懷疑是這兩個進程導致的高IO，通過停止了JBoss和MySQL之後，IO立刻降為0%. 但我們還是不能確定誰是主因，於是尋找可以查看特定進程IO的方法。
   最後，找到了兩個方法可以查看進程IO的活動狀況。
   1. 第一個方法是通過一個python腳本來實現。
   方法是將以下內容另存為一個叫io.py的腳本中，然後直接以root身份執行腳本，就可以看到如下圖所示的信息（由於我們已經通過升級到SSD硬碟解決了MySQL的IO問題，所以不能提供關於MySQL的截圖了），其中出現次數最多，數據最大的進程，就是導致高IO的主因。不過比較遺憾的是這個腳本並不能顯示進程在每一秒的准確的IO讀寫。
   
   # vim io.py
   # chmod +x io.py
   # ./io.py
   #!/usr/bin/python
   # Monitoring per-process disk I/O activity
   # written by http://www.vpsee.com
   
   import sys, os, time, signal, re
   
   class DiskIO:
   def __init__(self, pname=None, pid=None, reads=0, writes=0):
   self.pname = pname
   self.pid = pid
   self.reads = 0
   self.writes = 0
   
   def main():
   argc = len(sys.argv)
   if argc != 1:
   print "usage: ./iotop"
   sys.exit(0)
   
   if os.getuid() != 0:
   print "must be run as root"
   sys.exit(0)
   
   signal.signal(signal.SIGINT, signal_handler)
   os.system('echo 1 > /proc/sys/vm/block_mp')
   print "TASK PID READ WRITE"
   while True:
   os.system('dmesg -c > /tmp/diskio.log')
   l = []
   f = open('/tmp/diskio.log', 'r')
   line = f.readline()
   while line:
   m = re.match(\
   '^(\S+)\((\d+)\): (READ|WRITE) block (\d+) on (\S+)', line)
   if m != None:
   if not l:
   l.append(DiskIO(m.group(1), m.group(2)))
   line = f.readline()
   continue
   found = False
   for item in l:
   if item.pid == m.group(2):
   found = True
   if m.group(3) == "READ":
   item.reads = item.reads + 1
   elif m.group(3) == "WRITE":
   item.writes = item.writes + 1
   if not found:
   l.append(DiskIO(m.group(1), m.group(2)))
   line = f.readline()
   time.sleep(1)
   for item in l:
   print "%-10s %10s %10d %10d" % \
   (item.pname, item.pid, item.reads, item.writes)
   
   def signal_handler(signal, frame):
   os.system('echo 0 > /proc/sys/vm/block_mp')
   sys.exit(0)
   
   if __name__=="__main__":
   main()
   
   2. 另一個方法是將Linux的內核升級到 >=2.6.20，然後安裝一個iotop軟體來實現。
   不過這種改動並不適用於生產環境，因為在RHEL5.6和5.7上，內核都在 2.6.20以下。但是它所顯示的結果是非常准確的，所以對於新上線的機器以及測試環境，非常值得一試，具體方法如下：
   
   下載和升級新內核（>=2.6.20），編譯時打開 TASK_DELAY_ACCT 和 TASK_IO_ACCOUNTING 選項。
   解壓內核後進入配置界面：
   # wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.39.tar.gz
   # tar jxvf linux-2.6.39.tar.gz
   # mv linux-2.6.39 /usr/src/
   # cd /usr/src/linux-2.6.39
   # make oldconfig //使用make oldconfig可以繼承老的kernel的配置，為自己的配置省去很多麻煩。
   # make menuconfig
   把General setup - Enable per-task storage I/O accounting這個選項選上。
   
   # vim .config
   將#CONFIG_SYSFS_DEPRECATED_V2 is not set的注釋去掉的，將其改為y，即修改為CONFIG_SYSFS_DEPRECATED_V2=y。
   保存內核後編譯內核：
   # make
   # make moles
   # make moles_install
   # make install
   修改默認以新的內核啟動：
   # vi /boot/grub/grub.conf
   default=0
   將新的內核配置文件復制到/boot目錄：
   # cp /usr/src/linux-2.6.39/.config /boot/config-2.6.39
   重啟伺服器：
   # reboot
   # uname –r
   2.6.39
   重啟完成後確認內核版本是否正確。
   源碼安裝iotop所需的Python 2.7.2（>= 2.5）：
   # wget http://www.python.org/ftp/python/2.7.2/Python-2.7.2.tgz
   # tar xzvf Python-2.7.2.tgz
   # cd Python-2.7.2
   # ./configure
   # make; make install
   下載並安裝iotop：
   # wget http://guichaz.free.fr/iotop/files/iotop-0.4.4.tar.bz2
   # tar -xjvf iotop-0.4.4.tar.bz2
   # cd iotop-0.4.4
   # python setup.py build
   # python setup.py install
   然後就可以使用iotop看到如下圖所示的信息：

   ❻ Linux 磁碟IO

   磁碟結構與數據存儲方式, 數據是如何存儲的，又通過怎樣的方式被訪問？

   機械硬碟主要由磁碟碟片、磁頭、主軸與傳動軸等組成；數據就存放在磁碟碟片中

   現代硬碟尋道都是採用CHS( Cylinder Head Sector )的方式，硬碟讀取數據時，讀寫磁頭沿徑向移動，移到要讀取的扇區所在磁軌的上方，這段時間稱為 尋道時間(seek time) 。 因讀寫磁頭的起始位置與目標位置之間的距離不同，尋道時間也不同 。磁頭到達指定磁軌後，然後通過碟片的旋轉，使得要讀取的扇區轉到讀寫磁頭的下方，這段時間稱為 旋轉延遲時間(rotational latencytime) 。然後再讀寫數據，讀寫數據也需要時間，這段時間稱為 傳輸時間(transfer time) 。

   固態硬碟主要由主控晶元、快閃記憶體顆粒與緩存組成；數據就存放在快閃記憶體晶元中
   通過主控晶元進行定址， 因為是電信號方式， 沒有任何物理結構， 所以定址速度非常快且與數據存儲位置無關

   如何查看系統IO狀態

   查看磁碟空間

   調用 open , fwrite 時到底發生了什麼?

   在一個IO過程中，以下5個API/系統調用是必不可少的
   Create 函數用來打開一個文件，如果該文件不存在，那麼需要在磁碟上創建該文件
   Open 函數用於打開一個指定的文件。如果在 Open 函數中指定 O_CREATE 標記，那麼 Open 函數同樣可以實現 Create 函數的功能
   Clos e函數用於釋放文件句柄
   Write 和 Read 函數用於實現文件的讀寫過程

   O_SYNC (先寫緩存, 但是需要實際落盤之後才返回, 如果接下來有讀請求, 可以從內存讀 ), write-through
   O_DSYNC (D=data, 類似O_SYNC, 但是只同步數據, 不同步元數據)
   O_DIRECT (直接寫盤, 不經過緩存)
   O_ASYNC (非同步IO, 使用信號機制實現, 不推薦, 直接用aio_xxx)
   O_NOATIME (讀取的時候不更新文件 atime(access time))

   sync() 全局緩存寫回磁碟
   fsync() 特定fd的sync()
   fdatasync() 只刷數據, 不同步元數據

   mount noatime(全局不記錄atime), re方式(只讀), sync(同步方式)

   一個IO的傳奇一生 這里有一篇非常好的資料，講述了整個IO過程；
   下面簡單記錄下自己的理解的一次常見的Linux IO過程， 想了解更詳細及相關源碼，非常推薦閱讀上面的原文

   Linux IO體系結構

   [站外圖片上傳中...(image-38a7b-1644137945193)]

   Superblock 超級描述了整個文件系統的信息。為了保證可靠性，可以在每個塊組中對superblock進行備份。為了避免superblock冗餘過多，可以採用稀疏存儲的方式，即在若干個塊組中對superblock進行保存，而不需要在所有的塊組中都進行備份
   GDT 組描述符表 組描述符表對整個組內的數據布局進行了描述。例如，數據塊點陣圖的起始地址是多少？inode點陣圖的起始地址是多少？inode表的起始地址是多少？塊組中還有多少空閑塊資源等。組描述符表在superblock的後面
   數據塊點陣圖 數據塊點陣圖描述了塊組內數據塊的使用情況。如果該數據塊已經被某個文件使用，那麼點陣圖中的對應位會被置1，否則該位為0
   Inode點陣圖 Inode點陣圖描述了塊組內inode資源使用情況。如果一個inode資源已經使用，那麼對應位會被置1
   Inode表 （即inode資源）和數據塊。這兩塊占據了塊組內的絕大部分空間，特別是數據塊資源

   一個文件是由inode進行描述的。一個文件佔用的數據塊block是通過inode管理起來的 。在inode結構中保存了直接塊指針、一級間接塊指針、二級間接塊指針和三級間接塊指針。對於一個小文件，直接可以採用直接塊指針實現對文件塊的訪問；對於一個大文件，需要採用間接塊指針實現對文件塊的訪問

   最簡單的調度器。它本質上就是一個鏈表實現的 fifo 隊列，並對請求進行簡單的 合並 處理。
   調度器本身並沒有提供任何可以配置的參數

   讀寫請求被分成了兩個隊列， 一個用訪問地址作為索引，一個用進入時間作為索引，並且採用兩種方式將這些request管理起來；
   在請求處理的過程中，deadline演算法會優先處理那些訪問地址臨近的請求，這樣可以最大程度的減少磁碟抖動的可能性。
   只有在有些request即將被餓死的時候，或者沒有辦法進行磁碟順序化操作的時候，deadline才會放棄地址優先策略，轉而處理那些即將被餓死的request

   deadline演算法可調整參數
   read_expire : 讀請求的超時時間設置(ms)。當一個讀請求入隊deadline的時候，其過期時間將被設置為當前時間＋read_expire，並放倒fifo_list中進行排序
   write_expire :寫請求的超時時間設置(ms)
   fifo_batch :在順序（sort_list）請求進行處理的時候，deadline將以batch為單位進行處理。每一個batch處理的請求個數為這個參數所限制的個數。在一個batch處理的過程中，不會產生是否超時的檢查，也就不會產生額外的磁碟尋道時間。這個參數可以用來平衡順序處理和飢餓時間的矛盾，當飢餓時間需要盡可能的符合預期的時候，我們可以調小這個值，以便盡可能多的檢查是否有飢餓產生並及時處理。增大這個值當然也會增大吞吐量，但是會導致處理飢餓請求的延時變長
   writes_starved :這個值是在上述deadline出隊處理第一步時做檢查用的。用來判斷當讀隊列不為空時，寫隊列的飢餓程度是否足夠高，以時deadline放棄讀請求的處理而處理寫請求。當檢查存在有寫請求的時候，deadline並不會立即對寫請求進行處理，而是給相關數據結構中的starved進行累計，如果這是第一次檢查到有寫請求進行處理，那麼這個計數就為1。如果此時writes_starved值為2，則我們認為此時飢餓程度還不足夠高，所以繼續處理讀請求。只有當starved >= writes_starved的時候，deadline才回去處理寫請求。可以認為這個值是用來平衡deadline對讀寫請求處理優先順序狀態的，這個值越大，則寫請求越被滯後處理，越小，寫請求就越可以獲得趨近於讀請求的優先順序
   front_merges :當一個新請求進入隊列的時候，如果其請求的扇區距離當前扇區很近，那麼它就是可以被合並處理的。而這個合並可能有兩種情況，一個是向當前位置後合並，另一種是向前合並。在某些場景下，向前合並是不必要的，那麼我們就可以通過這個參數關閉向前合並。默認deadline支持向前合並，設置為0關閉

   在調度一個request時，首先需要選擇一個一個合適的cfq_group。Cfq調度器會為每個cfq_group分配一個時間片，當這個時間片耗盡之後，會選擇下一個cfq_group。每個cfq_group都會分配一個vdisktime，並且通過該值採用紅黑樹對cfq_group進行排序。在調度的過程中，每次都會選擇一個vdisktime最小的cfq_group進行處理。
   一個cfq_group管理了7棵service tree，每棵service tree管理了需要調度處理的對象cfq_queue。因此，一旦cfq_group被選定之後，需要選擇一棵service tree進行處理。這7棵service tree被分成了三大類，分別為RT、BE和IDLE。這三大類service tree的調度是按照優先順序展開的

   通過優先順序可以很容易的選定一類Service tree。當一類service tree被選定之後，採用service time的方式選定一個合適的cfq_queue。每個Service tree是一棵紅黑樹，這些紅黑樹是按照service time進行檢索的，每個cfq_queue都會維護自己的service time。分析到這里，我們知道，cfq演算法通過每個cfq_group的vdisktime值來選定一個cfq_group進行服務，在處理cfq_group的過程通過優先順序選擇一個最需要服務的service tree。通過該Service tree得到最需要服務的cfq_queue。該過程在 cfq_select_queue 函數中實現

   一個cfq_queue被選定之後，後面的過程和deadline演算法有點類似。在選擇request的時候需要考慮每個request的延遲等待時間，選擇那種等待時間最長的request進行處理。但是，考慮到磁碟抖動的問題，cfq在處理的時候也會進行順序批量處理，即將那些在磁碟上連續的request批量處理掉

   cfq調度演算法的參數
   back_seek_max :磁頭可以向後定址的最大范圍，默認值為16M
   back_seek_penalty :向後定址的懲罰系數。這個值是跟向前定址進行比較的

   fifo_expire_async :設置非同步請求的超時時間。同步請求和非同步請求是區分不同隊列處理的，cfq在調度的時候一般情況都會優先處理同步請求，之後再處理非同步請求，除非非同步請求符合上述合並處理的條件限制范圍內。當本進程的隊列被調度時，cfq會優先檢查是否有非同步請求超時，就是超過fifo_expire_async參數的限制。如果有，則優先發送一個超時的請求，其餘請求仍然按照優先順序以及扇區編號大小來處理
   fifo_expire_sync :這個參數跟上面的類似，區別是用來設置同步請求的超時時間
   slice_idle :參數設置了一個等待時間。這讓cfq在切換cfq_queue或service tree的時候等待一段時間，目的是提高機械硬碟的吞吐量。一般情況下，來自同一個cfq_queue或者service tree的IO請求的定址局部性更好，所以這樣可以減少磁碟的定址次數。這個值在機械硬碟上默認為非零。當然在固態硬碟或者硬RAID設備上設置這個值為非零會降低存儲的效率，因為固態硬碟沒有磁頭定址這個概念，所以在這樣的設備上應該設置為0，關閉此功能
   group_idle :這個參數也跟上一個參數類似，區別是當cfq要切換cfq_group的時候會等待一段時間。在cgroup的場景下，如果我們沿用slice_idle的方式，那麼空轉等待可能會在cgroup組內每個進程的cfq_queue切換時發生。這樣會如果這個進程一直有請求要處理的話，那麼直到這個cgroup的配額被耗盡，同組中的其它進程也可能無法被調度到。這樣會導致同組中的其它進程餓死而產生IO性能瓶頸。在這種情況下，我們可以將slice_idle ＝ 0而group_idle ＝ 8。這樣空轉等待就是以cgroup為單位進行的，而不是以cfq_queue的進程為單位進行，以防止上述問題產生
   low_latency :這個是用來開啟或關閉cfq的低延時（low latency）模式的開關。當這個開關打開時，cfq將會根據target_latency的參數設置來對每一個進程的分片時間（slice time）進行重新計算。這將有利於對吞吐量的公平（默認是對時間片分配的公平）。關閉這個參數（設置為0）將忽略target_latency的值。這將使系統中的進程完全按照時間片方式進行IO資源分配。這個開關默認是打開的

   target_latency :當low_latency的值為開啟狀態時，cfq將根據這個值重新計算每個進程分配的IO時間片長度
   quantum :這個參數用來設置每次從cfq_queue中處理多少個IO請求。在一個隊列處理事件周期中，超過這個數字的IO請求將不會被處理。這個參數只對同步的請求有效
   slice_sync :當一個cfq_queue隊列被調度處理時，它可以被分配的處理總時間是通過這個值來作為一個計算參數指定的。公式為： time_slice = slice_sync + (slice_sync/5 * (4 - prio)) 這個參數對同步請求有效
   slice_async :這個值跟上一個類似，區別是對非同步請求有效
   slice_async_rq :這個參數用來限制在一個slice的時間范圍內，一個隊列最多可以處理的非同步請求個數。請求被處理的最大個數還跟相關進程被設置的io優先順序有關

   通常在Linux上使用的IO介面是同步方式的，進程調用 write / read 之後會阻塞陷入到內核態，直到本次IO過程完成之後，才能繼續執行，下面介紹的非同步IO則沒有這種限制，但是當前Linux非同步IO尚未成熟

   目前Linux aio還處於較不成熟的階段，只能在 O_DIRECT 方式下才能使用(glibc_aio)，也就是無法使用默認的Page Cache機制

   正常情況下，使用aio族介面的簡要方式如下：

   io_uring 是 2019 年 5 月發布的 Linux 5.1 加入的一個重大特性 —— Linux 下的全新的非同步 I/O 支持，希望能徹底解決長期以來 Linux AIO 的各種不足
   io_uring 實現非同步 I/O 的方式其實是一個生產者-消費者模型:

   邏輯卷管理
   RAID0
   RAID1
   RAID5（糾錯）
   條帶化

   Linux系統性能調整：IO過程
   Linux的IO調度
   一個IO的傳奇一生
   理解inode
   Linux 文件系統是怎麼工作的？
   Linux中Buffer cache性能問題一探究竟
   Asynchronous I/O and event notification on linux
   AIO 的新歸宿：io_uring
   Linux 文件 I/O 進化史（四）：io_uring —— 全新的非同步 I/O

   ❼ 如何查看Linux cpu/內存/硬碟/IO等數據

   cpu
   top
   看進程和cpu的使用率
   uptime
   看cpu負載
   內存
   free
   看內存呢虛擬內存
   -m
   是以兆為單位顯示
   硬碟
   df
   -hT
   查看個各個分區的使用情況，-h是以G為單位顯示
   -T是顯示分區的系統類型
   iostat
   -x
   1
   可以查看磁碟的IO信息

   ❽ linux查看網路io使用率

   sar -n DEV
   
   不帶其他參數 看當天的網路IO 預設取樣時間為1秒,間隔為10分鍾
   加 -f /var/log/sa/saxx可察看某日的歷史,xx為當月或上月的日期(day of the month)前提是改文件存在
   
   察看即時IO用sar -n DEV 1 999 表示取樣間隔為1秒,取樣999次
   
   具體欄位的含義我就不醉贅述了

   ❾ linux系統如何查看網路IO

   首先 、用top命令查看

   top - 16:15:05 up 6 days, 6:25, 2 users, load average: 1.45, 1.77, 2.14

   Tasks: 147 total, 1 running, 146 sleeping, 0 stopped, 0 zombie

   Cpu(s): 0.2% us, 0.2% sy, 0.0% ni, 86.9% id, 12.6% wa, 0.0% hi, 0.0% si

   Mem: 4037872k total, 4003648k used, 34224k free, 5512k buffers

   Swap: 7164948k total, 629192k used, 6535756k free, 3511184k cached

   查看12.6% wa

   IO等待所佔用的CPU時間的百分比,高過30%時IO壓力高

   其次、 用iostat -x 1 10

   avg-cpu: %user %nice %sys %iowait %idle

   0.00 0.00 0.25 33.46 66.29

   Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

   sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

   sdb 0.00 1122 17.00 9.00 192.00 9216.00 96.00 4608.00 123.79 137.23 1033.43 13.17 100.10

   sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

   查看%util 100.10 %idle 66.29

   如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁碟可能存在瓶頸。

   idle小於70% IO壓力就較大了,一般讀取速度有較多的wait.

   同時可以結合vmstat 查看查看b參數(等待資源的進程數)

   vmstat -1

   如果你想對硬碟做一個IO負荷的壓力測試可以用如下命令

   time dd if=/dev/zero bs=1M count=2048 of=direct_2G

   此命令為在當前目錄下新建一個2G的文件

   我們在新建文件夾的同時來測試IO的負荷情況。

   ❿ 如何查看Linux下進程的IO活動狀況 00 Hey，Linux

   您好，很高興為您解答。伺服器cpu使用率不高，load比較高，所以要查看一下IO。硬碟IO可以通過命令vmstat或iostat獲得（也可以用yum安裝dstat獲得），網路IO可以用iftop命令獲取。但是不知道那個進程使用硬碟IO比較高，通過查找沒有找到相關命令，只好自己寫個腳本進行統計處理。本腳本在CentOS6下（kernel2.6以上）python2.6測試通過。直接運行腳本，默認情況下收集3秒鍾數據，顯示讀寫最高的前三個進程。如用參數可以使用命令「pythonfhip.py453」，第一個數位每次收集讀寫數據的間隔秒數，第二個數是列印出讀寫最多的n個進程，第三個為運行腳本的次數。因為參數部分寫的比較簡單那，所以用參數必須3個全寫。。#!/bin/python#-*-coding:utf-8-*-#Filename:ind_high_io_process#Revision:1.0#Date:2013-3-8#Author:simonzhang#web:#######sys_proc_path='/proc/'re_find_process_number='^\d+$'#####通過/proc/$pid/io獲取讀寫信息####defcollect_info():_tmp={}re_find_process_dir=re.compile(re_find_process_number)foriinos.listdir(sys_proc_path):ifre_find_process_dir.search(i):#獲得進程名process_name=open("%s%s/stat"%(sys_proc_path,i),"rb").read().split("")[1]#讀取io信息rw_io=open("%s%s/io"%(sys_proc_path,i),"rb").readlines()for_infoinrw_io:cut_info=strip(_info).split(':')ifstrip(cut_info[0])=="read_bytes":read_io=int(strip(cut_info[1]))ifstrip(cut_info[0])=="write_bytes":write_io=int(strip(cut_info[1]))_tmp[i]={"name":process_name,"read_bytes":read_io,"write_bytes":write_io}return_tmpdefmain(_sleep_time,_list_num):_sort_read_dict={}_sort_write_dict={}#獲取系統讀寫數據process_info_list_frist=collect_info()time.sleep(_sleep_time)process_info_list_second=collect_info()#將讀數據和寫數據進行分組，寫入兩個字典中forloopinprocess_info_list_second.keys():second_read_v=process_info_list_second[loop]["read_bytes"]second_write_v=process_info_list_second[loop]["write_bytes"]try:frist_read_v=process_info_list_frist[loop]["read_bytes"]except:frist_read_v=0try:frist_write_v=process_info_list_frist[loop]["write_bytes"]except:frist_write_v=0#計算第二次獲得數據域第一次獲得數據的差_sort_read_dict[loop]=second_read_v-frist_read_v_sort_write_dict[loop]=second_write_v-frist_write_v#將讀寫數據進行排序sort_read_dict=sorted(_sort_read_dict.items(),key=lambda_sort_read_dict:_sort_read_dict[1],reverse=True)sort_write_dict=sorted(_sort_write_dict.items(),key=lambda_sort_write_dict:_sort_write_dict[1],reverse=True)#列印統計結果print"pidprocessread(bytes)pidprocesswrite(btyes)"for_numinrange(_list_num):read_pid=sort_read_dict[_num][0]write_pid=sort_write_dict[_num][0]res="%s"%read_pidres+=""*(8-len(read_pid))+process_info_list_second[read_pid]["name"]res+=""*(12-len(process_info_list_second[read_pid]["name"]))+"%s"%sort_read_dict[_num][1]res+=""*(12-len("%s"%sort_read_dict[_num][1]))+write_pidres+=""*(8-len(write_pid))+process_info_list_second[write_pid]["name"]res+=""*(12-len("%s"%process_info_list_second[write_pid]["name"]))+"%s"%sort_write_dict[_num][1]printresprint"\n"*1if__name__=='__main__':try:_sleep_time=sys.argv[1]except:_sleep_time=3try:_num=sys.argv[2]except:_num=3try:loop=sys.argv[3]except:loop=1foriinrange(int(loop)):main(int(_sleep_time),int(_num))如若滿意，請點擊【採納答案】，如若還有問題，請點擊【追問】希望我的回答對您有所幫助，望採納！~O(∩_∩)O~