数か月後の極端なZFSの減速


8

私は汎用サーバーを持っており、メール、DNS、ウェブ、データベース、その他のサービスをいくつかのユーザーに提供しています。

Xeon E3-1275(3.40 GHz、16 GB ECC RAM)を搭載しています。Linuxカーネル4.2.3とZFS-on-Linux 0.6.5.3を実行します。

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

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

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

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

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

奇妙なことに、FreeBSDを実行しているSSDではなく、同じ仕様のハードウェアを使用して、別のマシンでまったく同じ経験をしました。数か月間は問題なく動作しましたが、同じように遅くなりました。

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

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

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

編集:コマンド出力

の出力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統計

スローダウン中にシステムを捕まえました(今朝8時頃に始まります)。一部の操作はかなり応答しますが、負荷平均は現在145でありzpool list、ハングします。グラフ:

/ dev / sdbレイテンシ


提示してくださいzpool listzfs list
ewwhite 2015年

プールは80%近く使用されていますか?問題が発生する可能性があります。
Ryan Babchishin、2015年

Linux上のZFSルート。うーん...あなたは何かチューニングをしましたか?また、断片化に苦しんでいる可能性があります。ZoLのバージョンは何ですか?更新しましたか?
ewwhite 2015年

私が物事を正しく読んでいる場合、zpoolはバージョン28、zfsはバージョン5です。80%に近い(16%に近いなど)ZoLは最新の0.6.5.3です。
カオリンファイア、

SSDがログとして大量に使用されている場合に障害が発生する可能性があることも示唆されましたが、SMARTはそれがうまく機能していると思います。Reallocated_Sector_Ct 0、Wear_Leveling_Countの未加工の値402(および値は88)、エラーなし...
Kaolin Fire

回答:


1

arc_meta_usedおよびarc_meta_limitを確認してください。多数の小さなファイルを使用すると、RAMのメタデータキャッシュをいっぱいにすることができるため、ディスクでファイル情報を確認する必要があり、世界のクロール速度が低下する可能性があります。

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


興味深い。ありがとう!参照用にgithub.com/zfsonlinux/zfs/issues/1261を追加します。chaos root:〜#cat / proc / spl / kstat / zfs / arcstats | grep arc_meta_used arc_meta_used 4 5895985776 chaos root:〜#cat / proc / spl / kstat / zfs / arcstats | grep arc_meta_limit arc_meta_limit 4 6301327872
Fire

ただし、ディスクIOレートを見ると、実際には多くの物理ディスクアクティビティがあるようには見えません。
squidpickles
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.