雑感

 

ウェブアプリケーションにおけるMaxClientsとは

快適な動作が保証できる最大値を指定するものと認識しています。

かつては

これを増やせば受け入れる人数が増えるのでパフォーマンスが上がるものなんだという幻想を抱いていた時もありました。^^;

さて、「MaxClients」の値

みなさんの会社では誰がどのように決めているのでしょうか?

dmmではインフラチームが今までの経験(平均的なアプリケーションとサーバスペック)からこのくらいだろうという数字を設定しています。

ただ、最近この値の設定が怪しくなってきました。

増え続ける開発者、短サイクルなデリバリー等により

アプリケーションのパフォーマンスにばらつきがでるようになります。

そのばらつきを考慮できず値をインフラチームが設定することで、

MaxClientsまでの接続を待たずしてサーバの負荷が高くなり、

特定のアプリケーションによる遅延で全体のパフォーマンス遅延へと発展するというケースが見られるようになってきています。

また、こういった例ではいつだって後手後手の対応となってしまいます。

 

これを踏まえて「誰のものか?」という問いかけに戻ります。

ウェブアプリケーション開発者側でデリバリーされるすべてのアプリに対して

保証できる数字を提示してもらえれば、

正確に「快適な動作を保証できる値」を設定が可能であろう思っています。

これにより先手(アプリチューニング、スケールアップ/アウト)での対応が可能となり品質の均一化も同時に解決できるのではないかと。

ですので、私個人としては「ウェブアプリケーション開発者」のものなのかなあと。

あとはフェールセーフな機構として、

すべての処理を見える化し処理に2秒以上かかるものは強制的に排除できるような仕組みを実装

これにより問題の伝搬を防ぐ対応ができれば完璧じゃないかなと。

みなさんは、どのようなお考えをお持ちですかね?

仮想化

 

dmmではmemcachedを

xenserver

kvm

といったハイパーバイザーを利用して展開しています。

最近わかってきたこととして、ある一定のパフォーマンスが必要となってくると

XenServerの仮想環境ではmemcachedのパフォーマンスが安定しないということが分かってきました。

下記のグラフはXenServerからkvm環境へ移行したmemcachedのレスポンスタイムのグラフです。

memcache_xenserver_to_kvm

 

23日以前でグラフが安定しない箇所がXenServer環境で、
グラフが安定しているところがkvm環境です。

3kくらいのコネクション数を超えてくると急激に悪化していきます。

kvmではコネクション数が上がってきても常に一定で安定しています。

ただ、低下するといってもmsec単位の変化ですので問題がでていない環境のほうが多いのかもしれませんが。

もともと、XenServerはネットワーク回りに不安を抱えており、dmmでもちょくちょくXenServerのネットワークが定期的にフリーズしています。

dmmでは

「XenServerのいつものやつで障害です」

で通じます。^^;

その都度、ネットワークインターフェースのdeactivate→activateで復旧させなければいけません。

tsoをoffにすることで改善するとの情報を得て対応させてはいるのですが、dmmの環境ではoffでもフリーズします

また、今まではXenServerは無償版でも有償のサポートサービスを契約できたのですが、最近になって無償版での有償サポートは提供しなくなったとのことです。サポートが必要であれば商用版を購入してそちらへ移行してから問い合わせてくださいと。

もともと、XenServerはバージョン依存も多くあってか、サポートを受けるにしてもバージョンを合わせないと調査もしてくれなかったという経緯もあったりして使いにくいなあとは思っていたのですがXenCenterは非常に使いやすいと思っていますので今後の改善に期待しています。

 

 

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が若干良いように思います。

akb48サービス

みなさま、東京ドームお疲れ様でした。

ツチノコの親分も

本日の秋元才加、卒業公演参加させていただきました。
※運よく3塁側の結構前のほうが取れたのです。去年の東京ドームは3塁ではなく3階席でしかも最上段でした。遠かったなあ^^;

さやかコール。感動しました。

「さやか!」「さやか!」「さやか!」「さやか!」「さやか!」「そいやっさ!」「そいやっさ!」

と、お祭りなモードになってしまいました。^^;

ユニットシャッフルやサプライズがなかったノーサプライズ公演でしたが、

カッコいい曲連発の才加の卒業らしい公演になったと思います。

草原の奇跡で振られたドームいっぱいの緑のサイリウム

優子が緑の草原と表現していましたが、まさにぴったりの表現でしたね。

東京のど真ん中に草原が出現。
猛暑の中にあっても今日の東京ドームだけは涼しくなった気がしました。

さて、

残念ながらツチノコの親分は東京ドームはこの1本の公演だけです。

ですが、

東京ドーム公演は明日からまだ3日間も続きます。参加される方は思いっきり楽しんできてくださいね。

私は、来週はdmmの卒業公演に切り替えだ。

 

 

 

 

 

hardware

同じスペックのサーバなのに、パフォーマンスに差がでることがありませんか?

D社のサーバは早いのにH社のサーバは少し遅いといったことがありました。

よくよく調べてみるとipmiもしくはbiosで設定する電力プロファイルの設定によるものでした。

電力プロファイルにはいくつかモードが存在するのですが、

CPUの利用率に基づいて適切な電力レベルに設定するモード「ダイナミックパワーセービング」

最高の電力状態を維持する「スタティックハイパフォーマンス」

上記の二つのモードの違いによって引き起こされている問題でした。

まずはそれぞれの通常時の電力使用量をご覧ください。

電力プロファイル「ダイナミックパワーセービング」
平均:180w

電力プロファイル「スタティックハイパフォーマンス」
平均:240w

まず、モードの違いで60wほど電力使用量に違いがあります。

その時のロードアベレージについて、

電力プロファイル「ダイナミックパワーセービング」
※メンテ中に電力プロファイル変更なし

電力プロファイル「スタティックハイパフォーマンス」
※メンテ中に電力プロファイル変更あり

 

※下がっている時間帯はメンテナンス中です。

ロードアベレージの値がプロファイルの変更によって半分以下になりました。

続いてhttpのレスポンスタイムの違いをご覧ください。

電力プロファイル「ダイナミックパワーセービング」

電力プロファイル「スタティックハイパフォーマンス」

レスポンスタイムにも影響しているということがわかると思います。

これで何が言いたいかといいますと、

レスポンスやロードアベレージに違いはあるのですが、

低負荷時のパフォーマンスの差はあまりに軽微なため気にしなくてよさそうということです。

高負荷時に差が出てしまうという事であれば別ですが。

シビアな環境や電力を固定で仕入れているという方は標準でスタティックハイパフォーマンスを選択しておいても悪くはないと思います。

セービングモードは従量課金で電力を仕入れている方には良い選択ではないでしょうか。

電力プロファイルのお話でした。

PAGE TOP