まず、
zfs create -V 10G z1/vdev
を実行した後、/etc/iet/ietd.confにて
Lun 0 Path=/dev/zvol/z1/zvdev,Type=blockio,ScsiId=zfs1,ScsiSN=zfs1
と設定した場合のベンチマークです。といってもCrystalDiskMarkを使用した簡単なものですが。ちなみにcompression=offです。
書き込み時に若干の波があるものの速度としては速いです。
次に、
#zfs create z1/iscsi
#dd if=/dev/zero of=/z1/iscsi/10G.img bs=1G count=10
を実行したあと、ietd.confを
Lun 0 Path=/z1/iscsi/10G.img,Type=fileio,ScsiId=z1,ScsiSN=z1,IOmode=wb
と変えてietdを再起動します。
その結果
QD32の4Krandwrite以外の数値はほぼ誤差の範囲で同じ速度が出ました。ただ、書き込み時における速度の波はfileioの方が安定しています。しかしなぜQD32の書き込みだけここまで差が出るのでしょうか?
予測ではblockIOの方が同期書き込みになるはずなので書き込み速度は遅くなると思っていたのですが…。逆にblockIOの時はキャッシュが効いてFileIOの時に同期書き込みをして…と考えたとしても、そもそも同期書き込みだとすればこんな数値は出ないはずで…ウボァ
もう一つ、fileio時にcompression=lzjbにしたときはどうなるのか、と言うのも試してみました。
#zfs set compression=lzjb z1/iscsi
#dd if=/dev/zero of=/z1/iscsi/10G2.img bs=1G count=10
ietd.conf
Lun 0 Path=/z1/iscsi/10G2.img,Type=fileio,ScsiId=z1,ScsiSN=z1,IOmode=wb
その結果
目に見えた変化はありませんが、やはり書き込み時にCPUをかなり消費します。compression=offの時は8CPU合計のidleが750%とかなのですが、compression=lzjbの時はidleが500-400%程度まで落ちます。それでも十分と言えば十分ですが。
何回かベンチを取ったところでメモリのキャッシュの空きがなくなってきたところでもう一度同じzvdevをマウントしてベンチを走らせてみました。
大きな変化として、crystaldiskmarkはベンチを取るときにあらかじめディスクに読み書きするためのファイルを書くようなのですが、その準備が長くなりました(波が跳ね上がる前の小さな波がそれ)。これはZILの空きがあふれて直接ディスクに書いているからこうなったのでしょうか?正直よく分からないです
まあ、書き込みはそこまで入らないと思うので、個人的に大きな違いがないのであればfileioを使いたいところです。もしパフォーマンスが大きく違わないとしたら、zvdevを使った利点…ってなんでしょうか。
おそらくSolarisでCOMSTARを使うときにvdevを作ると思うのですが、Linux上では…?
誰か詳しい人おしえて!
ツイート
コメントを書く
必要事項とコメントを入力して下さい。