云服务器如何升级内核

㈠ 怎么查看自己的云服务器是几核的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的峰值