首先，磁碟io主要的延時是由（以15000rpm硬碟為例）： 機械轉動延時（機械磁碟的主要效能瓶頸，平均為2ms） + 定址延時（2~3ms） + 塊傳輸延時（一般4k每塊，40m/s的傳輸速度，延時一般為0.1ms) 決定。（平均為5ms）
而網路io主要延時由： 伺服器響應延時 + 頻寬限制 + 網路延時 + 跳轉路由延時 + 本地接收延時 決定。（一般為幾十到幾千毫秒，受環境干擾極大）
所以兩者一般來說網路io延時要大於磁碟io的延時。
在研究磁碟效能之前我們必須先了解磁碟的結構，以及工作原理。不過在這裡就不再重複說明了，關係硬碟結構和工作原理的資訊可以參考維基百科上面的相關詞條——hard disk drive(英文)和硬碟驅動器(中文)。
讀寫io(read/write io)操作
磁碟是用來給我們訪問資料用的，因此當說到io操作的時候，就會存在兩種相對應的操作，存資料時候對應的是寫io操作，取資料的時候對應的是是讀io操作。
單個io操作
當控制磁碟的控制器接到作業系統的讀io操作指令的時候，控制器就會給磁碟發出乙個讀資料的指令，並同時將要讀取的資料塊的位址傳遞給磁碟，然後磁碟會將讀取到的資料傳給控制器，並由控制器返回給作業系統，完成乙個寫io的操作;同樣的，乙個寫io的操作也類似，控制器接到寫的io操作的指令和要寫入的資料，並將其傳遞給磁碟，磁碟在資料寫入完成之後將操作結果傳遞歸控制器，再由控制器返回給作業系統，完成乙個寫io的操作。單個io操作指的就是完成乙個寫io或者是讀io的操作。
隨機訪問(random access)與連續訪問(sequential access)
隨機訪問指的是本次io所給出的扇區位址和上次io給出扇區位址相差比較大，這樣的話磁頭在兩次io操作之間需要作比較大的移動動作才能重新開始讀/寫資料。相反的，如果當次io給出的扇區位址與上次io結束的扇區位址一致或者是接近的話，那磁頭就能很快的開始這次io操作，這樣的多個io操作稱為連續訪問。因此儘管相鄰的兩次io操作在同一時刻發出，但如果它們的請求的扇區位址相差很大的話也只能稱為隨機訪問，而非連續訪問。
順序io模式(queue mode)/併發io模式(burst mode)
磁碟控制器可能會一次對磁碟組發出一連串的io命令，如果磁碟組一次只能執行乙個io命令時稱為順序io;當磁碟組能同時執行多個io命令時，稱為併發io。併發io只能發生在由多個磁碟組成的磁碟組上，單塊磁碟只能一次處理乙個io命令。
單個io的大小(io chunk size)
熟悉資料庫的人都會有這麼乙個概念，那就是資料庫儲存有個基本的塊大小(block size)，不管是sql server還是oracle，預設的塊大小都是8kb，就是資料庫每次讀寫都是以8k為單位的。那麼對於資料庫應用發出的固定8k大小的單次讀寫到了寫磁碟這個層面會是怎麼樣的呢，就是對於讀寫磁碟來說單個io操作運算元據的大小是多少呢，是不是也是乙個固定的值?
答案是不確定。首先作業系統為了提高 io的效能而引入了檔案系統快取(file system cache)，系統會根據請求資料的情況將多個來自io的請求先放在快取裡面，然後再一次性的提交給磁碟，也就是說對於資料庫發出的多個8k資料塊的讀操作有可能放在乙個磁碟讀io裡就處理了。
還有對於有些儲存系統也是提供了快取(cache)的，接收到作業系統的io請求之後也是會將多個作業系統的 io請求合併成乙個來處理。不管是作業系統層面的快取還是磁碟控制器層面的快取，目的都只有乙個，提高資料讀寫的效率。因此每次單獨的io操作大小都是不一樣的，它主要取決於系統對於資料讀寫效率的判斷。
當一次io操作大小比較小的時候我們成為小的io操作，比如說1k，4k，8k這樣的;當一次io操作的資料量比較的的時候稱為大io操作，比如說32k，64k甚至更大。
在我們說到塊大小(block size)的時候通常我們會接觸到多個類似的概念，像我們上面提到的那個在資料庫裡面的資料最小的管理單位，oralce稱之為塊(block)，大小一般為8k，sql server稱之為頁(page)，一般大小也為8k。
在檔案系統裡面我們也能碰到乙個檔案系統的塊，在現在很多的linux系統中都是4k(通過 /usr/bin/time -v可以看到)，它的作用其實跟資料庫裡面的塊/頁是一樣的，都是為了方便資料的管理。但是說到單次io的大小，跟這些塊的大小都是沒有直接關係的，在英文裡單次io大小通常被稱為是io chunk size，不會說成是io block size的。
iops(io per second)
iops，io系統每秒所執行io操作的次數，是乙個重要的用來衡量系統io能力的乙個引數。對於單個磁碟組成的io系統來說，計算它的iops不是一件很難的事情，只要我們知道了系統完成一次io所需要的時間的話我們就能推算出系統iops來。
現在我們就來推算一下磁碟的iops，假設磁碟的轉速(rotational speed)為15k rpm，平均尋道時間為5ms，最大傳輸速率為40mb/s(這裡將讀寫速度視為一樣，實際會差別比較大)。
對於磁碟來說乙個完整的io操作是這樣進行的：當控制器對磁碟發出乙個io操作命令的時候，磁碟的驅動臂(actuator arm)帶讀寫磁頭(head)離開著陸區(landing zone，位於內圈沒有資料的區域)，移動到要操作的初始資料塊所在的磁軌(track)的正上方，這個過程被稱為定址(seeking)，對應消耗的時間被稱為定址時間(seek time);但是找到對應磁軌還不能馬上讀取資料，這時候磁頭要等到磁碟碟片(platter)旋轉到初始資料塊所在的扇區(sector)落在讀寫磁頭正上方的之後才能開始讀取資料，在這個等待碟片旋轉到可操作扇區的過程中消耗的時間稱為旋轉延時(rotational delay);接下來就隨著碟片的旋轉，磁頭不斷的讀/寫相應的資料塊，直到完成這次io所需要操作的全部資料，這個過程稱為資料傳送(data transfer)，對應的時間稱為傳送時間(transfer time)。完成這三個步驟之後一次io操作也就完成了。
在我們看硬碟廠商的宣傳單的時候我們經常能看到3個引數，分別是平均定址時間、碟片旋轉速度以及最大傳送速度，這三個引數就可以提供給我們計算上述三個步驟的時間。
第乙個定址時間，考慮到被讀寫的資料可能在磁碟的任意乙個磁軌，既有可能在磁碟的最內圈(定址時間最短)，也可能在磁碟的最外圈(定址時間最長)，所以在計算中我們只考慮平均定址時間，也就是磁碟引數中標明的那個平均定址時間，這裡就採用當前最多的10krmp硬碟的5ms。
第二個旋轉延時，和定址一樣，當磁頭定位到磁軌之後有可能正好在要讀寫扇區之上，這時候是不需要額外額延時就可以立刻讀寫到資料，但是最壞的情況確實要磁碟旋轉整整一圈之後磁頭才能讀取到資料，所以這裡我們也考慮的是平均旋轉延時，對於10krpm的磁碟就是(60s/15k)*(1/2) = 2ms。
第三個傳送時間，磁碟引數提供我們的最大的傳輸速度，當然要達到這種速度是很有難度的，但是這個速度卻是磁碟純讀寫磁碟的速度，因此只要給定了單次 io的大小，我們就知道磁碟需要花費多少時間在資料傳送上，這個時間就是io chunk size / max transfer rate。
當單次io越小的時候，單次io所耗費的時間也越少，相應的iops也就越大。
這裡的理想的情況就是磁碟要花費平均大小的定址時間和平均的旋轉延時，這個假設其實是比較符合我們實際情況中的隨機讀寫，在隨機讀寫中，每次io操作的定址時間和旋轉延時都不能忽略不計，有了這兩個時間的存在也就限制了iops的大小。現在我們考慮一種相對極端的順序讀寫操作，比如說在讀取乙個很大的儲存連續分布在磁碟的的檔案，因為檔案的儲存的分布是連續的，磁頭在完成乙個讀io操作之後，不需要從新的定址，也不需要旋轉延時，在這種情況下我們能到乙個很大的iops值
當我們要用iops來衡量乙個io系統的系能的時候我們一定要說清楚是在什麼情況的iops，也就是要說明讀寫的方式以及單次io的大小，當然在實際當中，特別是在oltp的系統的，隨機的小io的讀寫是最有說服力的。
傳輸速度(transfer rate)/吞吐率(throughput)
現在我們要說的傳輸速度(另乙個常見的說法是吞吐率)不是磁碟上所表明的最大傳輸速度或者說理想傳輸速度，而是磁碟在實際使用的時候從磁碟系統匯流排上流過的資料量。有了iops資料之後我們是很容易就能計算出對應的傳輸速度來的
這裡一定要明確乙個概念，那就是儘管上面我們使用iops來計算傳輸速度，但是實際上傳輸速度和iops是沒有直接關係，在沒有快取的情況下它們共同的決定因素都是對磁碟系統的訪問方式以及單個io的大小。對磁碟進行隨機訪問時候我們可以利用iops來衡量乙個磁碟系統的效能，此時的傳輸速度不會太大;但是當對磁碟進行連續訪問時，此時的iops已經沒有了參考的價值，這個時候限制實際傳輸速度卻是磁碟的最大傳輸速度。因此在實際的應用當中，只會用iops來衡量小io的隨機讀寫的效能，而當要衡量大io連續讀寫的效能的時候就要採用傳輸速度而不能是iops了。
io響應時間(io response time)
最後來關注一下能直接描述io效能的io響應時間。io響應時間也被稱為io延時(io latency)，io響應時間就是從作業系統核心發出的乙個讀或者寫的io命令到作業系統核心接收到io回應的時間，注意不要和單個io時間混淆了，單個io時間僅僅指的是io操作在磁碟內部處理的時間，而io響應時間還要包括io操作在io等待佇列中所花費的等待時間。
從上面的資料可以看出，隨著系統實際iops越接近理論的最大值，io的響應時間會成非線性的增長，越是接近最大值，響應時間就變得越大，而且會比預期超出很多。一般來說在實際的應用中有乙個70%的指導值，也就是說在io讀寫的佇列中，當佇列大小小於最大iops的70%的時候，io的響應時間增加會很小，相對來說讓人比較能接受的，一旦超過70%，響應時間就會戲劇性的暴增，所以當乙個系統的io壓力超出最大可承受壓力的70%的時候就是必須要考慮調整或公升級了。
另外補充說一下這個70%的指導值也適用於cpu響應時間，這也是在實踐中證明過的，一旦cpu超過70%，系統將會變得受不了的慢。很有意思的東西
優化系統效能
程式框架 hibernate3 struts2 spring2 資料庫 sqlserver2008 伺服器 tomcat6 優化方法 1 配置連線池 採用的c3p0連線池 2 在程式中獲取列表時，用iterator代替list 3 在查詢之後可以使用session.clear 方法釋放快取 4 用資...
系統效能分析
當系統變慢時候，我們首先關注的可能是cpu的指標，有時候發現cpu使用率一點都不高，但是系統還是卡，這時可能就需要關心另外乙個影響效能的東西 磁碟的io效能。通過top命令中的 wa可以獲取系統當前的io狀態，如果該值居高不小，那磁碟的io可能就有問題了。另外可以通過iotop命令來詳細了解什麼程式...
系統效能分析
系統的整體效能取決於各種資源的平衡，類似木桶理論，某種資源的耗盡會嚴重阻礙系統的效能。linux中需要監控的資源主要有 cpu 主存 記憶體 硬碟空間 i o時間 網路時間 應用程式等。統效能的主要因素有 因素 說明使用者態cpu cpu在使用者態執行使用者程式所花費的時間，包括庫呼叫，但是不包括核...