導航:首頁 > 操作系統 > linux測試io性能

linux測試io性能

發布時間:2023-07-17 12:23:03

A. linux中block IO,no-block IO,非同步IO,IO多路復用筆記

        現在操作系統都是採用虛擬存儲器,那麼對32位操作系統而言,它的定址空間(虛擬存儲空間)為4G(2的32次方)。操作系統的核心是內核,獨立於普通的應用程序,可以訪問受保護的內存空間,也有訪問底層硬體設備的所有許可權。 為了保證用戶進程不能直接操作內核(kernel),保證內核的安全,操心系統將虛擬空間劃分為兩部分,一部分為內核空間,一部分為用戶空間 。針對linux操作系統而言, 將最高的1G位元組(從虛擬地址0xC0000000到0xFFFFFFFF) ,供內核使用,稱為內核空間, 而將較低的3G位元組(從虛擬地址0x00000000到0xBFFFFFFF),供各個進程使用,稱為用戶空間。

        文件描述符(File descriptor)是計算機科學中的一個術語,是一個用於表述 指向文件的引用的抽象化概念 。文件描述符在形式上是一個非負整數。 實際上,它是一個索引值,指向內核為每一個進程所維護的該進程打開文件的記錄表 。當程序打開一個現有文件或者創建一個新文件時,內核向進程返回一個文件描述符。在程序設計中,一些涉及底層的程序編寫往往會圍繞著文件描述符展開。但是文件描述符這一概念往往只適用於UNIX、Linux這樣的操作系統。

       剛才說了,對於一次IO訪問(以read舉例),數據會先被拷貝到操作系統內核的緩沖區中,然後才會從操作系統內核的緩沖區拷貝到應用程序的地址空間。所以說,當一個read操作發生時,它會經歷兩個階段:

1、等待數據准備 (Waiting for the data to be ready)

2、將數據從內核拷貝到進程中 (Copying the data from the kernel to the process)

正式因為這兩個階段,linux系統產生了下面 五種網路模式 的方案。

阻塞 I/O(blocking IO)

非阻塞 I/O(nonblocking IO)

I/O 多路復用( IO multiplexing)

非同步 I/O(asynchronous IO)

信號驅動 I/O( signal driven IO)

註:由於signal driven IO在實際中並不常用,所以我這只提及剩下的四種IO Model。

阻塞 I/O(blocking IO)

在linux中,默認情況下所有的socket都是blocking,一個典型的讀操作流程大概是這樣:

        當用戶進程調用了recvfrom這個系統調用,kernel就開始了IO的第一個階段:准備數據(對於網路IO來說,很多時候數據在一開始還沒有到達。比如,還沒有收到一個完整的UDP包。這個時候kernel就要等待足夠的數據到來)。這個過程需要等待,也就是說數據被拷貝到操作系統內核的緩沖區中是需要一個過程的。而在用戶進程這邊,整個進程會被阻塞(當然,是進程自己選擇的阻塞)。當kernel一直等到數據准備好了,它就會將數據從kernel中拷貝到用戶內存,然後kernel返回結果,用戶進程才解除block的狀態,重新運行起來。

所以,blocking IO的特點就是在IO執行的兩個階段都被block了(內核阻塞讀取數據,內核將數據復制到應用戶態)。

非阻塞 I/O(nonblocking IO)

linux下,可以通過設置socket使其變為non-blocking。當對一個non-blocking socket執行讀操作時,流程是這個樣子:

       當用戶進程發出read操作時,如果kernel中的數據還沒有準備好,那麼它並不會block用戶進程,而是立刻返回一個error。從用戶進程角度講 ,它發起一個read操作後,並不需要等待,而是馬上就得到了一個結果。用戶進程判斷結果是一個error時,它就知道數據還沒有準備好,於是它可以再次發送read操作。一旦kernel中的數據准備好了,並且又再次收到了用戶進程的system call,那麼它馬上就將數據拷貝到了用戶內存,然後返回。

所以,nonblocking IO的特點是用戶進程需要 不斷的主動詢問 kernel數據好了沒有( 內核讀取數據時,用戶態不需要阻塞,內核將數據復制到用戶態時,需要阻塞 )。

I/O 多路復用( IO multiplexing)

         IO multiplexing就是我們說的select,poll,epoll,有些地方也稱這種IO方式為event driven IO。select/epoll的好處就在於單個process就可以同時處理多個網路連接的IO。它的基本原理就是 select,poll,epoll這個function會不斷的輪詢所負責的所有socket ,當某個socket有數據到達了,就通知用戶進程。

        當用戶 進程調用了select , 那麼整個進程會被block ,而同時,kernel會「監視」所有 select負責的socket(一個管理多個socket連接),當任何一個socket中的數據准備好了,select就會返回 。這個時候用戶進程再調用read操作, 將數據從kernel拷貝到用戶進程 。

所以,I/O 多路復用的特點是通過一種機制一個進程能同時等待多個文件描述符,而這些文件描述符(套接字描述符)其中的任意一個進入讀就緒狀態,select()函數就可以返回。

這個圖和blocking IO的圖其實並沒有太大的不同,事實上,還更差一些。 因為這里需要使用兩個system call (select 和 recvfrom),而blocking IO只調用了一個system call (recvfrom) 。但是,用select的優勢在於它可以同時處理多個connection。

所以,如果處理的 連接數不是很高的話,使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好,可能延遲還更大 。select/epoll的優勢並不是對於單個連接能處理得更快,而是在於能處理更多的連接。)

在IO multiplexing Model中,實際中,對於每一個socket,一般都設置成為non-blocking,但是,如上圖所示,整個用戶的process其實是一直被block的。只不過process是被select這個函數block,而不是被socket IO給block。

總結:IO多路復用其實也是阻塞的,阻塞的地方在用當有socket連接有數據以後, 會阻塞知道數據從內核復制到用戶態(第二步阻塞)。

非同步 I/O(asynchronous IO)

inux下的asynchronous IO其實用得很少。先看一下它的流程:

        用戶進程發起read操作之後,立刻就可以開始去做其它的事。而另一方面,從kernel的角度,當它受到一個asynchronous read之後,首先它會立刻返回,所以不會對用戶進程產生任何block。然後,kernel會等待數據准備完成,然後將數據拷貝到用戶內存,當這一切都完成之後,kernel會給用戶進程發送一個signal,告訴它read操作完成了。

總結:兩個階段都不需要用戶進程干涉,內核將數據准備好以後通知用戶態去讀取

總結

blocking和non-blocking的區別

調用blocking IO會一直block住對應的進程直到操作完成,而non-blocking IO在kernel還准備數據的情況下會立刻返回。

synchronous IO和asynchronous IO的區別

在說明synchronous IO和asynchronous IO的區別之前,需要先給出兩者的定義。POSIX的定義是這樣子的:

- A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;

- An asynchronous I/O operation does not cause the requesting process to be blocked;

兩者的區別就在於synchronous IO做」IO operation」的時候會將process阻塞。按照這個定義,之前所述的 blocking IO,non-blocking IO,IO multiplexing都屬於synchronous IO 。

       有人會說,non-blocking IO並沒有被block啊。這里有個非常「狡猾」的地方,定義中所指的」IO operation」是指真實的IO操作,就是例子中的recvfrom這個system call。non-blocking IO在執行recvfrom這個system call的時候,如果kernel的數據沒有準備好,這時候不會block進程。但是, 當kernel中數據准備好的時候,recvfrom會將數據從kernel拷貝到用戶內存中,這個時候進程是被block了,在這段時間內,進程是被block的。

而asynchronous IO則不一樣,當進程發起IO 操作之後,就直接返回再也不理睬了,直到kernel發送一個信號,告訴進程說IO完成。在這整個過程中,進程完全沒有被block。

B. 如何查看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~

C. 我想做linux的磁碟io性能測試,有什麼好的工具和方法推薦嗎,感謝

除了fio測試工具和iostat,其他工具的測試結果基本上都是扯淡,跟直觀感受毀鎮距離太遠,尤其是隨機IO。

而且測試結果都不能反如戚映真實負載纖橡粗,如果依據這個結果去預估負載,更是差的遠。

D. 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

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

top命令的其他參數代表的含義詳見top命令詳解

sar 命令是分析系統瓶頸的神器,可以用來查看 CPU 、內存、磁碟、網路等性能。

sar 命令查看當前磁碟性能的命令為:

F. Linux 如何測試 IO 性能(磁碟讀寫速度

linux下測試磁碟IO讀寫速度
[root@node3 /]# time dd if=/dev/sda2 of=/dev/null bs=8k count=524288
524288+0 records in
524288+0 records out
4294967296 bytes (4.3 GB) copied, 37.4222 seconds, 115 MB/s
real 0m37.497s
user 0m0.036s
sys 0m1.320s
了4.3G的數據,平均速度為115M/s

[root@node3 /]# hdparm -t /dev/sda2
/dev/sda2:
Timing buffered disk reads: 284 MB in 3.00 seconds = 94.55 MB/sec

[root@node3 /]# hdparm -t /dev/sda2
/dev/sda2:
Timing buffered disk reads: 292 MB in 3.02 seconds = 96.82 MB/sec

讀了將近300M的數據,平均速度大約為95M/s
經過以上的測試數據大體估算該磁碟的性能大約為100M/s

閱讀全文

與linux測試io性能相關的資料

熱點內容
阿里雲伺服器遠程鏈接 瀏覽:247
墨鏡慧眼怎麼下載廠商的app 瀏覽:61
iphone加密專線 瀏覽:491
aes產生加密文件 瀏覽:415
編程實現藍牙通信 瀏覽:768
怎麼恢復掉簽的app 瀏覽:847
伺服器部署ip地址 瀏覽:321
涉密場所周邊安全防護距離演算法 瀏覽:672
安卓fpse模擬器怎麼設置加速 瀏覽:946
建行app怎麼生成電子簽章 瀏覽:508
獲取當前時間javadate 瀏覽:73
帶密碼的wifi如何加密 瀏覽:237
伺服器怎麼變成陣列 瀏覽:718
web前端黑客技術pdf 瀏覽:71
育兒百科全書pdf 瀏覽:600
任務欄啟動命令 瀏覽:912
編譯優化等級區別 瀏覽:757
unix網關命令 瀏覽:877
想自己做網站要學編程嗎 瀏覽:599
租個伺服器開個私服需要什麼 瀏覽:274