監控硬碟演算法

A. 怎樣計算監控硬碟的容量

1、根據我安裝經驗，只能大概測算，比如說：在CIF格式下，650TV的攝像頭錄像文件大約全天需要5G的容量。高清（D1）全天大約需要20G的容量。但是在不同的環境下面，數據會有差異，比如說動態環境與靜態環境下錄像文件的大小也是不一樣的，所以計算監控硬碟所需要的容量只能說大概。
2、CIF是常用的錄像格式,一小時一路視頻佔用100到200M,通常情況下,你按照130M算就可以。看你有多少路視頻,多少小時的錄像，錄像方式中有一個選項是動態錄像是指只有當畫面中有物體移動時才錄像,這種情況下,一般比時間錄像少60%。然後看自己的情況選擇硬碟吧。

B. 硬碟錄像機怎麼算硬碟能錄多少天

首先要看硬碟容量是多大的？再就是硬碟錄像機是用什麼演算法進行壓縮的，第三看一共有多少個攝像機，
先看看現在流行的演算法有哪些：
1、MJPEG （Motion JPEG）壓縮技術標准源於JPEG圖片壓縮技術，是一種簡單的幀內JPEG壓縮，它對視頻的每一幀進行壓縮，壓縮比率較小，數量大，通常每路每小時325X288解析度錄像需要硬碟空間1G左右。
2、小波演算法是基於小波變換的視頻壓縮，該技術是使圖像信號的時域解析度和頻域解析度同時達到最高。內核是採用行進中壓縮和解壓縮方式，視頻中幀與幀之間沒有相關性，以352X288錄像，每路每小時一般為350M左右.
3、MPEG-4標準是面向對象的壓縮方式，不是像MPEG-1和MPEG-2簡單地將圖像分為一些像塊，而是根據圖像內容，將其中的對象（物體、人物、背景）分離出來分別進行幀內、幀間編碼壓縮，並允許在不同的對象之間靈活分配碼率，對重要的對象分配較多的位元組，對次要的對象分配較少的位元組，從而大大提高了壓縮比，使其在較低的碼率下獲得較好的效果。MPEG-4的傳輸速率為4.8~64kbit/s，使用時佔用的存儲空間比較小，以352X288錄像，每路每小時一般為120M左右.

如果你摸不準到底是什麼演算法的，你可以大致估算為200M單路每小時：

舉例說明，某小區用小波演算法的壓縮卡來做監控，主機12路，要求24小時錄像15天，需要多大的硬碟容量？
根據公式我們的到H=24,N=12 x=350M T=15天
最後得到G=24*12*350*15/1024=1476.5G 這樣就是最後硬碟的容量大小了
反之 知道硬碟的容量，想知道能錄多少天，倒過來一除就可以了。

C. 2.64與2.65監控硬碟區別

是H.264跟H.265吧，這是視頻壓縮編碼方式，跟硬碟沒任何關系。理論上H.265有更高效的壓縮演算法，產生的數據量會更小。實際使用265對網路質量的要求要比264高很多。

D. 監控項目，如何計算磁碟個數

以H264的720P也就是130萬像素的頭，一般設置碼率2Mbps計算，每個小時900M左右，一天24小時錄像文件約21G，那就是400*21*30除以1862（因為一般2TB硬碟可用容量是1862G），那就大約等於135.33。起碼要135個硬碟

E. 監控的硬碟錄像機的錄像天數與硬碟的大小是怎麼算的

錄像硬碟容量與天數與壓縮方式、解析度、幀率、錄像方式、畫面質量、是否帶音頻等有關

根據碼率計算公式
先計算單個通道每小時所需要的存儲容量S1 , 單位MByte。
S1=D / 8 * 3600 / 1024
其中：D－ 碼率（即錄像設置中的「位率/位率上限」），單位Kbit/s
確定錄像時間要求後，計算單個通道所需要的存儲容量S2, 單位MByte
S2=S1 * 24 * t
其中：t為保存天數 24表示一天24小時錄像
再確定視頻通道數 計算最終所需容量S3
S3=S2 *N
其中：N為視頻通道數
CIF 352×288的解析度，建議碼流設置為512kbps，用0.5M的帶寬傳輸
4CIF 704×576的解析度，建議碼流設置為2048kbps，用2M的帶寬傳輸

根據壓縮方式估算（以CIF解析度為例，其他解析度可以按比例進行換算）
目前常用的幾種壓縮方式
1） MJPEG
MJPEG （Motion JPEG）壓縮技術標准源於JPEG圖片壓縮技術，是一種簡單的幀內JPEG壓縮，它對視頻的每一幀進行壓縮，壓縮比率較小，數量大，通常每路每小時325X288解析度錄像需要硬碟空間1G左右。
2） 小波演算法
小波演算法是基於小波變換的視頻壓縮，該技術是使圖像信號的時域解析度和頻域解析度同時達到最高。內核是採用行進中壓縮和解壓縮方式，視頻中幀與幀之間沒有相關性，以352X288錄像，每路每小時一般為450M左右.
3） MPEG-4
MPEG-4標準是面向對象的壓縮方式，不是像MPEG-1和MPEG-2簡單地將圖像分為一些像塊，而是根據圖像內容，將其中的對象（物體、人物、背景）分離出來分別進行幀內、幀間編碼壓縮，並允許在不同的對象之間靈活分配碼率，對重要的對象分配較多的位元組，對次要的對象分配較少的位元組，從而大大提高了壓縮比，使其在較低的碼率下獲得較好的效果。MPEG-4的傳輸速率為4.8~64kbit/s，使用時佔用的存儲空間比較小，以352X288錄像，每路每小時一般為160M左右.
4) H.264
這種壓縮模式和MPEG-4基本一致，所以計算的時候大家可以按照MPEG-4的容量進行計算。

其容量計算公式 G=H*N*T*X/1024
G--就是最後算出的硬碟的容量
H--代表每天要錄像幾個小時
T--代表想錄像的天數
X--代表上面的4種壓縮模式每路每小時錄像需要硬碟空間

舉例說明，某小區用小波演算法的壓縮卡來做監控，主機12路，要求24小時錄像15天，需要多大的硬碟容量？
根據公式我們的到H=24小時 N=12 路 X=450M T=15天
得到G=24*12*450*15/1024=1898.4375G

F. 安防監控系統中硬碟錄像機內配置的硬碟個數演算法

是這樣的：根據攝像機的多少、攝像頭的像素與存儲要達到的天數來計算硬碟容量，再根據硬碟容量來換算硬碟個數；，攝像機的像素是多少，才能知道用多少硬碟空間，100萬是2.2G/小時/台；200萬是4.4G/小時/台；300萬是5.5G/小時/台；比如200萬的16路攝像頭，按照15天則需要2.54T(4.4Gx16x24×15天)。那就需要2T硬碟2塊。

G. 10個監控攝像頭，以每秒24幀傳輸數據，如果用2T硬碟來存儲這些數據，大概可以存儲多久，怎麼計算

使用D1存儲，大約能存儲12天
D1存儲，每路2Mbps/秒
如果是CIF存儲，大約48天
CIF每路512Kbps/秒

H. 如何使用windows性能監視器監控磁碟性能

Windows性能計數器--磁碟性能分析Disk
Physical Disk：
單次IO大小
Avg.Disk Bytes/Read
Avg.Disk Bytes/Write
IO響應時間
Avg.Disk sec/Read
Avg.Disk sec/Write
IOPS
DiskReads/sec
DiskWrites/sec
DiskTransfers/sec
IO吞吐率
DiskBytes/sec
DiskRead Bytes/sec
DiskWrite Bytes/sec

磁碟有兩個重要的參數：Seek time、Rotational latency。
正常的I/O計數為：①1000/(Seek time+Rotational latency)*0.75，在此范圍內屬正常。當達到85％的I/O計數以上時則基本認為已經存在I/O瓶頸。理論情況下，磁碟的隨機讀計數為125、 順序讀計數為225。對於數據文件而言是隨機讀寫，日誌文件是順序讀寫。因此，數據文件建議存放於RAID5上，而日誌文件存放於RAID10或 RAID1中。
附：
15000 RPM：150隨機IOPS
10000 RPM：110隨機IOPS
5400 RPM：50隨機IOPS

下面假設在有4塊硬碟的RAID5中觀察到的Physical Disk性能對象的部分值：

Avg. DiskQueue Length 12 隊列長度
Avg. DiskSec/Read .035 讀數據所用時間ms
Avg. DiskSec/Write .045 寫數據所用時間ms
DiskReads/sec 320 每秒讀數據量
DiskWrites/sec 100 每秒寫數據量
Avg. DiskQueue Length，12/4=3，每塊磁碟的平均隊列建議不超過2。
Avg. DiskSec/Read一般不要超過11～15ms。
Avg. DiskSec/Write一般建議小於12ms。

從上面的結果，我們看到磁碟本身的I/O能力是滿足我們的要求的，原因是因為有大量的請求才導致隊列等待，這很可能是因為你的SQL語句導致大量的表掃描所致。在進行優化後，如果還是不能達到要求，下面的公式可以幫助你計算使用幾塊硬碟可以滿足這樣的並發要求：
Raid 0 -- I/Os per disk = (reads +writes) / number of disks
Raid 1 -- I/Os per disk = [reads +(2 * writes)] / 2
Raid 5 -- I/Os per disk = [reads +(4 * writes)] / number of disks
Raid 10 -- I/Os per disk = [reads +(2 * writes)] / number of disks

我們得到的結果是：(320+400)/4=180，這時你可以根據公式①來得到磁碟的正常I/O值。假設現在正常I/O計數為125，為了達到這個結果：720/125=5.76。就是說要用6塊磁碟才能達到這樣的要求。

但是上面的Disk Reads/sec和Disk Writes/sec是個很難正確估算的值。因此只能在系統比較忙時，大概估算一個平均值，作為計算公式的依據。另一個是你很難從客戶那裡得到Seek time、 Rotational latency參數的值，這也只能用理論值125進行計算。
前言
作為一個資料庫管理員，關注系統的性能是日常最重要的工作之一，而在所關注的各方面的性能只能IO性能卻是最令人頭痛的一塊，面對著各種生澀的參數和令人眼花繚亂的新奇的術語，再加上存儲廠商的忽悠，總是讓我們有種雲里霧里的感覺。本系列文章試圖從基本概念開始對磁碟存儲相關的各種概念進行綜合歸納，讓大家能夠對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模式(BurstMode)
磁碟控制器可能會一次對磁碟組發出一連串的IO命令，如果磁碟組一次只能執行一個IO命令時稱為順序IO；當磁碟組能同時執行多個IO命令時，稱為並發IO。並發IO只能發生在由多個磁碟組成的磁碟組上，單塊磁碟只能一次處理一個IO命令。

單個IO的大小(IO ChunkSize)
熟悉資料庫的人都會有這么一個概念，那就是資料庫存儲有個基本的塊大小(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操作命令的時候，磁碟的驅動臂(ActuatorArm)帶讀寫磁頭(Head)離開著陸區(LandingZone，位於內圈沒有數據的區域)，移動到要操作的初始數據塊所在的磁軌(Track)的正上方，這個過程被稱為定址(Seeking)，對應消耗的時間被稱為定址時間(SeekTime)；但是找到對應磁軌還不能馬上讀取數據，這時候磁頭要等到磁碟碟片(Platter)旋轉到初始數據塊所在的扇區(Sector)落在讀寫磁頭正上方的之後才能開始讀取數據，在這個等待碟片旋轉到可操作扇區的過程中消耗的時間稱為旋轉延時(RotationalDelay)；接下來就隨著碟片的旋轉，磁頭不斷的讀/寫相應的數據塊，直到完成這次IO所需要操作的全部數據，這個過程稱為數據傳送(DataTransfer)，對應的時間稱為傳送時間(TransferTime)。完成這三個步驟之後一次IO操作也就完成了。
在我們看硬碟廠商的宣傳單的時候我們經常能看到3個參數，分別是平均定址時間、碟片旋轉速度以及最大傳送速度，這三個參數就可以提供給我們計算上述三個步驟的時間。
第一個定址時間，考慮到被讀寫的數據可能在磁碟的任意一個磁軌，既有可能在磁碟的最內圈（定址時間最短），也可能在磁碟的最外圈（定址時間最長），所以在計算中我們只考慮平均定址時間，也就是磁碟參數中標明的那個平均定址時間，這里就採用當前最多的10krmp硬碟的5ms。
第二個旋轉延時，和定址一樣，當磁頭定位到磁軌之後有可能正好在要讀寫扇區之上，這時候是不需要額外額延時就可以立刻讀寫到數據，但是最壞的情況確實要磁碟旋轉整整一圈之後磁頭才能讀取到數據，所以這里我們也考慮的是平均旋轉延時，對於10krpm的磁碟就是(60s/15k)*(1/2)= 2ms。
第三個傳送時間，磁碟參數提供我們的最大的傳輸速度，當然要達到這種速度是很有難度的，但是這個速度卻是磁碟純讀寫磁碟的速度，因此只要給定了單次IO的大小，我們就知道磁碟需要花費多少時間在數據傳送上，這個時間就是IOChunk Size / Max Transfer Rate。
現在我們就可以得出這樣的計算單次IO時間的公式：
IO Time = Seek Time + 60 sec/Rotational Speed/2 + IO ChunkSize/Transfer Rate
於是我們可以這樣計算出IOPS
IOPS = 1/IO Time = 1/(Seek Time + 60 sec/Rotational Speed/2 + IOChunk Size/Transfer Rate)
對於給定不同的IO大小我們可以得出下面的一系列的數據
4K (1/7.1 ms = 140 IOPS)
5ms + (60sec/15000RPM/2) + 4K/40MB = 5 + 2 + 0.1 = 7.1
8k (1/7.2 ms = 139 IOPS)
5ms + (60sec/15000RPM/2) + 8K/40MB = 5 + 2 + 0.2 = 7.2
16K (1/7.4 ms = 135 IOPS)
5ms + (60sec/15000RPM/2) + 16K/40MB = 5 + 2 + 0.4 = 7.4
32K (1/7.8 ms = 128 IOPS)
5ms + (60sec/15000RPM/2) + 32K/40MB = 5 + 2 + 0.8 = 7.8
64K (1/8.6 ms = 116 IOPS)
5ms + (60sec/15000RPM/2) + 64K/40MB = 5 + 2 + 1.6 = 8.6
從上面的數據可以看出，當單次IO越小的時候，單次IO所耗費的時間也越少，相應的IOPS也就越大。
上面我們的數據都是在一個比較理想的假設下得出來的，這里的理想的情況就是磁碟要花費平均大小的定址時間和平均的旋轉延時，這個假設其實是比較符合我們實際情況中的隨機讀寫，在隨機讀寫中，每次IO操作的定址時間和旋轉延時都不能忽略不計，有了這兩個時間的存在也就限制了IOPS的大小。現在我們考慮一種相對極端的順序讀寫操作，比如說在讀取一個很大的存儲連續分布在磁碟的文件，因為文件的存儲的分布是連續的，磁頭在完成一個讀IO操作之後，不需要從新的定址，也不需要旋轉延時，在這種情況下我們能到一個很大的IOPS值，如下
4K (1/0.1 ms = 10000 IOPS)
0ms + 0ms + 4K/40MB = 0.1
8k (1/0.2 ms = 5000 IOPS)
0ms + 0ms + 8K/40MB = 0.2
16K (1/0.4 ms = 2500 IOPS)
0ms + 0ms + 16K/40MB = 0.4
32K (1/0.8 ms = 1250 IOPS)
0ms + 0ms + 32K/40MB = 0.8
64K (1/1.6 ms = 625 IOPS)
0ms + 0ms + 64K/40MB = 1.6
相比第一組數據來說差距是非常的大的，因此當我們要用IOPS來衡量一個IO系統的系能的時候我們一定要說清楚是在什麼情況的IOPS，也就是要說明讀寫的方式以及單次IO的大小，當然在實際當中，特別是在OLTP的系統的，隨機的小IO的讀寫是最有說服力的。
傳輸速度(Transfer Rate)/吞吐率(Throughput)
現在我們要說的傳輸速度（另一個常見的說法是吞吐率）不是磁碟上所表明的最大傳輸速度或者說理想傳輸速度，而是磁碟在實際使用的時候從磁碟系統匯流排上流過的數據量。有了IOPS數據之後我們是很容易就能計算出對應的傳輸速度來的
Transfer Rate = IOPS * IO Chunk Size
還是那上面的第一組IOPS的數據我們可以得出相應的傳輸速度如下
4K: 140 * 4K = 560K / 40M = 1.36%
8K: 139 * 8K = 1112K / 40M = 2.71%
16K: 135 * 16K = 2160K / 40M = 5.27%
32K: 116 * 32K = 3712K / 40M = 9.06%
可以看出實際上的傳輸速度是很小的，對匯流排的利用率也是非常的小。
這里一定要明確一個概念，那就是盡管上面我們使用IOPS來計算傳輸速度，但是實際上傳輸速度和IOPS是沒有直接關系，在沒有緩存的情況下它們共同的決定因素都是對磁碟系統的訪問方式以及單個IO的大小。對磁碟進行隨機訪問時候我們可以利用IOPS來衡量一個磁碟系統的性能，此時的傳輸速度不會太大；但是當對磁碟進行連續訪問時，此時的IOPS已經沒有了參考的價值，這個時候限制實際傳輸速度卻是磁碟的最大傳輸速度。因此在實際的應用當中，只會用IOPS 來衡量小IO的隨機讀寫的性能，而當要衡量大IO連續讀寫的性能的時候就要採用傳輸速度而不能是IOPS了。
IO響應時間(IOResponse Time)
最後來關注一下能直接描述IO性能的IO響應時間。IO響應時間也被稱為IO延時(IOLatency)，IO響應時間就是從操作系統內核發出的一個讀或者寫的IO命令到操作系統內核接收到IO回應的時間，注意不要和單個IO時間混淆了，單個IO時間僅僅指的是IO操作在磁碟內部處理的時間，而IO響應時間還要包括IO操作在IO等待隊列中所花費的等待時間。
計算IO操作在等待隊列裡面消耗的時間有一個衍生於利托氏定理(Little』sLaw)的排隊模型M/M/1模型可以遵循，由於排隊模型演算法比較復雜，到現在還沒有搞太明白（如果有誰對M/M/1模型比較精通的話歡迎給予指導），這里就羅列一下最後的結果，還是那上面計算的IOPS數據來說：
8K IO Chunk Size (135 IOPS, 7.2 ms)
135 => 240.0 ms
105 => 29.5 ms
75 => 15.7 ms
45 => 10.6 ms

64K IO Chunk Size(116 IOPS, 8.6 ms)
135 => 沒響應了……
105 => 88.6 ms
75 => 24.6 ms
45 => 14.6 ms
從上面的數據可以看出，隨著系統實際IOPS越接近理論的最大值，IO的響應時間會成非線性的增長，越是接近最大值，響應時間就變得越大，而且會比預期超出很多。一般來說在實際的應用中有一個70%的指導值，也就是說在IO讀寫的隊列中，當隊列大小小於最大IOPS的70%的時候，IO的響應時間增加會很小，相對來說讓人比較能接受的，一旦超過70%，響應時間就會戲劇性的暴增，所以當一個系統的IO壓力超出最大可承受壓力的70%的時候就是必須要考慮調整或升級了。
另外補充說一下這個70%的指導值也適用於CPU響應時間，這也是在實踐中證明過的，一旦CPU超過70%，系統將會變得受不了的慢。很有意思的東西。
從上一篇文章的計算中我們可以看到一個15k轉速的磁碟在隨機讀寫訪問的情況下IOPS竟然只有140左右，但在實際應用中我們卻能看到很多標有5000IOPS甚至更高的存儲系統，有這么大IOPS的存儲系統怎麼來的呢？這就要歸結於各種存儲技術的使用了，在這些存儲技術中使用最廣的就是高速緩存(Cache)和磁碟冗餘陣列(RAID)了，本文就將探討緩存和磁碟陣列提高存儲IO性能的方法。
高速緩存(Cache)
在當下的各種存儲產品中，按照速度從快到慢應該就是內存>快閃記憶體>磁碟>磁帶了，然而速度越快也就意味著價格越高，快閃記憶體雖然說是發展勢頭很好，但目前來說卻還是因為價格問題無法普及，因此現在還是一個磁碟作霸王的時代。與CPU和內存速度相比，磁碟的速度無疑是計算機系統中最大的瓶頸了，所以在必須使用磁碟而又想提高性能的情況下，人們想出了在磁碟中嵌入一塊高速的內存用來保存經常訪問的數據從而提高讀寫效率的方法來折中的解決，這塊嵌入的內存就被稱為高速緩存。
說到緩存，這東西應用現在已經是無處不在，從處於上層的應用，到操作系統層，再到磁碟控制器，還有CPU內部，單個磁碟的內部也都存在緩存，所有這些緩存存在的目的都是相同的，就是提高系統執行的效率。當然在這里我們只關心跟IO性能相關的緩存，與IO性能直接相關的幾個緩存分別是文件系統緩存(FileSystem Cache)、磁碟控制器緩存(DiskController Cache)和磁碟緩存(DiskCache,也稱為DiskBuffer)，不過當在計算一個磁碟系統性能的時候文件系統緩存也是不會考慮在內的，因此我們重點考察的就是磁碟控制器緩存和磁碟緩存。
不管是控制器緩存還是磁碟緩存，他們所起的作用主要是分為三部分：緩存數據、預讀(Read-ahead)和回寫(Write-back)。

緩存數據
首先是系統讀取過的數據會被緩存在高速緩存中，這樣下次再次需要讀取相同的數據的時候就不用在訪問磁碟，直接從緩存中取數據就可以了。當然使用過的數據也不可能在緩存中永久保留的，緩存的數據一般那是採取LRU演算法來進行管理，目的是將長時間不用的數據清除出緩存，那些經常被訪問的卻能一直保留在緩存中，直到緩存被清空。
預讀
預讀是指採用預讀演算法在沒有系統的IO請求的時候事先將數據從磁碟中讀入到緩存中，然後在系統發出讀IO請求的時候，就會實現去檢查看看緩存裡面是否存在要讀取的數據，如果存在（即命中）的話就直接將結果返回，這時候的磁碟不再需要定址、旋轉等待、讀取數據這一序列的操作了，這樣是能節省很多時間的；如果沒有命中則再發出真正的讀取磁碟的命令去取所需要的數據。

緩存的命中率跟緩存的大小有很大的關系，理論上是緩存越大的話，所能緩存的數據也就越多，這樣命中率也自然越高，當然緩存不可能太大，畢竟成本在那兒呢。如果一個容量很大的存儲系統配備了一個很小的讀緩存的話，這時候問題會比較大的，因為小緩存的數據量非常小，相比整個存儲系統來說比例非常低，這樣隨機讀取（資料庫系統的大多數情況）的時候命中率也自然就很低，這樣的緩存不但不能提高效率（因為絕大部分讀IO都還要讀取磁碟），反而會因為每次去匹配緩存而浪費時間。
執行讀IO操作是讀取數據存在於緩存中的數量與全部要讀取數據的比值稱為緩存命中率(ReadCache Hit Radio)，假設一個存儲系統在不使用緩存的情況下隨機小IO讀取能達到150IOPS，而它的緩存能提供10%的緩存命中率的話，那麼實際上它的IOPS可以達到150/(1-10%)=166。
回寫
首先說一下，用於回寫功能的那部分緩存被稱為寫緩存(WriteCache)。在一套寫緩存打開的存儲中，操作系統所發出的一系列寫IO命令並不會被挨個的執行，這些寫IO的命令會先寫入緩存中，然後再一次性的將緩存中的修改推到磁碟中，這就相當於將那些相同的多個IO合並成一個，多個連續操作的小IO合並成一個大的IO，還有就是將多個隨機的寫IO變成一組連續的寫IO，這樣就能減少磁碟定址等操作所消耗的時間，大大的提高磁碟寫入的效率。

讀緩存雖然對效率提高是很明顯的，但是它所帶來的問題也比較嚴重，因為緩存和普通內存一樣，掉點以後數據會全部丟失，當操作系統發出的寫IO命令寫入到緩存中後即被認為是寫入成功，而實際上數據是沒有被真正寫入磁碟的，此時如果掉電，緩存中的數據就會永遠的丟失了，這個對應用來說是災難性的，目前解決這個問題最好的方法就是給緩存配備電池了，保證存儲掉電之後緩存數據能如數保存下來。
和讀一樣，寫緩存也存在一個寫緩存命中率(WriteCache Hit Radio)，不過和讀緩存命中情況不一樣的是，盡管緩存命中，也不能將實際的IO操作免掉，只是被合並了而已。
控制器緩存和磁碟緩存除了上面的作用之外還承當著其他的作用，比如磁碟緩存有保存IO命令隊列的功能，單個的磁碟一次只能處理一個IO命令，但卻能接收多個IO命令，這些進入到磁碟而未被處理的命令就保存在緩存中的IO隊列中。
RAID(Rendant Array Of InexpensiveDisks)
如果你是一位資料庫管理員或者經常接觸伺服器，那對RAID應該很熟悉了，作為最廉價的存儲解決方案，RAID早已在伺服器存儲中得到了普及。在RAID的各個級別中，應當以RAID10和RAID5（不過RAID5已經基本走到頭了，RAID6正在崛起中，看看這里了解下原因）應用最廣了。下面將就RAID0，RAID1，RAID5，RAID6，RAID10這幾種級別的RAID展開說一下磁碟陣列對於磁碟性能的影響，當然在閱讀下面的內容之前你必須對各個級別的RAID的結構和工作原理要熟悉才行，這樣才不至於滿頭霧水，推薦查看wikipedia上面的如下條目：RAID，StandardRAID levels，Nested RAID levels。

I. 電腦安裝16路的監控系統需要多大的硬碟(24小時監控錄像要保存20天）

這個可以算的，要看你把DVR錄像設置成多高的碼率，一般DVR最大錄像效果在512K，可以自己選，64K,128K,256K等等，也有雜牌DVR不能選的，一般在128K。就是一路一秒512K，再乘以60秒，乘以60分，乘以24小時，乘以16路再乘以天數：512*60*60*24*16*20=14155776000K 大約在13500G，128K的就要3T就夠了。
這只是理論演算法，實際上設成128K，機器也大多達不到，同一路通道里不同時間不同光線條件，錄像文件的大小都會變化，基本上是像機線數越高，顏色越多越強烈，就越接近這個設定的值。像晚上光照效果不好時，有的像機就基本全黑了，有的是差不多黑白圖像，這個時候的錄像文件大小會小的多。
如果要用128K的碼率，基本2T就夠夠的了

J. 硬碟錄像機安裝硬碟總容量的參考計算方法

根據錄像要求（錄像類型、錄像資料保存時間）計算一台硬碟錄像機所需總容量
計算方法：
(1)計算單個通道每小時所需的存儲容量q，單位Mbyte。
q=d÷8×3600÷1024
其中d是碼率(即錄像設置中的「位率/位率上限」)，單位Kbit/s
(2)確定錄像時間要求後單個通道所需的存儲容量m，單位Mbyte
m=q×h×D
其中 h是每天錄像時間（小時）
D是需要保存錄像的天數

碼率是512時候，正常錄像每小時單通道文件大小225M；每天(24小時)大概5.3G

碼率是384時候，正常錄像每小時單通道文件大小168.75M；每天(24小時)大概4G
碼率
碼率就是數據傳輸時單位時間傳送的數據位數,一般我們用的單位是kbps即千位每秒。
通俗一點的理解就是取樣率，單位時間內取樣率越大，精度就越高，處理出來的文件就越接近原始文件，但是文件體積與取樣率是成正比的，所以幾乎所有的編碼格式重視的都是如何用最低的碼率達到最少的失真，圍繞這個核心衍生出來的cbr（固定碼率）與vbr（可變碼率），都是在這方面做的文章，不過事情總不是絕對的，從音頻方面來說，碼率越高，被壓縮的比例越小，音質損失越小，與音源的音質越接近。
編輯本段碼率計算公式
基本的演算法是：文件體積=時間X碼率/8
這里時間單位是秒，碼率除以8，就不用說了。舉例，D5的碟，容量4.3G，考慮到音頻的不同格式，佔用一定的空間，姑且算為600M，視頻文件應不大於3.7G，視頻長度100分鍾（6000秒），計算結果：碼率應為4900K。
編輯本段碼率幾點原則
1、碼率和質量成正比（廢話），但是文件體積也和碼率成正比。這是要牢記的。
2、碼率超過一定數值，對圖像的質量沒有多大影響。
3、DVD的容量有限，無論是標準的4.3G，還是超刻，或是D9，都有極限。這也是廢話，但是就有人記不住或忽略這點，漫天討論。
編輯本段視頻碼率
計算機中的信息都是二進制的0和1來表示，其中每一個0或1被稱作一個位，用小寫b表示，即bit（位）；大寫B表示byte,即位元組，一個位元組＝八個位，即1B＝8b；前面的大寫K表示千的意思，即千個位（Kb)或千個位元組(KB)。表示文件的大小單位，一般都使用位元組（KB）來表示文件的大小。
Kbps：首先要了解的是，ps指的是/s，即每秒。Kbps指的是網路速度，也就是每秒鍾傳送多少個千位的信息（K表示千位，Kb表示的是多少千個位），為了在直觀上顯得網路的傳輸速度較快，一般公司都使用kb（千位）來表示，如果是KBps，則表示每秒傳送多少千位元組。1KBps＝8Kbps。ADSL上網時的網速是512Kbps,如果轉換成位元組，就是512/8＝64KBps(即64千位元組每秒）。