linux

と思って試してみました。

tuned-admというコマンドでlatency-performanceプロファイルを使ってみると

pingの応答時間が改善したという例です。

latency-performanceプロファイルでは主に下記の2点の設定が行われます。

  1. i/o scheduler cfq -> deadline
  2. /dev/cpu_dma_latency

では、さっそく確認してみます。

■設定前

■インストール&設定

■設定後

元に戻したい場合は

で元に戻りpingの応答時間も長くなります。

これを見ると低負荷時においても遅延が最小限に抑えられているように見えます。

低レイテンシーな環境が求められるトレーディングのシステムやシェアードのディスクを使うホスト等で利用するとよいかもしれません。

ただし、CPUガバナーを利用して強制的にCPUをC0ステート(最大パフォーマンス)で動作させているので、

あまり利用していないシーンでも電力量が増加しますので注意が必要です。

このテストで使用されているサーバは誰も利用していないのですが、

これが

tuned前

こうなります。

tuned後
ちなみに

tuned-utilsをインストールすれば、下記のコマンドで設定も可能です。

/usr/libexec/tuned/pmqos-static.py cpu_dma_latency=0

各動作の状態は下記のlatencyの値により決定しているようです。

下記の数字にそってlatencyの値を変更するとCステートのモードが切り替わります。

IntelがOSSで公開しているpowertop(epelrepoでインストール可能)でどのステートで動作しているのかわかりますので確認してみると面白いと思います。

プロファイルはいくつか用意されていますので下記コマンドで確認し、いろいろ試してみるのはいかがでしょうか?

linux

 

lvmでもmdadmでもRAIDの構成が組めるのですが、

どちらがパフォーマンスが良いのだろうと。ふと疑問に思ったので計測してみました。

RAID0 iops latency スループット テスト方法 クローン数
mdadm 42181 2msec 2636MB/s randread 50
lvm 45298 2msec 2831MB/s randread 50
mdadm 25530 250usec 1595MB/s randread 4
lvm 25051 250usec 1565MB/s randread 4
mdadm 10232 4msec 654MB/s randwrite 50
lvm 9122 10msec 583MB/s randwrite 50
mdadm 10959 500usec 701MB/s randwrite 4
lvm 9648 500usec 617MB/s randwrite 4

結果、そんなに変わらないんじゃないかなと思います。

そもそもraid0はキャッシュ系でしか使わないですが、強いて言うなら

コンテンツ系はmdadm、db系はlvmになるかと思います。

参考までに下記にコマンドの結果を張り付けておきます。

■ベンチマーク取得方法

fio -filename=/data/testfile2 -direct=1 -rw=randread -bs=64k -size=2G -group_reporting -name=testfile1 -numjobs=50 -runtime=60 -output=fio.txt

■mdadm

testfile1: (g=0): rw=randread, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1

testfile1: (g=0): rw=randread, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1
fio-2.0.13
Starting 50 processes
testfile1: Laying out IO file(s) (1 file(s) / 2048MB)

testfile1: (groupid=0, jobs=50): err= 0: pid=14325: Fri Aug 23 15:24:31 2013
read : io=102400MB, bw=2636.4MB/s, iops=42181 , runt= 38842msec
clat (usec): min=110 , max=6460 , avg=1179.19, stdev=896.11
lat (usec): min=110 , max=6460 , avg=1179.36, stdev=896.11
clat percentiles (usec):
| 1.00th=[ 131], 5.00th=[ 161], 10.00th=[ 201], 20.00th=[ 306],
| 30.00th=[ 418], 40.00th=[ 684], 50.00th=[ 1144], 60.00th=[ 1336],
| 70.00th=[ 1576], 80.00th=[ 1896], 90.00th=[ 2416], 95.00th=[ 2864],
| 99.00th=[ 3760], 99.50th=[ 4080], 99.90th=[ 4704], 99.95th=[ 4960],
| 99.99th=[ 5408]
bw (KB/s) : min=42794, max=63105, per=2.00%, avg=54098.93, stdev=3469.18
lat (usec) : 250=14.84%, 500=20.11%, 750=6.31%, 1000=4.02%
lat (msec) : 2=37.42%, 4=16.69%, 10=0.61%
cpu : usr=0.37%, sys=2.16%, ctx=1638766, majf=0, minf=2244
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=1638400/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
READ: io=102400MB, aggrb=2636.4MB/s, minb=2636.4MB/s, maxb=2636.4MB/s, mint=38842msec, maxt=38842msec

Disk stats (read/write):
md0: ios=1635916/25, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=819200/5, aggrmerge=0/0, aggrticks=953296/7, aggrin_queue=125, aggrutil=0.64%
fioa: ios=819200/10, merge=0/0, ticks=881320/14, in_queue=250, util=0.64%
fiob: ios=819200/0, merge=0/0, ticks=1025273/0, in_queue=0, util=0.00%

IOPS:42181
スループット:2636MB
Latency:2msec

Latencyは2msec台が一番多かった。4msec台も多いのが気になります。

■lvm

testfile1: (g=0): rw=randread, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1

testfile1: (g=0): rw=randread, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1
fio-2.0.13
Starting 50 processes
testfile1: Laying out IO file(s) (1 file(s) / 2048MB)

testfile1: (groupid=0, jobs=50): err= 0: pid=4376: Fri Aug 23 15:48:50 2013
read : io=102400MB, bw=2831.2MB/s, iops=45298 , runt= 36169msec
clat (usec): min=116 , max=6101 , avg=1096.96, stdev=621.64
lat (usec): min=116 , max=6101 , avg=1097.14, stdev=621.64
clat percentiles (usec):
| 1.00th=[ 189], 5.00th=[ 326], 10.00th=[ 390], 20.00th=[ 516],
| 30.00th=[ 684], 40.00th=[ 868], 50.00th=[ 1032], 60.00th=[ 1176],
| 70.00th=[ 1336], 80.00th=[ 1560], 90.00th=[ 1912], 95.00th=[ 2256],
| 99.00th=[ 3024], 99.50th=[ 3280], 99.90th=[ 3920], 99.95th=[ 4128],
| 99.99th=[ 4704]
bw (KB/s) : min=51712, max=62848, per=2.00%, avg=58073.36, stdev=1572.02
lat (usec) : 250=2.33%, 500=16.55%, 750=14.87%, 1000=14.36%
lat (msec) : 2=43.43%, 4=8.39%, 10=0.08%
cpu : usr=0.40%, sys=2.75%, ctx=1639226, majf=0, minf=2243
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=1638400/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
READ: io=102400MB, aggrb=2831.2MB/s, minb=2831.2MB/s, maxb=2831.2MB/s, mint=36169msec, maxt=36169msec

Disk stats (read/write):
dm-1: ios=1635806/3, merge=0/0, ticks=1770044/0, in_queue=1780343, util=100.00%, aggrios=819200/1, aggrmerge=0/0, aggrticks=881151/0, aggrin_queue=0, aggrutil=0.00%
fioa: ios=819200/0, merge=0/0, ticks=870557/0, in_queue=0, util=0.00%
fiob: ios=819200/2, merge=0/0, ticks=891746/0, in_queue=0, util=0.00%

IOPS:45298
スループット:2831MB
Latency:2msec

Latencyは2msec台が一番多い。また2msecよりも低遅延のものが大半。

ここまで見るとlvmが優勢ですね。

 

次にベンチマークの多重度を変更してみました。

■取得コマンド numjogs 50 → 4

fio -filename=/data/testfile2 -direct=1 -rw=randread -bs=64k -size=2G -group_reporting -name=testfile1 -numjobs=4 -runtime=60 -output=/root/fio.txt

■mdadm

testfile1: (g=0): rw=randread, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1

testfile1: (g=0): rw=randread, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1
fio-2.0.13
Starting 4 processes

testfile1: (groupid=0, jobs=4): err= 0: pid=14405: Fri Aug 23 15:36:32 2013
read : io=8192.0MB, bw=1595.7MB/s, iops=25530 , runt= 5134msec
clat (usec): min=110 , max=351 , avg=153.77, stdev=28.96
lat (usec): min=110 , max=351 , avg=153.91, stdev=28.96
clat percentiles (usec):
| 1.00th=[ 114], 5.00th=[ 116], 10.00th=[ 120], 20.00th=[ 131],
| 30.00th=[ 135], 40.00th=[ 141], 50.00th=[ 149], 60.00th=[ 155],
| 70.00th=[ 167], 80.00th=[ 175], 90.00th=[ 195], 95.00th=[ 211],
| 99.00th=[ 239], 99.50th=[ 251], 99.90th=[ 274], 99.95th=[ 282],
| 99.99th=[ 302]
bw (KB/s) : min=402560, max=415872, per=25.05%, avg=409225.60, stdev=2367.20
lat (usec) : 250=99.39%, 500=0.61%
cpu : usr=1.98%, sys=14.91%, ctx=132775, majf=0, minf=174
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=131072/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
READ: io=8192.0MB, aggrb=1595.7MB/s, minb=1595.7MB/s, maxb=1595.7MB/s, mint=5134msec, maxt=5134msec

Disk stats (read/write):
md0: ios=125197/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=65536/0, aggrmerge=0/0, aggrticks=9628/0, aggrin_queue=0, aggrutil=0.00%
fioa: ios=65536/0, merge=0/0, ticks=9674/0, in_queue=0, util=0.00%
fiob: ios=65536/0, merge=0/0, ticks=9582/0, in_queue=0, util=0.00%

IOPS:25530
スループット:1595MB
Latency:250usec

Latencyは250usecがほとんどを占めていました。

 

■lvm

testfile1: (g=0): rw=randread, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1

testfile1: (g=0): rw=randread, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1
fio-2.0.13
Starting 4 processes

testfile1: (groupid=0, jobs=4): err= 0: pid=4433: Fri Aug 23 15:50:35 2013
read : io=8192.0MB, bw=1565.8MB/s, iops=25051 , runt= 5232msec
clat (usec): min=113 , max=339 , avg=155.87, stdev=26.96
lat (usec): min=113 , max=339 , avg=156.01, stdev=26.96
clat percentiles (usec):
| 1.00th=[ 118], 5.00th=[ 121], 10.00th=[ 124], 20.00th=[ 135],
| 30.00th=[ 139], 40.00th=[ 145], 50.00th=[ 151], 60.00th=[ 157],
| 70.00th=[ 167], 80.00th=[ 175], 90.00th=[ 195], 95.00th=[ 209],
| 99.00th=[ 237], 99.50th=[ 249], 99.90th=[ 274], 99.95th=[ 282],
| 99.99th=[ 294]
bw (KB/s) : min=399104, max=405888, per=25.11%, avg=402524.80, stdev=1703.54
lat (usec) : 250=99.55%, 500=0.45%
cpu : usr=2.08%, sys=17.39%, ctx=132013, majf=0, minf=174
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=131072/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
READ: io=8192.0MB, aggrb=1565.8MB/s, minb=1565.8MB/s, maxb=1565.8MB/s, mint=5232msec, maxt=5232msec

Disk stats (read/write):
dm-1: ios=129397/0, merge=0/0, ticks=18952/0, in_queue=19044, util=98.40%, aggrios=65536/0, aggrmerge=0/0, aggrticks=9431/0, aggrin_queue=0, aggrutil=0.00%
fioa: ios=65536/0, merge=0/0, ticks=9366/0, in_queue=0, util=0.00%
fiob: ios=65536/0, merge=0/0, ticks=9497/0, in_queue=0, util=0.00%

IOPS:25051
スループット:1565MB
Latency:250usec

Latencyは250usecがほとんど占めていました。

多重化が少なければ誤差の範囲に収まるという結果でした。

ということは多重化すればするほどlvmのほうが高速だと言えますね。

ここまではrandom readでしたが、writeのほうも見てみます。

■取得コマンド

fio -filename=/data/testfile2 -direct=1 -rw=randwrite -bs=64k -size=2G -group_reporting -name=testfile1 -numjobs=50 -runtime=60 -output=/root/fio.txt

■mdadm

testfile1: (g=0): rw=randwrite, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1

testfile1: (g=0): rw=randwrite, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1
fio-2.0.13
Starting 50 processes

testfile1: (groupid=0, jobs=50): err= 0: pid=14620: Fri Aug 23 16:01:02 2013
write: io=38376MB, bw=654882KB/s, iops=10232 , runt= 60006msec
clat (usec): min=72 , max=7589 , avg=2582.32, stdev=1876.14
lat (usec): min=75 , max=7592 , avg=2585.75, stdev=1876.39
clat percentiles (usec):
| 1.00th=[ 80], 5.00th=[ 86], 10.00th=[ 89], 20.00th=[ 94],
| 30.00th=[ 101], 40.00th=[ 3280], 50.00th=[ 3568], 60.00th=[ 3760],
| 70.00th=[ 3952], 80.00th=[ 4128], 90.00th=[ 4384], 95.00th=[ 4640],
| 99.00th=[ 5152], 99.50th=[ 5344], 99.90th=[ 5792], 99.95th=[ 5984],
| 99.99th=[ 6688]
bw (KB/s) : min= 7296, max=50258, per=2.00%, avg=13111.66, stdev=4689.74
lat (usec) : 100=27.91%, 250=7.33%, 500=0.01%, 750=0.01%, 1000=0.01%
lat (msec) : 2=0.01%, 4=37.43%, 10=27.32%
cpu : usr=0.17%, sys=1.15%, ctx=1597780, majf=0, minf=1485
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=0/w=614013/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
WRITE: io=38376MB, aggrb=654881KB/s, minb=654881KB/s, maxb=654881KB/s, mint=60006msec, maxt=60006msec

Disk stats (read/write):
md0: ios=0/613139, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/307018, aggrmerge=0/0, aggrticks=0/25550, aggrin_queue=23766, aggrutil=41.21%
fioa: ios=0/343825, merge=0/0, ticks=0/29627, in_queue=24768, util=41.21%
fiob: ios=0/270212, merge=0/0, ticks=0/21474, in_queue=22764, util=37.88%

IOPS:10232
スループット:654881KB/s
Latency:4msec

Latencyは4msecと10msecで6割以上を占めていました。

■lvm

testfile1: (g=0): rw=randwrite, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1

testfile1: (g=0): rw=randwrite, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1
fio-2.0.13
Starting 50 processes

testfile1: (groupid=0, jobs=50): err= 0: pid=4624: Fri Aug 23 16:01:13 2013
write: io=34215MB, bw=583866KB/s, iops=9122 , runt= 60007msec
clat (usec): min=83 , max=12681 , avg=2881.24, stdev=2356.27
lat (usec): min=86 , max=12684 , avg=2884.69, stdev=2356.38
clat percentiles (usec):
| 1.00th=[ 95], 5.00th=[ 97], 10.00th=[ 100], 20.00th=[ 105],
| 30.00th=[ 109], 40.00th=[ 3344], 50.00th=[ 3952], 60.00th=[ 4256],
| 70.00th=[ 4512], 80.00th=[ 4768], 90.00th=[ 5280], 95.00th=[ 5984],
| 99.00th=[ 8032], 99.50th=[ 8640], 99.90th=[ 9920], 99.95th=[10304],
| 99.99th=[11200]
bw (KB/s) : min= 3713, max=48442, per=2.00%, avg=11688.53, stdev=4390.29
lat (usec) : 100=9.95%, 250=29.24%, 500=0.01%, 750=0.01%
lat (msec) : 2=0.01%, 4=12.65%, 10=48.07%, 20=0.08%
cpu : usr=0.15%, sys=1.22%, ctx=1406268, majf=0, minf=1488
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=0/w=547438/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
WRITE: io=34215MB, aggrb=583865KB/s, minb=583865KB/s, maxb=583865KB/s, mint=60007msec, maxt=60007msec

Disk stats (read/write):
dm-1: ios=0/546670, merge=0/0, ticks=0/49396, in_queue=49399, util=82.34%, aggrios=0/273732, aggrmerge=0/0, aggrticks=0/24316, aggrin_queue=23512, aggrutil=39.82%
fioa: ios=0/278364, merge=0/0, ticks=0/24718, in_queue=23096, util=38.43%
fiob: ios=0/269100, merge=0/0, ticks=0/23914, in_queue=23929, util=39.82%

IOPS:9122
スループット:583865KB/s
Latency:10msec

Latencyは10msecが5割を占めていました。

多重書き込みについてはmdadmのほうがよさそうです。何度やってもこのくらいの差が出てました。

次に多重度を下げてみます。

■取得コマンド numjobs 50 → 4

fio -filename=/data/testfile2 -direct=1 -rw=randwrite -bs=64k -size=2G -group_reporting -name=testfile1 -numjobs=4 -runtime=60 -output=/root/fio.txt

■mdadm

testfile1: (g=0): rw=randwrite, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1

testfile1: (g=0): rw=randwrite, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1
fio-2.0.13
Starting 4 processes

testfile1: (groupid=0, jobs=4): err= 0: pid=14821: Fri Aug 23 16:36:24 2013
write: io=8192.0MB, bw=701389KB/s, iops=10959 , runt= 11960msec
clat (usec): min=70 , max=1605 , avg=221.76, stdev=96.44
lat (usec): min=73 , max=1611 , avg=224.58, stdev=96.46
clat percentiles (usec):
| 1.00th=[ 75], 5.00th=[ 78], 10.00th=[ 82], 20.00th=[ 96],
| 30.00th=[ 173], 40.00th=[ 183], 50.00th=[ 262], 60.00th=[ 270],
| 70.00th=[ 278], 80.00th=[ 290], 90.00th=[ 358], 95.00th=[ 362],
| 99.00th=[ 374], 99.50th=[ 378], 99.90th=[ 394], 99.95th=[ 418],
| 99.99th=[ 532]
bw (KB/s) : min=140800, max=258432, per=25.89%, avg=181560.09, stdev=37150.24
lat (usec) : 100=23.27%, 250=22.55%, 500=54.16%, 750=0.01%
lat (msec) : 2=0.01%
cpu : usr=1.83%, sys=13.26%, ctx=330432, majf=0, minf=106
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=0/w=131072/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
WRITE: io=8192.0MB, aggrb=701388KB/s, minb=701388KB/s, maxb=701388KB/s, mint=11960msec, maxt=11960msec

Disk stats (read/write):
md0: ios=0/130468, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/65538, aggrmerge=0/0, aggrticks=0/5214, aggrin_queue=4498, aggrutil=41.46%
fioa: ios=0/65540, merge=0/0, ticks=0/5350, in_queue=5001, util=41.46%
fiob: ios=0/65536, merge=0/0, ticks=0/5079, in_queue=3995, util=33.12%

IOPS:10959
スループット:701388KB/s
Latency:500usec

Latencyは500usecが5割以上を占めていました。

■lvm

testfile1: (g=0): rw=randwrite, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1

testfile1: (g=0): rw=randwrite, bs=64K-64K/64K-64K/64K-64K, ioengine=sync, iodepth=1
fio-2.0.13
Starting 4 processes

testfile1: (groupid=0, jobs=4): err= 0: pid=4874: Fri Aug 23 16:36:31 2013
write: io=8192.0MB, bw=617536KB/s, iops=9648 , runt= 13584msec
clat (usec): min=89 , max=2131 , avg=252.59, stdev=108.42
lat (usec): min=91 , max=2134 , avg=255.35, stdev=108.44
clat percentiles (usec):
| 1.00th=[ 92], 5.00th=[ 95], 10.00th=[ 98], 20.00th=[ 105],
| 30.00th=[ 199], 40.00th=[ 207], 50.00th=[ 298], 60.00th=[ 306],
| 70.00th=[ 310], 80.00th=[ 322], 90.00th=[ 406], 95.00th=[ 414],
| 99.00th=[ 422], 99.50th=[ 426], 99.90th=[ 442], 99.95th=[ 478],
| 99.99th=[ 900]
bw (KB/s) : min=126592, max=571648, per=26.14%, avg=161424.48, stdev=46945.30
lat (usec) : 100=11.53%, 250=33.37%, 500=55.06%, 750=0.03%, 1000=0.01%
lat (msec) : 2=0.01%, 4=0.01%
cpu : usr=1.60%, sys=14.06%, ctx=329594, majf=0, minf=106
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=0/w=131072/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
WRITE: io=8192.0MB, aggrb=617535KB/s, minb=617535KB/s, maxb=617535KB/s, mint=13584msec, maxt=13584msec

Disk stats (read/write):
dm-1: ios=0/129255, merge=0/0, ticks=0/10583, in_queue=10586, util=78.46%, aggrios=0/65538, aggrmerge=0/0, aggrticks=0/5246, aggrin_queue=5625, aggrutil=41.97%
fioa: ios=0/65536, merge=0/0, ticks=0/5259, in_queue=5504, util=40.20%
fiob: ios=0/65540, merge=0/0, ticks=0/5233, in_queue=5746, util=41.97%

IOPS:9648
スループット:617535KB/s
Latency:500usec

Latencyは500usecが5割以上を占めていました。

多重度を変えてもあまり変化は見られませんでした。

書き込みに関してはmdadmが若干良いように思います。

linux

ツチノコの子分です
親分同様オールドタイプですが頑張ります

RedHat系のRunレベルが0~6+Sがあることはご存知と思いますが、
皆さんはどのRunレベルを使ったことがありますか?

2,4を除いた6つのRunレベルを使用されている方が多いと思います。

実は私が入社最初に関わったプロジェクトでは、Runレベルの2,4を通常運用で使用していました。

どのように使用していたかというと、各Runレベルに以下のスクリプトを作成していました。
 Runレベル2 :プロジェクトで作成したアプリケーションなどの起動スクリプトとプロセス起動確認スクリプトを作成
 Runレベル4 :Runレベル2で起動したアプリケーションの停止スクリプトなどとプロセス停止確認スクリプトを作成

サーバを起動(Runレベル3)後、サービスを起動する際にいちいちプロセスの起動スクリプトを起動せず、Runレベル2へスイッチすることでサービスを開始していました。
停止する場合はRunレベルを4に切り替えることですべてのプロセスを一発で停止していました。

今考えると、各Runレベルの起動手順や、Runレベル2・4が普段使用されていないことなどのLinuxの仕様をよく理解した上で運用オペレーションを簡略化させていた巧妙な使用方法だと改めて感心しました。

ちなみに皆さんはRunレベル1とSの違いをご存知ですか
ためしにRunレベルを1に切り替えた後”runlever”コマンドでRunレベルの遷移を確かめてみては

glusterfs, linux

DMMで利用されているGlusterfs

ちょっとした工夫で耐障害性を向上させています。

通常は下記のようにサーバがfuseによってglusterのボリュームをマウントします。

※nfsでもcifsでもマウントできますがfuseが推奨されているようです。残念ながらWindows版のfuseクライアントは開発途中です。

この場合Glusterpeerで冗長性が取られていたとしてもサーバがマウントしているGlusterサーバが落ちるとサーバ側にも障害が発生してしまいます。しかも裏側が死んでいるのにもかかわらずフロント側のアプリケーションがサービスを受け続ける状態となってしまうのでやっかいな状態となる。

これを回避するために書き込みができるかどうかの監視を行い障害箇所を切り離すようするのですが、リアルタイムではないので問題は完全に解決しません。

fuse_mount

そこで我々がとったアプローチは下記の構成です。

サーバもglusterpeerに参加させ、そのpeer上でGlusterボリュームをマウントする。

こうする事でGlusterサーバのA,B,Cのどれが落ちても冗長性が保てるようになります。

Glusterpeer_mount

 

サーバはpeerに参加はするのですがbrickは一つも提供しません。

また、別のアプローチとしてglusterサーバ上にアプリケーションを乗っけてそのまま運用している場合もあります。

用途に合わせた使い分けを行うのが重要です。

みなさんはどのようにお使いですか?ぜひ教えてください。

linux

bondingについてはここで説明するよりも過去の先人たちの記事のほうが参考になるかと思いますので割愛します。

bondingを利用するということはsofをなくすための構成をとるということになりますが、そのためには

動作が把握しやすいactive-backupモード(mode=1)を利用し、
同一L2スイッチ内で接続が完結する場合は「miiリンク監視」
その他は「arp監視」を選択するのが冗長性を担保するために良い選択となると思います。

が、

dmmでは基本的には設定が簡単で運用が楽なmiiリンク監視をどの場面でも利用しています。

miiを冗長構成できちんと構成するためにはspanningtreeなどの駆使する必要があるのですが、dmmではspanningtreeは原則使っていないので、
ポート障害を防ぐためのスイッチ間リンクの二重化で耐障害性を高めるなどの措置をとっています。

なるべく状況が把握しやすく確実にコントロールが可能なコントローラブル設計が基本となります。

どうしても落としたくないサービスは別の構成を考えますが、
現在はそんな場合でもスイッチドファブリック技術(vcs fabricpath,qfabric,vena)を投入し冗長性を保ちます。

意識せずともmiiリンク監視が標準となる日が近くなっています。

arp監視:無駄なパケットがブロードキャストドメイン内に流れます。mii監視より切り替わりに時間がかかる。arpの監視先のメンテナンス性が損なわれる。監視先で障害が発生すると全面的に断となる。監視先を設定しなくてはいけない。

mii監視:リンクのアップダウンだけで切り替えができるので切り替えが早い。hsrp、vrrp、nsrpなどのL3レベルの切り替えがわからない。gsrpなどのl2レベルでの切り替えもわからない。自身以外のリンクの状態がわからない。接続するスイッチでスパニングツリーもしくはファブリック技術やopenflowなどのSDNソフトウェアによる制御が冗長の条件となる。

PAGE TOP