元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2013/04/18

by AndiH

Amazon EBS の性能ベンチマーク その3 (Provisioned IOPS編)


さて、またまた昨日のエントリ「Amazon EBS の性能ベンチマーク その2 (Standard-Vol増量編)」の続きです。

ここまでの経緯は以下。


ここまでのベンチマークでは、StandardタイプのEBSボリュームを使っていたのですが、ここからは、必要とするIOPSを設定することが可能な"Provisioned IOPS"なEBSボリューム(プロビジョンドIOPSボリューム)を使って性能を計測してみたいと思います。

# 個人で Provisioned IOPS ボリュームを使って高負荷テストとかクラウド破産まっしぐら。


ベンチマークの条件の詳細等は、上記のこれまでのエントリからご確認くださいませ。


今回ベンチマークの対象とする「Provisioned IOPS for EBS」の詳細については下記リンク先をご覧ください。




7. 200GBの Provisioned IOPS ボリュームを使ったベンチマーク

ところで、Provisioned IOPSボリュームは、何も制限解除していないと(通常利用)、1アカウントあたり10000IOPSまでしか使えないんですね。現在(2013/4)、1EBSボリュームあたり2000IOPSが上限になっているので、2000IOPSに設定したボリュームだと5つまでしか作れない。

本当はこれまでのエントリ同様、ボリュームを16本作りたかったんですが、解除申請も面倒くさかったので、一旦4本まででやってみることにしました。(これは後日追試かな。)


というわけで、おさらい的にベンチマークを取得した環境は以下です。

  • 東京リージョン(ap-northeast)で実施。
  • c1.xlarge (High-CPU Extra Large Instance) のインスタンスを利用。
  • 200GBProvisioned IOPS EBSボリューム1〜4個(2000IOPS)利用。
  • Amazon Linux AMI (2013.3)
  • ファイルシステムは"xfs"
  • ベンチマークプログラムは"fio"
    • 扱うファイルサイズは5GBです。(パラメータ詳細は昨日のエントリをご参照ください。)

さて、それでは、これまでと同じような感じでベンチマークを行った結果が以下です。まずはIOPS(4k)から。

ebs * 1ebs * 2ebs * 4
sequential read354537714347
sequential write346136964203
randam read206441148150
randam write205641128157

f:id:rx7:20130418013716p:image:w480


続いて、Bandwidth。単位はMB/sec。

ebs * 1ebs * 2ebs * 4
read41.8683.72113.238
write41.72983.508114.232

f:id:rx7:20130418013717p:image:w480


これは特に考察する必要が無いくらい美しいグラフを描いていますw

ランダムアクセスに関しては読み込み/書き込みともに、1本あたり約2000IOPSな結果ですね。公称値通りです。2本束ねたらIOPSが2倍。4本束ねたらIOPSは4倍となっています。シーケンシャルアクセスについては、1〜4本でそれほど大きな変化はないですね。(3500〜4300IOPS)

しかし、StandardなEBSボリュームと比較すると、ピークのパフォーマンスの数字そのものは落ちていて、全体的に綺麗にキャップされてるなぁ、という印象です。


8. Provisioned IOPS ボリューム200GBで、fioで扱うサイズを50GBに変更

では、これまでのパターン通り、fioで扱うファイルサイズを50GBまで上げてみます。

これまで同様、fioのruntimeオプションを"64"(sec)に変更して実行し、対象となるEBSボリュームの本数は4本(いずれもRAID0)のみとしました。

前回のエントリの6.の結果と並列に結果を書いてみます。その結果が以下です。IOPS(4k)。

今回のProvisioned IOPS ボリュームのベンチマーク結果は、一番右端の"ebs 200GB (provisioned)"列となります。


ebs 20GBebs 200GBebs 200GB
(provisioned)
randam read162013448191
randam write5135778094

f:id:rx7:20130418013718p:image:w480


Standardボリュームでは、一度に扱うファイルサイズが大きくなるにつれて、ランダムアクセスのIOPSが落ち込んでいっていましたが、Provisioned IOPSボリュームでは、見事に公称値(2000IOPS * 4ボリュームでRAID0)のパフォーマンスを保ったままでした。違いは、そういうことなんですね。


まとめ

  • 一度に扱うファイルサイズが大きくなった場合においても、Provisioned IOPSボリュームは設定したIOPS通りのパフォーマンスを出してくれる。
  • 一度に扱うファイルサイズが小さい場合は、Standardボリュームの方がパフォーマンスは良い。
  • Standardボリュームは、ベンチマークパターンの相性なのかタイミングなのかはわからないが、ランダムアクセス時にパフォーマンスが落ち込んでしまうことが、所々で見受けられた。それに比べ、Provisioned IOPSボリュームは終始一貫したパフォーマンスだった。
    • 簡単に言うと、「普段は速いけど、たまに遅くなるボリューム」 VS 「安定してそこそこ速いボリューム」的な?
  • Provisioned IOPSボリュームの方がお高くつくので、負荷試験利用でのクラウド破産までの道のりが(ry

次回予告

  • Provisioned IOPSボリューム16本でのベンチマーク。
  • ランダムアクセスで性能が落ち込むケースにおいての詳細調査。

それでは次回もお楽しみに! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


あわせて読みたい



まとめ


2013/04/17

by Jemimus

Amazon EBS の性能ベンチマーク その2 (Standard-Vol増量編)


昨日エントリ「Amazon EBS の性能ベンチマーク その1 (Standard編)」の続きです。

昨日のエントリで、次はEBSボリュームのサイズを20GBではなく、もっと大きなものにしてみたら、どうなるのだろう?と疑問となった部分があるので、そこのベンチマーク結果となります。


ベンチマークの条件の詳細等は、以下の昨日のエントリからご確認くださいませ。


5. 200GBのEBSボリュームを使ったベンチマーク

おさらい的にベンチマークを取得した環境は以下です。

  • 東京リージョン(ap-northeast)で実施。
  • c1.xlarge (High-CPU Extra Large Instance) のインスタンスを利用。
  • 200GBStandard EBSボリューム1〜16個利用。
  • Amazon Linux AMI (2013.3)
  • ファイルシステムは"xfs"
  • ベンチマークプログラムは"fio"
    • 扱うファイルサイズは5GBです。(パラメータ詳細は昨日のエントリをご参照ください。)

さて、それでは、昨日のエントリと同じような感じでベンチマークを行った結果が以下です。まずはIOPS(4k)から。


ebs * 1ebs * 2ebs * 4ebs * 8ebs * 16
sequential read1477419310210922509426320
sequential write492658136887903913796
randam read1607422964303213037130276
randam write9331106232152343123582

f:id:rx7:20130417024019p:image:w480


続いて、Bandwidth。単位はMB/sec。

ebs * 1ebs * 2ebs * 4ebs * 8ebs * 16
read113.737145.059144.386146.711145.317
write32.52795.964120.228122.126122.262

f:id:rx7:20130417024020p:image:w480


計測したタイミングでは、EBSボリュームが1本のときと2本のときのランダムライトの落ち込みが大きかったです。昨日のエントリでも、ランダムアクセスが落ちていたケースがあったので、もうちょっと踏み込んで後日追試予定です。

その他については、EBSボリュームが20GBのケースとそれほど差の無い結果となりました(下部にEBSボリューム20GBでの測定結果を掲載)。EBSボリュームの大小に関しては、性能に影響を及ぼさないようです。


参考: EBSボリューム(20GB)の同一ベンチマーク結果(IOPS)

f:id:rx7:20130416211204p:image:480]


6. EBSボリューム200GBで、fioで扱うサイズを50GBに変更

それでは、ベンチマークで扱うファイルサイズを10倍の50GBまで増やしてみます。

EBSボリュームの容量を増やすことで、利用できるキャッシュ(?)の容量との相関を調べてみます。

昨日同様、fioのruntimeオプションを"64"(sec)に変更して実行し、対象となるEBSボリュームの本数は、4, 8, 16本(いずれもRAID0)としました。


その結果が以下です。IOPS(4k)。

ebs * 4ebs * 8ebs * 16
randam read1344332210493
randam write57718294357

f:id:rx7:20130417024021p:image:w480


これだけでは、比較結果わかりづらいと思いますので、昨日のエントリの4.のベンチマーク結果(同一条件でEBSボリューム20GBのもの)とあわせて表とグラフにしてみます。


ebs * 4ebs * 8ebs * 16
ebs-20GB, randam read162037746443
ebs-20GB, randam write5137362367
ebs-200GB, randam read1344332210493
ebs-200GB, randam write57718294357

f:id:rx7:20130417204139p:image:w480


ここからは、EBSボリュームの容量が大きい方(特に16本でRAID0を組んだケース)が優れた性能が出ているため、やはり扱うファイルサイズが大きい場合は、EBSボリュームの容量および束ねる本数を多くするほうが、より高いランダムアクセス性能を引き出せそうです。


まとめ

  • スタンダードタイプのEBSボリュームは、ランダムアクセス(特に書き込み)については、たまに(相性なのかタイミングなのかは不明。後日追試予定。)性能が落ちて不安定なケースがある。
  • EBSボリュームは、キャッシュ機構っぽい仕組みがあり、ランダムアクセスについては、そのキャッシュをできるだけ利用したほうが高性能となるっぽい。
  • キャッシュっぽいところに乗ってしまうと、ランダムアクセス(4k)は、「Read: 約30000, Write: 約23000」あたりまで性能が出る。
  • スループットのMAX値は、「Read: 145MB/sec, Write: 120MB/sec」。
  • 利用できるキャッシュの容量は限られていて、一度に扱うファイルサイズに影響している。
  • EBSボリューム自体の容量と、束ねる本数を増やしていくことで、ある程度までのランダムアクセス性能の低下を防ぐことができそう。

次回予告

  • EBSのProvisioned IOPS(プロビジョンドIOPS)だと、どのような結果になるか確認する。
  • ランダムアクセスで性能が落ち込むケースにおいての詳細調査。

それでは次回もお楽しみに! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


追記

続編を書きました。


あわせて読みたい



まとめ


2013/04/16

by grover_net

Amazon EBS の性能ベンチマーク その1 (Standard編)


以前、「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた」でAmazon EC2で利用できるSSDボリュームのベンチマークを取った際に、EBSボリュームに関しても簡単に計測しているのですが、もう少し詳細に見てみようと思い、もうちょっと詳しく性能を計測してみました。(急いでいる方は最後のまとめを読むだけでOKですw)

実は、大昔(3〜4年くらい前)にも同じようなことを軽くやったのですが、結果がどこかにいってしまった&今はまた結果が違うかもなので、やってみた。


ベンチマークの目的は、EBSボリュームをソフトウェアRAIDで束ねた(ストライピング)場合に、どのくらいパフォーマンスが出せるのかという観点。

というわけで、色々な観点から性能を測ってみました。使ったツールは「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた - 元RX-7乗りの適当な日々」の時と同様にfioです。

(シリーズもののエントリとして、しばらく続きますw)


1. c1.mediumでベンチマーク

以下がベンチマークを取得した際の環境です。

  • 東京リージョン(ap-northeast)で実施。
  • c1.medium (High-CPU Medium Instance) のインスタンスを利用。
  • 20GBStandard EBSボリューム1〜16個利用。
  • Amazon Linux AMI (2013.3)

fioは以下のような感じでインストールしておきます。

# wget http://pkgs.repoforge.org/fio/fio-2.0.9-1.rf.src.rpm
# yum -y install rpm-build libaio-devel gcc make
# rpmbuild --rebuild fio-2.0.9-1.rf.src.rpm
# rpm -Uvh rpmbuild/RPMS/x86_64/fio-2.0.9-1.amzn1.x86_64.rpm

使ったファイルシステムは"xfs"で、以下のようなパラメータで作成/マウントしています。

# mkfs.xfs -f -b size=4096 -i size=512 [デバイス]
# mount -t xfs -o noatime,logbufs=8 [デバイス] /data

ちなみにI/Oスケジューラは、EBSボリュームはデフォルトで"noop"でした。


さて、実際にベンチマークを取ったのは、EBSボリューム単体のケース、2台をRAID0で組んだケース、同じく4台(RAID0)8台(RAID0)16台(RAID0)の5パターンです。

それぞれのボリュームに関して、以下のパラメータでfioを走らせました。

# fio -filename=/data/testfio -direct=1 -rw=read -bs=4k -size=5G -numjobs=64 -runtime=16 -group_reporting -name=file1
# fio -filename=/data/testfio -direct=1 -rw=write -bs=4k -size=5G -numjobs=64 -runtime=16 -group_reporting -name=file1
# fio -filename=/data/testfio -direct=1 -rw=randread -bs=4k -size=5G -numjobs=64 -runtime=16 -group_reporting -name=file1
# fio -filename=/data/testfio -direct=1 -rw=randwrite -bs=4k -size=5G -numjobs=64 -runtime=16 -group_reporting -name=file1

上から4つは、それぞれシーケンシャルリード/ライトとランダムリード/ライト、ブロックサイズは4kで設定しています。IOPSのチェックが主目的です。扱うファイルサイズは5GBです。


# fio -filename=/data/testfio -direct=1 -rw=read -bs=32m -size=5G -numjobs=8 -runtime=16 -group_reporting -name=file1
# fio -filename=/data/testfio -direct=1 -rw=write -bs=32m -size=5G -numjobs=8 -runtime=16 -group_reporting -name=file1

あとの2つは、ブロックサイズを大きくして、主にBandwidth(転送レート)をチェックしています。


では、ベンチマーク結果です。まずはIOPS(4k)から。


ebs * 1ebs * 2ebs * 4ebs * 8ebs * 16
sequential read1600019408182072069329066
sequential write542160616083847811380
randam read1369522821244902958231047
randam write6450123451736101935139

f:id:rx7:20130416211202p:image:w480


続いて、Bandwidth。単位はMB/sec。


ebs * 1ebs * 2ebs * 4ebs * 8ebs * 16
read94.935138.043144.395146.329145.51
write50.94192.38116.796121.771122.54

f:id:rx7:20130416211203p:image:w480


まず、数値が全体にただのディスクとは思えないレベルですね。FlashCacheのようなSSDを使ったキャッシュ機構の仕組みが介在していそうな感じです。一度に5GBくらいのファイルサイズの書き込みだと、結構キャッシュが効いてくるのでしょうか。

どの程度のパフォーマンスが欲しいのかによりますが、EBSボリューム2本のRAID0でもバランスの良いパフォーマンスが出そうな雰囲気です。


ただし、ランダムライトに関しては、グラフの通り、あまり安定したパフォーマンスは出ていないです。たまたまなのか、時間帯が関連しているのか、ベンチマークプログラムとの相性なのかは不明ですが、突拍子に良い結果になることもあれば、思うようにパフォーマンスが出ていない時もありましたが、ベースがハードディスクだとすると、こんなもんでしょうと思えるレベルはいずれも上回っていました。


2. c1.xlargeでベンチマーク

次にインスタンスタイプを変えて、ベンチマークをとってみました。条件は以下の通りです。

先ほどのc1.mediumでのベンチマークからの変更点は以下の通りです。


先ほど同様のfioコマンドを実行した結果が以下です。

IOPS(4k)から。


ebs * 1ebs * 2ebs * 4ebs * 8ebs * 16
sequential read1673017854198302831529210
sequential write537259396465791811894
randam read1431124287306133018030213
randam write595611769207132294023253

f:id:rx7:20130416211204p:image:w480


続いて、Bandwidth。単位はMB/sec。

ebs * 1ebs * 2ebs * 4ebs * 8ebs * 16
read104.978142.768144.378143.793144.915
write48.41694.625120.106121.975121.477

f:id:rx7:20130416211205p:image:w480


インスタンスタイプを大きくして、よりCPU core数の大きいもので、EBSの最適化利用で1000Mbpsのスループットが要求できるものにしてみましたが、結果は上記の通り、c1.mediumと大きな差はついていません。Bandwidthの部分についてもあまり結果が変わらなかったのは、"最適化利用:不可"のc1.mediumでもMbpsのスループットに換算すると、1000Mbps以上出ているため、この結果から「Read: 145MB/sec, Write: 120MB/sec」が通常のEBSボリュームのスループットの上限なのでしょう。

ランダムライトのパフォーマンスのバラつきはなく、安定したパフォーマンスを発揮している印象です。

上記の結果から、今回のベンチマークの条件だと、よほどのことがない限り、EBSボリュームを4本より大きい数で束ねることによるメリットはそんなになさそうです。


3. c1.xlargeでfioで扱うサイズを15GBに変更

ここまでのベンチマークで何か前段にキャッシュがいそうな雰囲気を出しているEBSボリュームですが、それならばと、fioで扱うファイルサイズを5GBから15GBで増やしてみました。

また、扱うファイルサイズを大きくしたので、fioのruntimeオプションを"32"(sec)に変更しました。

それ以外の条件は、先ほどの2.のベンチマークと同じです。


結果が以下です。IOPS(4k)から。


ebs * 1ebs * 2ebs * 4ebs * 8ebs * 16
sequential read2094222552233132636926673
sequential write498066167055898116939
randam read3751644109122664326002
randam write119430143611482034

f:id:rx7:20130416211206p:image:w480


続いて、Bandwidth。単位はMB/sec。

ebs * 1ebs * 2ebs * 4ebs * 8ebs * 16
read106.325122.6131.364131.727131.807
write46.16895.129118.033118.611119.533

f:id:rx7:20130416211207p:image:w480


今度は明らかに、EBSボリュームのデバイス本数が少ない場合において、ランダムアクセスの性能が落ちました。また、ランダムライトについては本数を増やしても大きく改善はしておらず、キャッシュから溢れる量が大きくなったのでしょうか。

EBSボリュームの本数を増やすことで、5GBのファイル対象のケースと同じような性能値に近づいていくのは、EBSボリュームの利用本数に比例する形で、使えるキャッシュの容量が増えるのかもしれません。

また、Bandwidthについては、Readで多少値は落ちていますが、大きく変化は見られないですね。(バックエンドとの1000Mbpsのスループットの制限でキャップされているみたいですね。)


では、EBSボリュームのサイズを増やせばどうなるのでしょうか?

というケースは、また次回のエントリとして、次はfioで扱うファイルサイズをさらに増やして確認してみます。


4. c1.xlargeでfioで扱うサイズを50GB, 100GBに変更

fioコマンドで扱うファイルサイズをさらに大きく(50GBに変更)して先ほどと同じベンチマークを行います。

(fioのruntimeオプションを"64"(sec)に変更して、実行しています。)


尚、さっきの15GB対象のベンチマークで、EBSボリューム2本のRAID0までは、ランダムアクセスで影響が出てIOPS値が落ちていたため、今回はEBSボリューム{4, 8, 16}本(RAID0)のランダムアクセス(IOPS)を対象としてみます。(あと、EBSボリュームを1本あたり20GBで作ったので、3本以上まとめないと50GBも書き込めない...w)


結果が以下です。IOPS(4k)。

ebs * 4ebs * 8ebs * 16
randam read162037746443
randam write5137362367

f:id:rx7:20130416211208p:image:w480


やはり、扱うファイルサイズが5GBや15GBのケースと比べて、IOPS値が落ちてきました。やはりキャッシュから溢れる量が多くなると、ハードディスクっぽいパフォーマンスに近づいていきますね。

ただ、やはり扱うファイルサイズが大きくなれば大きくなるほど、EBSボリュームをRAIDで束ねる数は多ければ多いほど、良いパフォーマンスが出る結果となっています。


おまけ

最後に、fioで扱うファイルサイズを100GBまで増やしてみて、EBSボリューム16本のRAID0で実行してみました。fioコマンドのruntimeオプションを"128"(sec)に変更して実行してみます。

IOPS(4k)の結果が以下。

ebs * 16
randam read2439
randam write1056

想定通りですが、扱うサイズが少量のものと比べて、パフォーマンスがどんどんハードディスクに近い値に近づいていきます。


まとめ

  • 一度扱うファイルサイズが小さいときは、SSDっぽいキャッシュ(?)のおかげで、ただのディスクとは思えないようなパフォーマンスを出してくれる。(IOPS)
    • EBSボリューム単体での利用が最もコストパフォーマンスに優れている。
    • RAID0で2本束ねるとランダムアクセスのパフォーマンスは良い。束ねてもコスパ的にも4本までかな。
    • たまたまかもしれないが、c1.mediumのインスタンスではランダムライトが安定しなかった。(IOPS)
  • 一度に扱うファイルサイズが増えてくると、ハードディスクっぽいパフォーマンスまで落ちてくる。
    • 扱うファイルサイズの増加に対しては、EBSボリュームを束ねる本数を増やすことが効果的。
  • Bandwidthについては、インスタンスタイプを変えても、影響はそれほどなさそう。
    • 束ねる数(RAID0)についても、Readなら2本、Writeでも4本で、ほぼMax値に到達する。
  • EBSボリュームは、I/Oリクエスト数でも課金されるので、ベンチマークで負荷かけまくると、"クラウド破産"に一直線なので、ベンチマークでのご利用は計画的に...

次回予告

続いて、以下についての結果をエントリにまとめます。

  • EBSボリュームのサイズを増やして、ベンチマークにどのくらい影響するか調べる。(キャッシュ的なヤツの使える範囲の増分があるかどうか。)
  • EBSのProvisioned IOPS(プロビジョンドIOPS)だと、どのような結果になるか確認する。

それでは次回もお楽しみに! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


追記

続編を書きました。


あわせて読みたい



まとめ


2013/04/15

15周年ということでお布施


ここしばらくチェックしてなかったので、タイトル通りですが、15周年記念の限定モノを購入。

またMISIAのライブ観にいきたいなぁ。歌声で圧倒されたい。


Super Best Records-15th Celebration-(初回生産限定盤)(DVD付)

Super Best Records-15th Celebration-(初回生産限定盤)(DVD付)

THE TOUR OF MISIA BOX Blu-ray 15th Celebration

THE TOUR OF MISIA BOX Blu-ray 15th Celebration


それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

2013/04/05

xfsファイルシステムのデフラグ方法とパフォーマンスについて

4/1のエントリで、頑張ってブログを書く頻度を上げます、と言ったまま4日が経過し、このままだとただのエイプリルフールの戯言になりかねないと思ったので、ちょっと調べてみたログを残します。


XFSの設計はエクステントベースで、ファイルの内容は1つ以上のエクステントと呼ばれる連続的な領域内に保存されている。XFSファイルシステム内のファイルは、ユーザーの使い方によってはフラグメント化することがあるが、xfs_fsrユーティリティを使ってそのようなファイルをデフラグすることでファイルアクセスについてのシステムの性能を向上させることができる。

Linux Hacks:xfs_fsrを使ってXFSファイルシステムをベストの状態で使用する (1/2) - ITmedia エンタープライズ

ココの部分の使い方を実際に試してみることにしました。

まず、用意したのは、xfsファイルシステムで2年くらい運用して役目を終えた、とあるサーバ(ハードディスク搭載、ディスクI/O多数)です。


デフラグのやり方

さて、まずフラグメンテーション度合い(断片化量)を測定してみます。コマンドは↓のような感じでパーティションを指定します。

# xfs_db -c frag -r /dev/sdb1
actual 343, ideal 259, fragmentation factor 24.49%

正直、数字はピンとこないのですが、理想長に対して実長が長いので、幾分か断片化しているということなのでしょう。

実際にいくつかのファイルを確認してみたところ、エクステントが分割されたような形になっていました。

たとえば、

# xfs_bmap -v /data/foo/hoge.1
/data/foo/hoge.1:
 EXT: FILE-OFFSET         BLOCK-RANGE           AG AG-OFFSET            TOTAL
   0: [0..108255]:        626753792..626862047  82 (4831024..4939279)  108256
   1: [108256..3195615]:  629540024..632627383  83 (32832..3120191)   3087360
   2: [3195616..4192255]: 643381216..644377855  84 (6289600..7286239)  996640

こんな感じです。

こいつを最適化するには、"xfs_fsr"コマンドを使います。このコマンドはCentOSだとxfsdumpパッケージに含まれるので、


# yum install xfsdump

こんな感じでインストールしましょう。


# xfs_fsr /data/foo/hoge.1

その後、↑のような感じでコマンドを実行すると、今回の例だと"hoge.1"ファイルの最適化が実施されます。


# xfs_bmap -v /data/foo/hoge.1
/data/foo/hoge.1:
 EXT: FILE-OFFSET      BLOCK-RANGE           AG AG-OFFSET          TOTAL
   0: [0..4192255]:    712935920..717128175  94 (64..4192319)    4192256

おお。結果、フラグメントの状態はこんな感じに最適化されました。

で、このコマンドは↑のように1ファイルに対するだけじゃなくて、パーティションを指定して、ファイルシステム全体を最適化したり、制限時間を設けること(利用が少ない深夜帯だけ実行するとか。)もできます。


# xfs_fsr /dev/sdb1
/data start inode=0

こんな感じでパーティションを指定して最適化。しばらく待つと処理は完了し、断片化量を調べてみると、、、

# xfs_db -c frag -r /dev/sdb1
actual 259, ideal 259, fragmentation factor 0.00%

こんな感じで最適化されました。


# xfs_bmap -v /data/foo/hoge.2
/data/foo/hoge.2:
 EXT: FILE-OFFSET         BLOCK-RANGE           AG AG-OFFSET            TOTAL
   0: [0..357295]:        626862048..627219343  82 (4939280..5296575)  357296
   1: [357296..3618527]:  637091680..640352911  84 (64..3261295)      3261232
   2: [3618528..4192255]: 650473952..651047679  85 (5797912..6371639)  573728

元々、↑な状態だったファイルも、、、

# xfs_bmap -v /data/foo/hoge.2
/data/foo/hoge.2:
 EXT: FILE-OFFSET      BLOCK-RANGE           AG AG-OFFSET          TOTAL
   0: [0..4192255]:    318546064..322738319  42 (256..4192511)   4192256

最適化後は、こんな感じで全ファイル綺麗に並んでおります。

めでたしめでたし。


パフォーマンスに関して

とはいえ、これって性能にどのくらい影響出ているのだろう?と思って、超超簡単に比較してみました。

適当に、断片化させまくった1GBのファイルを何パターンか作って、単純なシーケンシャルアクセスで読み出しにかかった時間を測ってみました。ちなみに都度OSキャッシュはdropさせています。


参考: Linuxのメモリ上のキャッシュを解放する - 元RX-7乗りの適当な日々


パターンA
# xfs_bmap -v /data/test1g_A
/data/test1g_A:
 EXT: FILE-OFFSET      BLOCK-RANGE       AG AG-OFFSET           TOTAL
   0: [0..2097151]:    230664..2327815    0 (230664..2327815) 2097152

まずは、こんな断片化していないファイルは、、、


# time cat /data/test1g_A > /dev/null

real    0m2.686s
user    0m0.012s
sys     0m0.339s

2.686秒でした。

以降、この環境が前提となります。


パターンB
# xfs_bmap -v /data/test1g_B
/data/test1g_B:
 EXT: FILE-OFFSET         BLOCK-RANGE         AG AG-OFFSET            TOTAL
   0: [0..131071]:        8446800..8577871     1 (862376..993447)    131072
   1: [131072..262143]:   8315728..8446799     1 (731304..862375)    131072
   2: [262144..1703935]:  8577872..10019663    1 (993448..2435239)  1441792
   3: [1703936..1835007]: 10257352..10388423   1 (2672928..2803999)  131072
   4: [1835008..1966079]: 10126264..10257335   1 (2541840..2672911)  131072
   5: [1966080..2097151]: 10388424..10519495   1 (2804000..2935071)  131072

この程度の断片化だと、


# time cat /data/test1g_B > /dev/null

real    0m2.798s
user    0m0.008s
sys     0m0.273s

2.798秒と、さほど差は出ません。

ケースバイケースだとは思いますが、シーケンシャルアクセスでは、フラグメンテーションはさほど気にしなくてもいいのかもしれません。


これ以上の断片化は、あまり遭遇しないかもしれませんが、せっかくなので作り出して測ってみましょうw


パターンC
# xfs_bmap -v /data/test1g_C
/data/test1g_C:
 EXT: FILE-OFFSET         BLOCK-RANGE       AG AG-OFFSET          TOTAL
   0: [0..32767]:         7806496..7839263   1 (222072..254839)   32768
   1: [32768..65535]:     8282960..8315727   1 (698536..731303)   32768
   2: [65536..98303]:     7524720..7557487   0 (7524720..7557487) 32768
   3: [98304..131071]:    6167744..6200511   0 (6167744..6200511) 32768
   4: [131072..163839]:   8053584..8086351   1 (469160..501927)   32768
   5: [163840..196607]:   6233280..6266047   0 (6233280..6266047) 32768
   6: [196608..229375]:   6279528..6312295   0 (6279528..6312295) 32768
   7: [229376..262143]:   7889744..7922511   1 (305320..338087)   32768
   8: [262144..294911]:   8184656..8217423   1 (600232..632999)   32768
   9: [294912..327679]:   8086352..8119119   1 (501928..534695)   32768
  10: [327680..360447]:   6377832..6410599   0 (6377832..6410599) 32768

・・・・・省略・・・・・

  50: [1736704..1769471]: 7098736..7131503   0 (7098736..7131503) 32768
  51: [1769472..1802239]: 6705512..6738279   0 (6705512..6738279) 32768
  52: [1802240..1835007]: 6902120..6934887   0 (6902120..6934887) 32768
  53: [1835008..1867775]: 7262576..7295343   0 (7262576..7295343) 32768
  54: [1867776..1900543]: 6803816..6836583   0 (6803816..6836583) 32768
  55: [1900544..1933311]: 7491952..7524719   0 (7491952..7524719) 32768
  56: [1933312..1966079]: 8250192..8282959   1 (665768..698535)   32768
  57: [1966080..1998847]: 7229808..7262575   0 (7229808..7262575) 32768
  58: [1998848..2031615]: 7773728..7806495   1 (189304..222071)   32768
  59: [2031616..2064383]: 7740960..7773727   1 (156536..189303)   32768

かなりフラグメンテーションさせまくりましたが、、、


# time cat /data/test1g_C > /dev/null

real    0m3.242s
user    0m0.009s
sys     0m0.355s

3.242秒です。遅くなってきましたが、大きくは劣化していませんね。


パターンD
# xfs_bmap -v /data/test1g_D
/data/test1g_D:
 EXT: FILE-OFFSET         BLOCK-RANGE       AG AG-OFFSET          TOTAL
   0: [0..2047]:          4891848..4893895   0 (4891848..4893895)  2048
   1: [2048..4095]:       4105408..4107455   0 (4105408..4107455)  2048
   2: [4096..6143]:       5096648..5098695   0 (5096648..5098695)  2048
   3: [6144..8191]:       4123840..4125887   0 (4123840..4125887)  2048
   4: [8192..10239]:      4187328..4189375   0 (4187328..4189375)  2048
   5: [10240..12287]:     4750528..4752575   0 (4750528..4752575)  2048
   6: [12288..14335]:     4877512..4879559   0 (4877512..4879559)  2048
   7: [14336..16383]:     4191424..4193471   0 (4191424..4193471)  2048
   8: [16384..18431]:     4093120..4095167   0 (4093120..4095167)  2048
   9: [18432..20479]:     4170944..4172991   0 (4170944..4172991)  2048
  10: [20480..22527]:     4207808..4209855   0 (4207808..4209855)  2048

・・・・・省略・・・・・

 992: [2066432..2068479]: 6005952..6007999   0 (6005952..6007999)  2048
 993: [2068480..2070527]: 6010048..6012095   0 (6010048..6012095)  2048
 994: [2070528..2074623]: 6001856..6005951   0 (6001856..6005951)  4096
 995: [2074624..2076671]: 6018240..6020287   0 (6018240..6020287)  2048
 996: [2076672..2078719]: 6042816..6044863   0 (6042816..6044863)  2048
 997: [2078720..2080767]: 6057152..6059199   0 (6057152..6059199)  2048
 998: [2080768..2084863]: 6024384..6028479   0 (6024384..6028479)  4096
 999: [2084864..2086911]: 6091968..6094015   0 (6091968..6094015)  2048
1000: [2086912..2088959]: 6048960..6051007   0 (6048960..6051007)  2048
1001: [2088960..2095103]: 6032576..6038719   0 (6032576..6038719)  6144

これはひどいレベルですね。もうありえない感じじゃないでしょうか。


# time cat /data/test1g_D > /dev/null

real    0m16.378s
user    0m0.023s
sys     0m0.456s

16.378秒。かなり遅くなってきました。


パターンE
# xfs_bmap -v /data/test1g_E
/data/test1g_E:
 EXT: FILE-OFFSET         BLOCK-RANGE       AG AG-OFFSET          TOTAL
   0: [0..7]:             4001000..4001007   0 (4001000..4001007)     8
   1: [8..15]:            2769576..2769583   0 (2769576..2769583)     8
   2: [16..23]:           3351192..3351199   0 (3351192..3351199)     8
   3: [24..31]:           3998048..3998055   0 (3998048..3998055)     8
   4: [32..39]:           2470088..2470095   0 (2470088..2470095)     8
   5: [40..47]:           2837536..2837543   0 (2837536..2837543)     8
   6: [48..55]:           2748600..2748607   0 (2748600..2748607)     8
   7: [56..63]:           2988880..2988887   0 (2988880..2988887)     8
   8: [64..71]:           3451752..3451759   0 (3451752..3451759)     8
   9: [72..79]:           3476944..3476951   0 (3476944..3476951)     8
  10: [80..87]:           hole                                        8

・・・・・省略・・・・・

261017: [2097064..2097071]: 46368..46375       0 (46368..46375)         8
261018: [2097072..2097079]: 3089136..3089143   0 (3089136..3089143)     8
261019: [2097080..2097087]: 2496016..2496023   0 (2496016..2496023)     8
261020: [2097088..2097095]: 3360472..3360479   0 (3360472..3360479)     8
261021: [2097096..2097103]: 3373552..3373559   0 (3373552..3373559)     8
261022: [2097104..2097111]: 3616384..3616391   0 (3616384..3616391)     8
261023: [2097112..2097119]: 3894400..3894407   0 (3894400..3894407)     8
261024: [2097120..2097127]: 2744288..2744295   0 (2744288..2744295)     8
261025: [2097128..2097135]: 2427728..2427735   0 (2427728..2427735)     8
261026: [2097136..2097143]: 3962440..3962447   0 (3962440..3962447)     8

これは、まずありえなさそうな状況ですが、、、このファイルを作るのも苦労しました(コンピュータが時間をかけて頑張ってくれました)w


# time cat /data/test1g_E > /dev/null

real    2m39.257s
user    0m0.012s
sys     0m1.291s

ぬお、2分39.257秒と、ここまで来るともう実用できない感じですね。

でも、こんな状態になるケースが・・・。


まとめ

ということで、今日はxfsファイルシステムのデフラグ方法を学びました!

多少はエクステントが分割していようが、シーケンシャルアクセスだとそれほど影響がでないことがわかりました。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


2013/04/01

by Ian A Kirk

LinuxでランダムアクセスなI/Oスループットを10倍以上に伸ばす方法だって?


そんな夢のような話が、簡単に存在するわけがない。(エイプリルフール)



・・・・・

は、さておき、今日から期も変わったので、頑張ってブログを書く頻度を上げていこうと思います。


ランダムアクセスを伸ばすなら、とりあえずSSD使え、とか言われそうですね。エヘヘ。

↑のタイトルはネタエントリということで適当に書いたものですが、ちょっと前にRAIDカードやSSDまわりのベンチマークを取りつつ、最適な諸々のパラメータを模索したり、ファイルシステム(主にxfs)まわりのオプション(kernelパラメータ含む)を色々弄ってチューニングしてみたりしたので、その辺を近々まとめていこうと思っています。SSDの性能を使いきるための調整/チューニングってやつですね。ハイ。

もちろん上記の話は、デバイスによって最適値が異なるのでケースバイケースにはなりますが、その辺も言及できれば。


最後に、ネタエントリですいませんでした・・・!

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)