MongoDBとZFSのパフォーマンスが悪い：書き込みのみを実行している間、ディスクは常に読み取りでビジーです
ZFSonlinuxでMongoDB（mmapped DBだと思います）を使用すると、パフォーマンスに大きな問題が発生します。
私たちのMongodbはほとんど書き込みのみです。 ZFSのないレプリカでは、アプリが30秒ごとにDBに書き込み、その間にディスクアクティビティがない場合、ディスクは約5秒のスパイクの間完全にビジー状態であるため、比較するベースライン動作としてそれを使用します。
ZFSを使用するレプリカでは、ディスクは完全にビジーですall時間であり、レプリカはMongoDBプライマリを最新の状態に保つのに苦労しています。すべてのレプリカでlz4圧縮を有効にしており、スペースを大幅に節約できるため、ディスクにヒットするデータははるかに少なくなるはずです。
したがって、これらのZFSサーバーでは、最初にデフォルトのrecordsize = 128kがありました。次に、Mongoデータを再同期する前に、データをワイプしてrecordsize = 8kに設定しました。次に、もう一度ワイプして、recordsize = 1kを試しました。チェックサムなしでrecordsize = 8kも試しました
それにもかかわらず、それは何も解決せず、ディスクは常に100％ビジー状態に保たれていました。 recordsize = 8kの1台のサーバーで1回だけ、ディスクは非ZFSレプリカよりもはるかにビジーではありませんでしたが、別の設定を試し、recordsize = 8kで再試行した後、ディスクは100％でした、以前の良好な動作を確認できませんでした。他のレプリカでも見ることができませんでした。
さらに、ほとんど書き込みのみが存在するはずですが、異なる設定のすべてのレプリカで、ディスクは75％の読み取りと25％の書き込みのみで完全にビジーです
（注：MongoDBはmmapされたDBだと思います。MongoDBをAIOモードで試すように言われましたが、設定方法が見つかりませんでした。MySQLInnoDBを実行している別のサーバーで、ZFSonLinuxに気づきました。とにかくAIOをサポートしていませんでした。）
私のサーバーはCentOS6.5カーネル2.6.32-431.5.1.el6.x86_64です。 spl-0.6.2-1.el6.x86_64 zfs-0.6.2-1.el6.x86_64
#PROD 13:44:55 root@rum-mongo-backup-1:~: zfs list
NAME USED AVAIL REFER MOUNTPOINT
zfs 216G 1.56T 32K /zfs
zfs/mongo_data-rum_a 49.5G 1.56T 49.5G /zfs/mongo_data-rum_a
zfs/mongo_data-rum_old 166G 1.56T 166G /zfs/mongo_data-rum_old
#PROD 13:45:20 root@rum-mongo-backup-1:~: zfs list -t snapshot
no datasets available
#PROD 13:45:29 root@rum-mongo-backup-1:~: zfs list -o atime,devices,compression,copies,dedup,mountpoint,recordsize,casesensitivity,xattr,checksum
ATIME DEVICES COMPRESS COPIES DEDUP MOUNTPOINT RECSIZE CASE XATTR CHECKSUM
off on lz4 1 off /zfs 128K sensitive sa off
off on lz4 1 off /zfs/mongo_data-rum_a 8K sensitive sa off
off on lz4 1 off /zfs/mongo_data-rum_old 8K sensitive sa off
そこで何が起こっているのでしょうか？ ZFSが何をしているのか、またはどの設定が正しく設定されていないのかを把握するには、何を確認する必要がありますか？
編集1：
ハードウェア：これらはレンタルサーバー、Xeon 1230または1240上の8つのvcore、16または32GBのRAM、zfs_arc_max=2147483648、HPハードウェアRAID1を使用。したがって、ZFSzpoolは/ dev/sda2にあり、基盤となるRAID1があることを認識していません。 ZFSのセットアップが最適ではない場合でも、DBが書き込みのみを行うのに、ディスクが読み取りで窒息する理由がわかりません。
ここで再度公開する必要のない多くの理由を理解しています。これは悪いことと悪いことです... ZFSにとって、まもなくJBODが作成されます。/NORAIDサーバー。sda2パーティションでZFS独自のRAID1実装を使用して同じテストを実行できます。/、/ bootおよびswapパーティションはmdadmを使用してソフトウェアRAID1を実行します。
これは少しクレイジーに聞こえるかもしれませんが、ZFSボリューム管理属性の恩恵を受ける別のアプリケーションをサポートしていますが、ネイティブZFSファイルシステムではうまく機能しません。
私の解決策？！？
XFS ontopof ZFS zvols 。
なぜ？！？
XFSはうまく機能し、ネイティブZFSで直面していたアプリケーション固有の問題を排除するためです。 ZFS zvolを使用すると、ボリュームのシンプロビジョニング、圧縮の追加、スナップショットの有効化、およびストレージプールの効率的な使用が可能になります。私のアプリにとってより重要なのは、zvolのARCキャッシュにより、ディスクのI/O負荷が軽減されたことです。
この出力を実行できるかどうかを確認します。
# zpool status
pool: vol0
state: ONLINE
scan: scrub repaired 0 in 0h3m with 0 errors on Sun Mar 2 12:09:15 2014
config:
NAME STATE READ WRITE CKSUM
vol0 ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
scsi-SATA_OWC_Mercury_AccOW140128AS1243223 ONLINE 0 0 0
scsi-SATA_OWC_Mercury_AccOW140128AS1243264 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
scsi-SATA_OWC_Mercury_AccOW140128AS1243226 ONLINE 0 0 0
scsi-SATA_OWC_Mercury_AccOW140128AS1243185 ONLINE 0 0 0
ZFS zvol、作成者：zfs create -o volblocksize=128K -s -V 800G vol0/pprovol（自動スナップショットが有効になっていることに注意してください）
# zfs get all vol0/pprovol
NAME PROPERTY VALUE SOURCE
vol0/pprovol type volume -
vol0/pprovol creation Wed Feb 12 14:40 2014 -
vol0/pprovol used 273G -
vol0/pprovol available 155G -
vol0/pprovol referenced 146G -
vol0/pprovol compressratio 3.68x -
vol0/pprovol reservation none default
vol0/pprovol volsize 900G local
vol0/pprovol volblocksize 128K -
vol0/pprovol checksum on default
vol0/pprovol compression lz4 inherited from vol0
vol0/pprovol readonly off default
vol0/pprovol copies 1 default
vol0/pprovol refreservation none default
vol0/pprovol primarycache all default
vol0/pprovol secondarycache all default
vol0/pprovol usedbysnapshots 127G -
vol0/pprovol usedbydataset 146G -
vol0/pprovol usedbychildren 0 -
vol0/pprovol usedbyrefreservation 0 -
vol0/pprovol logbias latency default
vol0/pprovol dedup off default
vol0/pprovol mlslabel none default
vol0/pprovol sync standard default
vol0/pprovol refcompressratio 4.20x -
vol0/pprovol written 219M -
vol0/pprovol snapdev hidden default
vol0/pprovol com.Sun:auto-snapshot true local
ZFS zvolブロックデバイスのプロパティ。 900GBボリューム（ディスク上の実際のサイズは143GB）：
# fdisk -l /dev/zd0
Disk /dev/zd0: 966.4 GB, 966367641600 bytes
3 heads, 18 sectors/track, 34952533 cylinders
Units = cylinders of 54 * 512 = 27648 bytes
Sector size (logical/physical): 512 bytes / 131072 bytes
I/O size (minimum/optimal): 131072 bytes / 131072 bytes
Disk identifier: 0x48811e83
Device Boot Start End Blocks Id System
/dev/zd0p1 38 34952534 943717376 83 Linux
ZFSブロックデバイスのXFS情報：
# xfs_info /dev/zd0p1
meta-data=/dev/zd0p1 isize=256 agcount=32, agsize=7372768 blks
= sectsz=4096 attr=2, projid32bit=0
data = bsize=4096 blocks=235928576, imaxpct=25
= sunit=32 swidth=32 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=65536, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
XFSマウントオプション：
# mount
/dev/zd0p1 on /ppro type xfs (rw,noatime,logbufs=8,logbsize=256k,nobarrier)
注：場合によっては、これをHP SmartアレイハードウェアRAIDの上でも行います。
プールの作成は次のようになります。
zpool create -o ashift=12 -f vol1 wwn-0x600508b1001ce908732af63b45a75a6b
結果は次のようになります。
# zpool status -v
pool: vol1
state: ONLINE
scan: scrub repaired 0 in 0h14m with 0 errors on Wed Feb 26 05:53:51 2014
config:
NAME STATE READ WRITE CKSUM
vol1 ONLINE 0 0 0
wwn-0x600508b1001ce908732af63b45a75a6b ONLINE 0 0 0
まず、ZFSがLinux上のMongoDBでサポートされているファイルシステムではないことを述べる価値があります-推奨されるファイルシステムはext4またはXFSです。 LinuxではZFSもチェックされないため（たとえば SERVER-1322 を参照）、スパースファイルを使用せず、代わりに事前割り当て（ゼロで埋める）を試みます。これは、 a [〜＃〜] cow [〜＃〜] ファイルシステム。それが修正されるまで、新しいデータファイルを追加すると、ZFSのパフォーマンスが大幅に低下します（書き込みで頻繁に実行しようとします）。そうしないとパフォーマンスは向上するはずですが、データを十分に速く追加していると、割り当てヒット間で回復できない可能性があります。
さらに、ZFSはダイレクトIOをサポートしていないため、データをメモリ（mmap、ARCなど）に複数回コピーします。これが読み取りのソースであると思われますが、確認するためにテストする必要があります。 LinuxでMongoDB/ZFSを使用したテストを最後に見たとき、SSD上のARCを使用してもパフォーマンスは低下しました。 ZFSは、将来LinuxでのMongoDBの本番環境での使用に適している可能性がありますが、現時点では準備ができていません。
ZFSでMongoを実行することを検討していたところ、この投稿で利用可能なパフォーマンスについて大きな懸念が生じていることがわかりました。 2年後、最新のUbuntu Xenialリリースに付属する現在公式にサポートされているZFSで、mmap上でWiredTigerを使用するMongoの新しいリリースがどのように実行されるかを確認したいと思いました。
要約すると、ZFSはEXT4やXFSほどパフォーマンスが良くないことは明らかでしたが、特にZFSが提供する追加機能を考慮すると、パフォーマンスのギャップはそれほど重要ではありません。
調査結果と方法論について ブログ投稿 を作成しました。お役に立てば幸いです。
あなたのディスクは、
zfs_arc_max=2147483648
設定。ここでは、16〜32Gbを使用している場合でも、ARCを2Gbに明示的に制限しています。 ZFSは、ARCに関しては、非常にメモリを消費し、熱心です。 ZFSレプリカと同一の非ZFSレプリカがある場合（下のHW RAID1）、いくつかの計算を行うと
5s spike @ (200Mb/s writes (estimated 1 hdd throughput) * 2 (RAID1)) = 2Gb over 5sec
これは、おそらく5秒以内にARCキャッシュ全体を無効にしていることを意味します。 ARCは（ある程度）「インテリジェント」であり、最近書き込まれたブロックと最も使用されたブロックの両方を保持しようとするため、ZFSボリュームは、限られたスペースで適切なデータキャッシュを提供しようとしている可能性があります。 zfs_arc_maxをRAM（またはそれ以上）の半分に上げ、arc_shrink_shiftを使用してARCキャッシュデータをより積極的に削除してみてください。
ここ ZFSファイルシステムのチューニングと理解のための17部構成のブログ記事を見つけることができます。
ここ ARCシュリンクシフト設定の説明（最初の段落）を見つけることができます。これにより、立ち退き時にさらにARC RAMを回収し、制御下に置くことができます。
XFS onzvolソリューションの信頼性がわかりません。 ZFSはCOWですが、XFSはそうではありません。 XFSがメタデータを更新していて、マシンが停電したとします。 ZFSは、COW機能のおかげでデータの最後の適切なコピーを読み取りますが、XFSはその変更を認識しません。 XFSボリュームは、半分は停電前のバージョンに、もう一方は停電後のバージョンに「スナップショット」されたままになる場合があります（8Mbの書き込みはすべてアトミックである必要があり、iノードのみが含まれていることがZFSに認識されていないため） 。
[編集] arc_shrink_shiftおよびその他のパラメーターは、ZFSonlinuxのモジュールパラメーターとして使用できます。試す
modinfo zfs
構成でサポートされているすべてのものを取得します。