雲伺服器如何升級內核

㈠ 怎麼查看自己的雲伺服器是幾核的cpu

可以通過DOS命令來查看伺服器的配置

一、DOS命令查看伺服器的配置

1.查詢CPU個數
cat /proc/cpuinfo | grep physical | sort -n | uniq | wc -l

2.查詢伺服器型號
dmidecode | grep "Proct Name"
或
dmidecode -s system-proct-name

3.查看CPU幾核
cat /proc/cpuinfo | grep physical | sort -n | uniq -c

4.查看CPU信息<型號>
cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq

5.查看CPU運行位數
# getconf LONG_BIT

(說明當前CPU運行在32bit模式下, 但不代表CPU不支持64bit)
# cat /proc/cpuinfo | grep flags | grep 'lm' | wc -l

(結果大於0, 說明支持64bit計算. lm指long mode, 支持lm則是64bit)

6.查看當前操作系統內核信息
uname -a

㈡ 怎麼選擇雲伺服器的配置

用來做網站還是做什麼用的。做個人博客、小型網站的話，1核1g、1核2g夠用。做企業網站 2核4g也夠用了。

頻繁計算的應用，選擇計算型伺服器，帶有高主頻CPU；

頻繁讀寫硬碟的應用，配置高速大容量磁碟，且帶I/O優化；

網路傳輸數據要求的應用，在網路傳輸包方面性能較強的網路型伺服器。留言或看博客內容，老魏寫過不少詳細的文章，可以幫助入門。

㈢ 高防雲伺服器原理是什麼

雲伺服器又叫做雲計算伺服器或者雲主機（Elastic Compute Service, ECS），雲伺服器解釋起來有點復雜，一句話兩句話很難說清雲伺服器到底是個啥，簡單來說他「雲伺服器」就是一個伺服器集群里的一個虛擬空間，但是他與我們網站經常使用的虛擬主機還有所不同，不知道大家有沒有用過Windows的虛擬機，在虛擬機裡面我們可以通過分配資源的形式在創建一個可視化的操作系統，而且我們擁有這個虛擬機的全部使用許可權，雲伺服器其實就是這樣的一個存在，我們現在經常接觸的雲伺服器提供商有阿里雲，騰訊雲，網路雲，AWS亞馬遜雲，谷歌雲，微軟雲等等，現在雲伺服器提供商很多，關鍵原因還是這些IT互聯網巨頭擁有著很多閑置的帶寬與伺服器主機資源，將這些閑置的資源租售給企業和個人用戶，可以使這些閑置的伺服器資源得到有效的利用，從而也節省了本身的成本。

雲伺服器的特點是支持彈性伸縮，例如磁碟不夠用了可以增加磁碟的大小，CPU與內存不夠了可以適當的在線升級CPU與內核，這些都是基於在線實時的，免去了配置物理主機所需要花費的大量時間。讓我們的網站或者其他基於伺服器實現的業務，能夠快速靈活的部署與訪問。

㈣ 浜戞湇鍔″櫒鏄浠涔堬紵

浜戞湇鍔″櫒鏄浠涔堬紵浜戞湇鍔″櫒鏄涓縐嶇被浼糣PS鏈嶅姟鍣ㄧ殑鉶氭嫙鍖栨妧鏈錛 VPS鏄閲囩敤鉶氭嫙杞浠訛紝VZ鎴朧M鍦ㄤ竴鍙版湇鍔″櫒涓婅櫄鎷熷嚭澶氫釜綾諱技鐙絝嬫湇鍔″櫒鐨勯儴鍒嗭紝姣忎釜閮ㄥ垎閮藉彲浠ュ仛鍗曠嫭鐨勬搷浣滅郴緇燂紝綆＄悊鏂規硶鍚屾湇鍔″櫒涓鏍楓 銆銆鑰屼簯鏈嶅姟鍣ㄦ槸鍦ㄤ竴緇勯泦緹ゆ湇鍔″櫒涓婅櫄鎷熷嚭澶氫釜綾諱技鐙絝嬫湇鍔″櫒鐨勯儴鍒嗭紝闆嗙兢涓姣忎釜鏈嶅姟鍣ㄤ笂閮芥湁浜戞湇鍔″櫒鐨勪竴涓闀滃儚錛屼粠鑰屽ぇ澶ф彁楂樹簡鉶氭嫙鏈嶅姟鍣ㄧ殑瀹夊叏紼沖畾鎬э紝闄ら潪鎵鏈夌殑闆嗙兢鍐呮湇鍔″櫒鍏ㄩ儴鍑虹幇闂棰橈紝浜戞湇鍔″櫒鎵嶄細鏃犳硶璁塊棶銆

浜戞湇鍔″櫒鏄涓縐嶅熀浜嶹EB鏈嶅姟錛屾彁渚涘彲璋冩暣浜戜富鏈洪厤緗鐨勫脊鎬т簯鎶鏈錛屾暣鍚堜簡璁＄畻銆佸瓨鍌ㄤ笌緗戠粶璧勬簮鐨処aas鏈嶅姟錛屽叿澶囨寜闇浣跨敤鍜屾寜闇鍗蟲椂浠樿垂鑳藉姏鐨勪簯涓繪満縐熺敤鏈嶅姟銆傚湪鐏墊椿鎬с佸彲鎺фс佹墿灞曟у強璧勬簮澶嶇敤鎬т笂閮芥湁寰堝ぇ鐨勬彁楂樸
浣挎父鎴忓唴鍚勪釜鍔熻兘緋葷粺鏇村姞鍚堢悊鍦板垎閰嶈繍綆楋紝澶уぇ鎻愰珮浜嗘父鎴忕殑瀹夊叏鎬у拰紼沖畾鎬э紝浠庤屼紭鍖栦簡娓告垙榪愯岀殑閫熷害錛屼嬌浜轟滑浣撻獙娓告垙鏇村姞欏虹晠銆備簯鏈嶅姟鍣ㄦ妧鏈鍦ㄣ婇唹路閫嶉仴銆嬪悇縐嶅ぇ鍨嬫椿鍔ㄤ腑鐨勮繍鐢錛岃濡傚崈浜哄壇鏈銆佷竾浜鴻禌璺戙佷笁澶ч樀钀ユ垬鍦虹瓑絳夛紝灝辨槸鏈鏈夊姏鐨勮存槑錛屼篃鏄浜轟滑鐣呯帺娓告垙鏈寮烘湁鍔涚殑淇濋殰銆

浜戜富鏈烘湇鍔＄殑搴旂敤
浜戜富鏈烘湇鍔℃槸浜戣＄畻鏈嶅姟鐨勯噸瑕佺粍鎴愰儴鍒嗭紝鏄闈㈠悜鍚勭被浜掕仈緗戠敤鎴鋒彁渚涚患鍚堜笟鍔¤兘鍔涚殑鏈嶅姟騫沖彴銆傚鉤鍙版暣鍚堜簡浼犵粺鎰忎箟涓婄殑浜掕仈緗戝簲鐢ㄤ笁澶ф牳蹇冭佺礌錛氳＄畻銆佸瓨鍌ㄣ佺綉緇滐紝闈㈠悜鐢ㄦ埛鎻愪緵鍏鐢ㄥ寲鐨勪簰鑱旂綉鍩虹璁炬柦鏈嶅姟銆
浜戜富鏈烘湇鍔″寘鎷涓や釜鏍稿績浜у搧錛氶潰鍚戜腑灝忎紒涓氱敤鎴蜂笌楂樼涓浜虹敤鎴風殑浜戞湇鍔″櫒縐熺敤鏈嶅姟錛涢潰鍚戝ぇ涓鍨嬩簰鑱旂綉鐢ㄦ埛鐨勫脊鎬ц＄畻騫沖彴鏈嶅姟銆
浜戜富鏈哄彲浠ユ湁鏁堢殑瑙ｅ喅浼犵粺鐗╃悊縐熸満涓嶸PS鏈嶅姟涓錛屽瓨鍦ㄧ殑綆＄悊闅懼害澶э紝涓氬姟鎵╁睍鎬у急鐨勭己闄楓傚湪瀹為檯搴旂敤涓鐨勪簯涓繪満鍏鋒湁涓変釜鏂歸潰鐨勫脊鎬ц兘鍔涳細
1.涓繪満鏈嶅姟閰嶇疆涓庝笟鍔¤勬ā鍙鏍規嵁鐢ㄦ埛鐨勯渶瑕佽繘琛岄厤緗錛屽苟鍙鐏墊椿鐨勮繘琛岃皟鏁達紱
2.鐢ㄦ埛鐢寵風殑涓繪満鏈嶅姟鍙浠ュ疄鐜板揩閫熶緵搴斿拰閮ㄧ講錛屽疄鐜頒簡闆嗙兢鍐呭脊鎬у彲浼哥緝錛
3.璁¤垂鏂瑰紡鐏墊椿錛岀敤鎴鋒棤闇鏀浠樻娂閲戱紝涓旀湁澶氱嶆敮浠樻柟寮忎緵鐢ㄦ埛閫夋嫨銆
浜戜富鏈哄鉤鍙伴泦緹よ妭鐐廣銆浜戜富鏈哄鉤鍙扮殑姣忎釜闆嗙兢鑺傜偣琚閮ㄧ講鍦ㄤ簰鑱旂綉鐨勬煇涓楠ㄥ共鏈烘埧錛屽彲鐙絝嬫彁渚 璁＄畻銆佸瓨鍌ㄣ佸湪綰垮囦喚銆佹墭綆°佸甫瀹界瓑浜掕仈緗戝熀紜璁炬柦鏈嶅姟銆傞泦緹よ妭鐐圭敱浠ヤ笅紜浠舵瀯鎴愶細
綆＄悊鏈嶅姟鍣錛氶噰鍙栧弻鏈虹儹澶囩殑鏂瑰紡錛屽規暣涓鑺傜偣鐨勬墍鏈夎＄畻鏈嶅姟鍣ㄣ佸叡浜瀛樺偍銆佺綉緇滆繘琛岀＄悊錛屽悓鏃跺瑰栨彁渚涚＄悊鏁翠釜鑺傜偣鐨凙PI銆傜＄悊鏈嶅姟鍣ㄤ笂鎻愪緵錛
綆＄悊鏈嶅姟錛堢＄悊鑺傜偣鐨勮＄畻鏈嶅姟鍣錛屽瑰栨彁渚涚＄悊鎺ュ彛錛夈丏HCP 鏈嶅姟錛堜負璁＄畻鏈嶅姟鍣ㄧ殑緗戠粶鍚鍔ㄥ垎閰嶇＄悊緗戞電殑IP錛夈乼ftp 鏈嶅姟錛堜負璁＄畻鏈嶅姟鍣ㄧ殑緗戠粶鍚鍔ㄦ彁渚涜繙紼嬪惎鍔ㄦ槧璞′笅杞斤級銆乶bd 鏈嶅姟錛堜負璁＄畻鏈嶅姟鍣ㄦ彁渚涚綉緇滃潡璁懼囨湇鍔★級銆傜＄悊鏈嶅姟鍣ㄤ笂榪樹細榪愯屼竴涓鏁版嵁閲囬泦紼嬪簭錛屼粬瀹氭椂灝嗗悇縐嶆ц兘鏁版嵁閲囬泦涓嬫潵騫跺彂閫佸埌涓澶鐨勬暟鎹閲囬泦鏈嶅姟鍣ㄤ笂 瀛樺偍鏈嶅姟鍣ㄧ兢錛氬瓨鍌ㄦ湇鍔″櫒鍙浠ユ槸ISCSI 鎴栧唴緗瀛樺偍瀹歸噺姣旇緝澶х殑x86 鏈嶅姟鍣錛岄氳繃CloudexFS 闆嗙兢鏂囦歡緋葷粺緇勬垚涓涓緇熶竴鐨勫瓨鍌ㄦ睜錛屼負鑺傜偣鍐呯殑鉶氭嫙鏈烘彁渚涢昏緫紓佺洏瀛樺偍銆侀潪緇撴瀯鏁版嵁瀛樺偍浠ュ強鏁村悎澶囦喚鏈嶅姟銆
璁＄畻鏈嶅姟鍣ㄧ兢錛氳＄畻鏈嶅姟鍣ㄦ槸楂橀厤緗鐨凞ELL 鏈嶅姟鍣錛岃＄畻鏈嶅姟鍣ㄦ棤闇瀹夎呮搷浣滅郴緇燂紝浣嗗繀欏誨叿澶囩綉緇滃紩瀵煎姛鑳斤紝鍏朵笂榪愯屼竴涓猯inux 寰鍐呮牳銆乆en 杞 浠躲佷竴涓涓庣＄悊鏈嶅姟鍣ㄨ繘琛岄氳鐨凙gent 銆銆浜ゆ崲鏈猴細鎸変笉鍚屽姛鑳藉拰鑺傜偣鎬ц兘瑕佹眰閰嶅囧氫釜涓夊眰浜ゆ崲鏈猴紝鍒嗗埆璐熻矗綆＄悊緗 孌點佸叕緗戜氦鎹㈢綉孌點佸唴閮ㄤ氦鎹㈢綉孌點佸瓨鍌ㄧ綉孌電瓑銆

浜戞湇鍔″櫒鐨勭壒寰
涓庝紶緇熸湇鍔″櫒鐩告瘮錛屼簯璁＄畻鏈嶅姟鍣ㄦ湁鍏舵樉钁楃壒寰侊紝鍗籌細楂樺瘑搴︺侀珮鍙鎵╁睍鎬у強寮哄ぇ鐨勮櫄鎷熷寲鑳藉姏銆
楂樺瘑搴 銆銆濡傛灉璇粹滀簯璁＄畻鈥濇槸澶у娍鎵瓚嬶紝閭ｄ箞楂樺瘑搴︽湇鍔″櫒灝辨槸鍔垮湪蹇呰屼簡錛2U絀洪棿鍐呴泦鎴2涓銆4涓銆佷箖鑷8涓鐙絝嬭＄畻鑺傜偣鐨勯珮瀵嗗害澶氳妭鐐規湇鍔″櫒錛屼竴鏃墮棿闆嗕竾鍗冨疇鐖變簬涓韜錛屽綋浠佷笉璁╃殑鎴愪負鏃朵笅IT鍩虹璁炬柦涓鑰鐪肩殑鐒︾偣銆
鎻愰珮鑳芥晥銆佸噺灝戝崰鍦伴潰縐銆侀檷浣庡姛鑰楋紝鏄楂樺瘑搴︽湇鍔″櫒鐨勬渶澶т紭鍔褲傜洰鍓嶉珮瀵嗗害鏈嶅姟鍣ㄤ富瑕佸垎涓哄氳礬鏈烘灦鍜屽垁鐗囥備簯璁＄畻瀵規暟鎹涓蹇冩ц兘鍜屾晥鐜囦篃鏈夌潃涓嶅悓鐨勮佹眰錛屼竴浜涙搷浣滀腑瀵硅＄畻闇奼傛洿楂橈紝楂樺瘑搴︽湇鍔″櫒鑳藉熷噺灝戝歡榪熴佹彁楂樺弽搴旈熷害銆傝岀綉緇滄父鎴忕瓑鏂歸潰宸茬粡寮濮嬪皾璇曚簯璁＄畻錛屾惌閰嶉珮瀵嗗害鏈嶅姟鍣ㄥ垯琛ㄧ幇鏇村姞鍑鴻壊銆
楂樺彲鎵╁睍鎬 銆銆鏈嶅姟鍣ㄧ殑鍙鎵╁睍鎬ф槸鎸囨湇鍔″櫒鐨勭‖浠墮厤緗鍙浠ユ牴鎹闇瑕佺伒媧婚厤緗錛屽傚唴瀛樸侀傞厤鍣ㄣ佺‖鐩樸佸勭悊鍣ㄧ瓑錛屽洜涓烘湇鍔″櫒鐨勭‖浠墮厤緗鍙鑳芥槸鏍規嵁涓嶅悓鏃舵湡鐨勭綉緇滈厤緗鑰屾敼鍙樸
浜戣＄畻鏈鏈璐ㄧ殑鐗圭偣涔嬩竴鏄甯鍔╀紒涓氱敤鎴峰疄鐜板嵆闇鍗崇敤銆佺伒媧婚珮鏁堢殑浣跨敤IT璧勬簮銆傚洜姝ゅ逛簬閮ㄧ講浜戣＄畻騫沖彴鏉ヨ達紝灝卞繀欏昏冭檻瀵瑰脊鎬х┖闂村拰鍙鎵╁睍鎬х殑鐪熷疄闇奼傘傚洜涓虹洰鍓嶆棤璁哄湪鏈嶅姟鍣ㄨ繕鏄瀛樺偍鏂歸潰錛岃稿氫紒涓氱幇鏈夌殑浜у搧鏋舵瀯閮芥棤娉曞叿澶囪壇濂界殑鎵╁睍鎬э紝鑳藉熷緢濂藉湴婊¤凍縐佹湁浜戝規墿灞曠┖闂寸殑寮規ч渶奼傘傚洜姝わ紝鐪熷疄璇勪及寮規у寲闇奼傦紝鏄瀹炵幇鎸夐渶娣誨姞鎴栧噺灝慖T璧勬簮鐨勭佹湁浜戦儴緗插墠鐨勪竴涓閲嶈佽冭檻銆
寮哄ぇ鐨勮櫄鎷熷寲鑳藉姏 銆銆鉶氭嫙鍖栧疄鐜頒簡IT璧勬簮鐨勯昏緫鎶借薄鍜岀粺涓琛ㄧず錛屽湪澶ц勬ā鏁版嵁涓蹇冪＄悊鍜岃В鍐蟲柟妗堜氦浠樻柟闈㈠彂鎸ョ潃宸ㄥぇ鐨勪綔鐢錛屾槸鏀鎾戜簯璁＄畻浼熷ぇ鏋勬兂鐨勬渶閲嶈佺殑鎶鏈鍩虹煶銆
浜戣＄畻涓涓嶅彲閬垮厤鍦伴渶瑕佷嬌鐢ㄦ湇鍔″櫒鉶氭嫙鍖栨妧鏈錛屽洜姝わ紝鏈嶅姟鍣ㄧ殑鉶氭嫙鍖栬兘鍔涙垚涓洪夊瀷鏃剁殑閲嶈佸弬鑰冩寚鏍囥傝繖瑕佹眰鏈嶅姟鍣ㄥ繀欏誨叿澶囪壇濂界殑鎬ц兘銆佽凍澶熺殑鍐呭瓨銆佸鉤鍙版敮鎸佸強寮閫氭晥鐜囩瓑銆

㈤ 如何測試雲硬碟

問題

UOS公有雲開放以來，一些用戶反應用dd命令測試出來的1TB雲硬碟的吞吐率(MBPS)只有128MB/s，而不是我們SLA保證的170MB /s ，這是為什麼？下面我會簡單介紹如何測試硬碟，RAID，SAN，SSD，雲硬碟等，然後再來回答上面的問題。

測試前提

我們在進行測試時，都會分清楚:

測試對象：要區分硬碟、SSD、RAID、SAN、雲硬碟等，因為它們有不同的特點
測試指標：IOPS和MBPS(吞吐率)，下面會具體闡述
測試工具：Linux下常用Fio、dd工具, Windows下常用IOMeter,
測試參數: IO大小，定址空間，隊列深度，讀寫模式，隨機/順序模式
測試方法：也就是測試步驟。
測試是為了對比，所以需要定性和定量。在宣布自己的測試結果時，需要說明這次測試的工具、參數、方法，以便於比較。

存儲系統模型

為了更好的測試，我們需要先了解存儲系統，塊存儲系統本質是一個排隊模型，我們可以拿銀行作為比喻。還記得你去銀行辦事時的流程嗎？

去前台取單號
等待排在你之前的人辦完業務
輪到你去某個櫃台
櫃台職員幫你辦完手續1
櫃台職員幫你辦完手續2
櫃台職員幫你辦完手續3
辦完業務，從櫃台離開
如何評估銀行的效率呢：

服務時間 = 手續1 + 手續2 + 手續3
響應時間 = 服務時間 + 等待時間
性能 = 單位時間內處理業務數量
那銀行如何提高效率呢:

增加櫃台數
降低服務時間
因此，排隊系統或存儲系統的優化方法是

增加並行度
降低服務時間
硬碟測試

硬碟原理

我們應該如何測試SATA/SAS硬碟呢？首先需要了解磁碟的構造，並了解磁碟的工作方式：

每個硬碟都有一個磁頭(相當於銀行的櫃台)，硬碟的工作方式是：

收到IO請求，得到地址和數據大小
移動磁頭(定址)
找到相應的磁軌(定址)
讀取數據
傳輸數據
則磁碟的隨機IO服務時間:

服務時間 = 尋道時間 + 旋轉時間 + 傳輸時間

對於10000轉速的SATA硬碟來說，一般尋道時間是7 ms，旋轉時間是3 ms, 64KB的傳輸時間是 0.8 ms， 則SATA硬碟每秒可以進行隨機IO操作是 1000/(7 + 3 + 0.8) = 93，所以我們估算SATA硬碟64KB隨機寫的IOPS是93。一般的硬碟廠商都會標明順序讀寫的MBPS。

我們在列出IOPS時，需要說明IO大小，定址空間，讀寫模式，順序/隨機，隊列深度。我們一般常用的IO大小是4KB，這是因為文件系統常用的塊大小是4KB。

使用dd測試硬碟

雖然硬碟的性能是可以估算出來的，但是怎麼才能讓應用獲得這些性能呢？對於測試工具來說，就是如何得到IOPS和MBPS峰值。我們先用dd測試一下SATA硬碟的MBPS(吞吐量)。

#dd if=/dev/zero of=/dev/sdd bs=4k count=300000 oflag=direct
記錄了300000+0 的讀入 記錄了300000+0 的寫出 1228800000位元組(1.2 GB)已復制，17.958 秒，68.4 MB/秒
#iostat -x sdd 5 10
...
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sdd 0.00 0.00 0.00 16794.80 0.00 134358.40 8.00 0.79 0.05 0.05 78.82
...
為什麼這塊硬碟的MBPS只有68MB/s? 這是因為磁碟利用率是78%，沒有到達95%以上，還有部分時間是空閑的。當dd在前一個IO響應之後，在准備發起下一個IO時，SATA硬碟是空閑的。那麼如何才能提高利用率，讓磁碟不空閑呢？只有一個辦法，那就是增加硬碟的隊列深度。相對於CPU來說，硬碟屬於慢速設備，所有操作系統會有給每個硬碟分配一個專門的隊列用於緩沖IO請求。

隊列深度

什麼是磁碟的隊列深度？

在某個時刻,有N個inflight的IO請求,包括在隊列中的IO請求、磁碟正在處理的IO請求。N就是隊列深度。
加大硬碟隊列深度就是讓硬碟不斷工作，減少硬碟的空閑時間。

加大隊列深度 -> 提高利用率 -> 獲得IOPS和MBPS峰值 -> 注意響應時間在可接受的范圍內
增加隊列深度的辦法有很多

使用非同步IO，同時發起多個IO請求，相當於隊列中有多個IO請求
多線程發起同步IO請求，相當於隊列中有多個IO請求
增大應用IO大小，到達底層之後，會變成多個IO請求，相當於隊列中有多個IO請求 隊列深度增加了。
隊列深度增加了，IO在隊列的等待時間也會增加，導致IO響應時間變大，這需要權衡。讓我們通過增加IO大小來增加dd的隊列深度，看有沒有效果：

dd if=/dev/zero of=/dev/sdd bs=2M count=1000 oflag=direct
記錄了1000+0 的讀入 記錄了1000+0 的寫出 2097152000位元組(2.1 GB)已復制，10.6663 秒，197 MB/秒
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sdd 0.00 0.00 0.00 380.60 0.00 389734.40 1024.00 2.39 6.28 2.56 97.42
可以看到2MB的IO到達底層之後，會變成多個512KB的IO，平均隊列長度為2.39，這個硬碟的利用率是97%，MBPS達到了197MB/s。(為什麼會變成512KB的IO，你可以去使用Google去查一下內核參數 max_sectors_kb的意義和使用方法 )

也就是說增加隊列深度，是可以測試出硬碟的峰值的。

使用fio測試硬碟

現在，我們來測試下SATA硬碟的4KB隨機寫的IOPS。因為我的環境是Linux，所以我使用FIO來測試。

$fio -ioengine=lio -bs=4k -direct=1 -thread -rw=randwrite -size=1000G -filename=/dev/vdb \
-name="EBS 4K randwrite test" -iodepth=64 -runtime=60
簡單介紹fio的參數

ioengine: 負載引擎，我們一般使用lio，發起非同步IO請求。
bs: IO大小
direct: 直寫，繞過操作系統Cache。因為我們測試的是硬碟，而不是操作系統的Cache，所以設置為1。
rw: 讀寫模式，有順序寫write、順序讀read、隨機寫randwrite、隨機讀randread等。
size: 定址空間，IO會落在 [0, size)這個區間的硬碟空間上。這是一個可以影響IOPS的參數。一般設置為硬碟的大小。
filename: 測試對象
iodepth: 隊列深度，只有使用lio時才有意義。這是一個可以影響IOPS的參數。
runtime: 測試時長
下面我們做兩次測試，分別 iodepth = 1和iodepth = 4的情況。下面是iodepth = 1的測試結果。

上圖中藍色方框裡面的是測出的IOPS 230, 綠色方框裡面是每個IO請求的平均響應時間，大約是4.3ms。黃色方框表示95%的IO請求的響應時間是小於等於 9.920 ms。橙色方框表示該硬碟的利用率已經達到了98.58%。

下面是 iodepth = 4 的測試:

我們發現這次測試的IOPS沒有提高，反而IO平均響應時間變大了，是17ms。

為什麼這里提高隊列深度沒有作用呢，原因當隊列深度為1時，硬碟的利用率已經達到了98%，說明硬碟已經沒有多少空閑時間可以壓榨了。而且響應時間為 4ms。 對於SATA硬碟，當增加隊列深度時，並不會增加IOPS，只會增加響應時間。這是因為硬碟只有一個磁頭，並行度是1， 所以當IO請求隊列變長時，每個IO請求的等待時間都會變長，導致響應時間也變長。

這是以前用IOMeter測試一塊SATA硬碟的4K隨機寫性能，可以看到IOPS不會隨著隊列深度的增加而增加，反而是平均響應時間在倍增。

隊列深度 IOPS 平均響應時間
1 332.931525 3.002217
2 333.985074 5.986528
4 332.594653 12.025060
8 336.568012 23.766359
16 329.785606 48.513477
32 332.054590 96.353934
64 331.041063 193.200815
128 331.309109 385.163111
256 327.442963 774.401781
定址空間對IOPS的影響

我們繼續測試SATA硬碟，前面我們提到定址空間參數也會對IOPS產生影響，下面我們就測試當size=1GB時的情況。

我們發現，當設置size=1GB時，IOPS會顯著提高到568，IO平均響應時間會降到7ms(隊列深度為4)。這是因為當定址空間為1GB時，磁頭需要移動的距離變小了，每次IO請求的服務時間就降低了，這就是空間局部性原理。假如我們測試的RAID卡或者是磁碟陣列(SAN)，它們可能會用Cache把這1GB的數據全部緩存，極大降低了IO請求的服務時間(內存的寫操作比硬碟的寫操作快很1000倍)。所以設置定址空間為1GB的意義不大，因為我們是要測試硬碟的全盤性能，而不是Cache的性能。

硬碟優化

硬碟廠商提高硬碟性能的方法主要是降低服務時間(延遲)：

提高轉速(降低旋轉時間和傳輸時間)
增加Cache(降低寫延遲，但不會提高IOPS)
提高單磁軌密度(變相提高傳輸時間)
RAID測試

RAID0/RAID5/RAID6的多塊磁碟可以同時服務，其實就是提高並行度，這樣極大提高了性能(相當於銀行有多個櫃台)。

以前測試過12塊RAID0，100GB的定址空間，4KB隨機寫，逐步提高隊列深度，IOPS會提高，因為它有12塊磁碟(12個磁頭同時工作)，並行度是12。

隊列深度 IOPS 平均響應時間
1 1215.995842 0.820917
2 4657.061317 0.428420
4 5369.326970 0.744060
8 5377.387303 1.486629
16 5487.911660 2.914048
32 5470.972663 5.846616
64 5520.234015 11.585251
128 5542.739816 23.085843
256 5513.994611 46.401606
RAID卡廠商優化的方法也是降低服務時間：

使用大內存Cache
使用IO處理器，降低XOR操作的延遲。
使用更大帶寬的硬碟介面


SAN測試

對於低端磁碟陣列，使用單機IOmeter就可以測試出它的IOPS和MBPS的峰值，但是對於高端磁碟陣列，就需要多機並行測試才能得到IOPS和MBPS的峰值(IOmeter支持多機並行測試)。下圖是紀念照。

磁碟陣列廠商通過以下手段降低服務時間：

更快的存儲網路，比如FC和IB，延時更低。
讀寫Cache。寫數據到Cache之後就馬上返回，不需要落盤。 而且磁碟陣列有更多的控制器和硬碟，大大提高了並行度。
現在的存儲廠商會找SPC幫忙測試自己的磁碟陣列產品(或全快閃記憶體陣列)， 並給SPC支付費用，這就是赤裸裸的標准壟斷。國內也有做存儲系統測試的，假如你要測試磁碟陣列，可以找NSTC (廣告時間)。

SSD測試

SSD的延時很低，並行度很高(多個nand塊同時工作)，缺點是壽命和GC造成的響應時間不穩定。

推薦用IOMeter進行測試，使用大隊列深度，並進行長時間測試，這樣可以測試出SSD的真實性能。

下圖是storagereview對一些SSD硬碟做的4KB隨機寫的長時間測試，可以看出有些SSD硬碟的最大響應時間很不穩定，會飆高到幾百ms，這是不可接受的。

雲硬碟測試

我們通過兩方面來提高雲硬碟的性能的：

降低延遲(使用SSD，使用萬兆網路，優化代碼，減少瓶頸)
提高並行度(數據分片，同時使用整個集群的所有SSD)
在Linux下測試雲硬碟

在Linux下，你可以使用FIO來測試
操作系統：Ubuntu 14.04
CPU： 2
Memory: 2GB
雲硬碟大小： 1TB(SLA: 6000 IOPS, 170MB/s吞吐率 )
安裝fio：

#sudo apt-get install fio
再次介紹一下FIO的測試參數：

ioengine: 負載引擎，我們一般使用lio，發起非同步IO請求。
bs: IO大小
direct: 直寫，繞過操作系統Cache。因為我們測試的是硬碟，而不是操作系統的Cache，所以設置為1。
rw: 讀寫模式，有順序寫write、順序讀read、隨機寫randwrite、隨機讀randread等。
size: 定址空間，IO會落在 [0, size)這個區間的硬碟空間上。這是一個可以影響IOPS的參數。一般設置為硬碟的大小。
filename: 測試對象
iodepth: 隊列深度，只有使用lio時才有意義。這是一個可以影響IOPS的參數。
runtime: 測試時長
4K隨機寫測試

我們首先進行4K隨機寫測試，測試參數和測試結果如下所示：

#fio -ioengine=lio -bs=4k -direct=1 -thread -rw=randwrite -size=100G -filename=/dev/vdb \
-name="EBS 4KB randwrite test" -iodepth=32 -runtime=60

藍色方框表示IOPS是5900，在正常的誤差范圍內。綠色方框表示IO請求的平均響應時間為5.42ms， 黃色方框表示95%的IO請求的響應時間是小於等於 6.24 ms的。

4K隨機讀測試

我們再來進行4K隨機讀測試，測試參數和測試結果如下所示：

#fio -ioengine=lio -bs=4k -direct=1 -thread -rw=randread -size=100G -filename=/dev/vdb \
-name="EBS 4KB randread test" -iodepth=8 -runtime=60

512KB順序寫測試

最後我們來測試512KB順序寫，看看雲硬碟的最大MBPS(吞吐率)是多少，測試參數和測試結果如下所示：

#fio -ioengine=lio -bs=512k -direct=1 -thread -rw=write -size=100G -filename=/dev/vdb \
-name="EBS 512KB seqwrite test" -iodepth=64 -runtime=60

藍色方框表示MBPS為174226KB/s，約為170MB/s。
使用dd測試吞吐率

其實使用dd命令也可以測試出170MB/s的吞吐率，不過需要設置一下內核參數，詳細介紹在 128MB/s VS 170MB/s 章節中。
在Windows下測試雲硬碟

在Windows下，我們一般使用IOMeter測試磁碟的性能，IOMeter不僅功能強大，而且很專業，是測試磁碟性能的首選工具。
IOMeter是圖形化界面(濃濃的MFC框架的味道)，非常方便操作，下面我將使用IOMeter測試我們UOS上1TB的雲硬碟。
操作系統：Window Server 2012 R2 64
CPU： 4
Memory: 8GB
雲硬碟大小： 1TB
當你把雲硬碟掛載到Windows主機之後，你還需要在windows操作系統裡面設置硬碟為聯機狀態。

4K隨機寫測試

打開IOMeter(你需要先下載)，你會看到IOMeter的主界面。在右邊，你回發現4個worker(數量和CPU個數相同)，因為我們現在只需要1個worker，所以你需要把其他3個worker移除掉。現在讓我們來測試硬碟的4K隨機寫，我們選擇好硬碟(Red Hat VirtIO 0001)，設置定址空間(Maximum Disk Size)為50GB(每個硬碟扇區大小是512B，所以一共是 50*1024*1024*1024/512 = 104857600)，設置隊列深度(Outstanding I/Os)為64。

然後在測試集中選擇」4KiB ALIGNED; 0% Read; 100% random(4KB對齊，100%隨機寫操作)」 測試

然後設置測試時間，我們設置測試時長為60秒，測試之前的預熱時間為10秒(IOMeter會發起負載，但是不統計這段時間的結果)。

在最後測試之前，你可以設置查看實時結果，設置實時結果的更新頻率是5秒鍾。最後點擊綠色旗子開始測試。

在測試過程中，我們可以看到實時的測試結果，當前的IOPS是6042，平均IO請求響應時間是10.56ms，這個測試還需要跑38秒，這個測試輪回只有這個測試。

我們可以看到IOMeter自動化程度很高，極大解放測試人員的勞動力，而且可以導出CSV格式的測試結果。
順序讀寫測試

我們再按照上面的步驟，進行了順序讀/寫測試。下面是測試結果：
IO大小 讀寫模式 隊列深度 MBPS
順序寫吞吐測試 512KB 順序寫 64 164.07 MB/s
順序讀吞吐測試 256KB 順序讀 64 179.32 MB/s
雲硬碟的響應時間

當前雲硬碟寫操作的主要延遲是

網路傳輸
多副本，寫三份(數據強一致性)
三份數據都落盤(數據持久化)之後，才返回
IO處理邏輯
我們當前主要是優化IO處理邏輯，並沒有去優化2和3，這是因為我們是把用戶數據的安全性放在第一位。

128MB/s VS 170MB/s

回到最開始的問題 「為什麼使用dd命令測試雲硬碟只有128MB/s」， 這是因為目前雲硬碟在處理超大IO請求時的延遲比SSD高(我們會不斷進行優化)，現在我們有兩種方法來獲得更高的MBPS：

設置max_sectors_kb為256 (系統默認為512)，降低延遲
使用fio來測試，加大隊列深度
通過設置max_sectors_kb這個參數，使用dd也可以測出170MB/s的吞吐量

root@ustack:~# cat /sys/block/vdb/queue/max_sectors_kb
512
root@ustack:~# echo "256" > /sys/block/vdb/queue/max_sectors_kb
root@ustack:~#
root@ustack:~# dd if=/dev/zero of=/dev/vdb bs=32M count=40 oflag=direct
40+0 records in
40+0 records out
1342177280 bytes (1.3 GB) copied, 7.51685 s, 179 MB/s
root@ustack:~#
同時查看IO請求的延遲：

root@ustack:~# iostat -x vdb 5 100
...
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vdb 0.00 0.00 0.00 688.00 0.00 176128.00 512.00 54.59 93.47 0.00 93.47 1.40 96.56
下面是使用fio工具的測試結果，也可以得到170MB/s的吞吐率。

不可測試的指標

IOPS和MBPS是用戶可以使用工具測試的指標，雲硬碟還有一些用戶不可測量的指標

數據一致性
數據持久性
數據可用性
這些指標我們只能通過根據系統架構和約束條件計算得到，然後轉告給用戶。這些指標衡量著公有雲廠商的良心，有機會會專門進行介紹。

總結

上面介紹了一下測試工具和一些觀點，希望對你有所幫助。

測試需要定性和定量
了解存儲模型可以幫助你更好的進行測試
增加隊列深度可以有效測試出IOPS和MBPS的峰值