予想していた数値に非常に近い速度を得ることができました。
400MB/秒を探していました 392MB/秒を管理 .だから私はそれが問題解決だと言います。後でキャッシュ デバイスを追加して、458MB を管理しました /sec read (キャッシュされていると思います)
1. これは最初、ZFS データセット recordsize を増やすだけで実現できました。 値を 1M に
zfs set recordsize=1M pool2/test
この変更により、ディスク アクティビティが減少し、大量の同期読み取りと書き込みがより効率的になると思います。まさに私が求めていたものです。
変更後の結果
- bonnie++ =書き込み 226MB、読み取り 392MB
- dd =書き込み 260MB、読み取り 392MB
- 2 プロセスの並列 =書き込み 227MB、読み取り 396MB
2. キャッシュ デバイス (120GB SSD) を追加すると、さらにうまく管理できました。書き込みが少し遅いです。理由はわかりません。
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
igor 63G 208325 48 129343 28 458513 35 326.8 16
キャッシュ デバイスのトリックは、l2arc_noprefetch=0 を設定することでした。 /etc/modprobe.d/zfs.conf 内 .これにより、ZFS はストリーミング/シーケンシャル データをキャッシュできます。私のように、キャッシュ デバイスがアレイよりも高速な場合にのみ、これを行ってください。
データセットのレコードサイズの変更から恩恵を受けた後、zvol のパフォーマンスの低下に対処する同様の方法ではないかと考えました。
volblocksize=64k を使用して良好なパフォーマンスが得られたと述べている深刻な人々に出くわしました ということで、やってみました。運が悪い。
zfs create -b 64k -V 120G pool/volume
しかし、ext4 (私がテストしていたファイルシステム) が stride のような RAID のオプションをサポートしていることを読みました。 および stripe-width 、これまで使用したことがありません。そこで、このサイト (https://busybox.net/~aldot/mkfs_stride.html) を使用して必要な設定を計算し、zvol を再度フォーマットしました。
mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume
bonnie++ を実行しました 簡単なベンチマークを行うと、結果は優れていました。残念ながら結果は手元にありませんが、思い出すと、書き込みは少なくとも 5 ～ 6 倍高速でした。もう一度ベンチマークしたら、この回答を更新します。