linuxiops
㈠ 如何測試雲硬碟
問題
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的峰值
㈡ 如何測試評估windows或linux下資料庫的iops
測試方法:
使用方式:
安裝FIO:
yum install gcc lio-devel -y
wget http://brick.kernel.dk/snaps/fio-2.0.10.tar.gz
tar -zxvf fio-2.0.10.tar.gz
cd fio-2.0.10
make && make install
測試:
隨機讀:
fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=16k -size=200G -numjobs=10 -runtime=1000 -group_reporting -name=mytest
參數說明:
filename=/dev/sdb1 測試文件名稱,通常選擇需要測試的盤的data目錄。
direct=1 測試過程繞過機器自帶的buffer。使測試結果更真實。
rw=randwrite 測試隨機寫的I/O
rw=randrw 測試隨機寫和讀的I/O
bs=16k 單次io的塊文件大小為16k
bsrange=512-2048 同上,提定數據塊的大小范圍
size=5g 本次的測試文件大小為5g,以每次4k的io進行測試。
numjobs=30 本次的測試線程為30.
runtime=1000 測試時間為1000秒,如果不寫則一直將5g文件分4k每次寫完為止。
ioengine=psync io引擎使用pync方式
rwmixwrite=30 在混合讀寫的模式下,寫佔30%
group_reporting 關於顯示結果的,匯總每個進程的信息。
此外
lockmem=1g 只使用1g內存進行測試。
zero_buffers 用0初始化系統buffer。
nrfiles=8 每個進程生成文件的數量。
###############################################
順序讀:
fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=1000 -group_reporting -name=mytest
隨機寫:
fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=1000 -group_reporting -name=mytest
順序寫:
fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=1000 -group_reporting -name=mytest
混合隨機讀寫:
fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=100 -group_reporting -name=mytest -ioscheler=noop
###############################################
實際測試範例:
[root@localhost ~]# fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=100 -group_reporting -name=mytest1
mytest1: (g=0): rw=randrw, bs=16K-16K/16K-16K, ioengine=psync, iodepth=1
…
mytest1: (g=0): rw=randrw, bs=16K-16K/16K-16K, ioengine=psync, iodepth=1
fio 2.0.7
Starting 30 threads
Jobs: 1 (f=1): [ [3.5% done] [6935K/3116K /s] [423 /190 iops] [eta 48m:20s] s]
mytest1: (groupid=0, jobs=30): err= 0: pid=23802
read : io=1853.4MB, bw=18967KB/s, iops=1185 , runt=100058msec
clat (usec): min=60 , max=871116 , avg=25227.91, stdev=3.46
lat (usec): min=60 , max=871117 , avg=25228.08, stdev=3.46
clat percentiles (msec):
| 1.00th=[ 3], 5.00th=[ 5], 10.00th=[ 6], 20.00th=[ 8],
| 30.00th=[ 10], 40.00th=[ 12], 50.00th=[ 15], 60.00th=[ 19],
| 70.00th=[ 26], 80.00th=[ 37], 90.00th=[ 57], 95.00th=[ 79],
| 99.00th=[ 151], 99.50th=[ 202], 99.90th=[ 338], 99.95th=[ 383],
| 99.99th=[ 523]
bw (KB/s) : min= 26, max= 1944, per=3.36%, avg=636.84, stdev=189.15
write: io=803600KB, bw=8031.4KB/s, iops=501 , runt=100058msec
clat (usec): min=52 , max=9302 , avg=146.25, stdev=299.17
lat (usec): min=52 , max=9303 , avg=147.19, stdev=299.17
clat percentiles (usec):
| 1.00th=[ 62], 5.00th=[ 65], 10.00th=[ 68], 20.00th=[ 74],
| 30.00th=[ 84], 40.00th=[ 87], 50.00th=[ 89], 60.00th=[ 90],
| 70.00th=[ 92], 80.00th=[ 97], 90.00th=[ 120], 95.00th=[ 370],
| 99.00th=[ 1688], 99.50th=[ 2128], 99.90th=[ 3088], 99.95th=[ 3696],
| 99.99th=[ 5216]
bw (KB/s) : min= 20, max= 1117, per=3.37%, avg=270.27, stdev=133.27
lat (usec) : 100=24.32%, 250=3.83%, 500=0.33%, 750=0.28%, 1000=0.27%
lat (msec) : 2=0.64%, 4=3.08%, 10=20.67%, 20=19.90%, 50=17.91%
lat (msec) : 100=6.87%, 250=1.70%, 500=0.19%, 750=0.01%, 1000=0.01%
cpu : usr=1.70%, sys=2.41%, ctx=5237835, majf=0, minf=6344162
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=118612/w=50225/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
READ: io=1853.4MB, aggrb=18966KB/s, minb=18966KB/s, maxb=18966KB/s, mint=100058msec, maxt=100058msec
WRITE: io=803600KB, aggrb=8031KB/s, minb=8031KB/s, maxb=8031KB/s, mint=100058msec, maxt=100058msec
Disk stats (read/write):
sdb: ios=118610/50224, merge=0/0, ticks=2991317/6860, in_queue=2998169, util=99.77%
㈢ Linux運維人員必知必會工具匯總
領域 :工具名稱
操作系統 :CentOS、Ubuntu、Redhat、suse、Freebsd
網站服務: nginx、apache、lighttpd、php、tomcat、resin
資料庫: Mysql、MariaDB、PostgreSQL
DB中間件 :maxscale、MyCat、atlas、cobar、amoeba、MySQL-proxy
代理相關: lvs、keepalived、haproxy、nginx、heartbeat
網站緩存: squid、nginx、varnish
NoSQL庫: Redis、CacheCloud、納氏和Memcached、MongoDB、HBase、Cassandra、CouchDB
存儲相關 :Nfs、FastDFS、Moosefs(mfs)、Ceph 、Hadoop、glusterfs、lustre
版本管理 :svn、git、gitlab、gogs
監控報警 :nagios、cacti、zabbix、munin、hyperic、mrtg、graphite
域名解析: bind、powerdns、dnsmasq
同步軟體: scp、rsync、inotify、sersync、drbd
批量管理: SSH、Ansible、Saltstack、expect、puppet
虛擬化: kvm、xen
雲計算: openstack、docker、k8s
內網軟體: iptables、zebra、iftraf、ntop、tc、iftop
郵件軟體: qmail、posfix、sendmail、zimbra
遠程撥號: openvpn、pptp、openswan、ipip
統一認證: openldap
隊列工具: ActiveMQ、RabbitMQ、核岩Metaq、MemcacheQ、Zeromq、kafka
打包發布: mvn、ants、Jenkins、Walle
測試軟體: ab、JMeter、Webbench、LoadRunner、http_load、tcp
帶寬測試 :smokeping
性能測試 ;dd、 fio(IOPS測試)、iozone(磁碟測試)
日誌相關: rsyslog、Awstats、flume、storm、ELK(Elasticsearch+Logstash+Kibana)
搜索軟體: Sphinx、Xapian、Solr
無人值守: rpm、yum(設計rpm包定製及yum倉庫構建)
大數據: HDFS、Hive、Hbase、Zookeeper、Pig、Spark、Mahout、flume、sqoop
項目管理: Jira、Redmine
linux管理: 寶塔Linux面板
滲透測試工具: SQLMap、Webscan
開源郵箱: iRedmail、extmail、Zimbra
軟體開發 :Sublime Text、Eclipse、Jetbrains
遠程連接: putty、Xshell、SecureCRT、MobaXterm、TeamViewer、向日葵
在此為伺服器運維人員推薦使用:寶塔面板 www.bt.cn
寶塔面板,近200個免費應用提供使用,如:網站管理、系統安全、系統監控、計劃任務、文件管理、軟體管洞盯理、一鍵部署等為伺服器運維人員提供安全高效的完成伺服器運維工作。
㈣ Linux上MySQL優化提升性能 哪些可以優化的關閉NUMA特性
Linux上MySQL優化提升性能,可以優化關閉NUMA特性如下:
這些其實都源於CPU最新的技術:節能模式。操作系統和CPU硬體配合,系統不繁忙的時候,為了節約電能和降低溫度,它會將CPU降頻。
為了保證MySQL能夠充分利用CPU的資源,建議設置CPU為最大性能模式。這個設置可以在BIOS和操作系統中設置,當然,在BIOS中設置該選項更好,更徹底。
然後我們看看內存方面,我們有哪些可以優化的。
i)
我們先看看numa
非一致存儲訪問結構
(NUMA
:
Non-Uniform
Memory
Access)
也是最新的內存管理技術。它和對稱多處理器結構
(SMP
:
Symmetric
Multi-Processor)
是對應的。
我們可以直觀的看到:SMP訪問內存的都是代價都是一樣的;但是在NUMA架構下,本地內存的訪問和非
本地內存的訪問代價是不一樣的。對應的根據這個特性,操作系統上,我們可以設置進程的內存分配方式。目前支持的方式包括:
--interleave=nodes
--membind=nodes
--cpunodebind=nodes
--physcpubind=cpus
--localalloc
--preferred=node
簡而言之,就是說,你可以指定內存在本地分配,在某幾個CPU節點分配或者輪詢分配。除非
是設置為--interleave=nodes輪詢分配方式,即內存可以在任意NUMA節點上分配這種方式以外。其他的方式就算其他NUMA節點上還有內
存剩餘,Linux也不會把剩餘的內存分配給這個進程,而是採用SWAP的方式來獲得內存。
所以最簡單的方法,還是關閉掉這個特性。
關閉特性的方法,分別有:可以從BIOS,操作系統,啟動進程時臨時關閉這個特性。
a)
由於各種BIOS類型的區別,如何關閉NUMA千差萬別,我們這里就不具體展示怎麼設置了。
b)
在操作系統中關閉,可以直接在/etc/grub.conf的kernel行最後添加numa=off,如下所示:
kernel
/vmlinuz-2.6.32-220.el6.x86_64
ro
root=/dev/mapper/VolGroup-root
rd_NO_LUKS.UTF-8
rd_LVM_LV=VolGroup/root
rd_NO_MD
quiet
SYSFONT=latarcyrheb-sun16
rhgb
crashkernel=auto
rd_LVM_LV=VolGroup/swap
rhgb
crashkernel=auto
quiet
KEYBOARDTYPE=pc
KEYTABLE=us
rd_NO_DM
numa=off
另外可以設置
vm.zone_reclaim_mode=0盡量回收內存。
c)
啟動MySQL的時候,關閉NUMA特性:
numactl
--interleave=all
mysqld
當然,最好的方式是在BIOS中關閉。
ii)
我們再看看vm.swappiness。
vm.swappiness是操作系統控制物理內存交換出去的策略。它允許的值是一個百分比的值,最小為0,最大運行100,該值默認為60。vm.swappiness設置為0表示盡量少swap,100表示盡量將inactive的內存頁交換出去。
具體的說:當內存基本用滿的時候,系統會根據這個參數來判斷是把內存中很少用到的inactive
內存交換出去,還是釋放數據的cache。
㈤ 面試 linux 文件系統怎樣io到底層
前言:本文主要講解LinuxIO調度層的三種模式:cfp、deadline和noop,並給出各自的優化和適用場景建議。IO調度發生在Linux內核的IO調度層。這個層次是針對Linux的整體IO層次體系來說的。從read()或者write()系統調用的角度來說,Linux整體IO體系可以分為七層,它們分別是:VFS層:虛擬文件系統層。由於內核要跟多種文件系統打交道,而每一種文件系統所實現的數據結構和相關方法都可能不盡相同,所以,內核抽象了這一層,專門用來適配各種文件系統,並對外提供統一操作介面。文件系統層:不同的文件系統實現自己的操作過程,提供自己特有的特徵,具體不多說了,大家願意的話自己去看代碼即可。頁緩存層:負責真對page的緩存。通用塊層:由於絕大多數情況的io操作是跟塊設備打交道,所以Linux在此提供了一個類似vfs層的塊設備操作抽象層。下層對接各種不同屬性的塊設備,對上提供統一的BlockIO請求標准。IO調度層:因為絕大多數的塊設備都是類似磁碟這樣的設備,所以有必要根據這類設備的特點以及應用的不同特點來設置一些不同的調度演算法和隊列。以便在不同的應用環境下有針對性的提高磁碟的讀寫效率,這里就是大名鼎鼎的Linux電梯所起作用的地方。針對機械硬碟的各種調度方法就是在這實現的。塊設備驅動層:驅動層對外提供相對比較高級的設備操作介面,往往是C語言的,而下層對接設備本身的操作方法和規范。塊設備層:這層就是具體的物理設備了,定義了各種真對設備操作方法和規范。有一個已經整理好的[LinuxIO結構圖],非常經典,一圖勝千言:我們今天要研究的內容主要在IO調度這一層。它要解決的核心問題是,如何提高塊設備IO的整體性能?這一層也主要是針對機械硬碟結構而設計的。眾所周知,機械硬碟的存儲介質是磁碟,磁頭在碟片上移動進行磁軌定址,行為類似播放一張唱片。這種結構的特點是,順序訪問時吞吐量較高,但是如果一旦對碟片有隨機訪問,那麼大量的時間都會浪費在磁頭的移動上,這時候就會導致每次IO的響應時間變長,極大的降低IO的響應速度。磁頭在碟片上尋道的操作,類似電梯調度,實際上在最開始的時期,Linux把這個演算法命名為Linux電梯演算法,即:如果在尋道的過程中,能把順序路過的相關磁軌的數據請求都「順便」處理掉,那麼就可以在比較小影響響應速度的前提下,提高整體IO的吞吐量。這就是我們為什麼要設計IO調度演算法的原因。目前在內核中默認開啟了三種演算法/模式:noop,cfq和deadline。嚴格算應該是兩種:因為第一種叫做noop,就是空操作調度演算法,也就是沒有任何調度操作,並不對io請求進行排序,僅僅做適當的io合並的一個fifo隊列。目前內核中默認的調度演算法應該是cfq,叫做完全公平隊列調度。這個調度演算法人如其名,它試圖給所有進程提供一個完全公平的IO操作環境。註:請大家一定記住這個詞語,cfq,完全公平隊列調度,不然下文就沒法看了。cfq為每個進程創建一個同步IO調度隊列,並默認以時間片和請求數限定的方式分配IO資源,以此保證每個進程的IO資源佔用是公平的,cfq還實現了針對進程級別的優先順序調度,這個我們後面會詳細解釋。查看和修改IO調度演算法的方法是:cfq是通用伺服器比較好的IO調度演算法選擇,對桌面用戶也是比較好的選擇。但是對於很多IO壓力較大的場景就並不是很適應,尤其是IO壓力集中在某些進程上的場景。因為這種場景我們需要的滿足某個或者某幾個進程的IO響應速度,而不是讓所有的進程公平的使用IO,比如資料庫應用。deadline調度(最終期限調度)就是更適合上述場景的解決方案。deadline實現了四個隊列:其中兩個分別處理正常read和write,按扇區號排序,進行正常io的合並處理以提高吞吐量。因為IO請求可能會集中在某些磁碟位置,這樣會導致新來的請求一直被合並,可能會有其他磁碟位置的io請求被餓死。另外兩個處理超時read和write的隊列,按請求創建時間排序,如果有超時的請求出現,就放進這兩個隊列,調度演算法保證超時(達到最終期限時間)的隊列中的請求會優先被處理,防止請求被餓死。不久前,內核還是默認標配四種演算法,還有一種叫做as的演算法(Anticipatoryscheler),預測調度演算法。一個高大上的名字,搞得我一度認為Linux內核都會算命了。結果發現,無非是在基於deadline演算法做io調度的之前等一小會時間,如果這段時間內有可以合並的io請求到來,就可以合並處理,提高deadline調度的在順序讀寫情況下的數據吞吐量。其實這根本不是啥預測,我覺得不如叫撞大運調度演算法,當然這種策略在某些特定場景差效果不錯。但是在大多數場景下,這個調度不僅沒有提高吞吐量,還降低了響應速度,所以內核乾脆把它從默認配置里刪除了。畢竟Linux的宗旨是實用,而我們也就不再這個調度演算法上多費口舌了。1、cfq:完全公平隊列調度cfq是內核默認選擇的IO調度隊列,它在桌面應用場景以及大多數常見應用場景下都是很好的選擇。如何實現一個所謂的完全公平隊列(CompletelyFairQueueing)?首先我們要理解所謂的公平是對誰的公平?從操作系統的角度來說,產生操作行為的主體都是進程,所以這里的公平是針對每個進程而言的,我們要試圖讓進程可以公平的佔用IO資源。那麼如何讓進程公平的佔用IO資源?我們需要先理解什麼是IO資源。當我們衡量一個IO資源的時候,一般喜歡用的是兩個單位,一個是數據讀寫的帶寬,另一個是數據讀寫的IOPS。帶寬就是以時間為單位的讀寫數據量,比如,100Mbyte/s。而IOPS是以時間為單位的讀寫次數。在不同的讀寫情境下,這兩個單位的表現可能不一樣,但是可以確定的是,兩個單位的任何一個達到了性能上限,都會成為IO的瓶頸。從機械硬碟的結構考慮,如果讀寫是順序讀寫,那麼IO的表現是可以通過比較少的IOPS達到較大的帶寬,因為可以合並很多IO,也可以通過預讀等方式加速數據讀取效率。當IO的表現是偏向於隨機讀寫的時候,那麼IOPS就會變得更大,IO的請求的合並可能性下降,當每次io請求數據越少的時候,帶寬表現就會越低。從這里我們可以理解,針對進程的IO資源的主要表現形式有兩個:進程在單位時間內提交的IO請求個數和進程佔用IO的帶寬。其實無論哪個,都是跟進程分配的IO處理時間長度緊密相關的。有時業務可以在較少IOPS的情況下佔用較大帶寬,另外一些則可能在較大IOPS的情況下佔用較少帶寬,所以對進程佔用IO的時間進行調度才是相對最公平的。即,我不管你是IOPS高還是帶寬佔用高,到了時間咱就換下一個進程處理,你愛咋樣咋樣。所以,cfq就是試圖給所有進程分配等同的塊設備使用的時間片,進程在時間片內,可以將產生的IO請求提交給塊設備進行處理,時間片結束,進程的請求將排進它自己的隊列,等待下次調度的時候進行處理。這就是cfq的基本原理。當然,現實生活中不可能有真正的「公平」,常見的應用場景下,我們很肯能需要人為的對進程的IO佔用進行人為指定優先順序,這就像對進程的CPU佔用設置優先順序的概念一樣。所以,除了針對時間片進行公平隊列調度外,cfq還提供了優先順序支持。每個進程都可以設置一個IO優先順序,cfq會根據這個優先順序的設置情況作為調度時的重要參考因素。優先順序首先分成三大類:RT、BE、IDLE,它們分別是實時(RealTime)、最佳效果(BestTry)和閑置(Idle)三個類別,對每個類別的IO,cfq都使用不同的策略進行處理。另外,RT和BE類別中,分別又再劃分了8個子優先順序實現更細節的QOS需求,而IDLE只有一個子優先順序。另外,我們都知道內核默認對存儲的讀寫都是經過緩存(buffer/cache)的,在這種情況下,cfq是無法區分當前處理的請求是來自哪一個進程的。只有在進程使用同步方式(syncread或者syncwirte)或者直接IO(DirectIO)方式進行讀寫的時候,cfq才能區分出IO請求來自哪個進程。所以,除了針對每個進程實現的IO隊列以外,還實現了一個公共的隊列用來處理非同步請求。當前內核已經實現了針對IO資源的cgroup資源隔離,所以在以上體系的基礎上,cfq也實現了針對cgroup的調度支持。總的來說,cfq用了一系列的數據結構實現了以上所有復雜功能的支持,大家可以通過源代碼看到其相關實現,文件在源代碼目錄下的block/cfq-iosched.c。1.1cfq設計原理在此,我們對整體數據結構做一個簡要描述:首先,cfq通過一個叫做cfq_data的數據結構維護了整個調度器流程。在一個支持了cgroup功能的cfq中,全部進程被分成了若干個contralgroup進行管理。每個cgroup在cfq中都有一個cfq_group的結構進行描述,所有的cgroup都被作為一個調度對象放進一個紅黑樹中,並以vdisktime為key進行排序。vdisktime這個時間紀錄的是當前cgroup所佔用的io時間,每次對cgroup進行調度時,總是通過紅黑樹選擇當前vdisktime時間最少的cgroup進行處理,以保證所有cgroups之間的IO資源佔用「公平」。當然我們知道,cgroup是可以對blkio進行資源比例分配的,其作用原理就是,分配比例大的cgroup佔用vdisktime時間增長較慢,分配比例小的vdisktime時間增長較快,快慢與分配比例成正比。這樣就做到了不同的cgroup分配的IO比例不一樣,並且在cfq的角度看來依然是「公平「的。選擇好了需要處理的cgroup(cfq_group)之後,調度器需要決策選擇下一步的service_tree。service_tree這個數據結構對應的都是一系列的紅黑樹,主要目的是用來實現請求優先順序分類的,就是RT、BE、IDLE的分類。每一個cfq_group都維護了7個service_trees,其定義如下:其中service_tree_idle就是用來給IDLE類型的請求進行排隊用的紅黑樹。而上面二維數組,首先第一個維度針對RT和BE分別各實現了一個數組,每一個數組中都維護了三個紅黑樹,分別對應三種不同子類型的請求,分別是:SYNC、SYNC_NOIDLE以及ASYNC。我們可以認為SYNC相當於SYNC_IDLE並與SYNC_NOIDLE對應。idling是cfq在設計上為了盡量合並連續的IO請求以達到提高吞吐量的目的而加入的機制,我們可以理解為是一種「空轉」等待機制。空轉是指,當一個隊列處理一個請求結束後,會在發生調度之前空等一小會時間,如果下一個請求到來,則可以減少磁頭定址,繼續處理順序的IO請求。為了實現這個功能,cfq在service_tree這層數據結構這實現了SYNC隊列,如果請求是同步順序請求,就入隊這個servicetree,如果請求是同步隨機請求,則入隊SYNC_NOIDLE隊列,以判斷下一個請求是否是順序請求。所有的非同步寫操作請求將入隊ASYNC的servicetree,並且針對這個隊列沒有空轉等待機制。此外,cfq還對SSD這樣的硬碟有特殊調整,當cfq發現存儲設備是一個ssd硬碟這樣的隊列深度更大的設備時,所有針對單獨隊列的空轉都將不生效,所有的IO請求都將入隊SYNC_NOIDLE這個servicetree。每一個servicetree都對應了若干個cfq_queue隊列,每個cfq_queue隊列對應一個進程,這個我們後續再詳細說明。cfq_group還維護了一個在cgroup內部所有進程公用的非同步IO請求隊列,其結構如下:非同步請求也分成了RT、BE、IDLE這三類進行處理,每一類對應一個cfq_queue進行排隊。BE和RT也實現了優先順序的支持,每一個類型有IOPRIO_BE_NR這么多個優先順序,這個值定義為8,數組下標為0-7。我們目前分析的內核代碼版本為Linux4.4,可以看出,從cfq的角度來說,已經可以實現非同步IO的cgroup支持了,我們需要定義一下這里所謂非同步IO的含義,它僅僅表示從內存的buffer/cache中的數據同步到硬碟的IO請求,而不是aio(man7aio)或者linux的native非同步io以及lio機制,實際上這些所謂的「非同步」IO機制,在內核中都是同步實現的(本質上馮諾伊曼計算機沒有真正的「非同步」機制)。我們在上面已經說明過,由於進程正常情況下都是將數據先寫入buffer/cache,所以這種非同步IO都是統一由cfq_group中的async請求隊列處理的。那麼為什麼在上面的service_tree中還要實現和一個ASYNC的類型呢?這當然是為了支持區分進程的非同步IO並使之可以「完全公平」做准備嘍。實際上在最新的cgroupv2的blkio體系中,內核已經支持了針對bufferIO的cgroup限速支持,而以上這些可能容易混淆的一堆類型,都是在新的體系下需要用到的類型標記。新體系的復雜度更高了,功能也更加強大,但是大家先不要著急,正式的cgroupv2體系,在Linux4.5發布的時候會正式跟大家見面。我們繼續選擇service_tree的過程,三種優先順序類型的service_tree的選擇就是根據類型的優先順序來做選擇的,RT優先順序最高,BE其次,IDLE最低。就是說,RT里有,就會一直處理RT,RT沒了再處理BE。每個service_tree對應一個元素為cfq_queue排隊的紅黑樹,而每個cfq_queue就是內核為進程(線程)創建的請求隊列。每一個cfq_queue都會維護一個rb_key的變數,這個變數實際上就是這個隊列的IO服務時間(servicetime)。這里還是通過紅黑樹找到servicetime時間最短的那個cfq_queue進行服務,以保證「完全公平」。選擇好了cfq_queue之後,就要開始處理這個隊列里的IO請求了。這里的調度方式基本跟deadline類似。cfq_queue會對進入隊列的每一個請求進行兩次入隊,一個放進fifo中,另一個放進按訪問扇區順序作為key的紅黑樹中。默認從紅黑樹中取請求進行處理,當請求的延時時間達到deadline時,就從紅黑樹中取等待時間最長的進行處理,以保證請求不被餓死。這就是整個cfq的調度流程,當然其中還有很多細枝末節沒有交代,比如合並處理以及順序處理等等。1.2cfq的參數調整理解整個調度流程有助於我們決策如何調整cfq的相關參數。所有cfq的可調參數都可以在/sys/class/block/sda/queue/iosched/目錄下找到,當然,在你的系統上,請將sda替換為相應的磁碟名稱。我們來看一下都有什麼:這些參數部分是跟機械硬碟磁頭尋道方式有關的,如果其說明你看不懂,請先補充相關知識:back_seek_max:磁頭可以向後定址的最大范圍,默認值為16M。back_seek_penalty:向後定址的懲罰系數。這個值是跟向前定址進行比較的。以上兩個是為了防止磁頭尋道發生抖動而導致定址過慢而設置的。基本思路是這樣,一個io請求到來的時候,cfq會根據其定址位置預估一下其磁頭尋道成本。設置一個最大值back_seek_max,對於請求所訪問的扇區號在磁頭後方的請求,只要定址范圍沒有超過這個值,cfq會像向前定址的請求一樣處理它。再設置一個評估成本的系數back_seek_penalty,相對於磁頭向前定址,向後定址的距離為1/2(1/back_seek_penalty)時,cfq認為這兩個請求定址的代價是相同。這兩個參數實際上是cfq判斷請求合並處理的條件限制,凡事復合這個條件的請求,都會盡量在本次請求處理的時候一起合並處理。fifo_expire_async:設置非同步請求的超時時間。同步請求和非同步請求是區分不同隊列處理的,cfq在調度的時候一般情況都會優先處理同步請求,之後再處理非同步請求,除非非同步請求符合上述合並處理的條件限制范圍內。當本進程的隊列被調度時,cfq會優先檢查是否有非同步請求超時,就是超過fifo_expire_async參數的限制。如果有,則優先發送一個超時的請求,其餘請求仍然按照優先順序以及扇區編號大小來處理。fifo_expire_sync:這個參數跟上面的類似,區別是用來設置同步請求的超時時間。slice_idle:參數設置了一個等待時間。這讓cfq在切換cfq_queue或servicetree的時候等待一段時間,目的是提高機械硬碟的吞吐量。一般情況下,來自同一個cfq_queue或者servicetree的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的低延時(lowlatency)模式的開關。當這個開關打開時,cfq將會根據target_latency的參數設置來對每一個進程的分片時間(slicetime)進行重新計算。這將有利於對吞吐量的公平(默認是對時間片分配的公平)。關閉這個參數(設置為0)將忽略target_latency的值。這將使系統中的進程完全按照時間片方式進行IO資源分配。這個開關默認是打開的。我們已經知道cfq設計上有「空轉」(idling)這個概念,目的是為了可以讓連續的讀寫操作盡可能多的合並處理,減少磁頭的定址操作以便增大吞吐量。如果有進程總是很快的進行順序讀寫,那麼它將因為cfq的空轉等待命中率很高而導致其它需要處理IO的進程響應速度下降,如果另一個需要調度的進程不會發出大量順序IO行為的話,系統中不同進程IO吞吐量的表現就會很不均衡。就比如,系統內存的cache中有很多臟頁要寫回時,桌面又要打開一個瀏覽器進行操作,這時臟頁寫回的後台行為就很可能會大量命中空轉時間,而導致瀏覽器的小量IO一直等待,讓用戶感覺瀏覽器運行響應速度變慢。這個low_latency主要是對這種情況進行優化的選項,當其打開時,系統會根據target_latency的配置對因為命中空轉而大量佔用IO吞吐量的進程進行限制,以達到不同進程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優先順序有關。1.3cfq的IOPS模式我們已經知道,默認情況下cfq是以時間片方式支持的帶優先順序的調度來保證IO資源佔用的公平。高優先順序的進程將得到的時間片長度,而低優先順序的進程時間片相對較小。當我們的存儲是一個高速並且支持NCQ(原生指令隊列)的設備的時候,我們最好可以讓其可以從多個cfq隊列中處理多路的請求,以便提升NCQ的利用率。此時使用時間片的分配方式分配資源就顯得不合時宜了,因為基於時間片的分配,同一時刻最多能處理的請求隊列只有一個。這時,我們需要切換cfq的模式為IOPS模式。切換方式很簡單,就是將slice_idle=0即可。內核會自動檢測你的存儲設備是否支持NCQ,如果支持的話cfq會自動切換為IOPS模式。另外,在默認的基於優先順序的時間片方式下,我們可以使用ionice命令來調整進程的IO優先順序。進程默認分配的IO優先順序是根據進程的nice值計算而來的,計算方法可以在manionice中看到,這里不再廢話。2、deadline:最終期限調度deadline調度演算法相對cfq要簡單很多。其設計目標是:在保證請求按照設備扇區的順序進行訪問的同時,兼顧其它請求不被餓死,要在一個最終期限前被調度到。我們知道磁頭對磁碟的尋道是可以進行順序訪問和隨機訪問的,因為尋道延時時間的關系,順序訪問時IO的吞吐量更大,隨機訪問的吞吐量小。如果我們想為一個機械硬碟進行吞吐量優化的話,那麼就可以讓調度器按照盡量復合順序訪問的IO請求進行排序,之後請求以這樣的順序發送給硬碟,就可以使IO的吞吐量更大。但是這樣做也有另一個問題,就是如果此時出現了一個請求,它要訪問的磁軌離目前磁頭所在磁軌很遠,應用的請求又大量集中在目前磁軌附近。導致大量請求一直會被合並和插隊處理,而那個要訪問比較遠磁軌的請求將因為一直不能被調度而餓死。deadline就是這樣一種調度器,能在保證IO最大吞吐量的情況下,盡量使遠端請求在一個期限內被調度而不被餓死的調度器。
㈥ 伺服器怎麼和電腦連接
怎樣把電腦和伺服器連接起來? 10分
1、 雙機直連
即是說其中一台計算機與ADSL Modem相連,然後通過網卡直接與另一台計算機連接。如果採用這種連接,就需要在寬頻接入的計算機上作internet共享代理設置,比如安裝wingate等代理軟體,來實現雙機共享上網。這算是最最廉價的網路。
2、 寬頻路由器+網卡+計算機
這種方式主要用在共享計算機不多的情況下。因為一般的寬頻路由器都提供了4個交換機埠,如果需要共享的計算機小於4台的話,就沒必要再花錢去購買交換機了。具體連接方式為:ADSL寬頻線路連接ADSL Modem,直連雙絞線連接Modem和路由器,其它計算機用交叉雙絞線與路由器相連即可。
3、 寬頻路由器+交換機+網卡+計算機
對應上面一種情況,此方式就是運用在共享計算機大於寬頻路由器交換埠的情況下。這時就需要交換機幫忙,並根據共享計算機的數量選擇相應埠的交換機。即是說,所有共享計算機先與交換機相連,再通過交換機連接寬頻路由器,從而實現共享上網。
4、 交換機+網卡+計算機
如果你的ADSL Modem自帶有寬頻路由功能(請查看產品說明書),那就可以省去路由器。這是跟上面三種方式唯一的區別。連接起來也更方便,根本不需要設置,連接方式為:ADSL Modem的LAN口用雙絞線和交換機的任一埠連接,再將各計算機分別接入交換機剩餘埠即可。
組建區域網,共享上網
——》一:網線直連不是最經濟的做法,雖然我們只需要添加1條網線、1塊網卡,總價格算起來不會超過100元。但是這種做法有個最大的弱點,就是上網時兩台機器必須同時開著,除非你只用主機上網,否則日積月累的電費,呵呵也不見得比其它方法省錢~~,所以建議最好不使用這種辦法!
——》二:採用交換機/HUB、伺服器的方式。我們可以採用SyGate等軟體做成誰先開機誰做主機的共享形式,但還潛在一個問題,就是當作為主機的那台機器提前關機了,另外一台機器的網路也許隨之斷開,如果你這時候正用ie下載文件到一半,如果你正在玩聯眾……呵呵後果可想而知!
——》三:採用寬頻路由方式。如果你不想自己設置,可以在購買寬頻的同時讓技術人員幫你設置好。
同時這種方式帶來的好處還有就是穩定!是以上所有方案中最穩定的,這個好像沒有異議吧。還有就是省力,你不需要每次上網都要撥號了,這都由寬頻路由來自動替你完成,而且寬頻路由還有斷線重撥功能,省去了多少麻煩?接下來就是安全,你暴露在Internet上的IP是你路由的IP,而非機器本身的IP,這樣你就無形中被保護起來。
再有就是不違反電信或者網通的規定,即使他限制了MAC地址也沒用,因為路由本身是有MAC地址的。
——》1,首先將寬頻貓與路由器的WLAN埠連接,可使用貓隨機帶的連接線。
——》2,用直連網線將路由器的一個Lan口與交換機的UpLing口連接。還用直連網線連接交換機的普通口和電腦。這樣硬體環境就做好了。如果你的機器比較少,也就2、3台的話,沒有必要加交換機,用直連網線將路由器的一個Lan口與一台電腦連接即可。
——》3,第一台機器,先設置你的網路參數(右鍵「網上鄰居」-「屬性」-右鍵「本地連接」-屬性-找到TCP/IP協議後雙擊它):
IP地址:192.168.1.11
子網掩碼:255.255.255.0
網關:192.16績.1.1
DNS:不要管它。
然後一路「確定」,需要重啟的時候重啟。不過有沒有提示,你最好還是重新啟動一下。
——》4,第二台機器,如第一台,只是將IP地址變成1......>>
怎樣在電腦連接伺服器
你好.我來解答下你的問題.
伺服器上架好以後服務商會給你提供IP用戶和密碼.如果是WIN的系統.只需要在本地電腦點開始-附件-程序-通訊-遠程桌面連接.然後輸入IP用戶和密碼.點連接即可登錄.若是用的LINUX系統.可以藉助於PUTTY遠程連接工具登錄.
海騰數據楊闖為你解答.
電腦怎麼連接學校的伺服器
1.首先打開電腦,看到右下角的網路標志,左鍵單擊一下點開,然後看到網路共享中心,左鍵單擊一下
2.進入網路共享中心之後,找到設置新的連接,左鍵單擊,開始設置
3.點擊手動連接到工作區這個選項
4.這里會出現要求設置新的連接,我是設置過了,才會有兩個選擇,沒有設置過得只有一個設置新的連接的選項,直接選擇設置新的連接就行了
5.點擊選擇我的VPN連接,進行地址設置,這個地址設置很關鍵,只有地址是對的才能接上校園網
6.這里填上學校給你的連接地址,每一個學校的地址都不同,這個就是學校伺服器端的IP,填好之後直接下一步
7.這個窗口是進行密碼設置的,填上你的賬號,和你的密碼,密碼要記住,以後登錄就靠它了,設置完了點擊鏈接
8.鏈接好了之後還需要設置一下你的VPN屬性,不然就不能上網,因為你的埠是子埠,要通過驗證。右鍵單擊你的VPN鏈接的標志,會看到屬性,單擊一下就行了
9.接下來出現的窗口選項,網路,安全,一個都不能少,全部要設置成圖中的選擇,必須和圖中的一樣,不然是不能聯網的。
我電腦連接不上我的伺服器?怎麼回事?
你的伺服器是用的windows操作系統嗎?
可能是你服務暢裡面沒有設置允許別的電腦通過遠程連接伺服器。你右鍵點伺服器里的我的電腦,然後點管理,裡面有個服務,服務裡面有很多項,其中一項是可以開啟的,就是允許別人遠程連接的服務,你看看你這個服務有沒有開啟啊。
電腦連接不上伺服器是怎麼回事?
我的電腦也出現過這樣的問題,還重裝了系統後來還是有這樣的問題。我告訴你兩個可能。
第一:電腦中毒了;解決方法:殺毒或重裝系統。
第二:DNS伺服器地址不能自動配置或配置錯誤.如果你可以直接用地址上網那就這種可能性大一些了。操作方法:,在IE瀏覽器中鍵入「202.103.69.205」。如果能夠進入網站那就是我說的第二個原因了。
解決方法:手動設置DNS伺服器地址。設置方法:網上鄰居右鍵-》屬性-》INTERNET連接協議雙擊—》使用下面的DNS伺服器地址。如果還不可以就建議重裝系統,然後在手動設置DNS伺服器地址。
如何連接伺服器
遠程連接是工作、生活中會經常用到的手段,當某台計算機開啟了遠程連接功能後我們就可以在網路的另一端控制這台計算機了,通過遠程桌面功能我們就可以實時的操作這台計算機了。 遠程連接的步驟是比較簡單的,下面給大家介紹遠程連接的操作 首先,需要將計算機(伺服器)的遠程訪問功能開啟,才能夠被遠程訪問。開啟遠程訪問:右鍵「我的電腦」點擊屬性,點擊最右邊的「遠程」按鈕,把遠程桌面裡面的「允許用戶遠程連接到此計算機」勾上就可以了。 然後使用其它計算機進行遠程桌面連接操作:點擊「開始—運行」 在運行窗口裡輸入mstsc(遠程桌面連接的命令) 或者可以在「開始—所有程序—附件—遠程桌面連接」進入遠程桌面連接 輸入你要連接的計算機的IP地址,然後使用對應的用戶名及密碼登陸 這里一定要確保IP地址、用戶名、密碼都是相關聯的,才能成功登陸其它計算機。因為安全原因,一般一個用戶連接一個遠程桌面只能連接三個,如果不正常退出,那麼會造成登錄三次以後就無法登錄了。
所以正確的退出也是很重要的。退出時,要點擊「開始-關機」,在下拉菜單中選擇「斷開」這樣就不會因為不正常退出而造成無法訪問了!
列印機連到伺服器上,怎樣把電腦上連上列印機?
你現在是將列印機到底連在什麼地方啊,伺服器還是你的電腦?
如果是伺服器上
在本機運行輸入cmd 輸入「\\你伺服器的IP地址」然後是在彈出的窗口中輸入登陸的用戶名和密碼進入,然後雙擊共享的列印機就可以了。
如果列印機是連在本機的
先關閉列印機電源,用驅動程序一步一步安裝,提示插入數據耽和電源時插入數據線,然後打開電源,自動找到列印機後直到安裝結束。
怎樣知道自己的電腦連接的哪台伺服器啊?
最簡單的可視化操作,如果你有360安全衛士,桌面右下角,右鍵360,流量防火牆,看見了沒有。
很直觀!
想問一下伺服器和電腦之間到底是怎麼運作的,伺服器直接連跟線到電腦上? 70分
差異很大,並非單純cpu和主板的區別,比如伺服器為了高可靠性,會設計成冗餘電源,磁碟子系統多使用帶冗餘的raid1和raid5,性能上可以提供很高的iops。伺服器通過網路給客戶提供服務,比如email,web,database,online交易等,因此大部分伺服器的顯示子系統很爛,大多是主板集成的一片2d顯卡,顯存16m,最多128m,比如mx200.
我租了伺服器。用我的電腦怎麼連接
點開始~程序~所有程度~附件~通迅~遠程桌面連接~輸入IP登錄~輸入張號和密碼