LinuxのZFSがAWS i2.8xlargeインスタンスで8x SSDを完全に利用できないのはなぜですか？
私はZFSを完全に使い始めたばかりなので、まずは簡単なベンチマークを実行して、ZFSの動作を感じ取ろうと思いました。私はそのパフォーマンスの限界を押し上げたかったので、Amazon EC2 i2.8xlargeインスタンスをプロビジョニングしました（ほぼ$ 7/hr、時間は本当にお金です！）。このインスタンスには8つの800GB SSDがあります。
SSD自体でfioテストを実行し、次の出力（トリミング）を取得しました。
$ Sudo fio --name randwrite --ioengine=libaio --iodepth=2 --rw=randwrite --bs=4k --size=400G --numjobs=8 --runtime=300 --group_reporting --direct=1 --filename=/dev/xvdb
[trimmed]
write: io=67178MB, bw=229299KB/s, iops=57324, runt=300004msec
[trimmed]
4Kランダム書き込みで57K IOPS。立派な。
次に、8つすべてにまたがるZFSボリュームを作成しました。最初に、8つのSSDがすべて含まれる1つのraidz1 vdevがありましたが、これがパフォーマンスに悪い理由を読んだので、4つのmirror vdevs、次のように：
$ Sudo zpool create testpool mirror xvdb xvdc mirror xvdd xvde mirror xvdf xvdg mirror xvdh xvdi
$ Sudo zpool list -v
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
testpool 2.91T 284K 2.91T - 0% 0% 1.00x ONLINE -
mirror 744G 112K 744G - 0% 0%
xvdb - - - - - -
xvdc - - - - - -
mirror 744G 60K 744G - 0% 0%
xvdd - - - - - -
xvde - - - - - -
mirror 744G 0 744G - 0% 0%
xvdf - - - - - -
xvdg - - - - - -
mirror 744G 112K 744G - 0% 0%
xvdh - - - - - -
xvdi - - - - - -
レコードサイズを4Kに設定して、テストを実行しました。
$ Sudo zfs set recordsize=4k testpool
$ Sudo fio --name randwrite --ioengine=libaio --iodepth=2 --rw=randwrite --bs=4k --size=400G --numjobs=8 --runtime=300 --group_reporting --filename=/testpool/testfile --fallocate=none
[trimmed]
write: io=61500MB, bw=209919KB/s, iops=52479, runt=300001msec
slat (usec): min=13, max=155081, avg=145.24, stdev=901.21
clat (usec): min=3, max=155089, avg=154.37, stdev=930.54
lat (usec): min=35, max=155149, avg=300.91, stdev=1333.81
[trimmed]
このZFSプールで得られるのは52K IOPSだけです。実際には、1つのSSD自体よりも少し悪いです。
ここで何が間違っているのか理解できません。 ZFSを誤って構成しましたか、それともこれはZFSパフォーマンスの不十分なテストですか？
注意：4.4.5 elrepoカーネルにアップグレードしましたが、公式の64ビットCentOS 7 HVMイメージを使用しています。
$ uname -a
Linux ip-172-31-43-196.ec2.internal 4.4.5-1.el7.elrepo.x86_64 #1 SMP Thu Mar 10 11:45:51 EST 2016 x86_64 x86_64 x86_64 GNU/Linux
リストされているzfsリポジトリ here からZFSをインストールしました。 zfsパッケージのバージョン0.6.5.5を持っています。
[〜＃〜] update [〜＃〜]：@ewwhiteの提案に従って、私はashift=12とashift=13を試しました：
$ Sudo zpool create testpool mirror xvdb xvdc mirror xvdd xvde mirror xvdf xvdg mirror xvdh xvdi -o ashift=12 -f
そして
$ Sudo zpool create testpool mirror xvdb xvdc mirror xvdd xvde mirror xvdf xvdg mirror xvdh xvdi -o ashift=13 -f
これらのどちらも違いを生みませんでした。私が理解しているところによると、最新のZFSビットは4K SSDを識別し、妥当なデフォルトを使用するのに十分スマートです。
ただし、CPU使用率が急上昇していることに気付きました。 @Timはこれを提案しましたが、却下しましたが、気付くほどCPUを十分に監視していなかったと思います。このインスタンスには30個のCPUコアのようなものがあり、CPU使用率が80％も急上昇しています。空腹のプロセス？ z_wr_iss、そのインスタンスがたくさんあります。
圧縮がオフであることを確認したので、圧縮エンジンではありません。
私はraidzを使用していないので、それはパリティ計算ではありません。
私がperf topを実行したところ、_raw_spin_unlock_irqrestoreのz_wr_int_4とosq_lockのz_wr_issに費やされたカーネル時間のほとんどが表示されました。
私は今、このパフォーマンスのボトルネックにはCPUコンポーネントがあると信じていますが、それが何であるかを理解するのに近づいているわけではありません。
更新2：@ewwhiteなどの提案によると、パフォーマンスの不確実性を生み出すのはこの環境の仮想化された性質であり、fioを使用してベンチマークランダム4K書き込みは、環境内の4つのSSDに分散します。 SSD単体では、約55K IOPSが得られるため、そのうちの4つで約240K IOSが予想されました。それは多かれ少なかれ私が得たものです：
$ Sudo fio --name randwrite --ioengine=libaio --iodepth=8 --rw=randwrite --bs=4k --size=398G --numjobs=8 --runtime=300 --group_reporting --filename=/dev/xvdb:/dev/xvdc:/dev/xvdd:/dev/xvde
randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=8
...
randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=8
fio-2.1.5
Starting 8 processes
[trimmed]
write: io=288550MB, bw=984860KB/s, iops=246215, runt=300017msec
slat (usec): min=1, max=24609, avg=30.27, stdev=566.55
clat (usec): min=3, max=2443.8K, avg=227.05, stdev=1834.40
lat (usec): min=27, max=2443.8K, avg=257.62, stdev=1917.54
[trimmed]
これは、仮想化されている可能性がありますが、仮想化環境が、私が見ているよりもはるかに高いIOPSを維持できることを明確に示しています。 ZFSの実装方法については、ZFSが最高速度に達しないようにしています。それが何なのかわからない。
この設定はうまく調整されていない可能性があります。 SSDを使用する場合、/ etc/modprobe/zfs.confファイルとashift値の両方に必要なパラメーターがあります
Ashift = 12または13を試して、もう一度テストしてください。
編集：
これはまだ仮想化されたソリューションであるため、基盤となるハードウェアやすべてがどのように相互接続されているかについてはあまり知りません。このソリューションからより良いパフォーマンスが得られるかどうかはわかりません。
編集：
この方法でクラウドインスタンスを最適化しようとする意味がわからないと思います。なぜなら、最高のパフォーマンスが目的であれば、ハードウェアを使用することになりますよね？
ただし、ZFSにはlotの調整可能な設定があり、デフォルトで得られるものはユースケースに近いものではないことに注意してください。
/etc/modprobe.d/zfs.confと再起動します。これは、アプリケーションサーバーのすべてのSSDデータプールで使用するものです。 ashiftは12または13である必要があります。compression= offのベンチマークですが、本番環境ではcompression = lz4を使用します。 atime = offを設定します。レコードサイズはデフォルト（128K）のままにしておきます。
options zfs zfs_vdev_scrub_min_active=48
options zfs zfs_vdev_scrub_max_active=128
options zfs zfs_vdev_sync_write_min_active=64
options zfs zfs_vdev_sync_write_max_active=128
options zfs zfs_vdev_sync_read_min_active=64
options zfs zfs_vdev_sync_read_max_active=128
options zfs zfs_vdev_async_read_min_active=64
options zfs zfs_vdev_async_read_max_active=128
options zfs zfs_top_maxinflight=320
options zfs zfs_txg_timeout=30
options zfs zfs_dirty_data_max_percent=40
options zfs zfs_vdev_scheduler=deadline
options zfs zfs_vdev_async_write_min_active=8
options zfs zfs_vdev_async_write_max_active=64
options zfs zfs_prefetch_disable=1
Linuxカーネルのミューテックスロックを待機している可能性が高く、そのロックがXenリングバッファーを待機している可能性があります。私は同様のマシンにアクセスしないとこれを確信することはできませんが、その特権に対してAmazonに1時間あたり$ 7を支払うことに興味はありません。
より長い記事はこちら： https://www.reddit.com/r/zfs/comments/4b4r1y/why_is_zfs_on_linux_unable_to_fully_utilize_8x/d1e91wo ; 2か所ではなく1か所にしたい。
私はこれを追跡するためにかなりの時間を費やしました。私の特定の課題：Postgresサーバーで、データボリュームにZFSを使用したい。ベースラインはXFSです。
何よりもまず、私の裁判でashift=12が間違っていることがわかりました。いくつかの魔法のashift番号がある場合、それは12ではありません。私は0を使用しており、非常に良い結果が得られています。
また、多数のzfsオプションを試してみましたが、以下の結果が得られます。
atime=off-アクセス時間は必要ありません
checksum=off-ミラーリングではなく、ストライピングしています
compression=lz4-圧縮するとパフォーマンスが向上します（CPUトレードオフ？）
exec=off-これはデータ用であり、実行可能ファイルではありません
logbias=throughput-インターウェブで読んでください。これはPostgresに適しています
recordsize=8k-PG固有の8kブロックサイズ
sync=standard-同期をオフにしようとしました。あまりメリットが見られなかった
以下のテストでは、XFSのパフォーマンスよりも優れています（テストでエラーが発生した場合はコメントしてください）。
これで私の次のステップは、2 x EBS ZFSファイルシステムでPostgresを実行することです。
私の特定のセットアップ：
EC2：m4.xlargeインスタンス
EBS：250GB gp2ボリューム
カーネル：Linux [...] 3.13.0-105-generic＃152-Ubuntu SMP [...] x86_64 x86_64 x86_64 GNU/Linux *
まず、生のEBSパフォーマンスをテストしたいと思いました。上記のfioコマンドのバリエーションを使用して、以下の呪文を思いつきました。注：8kブロックを使用しています。これは、PostgreSQLの書き込みで次のように読み取ったためです。
ubuntu@ip-172-31-30-233:~$ device=/dev/xvdbd; Sudo dd if=/dev/zero of=${device} bs=1M count=100 && Sudo fio --name randwrite --ioengine=libaio --iodepth=4 --rw=randwrite --bs=8k --size=400G --numjobs=4 --runtime=60 --group_reporting --fallocate=none --filename=${device}
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.250631 s, 418 MB/s
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
...
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
fio-2.1.3
Starting 4 processes
Jobs: 4 (f=4): [wwww] [100.0% done] [0KB/13552KB/0KB /s] [0/1694/0 iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=4): err= 0: pid=18109: Tue Feb 14 19:13:53 2017
write: io=3192.2MB, bw=54184KB/s, iops=6773, runt= 60327msec
slat (usec): min=2, max=805209, avg=585.73, stdev=6238.19
clat (usec): min=4, max=805236, avg=1763.29, stdev=10716.41
lat (usec): min=15, max=805241, avg=2349.30, stdev=12321.43
clat percentiles (usec):
| 1.00th=[ 15], 5.00th=[ 16], 10.00th=[ 17], 20.00th=[ 19],
| 30.00th=[ 23], 40.00th=[ 24], 50.00th=[ 25], 60.00th=[ 26],
| 70.00th=[ 27], 80.00th=[ 29], 90.00th=[ 36], 95.00th=[15808],
| 99.00th=[31872], 99.50th=[35584], 99.90th=[99840], 99.95th=[199680],
| 99.99th=[399360]
bw (KB /s): min= 156, max=1025440, per=26.00%, avg=14088.05, stdev=67584.25
lat (usec) : 10=0.01%, 20=20.53%, 50=72.20%, 100=0.86%, 250=0.17%
lat (usec) : 500=0.13%, 750=0.01%, 1000=0.01%
lat (msec) : 2=0.01%, 4=0.01%, 10=0.59%, 20=2.01%, 50=3.29%
lat (msec) : 100=0.11%, 250=0.05%, 500=0.02%, 750=0.01%, 1000=0.01%
cpu : usr=0.22%, sys=1.34%, ctx=9832, majf=0, minf=114
IO depths : 1=0.1%, 2=0.1%, 4=100.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=408595/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
WRITE: io=3192.2MB, aggrb=54184KB/s, minb=54184KB/s, maxb=54184KB/s, mint=60327msec, maxt=60327msec
Disk stats (read/write):
xvdbd: ios=170/187241, merge=0/190688, ticks=180/8586692, in_queue=8590296, util=99.51%
EBSボリュームの生のパフォーマンスはWRITE: io=3192.2MBです。
次に、同じfioコマンドを使用してXFSをテストします。
Jobs: 4 (f=4): [wwww] [100.0% done] [0KB/0KB/0KB /s] [0/0/0 iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=4): err= 0: pid=17441: Tue Feb 14 19:10:27 2017
write: io=3181.9MB, bw=54282KB/s, iops=6785, runt= 60024msec
slat (usec): min=3, max=21077K, avg=587.19, stdev=76081.88
clat (usec): min=4, max=21077K, avg=1768.72, stdev=131857.04
lat (usec): min=23, max=21077K, avg=2356.23, stdev=152444.62
clat percentiles (usec):
| 1.00th=[ 29], 5.00th=[ 40], 10.00th=[ 46], 20.00th=[ 52],
| 30.00th=[ 56], 40.00th=[ 59], 50.00th=[ 63], 60.00th=[ 69],
| 70.00th=[ 79], 80.00th=[ 99], 90.00th=[ 137], 95.00th=[ 274],
| 99.00th=[17024], 99.50th=[25472], 99.90th=[70144], 99.95th=[120320],
| 99.99th=[1564672]
bw (KB /s): min= 2, max=239872, per=66.72%, avg=36217.04, stdev=51480.84
lat (usec) : 10=0.01%, 20=0.03%, 50=15.58%, 100=64.51%, 250=14.55%
lat (usec) : 500=1.36%, 750=0.33%, 1000=0.25%
lat (msec) : 2=0.68%, 4=0.67%, 10=0.71%, 20=0.58%, 50=0.59%
lat (msec) : 100=0.10%, 250=0.02%, 500=0.01%, 750=0.01%, 1000=0.01%
lat (msec) : 2000=0.01%, >=2000=0.01%
cpu : usr=0.43%, sys=4.81%, ctx=269518, majf=0, minf=110
IO depths : 1=0.1%, 2=0.1%, 4=100.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=407278/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
WRITE: io=3181.9MB, aggrb=54282KB/s, minb=54282KB/s, maxb=54282KB/s, mint=60024msec, maxt=60024msec
Disk stats (read/write):
xvdbd: ios=4/50983, merge=0/319694, ticks=0/2067760, in_queue=2069888, util=26.21%
ベースラインはWRITE: io=3181.9MBです。実際のディスク速度に非常に近い。
次に、WRITE: io=3181.9MBを参照としてZFSにアクセスします。
ubuntu@ip-172-31-30-233:~$ Sudo zpool create testpool xvdbd -f && (for option in atime=off checksum=off compression=lz4 exec=off logbias=throughput recordsize=8k sync=standard; do Sudo zfs set $option testpool; done;) && Sudo fio --name randwrite --ioengine=libaio --iodepth=4 --rw=randwrite --bs=8k --size=400G --numjobs=4 --runtime=60 --group_reporting --fallocate=none --filename=/testpool/testfile; Sudo zpool destroy testpool
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
...
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
fio-2.1.3
Starting 4 processes
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
Jobs: 4 (f=4): [wwww] [100.0% done] [0KB/41328KB/0KB /s] [0/5166/0 iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=4): err= 0: pid=18923: Tue Feb 14 19:17:18 2017
write: io=4191.7MB, bw=71536KB/s, iops=8941, runt= 60001msec
slat (usec): min=10, max=1399.9K, avg=442.26, stdev=4482.85
clat (usec): min=2, max=1400.4K, avg=1343.38, stdev=7805.37
lat (usec): min=56, max=1400.4K, avg=1786.61, stdev=9044.27
clat percentiles (usec):
| 1.00th=[ 62], 5.00th=[ 75], 10.00th=[ 87], 20.00th=[ 108],
| 30.00th=[ 122], 40.00th=[ 167], 50.00th=[ 620], 60.00th=[ 1176],
| 70.00th=[ 1496], 80.00th=[ 2320], 90.00th=[ 2992], 95.00th=[ 4128],
| 99.00th=[ 6816], 99.50th=[ 9536], 99.90th=[30592], 99.95th=[66048],
| 99.99th=[185344]
bw (KB /s): min= 2332, max=82848, per=25.46%, avg=18211.64, stdev=15010.61
lat (usec) : 4=0.01%, 50=0.09%, 100=14.60%, 250=26.77%, 500=5.96%
lat (usec) : 750=5.27%, 1000=4.24%
lat (msec) : 2=20.96%, 4=16.74%, 10=4.93%, 20=0.30%, 50=0.08%
lat (msec) : 100=0.04%, 250=0.03%, 500=0.01%, 2000=0.01%
cpu : usr=0.61%, sys=9.48%, ctx=177901, majf=0, minf=107
IO depths : 1=0.1%, 2=0.1%, 4=100.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=536527/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
WRITE: io=4191.7MB, aggrb=71535KB/s, minb=71535KB/s, maxb=71535KB/s, mint=60001msec, maxt=60001msec
これは、XFS WRITE: io=4191.7MBよりもパフォーマンスが優れています。これは圧縮によるものだと確信しています。
キックについては、2番目のボリュームを追加します。
ubuntu@ip-172-31-30-233:~$ Sudo zpool create testpool xvdb{c,d} -f && (for option in atime=off checksum=off compression=lz4 exec=off logbias=throughput recordsize=8k sync=standard; do Sudo zfs set $option testpool; done;) && Sudo fio --name randwrite --ioengine=libaio --iodepth=4 --rw=randwrite --bs=8k --size=400G --numjobs=4 --runtime=60 --group_reporting --fallocate=none --filename=/testpool/testfile; Sudo zpool destroy testpool
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
...
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
fio-2.1.3
Starting 4 processes
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
Jobs: 4 (f=4): [wwww] [100.0% done] [0KB/71936KB/0KB /s] [0/8992/0 iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=4): err= 0: pid=20901: Tue Feb 14 19:23:30 2017
write: io=5975.9MB, bw=101983KB/s, iops=12747, runt= 60003msec
slat (usec): min=10, max=1831.2K, avg=308.61, stdev=4419.95
clat (usec): min=3, max=1831.6K, avg=942.64, stdev=7696.18
lat (usec): min=58, max=1831.8K, avg=1252.25, stdev=8896.67
clat percentiles (usec):
| 1.00th=[ 70], 5.00th=[ 92], 10.00th=[ 106], 20.00th=[ 129],
| 30.00th=[ 386], 40.00th=[ 490], 50.00th=[ 692], 60.00th=[ 796],
| 70.00th=[ 932], 80.00th=[ 1160], 90.00th=[ 1624], 95.00th=[ 2256],
| 99.00th=[ 5344], 99.50th=[ 8512], 99.90th=[30592], 99.95th=[60672],
| 99.99th=[117248]
bw (KB /s): min= 52, max=112576, per=25.61%, avg=26116.98, stdev=15313.32
lat (usec) : 4=0.01%, 10=0.01%, 50=0.04%, 100=7.17%, 250=19.04%
lat (usec) : 500=14.36%, 750=15.36%, 1000=17.41%
lat (msec) : 2=20.28%, 4=4.82%, 10=1.13%, 20=0.25%, 50=0.08%
lat (msec) : 100=0.04%, 250=0.02%, 2000=0.01%
cpu : usr=1.05%, sys=15.14%, ctx=396649, majf=0, minf=103
IO depths : 1=0.1%, 2=0.1%, 4=100.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=764909/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
WRITE: io=5975.9MB, aggrb=101982KB/s, minb=101982KB/s, maxb=101982KB/s, mint=60003msec, maxt=60003msec
2番目のボリュームWRITE: io=5975.9MBを使用すると、書き込みの約1.8倍になります。
3番目のボリュームはWRITE: io=6667.5MBを提供するため、書き込みの最大2.1倍です。
4番目のボリュームはWRITE: io=6552.9MBです。このインスタンスタイプの場合、2つのボリュームでEBSネットワークの上限を設定しているように見えます。3つで間違いなく、4つ（750 * 3 = 2250 IOPS）の方が適しています。
* このビデオ から、すべてのEBSの良さを得るために3.8以降のLinuxカーネルを使用していることを確認してください。