内部処理を4KB/sectorで行うというWD Caviar Green (Advanced Format)シリーズのハードディスク、WD15EARSを調達したので性能を見てみる。昨日の記事の通り、OSはFreeBSD 8/amd64、接続インターフェースはeSATAである。
まず、単体のraw書き込み性能を見てみる。
|
1 2 3 4 5 |
% sudo dd if=/dev/zero of=/dev/ada0 bs=1M count=10000 10000+0 records in 10000+0 records out 10485760000 bytes transferred in 104.850489 secs (100006782 bytes/sec) |
つまり100MB/s弱だ。eSATAインターフェースカードで律速していないかは、後日内蔵SATAと比較するとしよう。
それでは、一台まるごとZFSにしてbonnie++で測ってみる。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
% sudo zpool create test ada0 % sudo bonnie++ -d /test -n 64:102400:128:8 -u root Writing a byte at a time...done [...] Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP daemon.musha.or 16G 138 99 58072 13 28952 6 420 99 82789 9 86.6 2 Latency 197ms 6496ms 8717ms 46942us 1645ms 2071ms Version 1.96 ------Sequential Create------ --------Random Create-------- daemon.musha.org -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 64:102400:128/8 139 3 82 1 17323 77 92 2 52 0 48 0 Latency 41400ms 5563ms 81225us 34264ms 6496ms 9847ms 1.96,1.96,daemon.musha.org,1,1271143734,16G,,138,99,58072,13,28952,6,420,99,82789,9,86.6,2,64,102400,128,,8,139,3,82,1,17323,77,92,2,52,0,48,0,197ms,6496ms,8717ms,46942us,1645ms,2071ms,41400ms,5563ms,81225us,34264ms,6496ms,9847ms % sudo zpool destroy test |
…うーん、シーケンシャル書き込みが58MB/sとはちょっとさびしい。
ところで、このディスクはどのように諸元情報を返しているのだろうか。
|
1 2 3 |
% sudo camcontrol identify ada0 | grep 'sector size' sector size logical 512, physical 512, offset 0 |
古いOSの互換性のためなのか、physical sector sizeも512Bと返しているようだ。ジャンパー設定を調べたが、残念ながらこれを変えることはできない模様。
それでは、GEOMを使って4KB/sectorでアクセスするようにしてみよう。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
% sudo gnop create -S 4096 ada0 % sudo zpool create test ada0.nop % sudo bonnie++ -d /test -n 64:102400:128:8 -u root Writing a byte at a time...done [...] Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP daemon.musha.or 16G 129 99 68255 15 38455 8 434 99 88872 9 100.1 2 Latency 64647us 5964ms 6305ms 37390us 1907ms 1397ms Version 1.96 ------Sequential Create------ --------Random Create-------- daemon.musha.org -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 64:102400:128/8 776 19 115 1 17922 82 790 20 110 1 21075 96 Latency 7490ms 1116ms 108ms 7415ms 1015ms 22992us 1.96,1.96,daemon.musha.org,1,1271239571,16G,,129,99,68255,15,38455,8,434,99,88872,9,100.1,2,64,102400,128,,8,776,19,115,1,17922,82,790,20,110,1,21075,96,64647us,5964ms,6305ms,37390us,1907ms,1397ms,7490ms,1116ms,108ms,7415ms,1015ms,22992us % sudo zpool destroy test % sudo gnop destroy ada0.nop |
おー。シーケンシャル書き込みだけ見ても68MB/sと15%以上もスループットが向上し、latencyも大幅に改善した。
さらに、2台でストライピングしてみるとこうなった。
|
1 2 3 4 5 6 7 8 9 10 11 |
Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP daemon.musha.or 16G 138 98 94311 22 58070 12 431 99 123342 13 172.8 5 Latency 155ms 3874ms 4034ms 38783us 990ms 730ms Version 1.96 ------Sequential Create------ --------Random Create-------- daemon.musha.org -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 64:102400:128/8 1123 29 134 1 16901 80 1062 27 111 1 18945 88 Latency 3282ms 1121ms 53040us 4831ms 910ms 4748us 1.96,1.96,daemon.musha.org,1,1271168105,16G,,138,98,94311,22,58070,12,431,99,123342,13,172.8,5,64,102400,128,,8,1123,29,134,1,16901,80,1062,27,111,1,18945,88,155ms,3874ms,4034ms,38783us,990ms,730ms,3282ms,1121ms,53040us,4831ms,910ms,4748us |
シーケンシャルで94MB/s。不満は残るがとりあえずよしとしよう。
ところで、gnop(8)の設定は保存されないので、起動するたびに設定する必要がある（つまり、起動用のシステムを構成するボリュームでは使えないと思った方がよさそう）。というわけで、こんな風なスクリプトを書いて/etc/rc.d/に置き、
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
#!/bin/sh # PROVIDE: zfs_prepare # BEFORE: zfs zvol . /etc/rc.subr name="zfs_prepare" rcvar="zfs_prepare_enable" start_cmd="zfs_prepare_start" stop_cmd="zfs_prepare_stop" #required_modules="geom_nop" zfs_prepare_start() { [ `$SYSCTL_N security.jail.jailed` -ne 1 ] || return 0 local dev for dev in $zfs_prepare_devs; do gnop create -S 4096 $dev done } zfs_prepare_stop() { [ `$SYSCTL_N security.jail.jailed` -ne 1 ] || return 0 local dev for dev in $zfs_prepare_devs; do gnop destroy $dev.nop done } load_rc_config $name run_rc_command "$1" |
/etc/rc.confに設定する。
|
1 2 |
zfs_prepare_enable="YES" zfs_prepare_devs="ada0 ada1 ada2" |
これで無事、nopデバイスが起動時にできるので、好きに使ってプールを構成すればいい。
外付け箱にはとりあえず3台積んでストライプし、内蔵している移行元HDDからのそこへのコピーが済んだら、古い内蔵HDD群を換装してada[0-2]にそれぞれattachすれば、RAID1+0のような構成になるだろう。空いたスロットには、起動ドライブのミラーボリュームを入れるつもり。
メンテナンスに入るときに、ホットスワップもテストしてみたい。夢が広がるよ！
ピンバック: 工夫と趣向と分別と。
I don’t think the title of your article matches the content lol. Just kidding, mainly because I had some doubts after reading the article.
Your point of view caught my eye and was very interesting. Thanks. I have a question for you. https://accounts.binance.com/fr/register?ref=GJY4VW8W