web-dev-qa-db-ja.com

数か月後の極端なZFSの速度低下

メール、DNS、Web、データベース、その他のサービスを多数のユーザーに提供する汎用サーバーがあります。

Xeon E3-1275（3.40 GHz、16 GB ECC RAM）を搭載しています。 Linuxカーネル4.2.3、ZFS-on-Linux0.6.5.3の実行。

ディスクレイアウトは2x Seagate ST32000641AS 2 TBドライブおよび1x Samsung 840 Pro 256 GB SSDです。

RAID-1ミラーに2つのHDがあり、SSDはキャッシュおよびログデバイスとして機能し、すべてZFSで管理されています。

私が最初にシステムをセットアップしたとき、それは驚くほど高速でした。本当のベンチマークはありません、ただ...速いです。

今、特にすべてのmaildirを保持しているファイルシステムで極端な速度低下に気づきました。夜間のバックアップを実行すると、わずか46GBのメールで90分以上かかります。場合によっては、バックアップによって極端な負荷が発生し、システムが最大6時間ほとんど応答しなくなることがあります。

これらの速度低下中にzpool iostat zroot（私のプールの名前はzroot）を実行し、100〜200kバイト/秒のオーダーの書き込みを確認しました。明らかなIOエラーはありません。ディスクは特にハードに動作しているようには見えませんが、読み取りはほとんど使用できないほど遅いです。

奇妙なことに、FreeBSDを実行しているSSDはありませんが、同じスペックのハードウェアを使用して、別のマシンでまったく同じ経験をしました。それは何ヶ月もうまく機能し、その後同じように遅くなりました。

私の疑いはこれです：私は zfs-auto-snapshot を使用して、各ファイルシステムのローリングスナップショットを作成します。 15分、毎時、毎日、毎月のスナップショットを作成し、それぞれの特定の数を保持して、最も古いスナップショットを削除します。つまり、時間の経過とともに、各ファイルシステムで数千のスナップショットが作成され、破棄されました。これは、累積的な影響で考えることができる唯一の進行中のファイルシステムレベルの操作です。すべてのスナップショットを破棄しようとしましたが（ただし、プロセスを実行し続け、新しいスナップショットを作成しました）、変更がないことに気付きました。

スナップショットを絶えず作成および破棄することに問題はありますか？私はそれらが非常に価値のあるツールであることを見つけ、それらが（ディスク領域を除いて）多かれ少なかれゼロコストであると信じるようになりました。

この問題を引き起こしている可能性のある他の何かがありますか？

編集：コマンド出力

zpool listの出力：

NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
zroot  1.81T   282G  1.54T         -    22%    15%  1.00x  ONLINE  -

zfs listの出力：

NAME             USED  AVAIL  REFER  MOUNTPOINT
zroot            282G  1.48T  3.55G  /
zroot/abs       18.4M  1.48T  18.4M  /var/abs
zroot/bkup      6.33G  1.48T  1.07G  /bkup
zroot/home       126G  1.48T   121G  /home
zroot/incoming  43.1G  1.48T  38.4G  /incoming
zroot/mail      49.1G  1.48T  45.3G  /mail
zroot/mailman   2.01G  1.48T  1.66G  /var/lib/mailman
zroot/moin       180M  1.48T   113M  /usr/share/moin
zroot/mysql     21.7G  1.48T  16.1G  /var/lib/mysql
zroot/postgres  9.11G  1.48T  1.06G  /var/lib/postgres
zroot/site       126M  1.48T   125M  /site
zroot/var       17.6G  1.48T  2.97G  legacy

一般的に、これはそれほど忙しいシステムではありません。以下のグラフのピークは、夜間のバックアップです。

IO statistics

スローダウン中（今朝8時頃から）にシステムをキャッチすることができました。一部の操作はかなり応答性がありますが、現在の平均負荷は145であり、zpool listがハングします。グラフ：

/dev/sdb latency

performancehard-drivezfszfsonlinux
8
squidpickles

Arc_meta_usedとarc_meta_limitを見てください。小さなファイルがたくさんあると、RAMのメタデータキャッシュがいっぱいになる可能性があるため、ディスクでファイル情報を確認する必要があり、世界のクロールが遅くなる可能性があります。

Linuxでこれを行う方法がわかりません。私の経験はFreeBSDです。

1
Aaron Tomosky