SATA 3.0バックプレーン経由で8x10TB HDDを備えたUbuntu 16.04バックアップサーバーを使用しています。8つのハードディスクはRAID6に組み立てられ、EXT4ファイルシステムが使用されています。このファイルシステムは、非常に多くのSEEK操作を伴う大量の小さなファイルを格納しますが、IOスループットは低くなります。実際、毎日rsnapshotを介してスナップショットを取得するさまざまなサーバーからの多くの小さなファイルがあります（複数のINODESが同じファイルに直接送信されます。ファイルシステム（60TBネット）の使用率が50％を超えているため、パフォーマンスは非常に低くなっています。現在、使用率は75％で、

du -sch /backup-root/

数日かかります！マシンには8つのコアと16GのRAMがあります。RAMはOSファイルシステムキャッシュによって完全に利用され、8つのコアのうち7つはIOWAITのために常にアイドル状態です。

Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          5af205b0-d622-41dd-990e-b4d660c12bd9
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              912203776
Block count:              14595257856
Reserved block count:     0
Free blocks:              4916228709
Free inodes:              793935052
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        768
Flex block group size:    16
Filesystem created:       Wed May 31 21:47:22 2017
Last mount time:          Sat Apr 14 18:48:25 2018
Last write time:          Sat Apr 14 18:48:18 2018
Mount count:              9
Maximum mount count:      -1
Last checked:             Wed May 31 21:47:22 2017
Check interval:           0 (<none>)
Lifetime writes:          152 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       513933330
Default directory hash:   half_md4
Directory Hash Seed:      5e822939-cb86-40b2-85bf-bf5844f82922
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke journal_64bit
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00c0b9d5
Journal start:            30179

この種のファイルシステムの使用経験はありません。これを調整するにはどのようなオプションが必要ですか。このシナリオではどのファイルシステムがより良いパフォーマンスを発揮しますか？OS組み込みのもの以外のキャッシュオプション用にRAMを使用するオプションはありますか？

大規模なRAIDアセンブリで非常に大量の小さなファイルをどのように処理しますか？

ありがとう、セバスチャン

私は似ていますが（よ​​り小さいですが）、同じ目的（rsnapshotバックアップサーバー）に使用されるRAID6アレイの12x 2TBディスクを使用しています。

まず、du -hsこのように大きく、使用されているファイルシステムで非常に時間がかかることは完全に正常です。さらにdu、ハードリンクも考慮に入れられます。これにより、明らかなIO負荷に加えて、かなりのバースト性のあるCPU負荷が発生します。

ファイルシステムのメタデータが非常に離れた（LBA用語で）ブロックに配置されているために多くのシークが発生するため、速度が低下します。通常の7.2K RPMディスクは約100 IOPSを提供するので、すべてのメタデータをロードするのに何日ではなくても何時間が必要かを確認できます。

あなたが（非破壊的に）状況を改善しようとすることができる何か：

• インデックスを作成しないようにしてmlocate/slocateください/backup-root/（プルーン機能を使用して回避できます）。そうしないと、メタデータキャッシュのトラッシングがバックアップ時間を著しく損ないます。
• 同じ理由で、実行しないようduに/backup-root/。必要に応じて、du関心のある特定のサブフォルダでのみ実行します。
• vfs_cache_pressureデフォルト値（100）からより控えめな値（10または20）に下げます。これは、データキャッシュではなくメタデータキャッシュを優先するようにカーネルに指示します。これにより、rsnapshot/rsync検出フェーズが高速化されます。
• たとえば、lvmcacheまたはbcacheを介して、ライトスルーメタデータキャッシングデバイスを追加してみてください。このメタデータデバイスは明らかにSSDである必要があります。
• 使用可能なRAMを増やします。
• ext4を使用しているときは、inode割り当ての問題に注意してください（例については、こちらをお読みください）。これはパフォーマンスとは直接関係ありませんが、extベースのファイルシステムに非常に多くのファイルがある場合は重要な要素です。

あなたが試すことができる他のこと-しかし、これらは破壊的な操作です：

• XFS -ftypeと-finobtオプションセットの両方を使用します。
• Linux（ZoL）でZFSを使用し、ARCとprimarycache=metadata設定を圧縮します（おそらく、読み取り専用キャッシュ用のL2ARC ）。

このファイルシステムは、非常に多くのSEEK操作を伴う大量の小さなファイルを格納しますが、IOスループットは低くなります。

🎉

これは、今日多くの人々を捕まえるものです。悲しいかな、従来のFSはここではうまく拡張できません。すでにお持ちのセットアップに関しては、ほんの少しアドバイスをお伝えします：HDD上のRAID-6上のEXT4：

1. 下げvm.vfs_cache_pressureダウン、それはしたい1に言うバイアスをcacheing変更する多くのメタデータ（iノード、のdentryを）維持に向けてデータの代わりに、それ自体とそれが求めているの数を減らすことでプラスの効果を持っている必要があります
2. RAMを追加します。ピギーアプリを実行していないサーバーでは奇妙に見えるかもしれませんが、覚えておいてください：シークを減らす唯一の方法は、より多くのメタデータをより高速なストレージに保存することです。 RAM容量を増やす
3. 私が言ったように、EXT4はあなたが持っているユースケースには良い選択ではありませんが、それでも痛みを和らげるためにもたらす機能のいくつかを使用することができます：
   • 外部ジャーナルがサポートされているので、SSD（より良いミラーリング）を追加して、そこにジャーナルを配置できます。「ext4：外部ジャーナルの警告」を確認してください
   • ジャーナルモードを「すべてのデータがジャーナルされている」マウントに切り替えてみてください。data=journal
4. 単一のFSスコープ外にファイルを移動してみてください。たとえば、ここにLVM-2がある場合、より小さなサイズのボリュームを作成して一時的に使用し、それがいっぱいになったら別のボリュームを作成することができます。
   • LVM-2がない場合は、/ dev / loopでそれを試すことができますが、それはそれほど便利ではなく、おそらくパフォーマンスが低くなります

UPD。：それはLinuxソフトウェアRAID（LSR）RAID-6であることが判明したので、ここに追加の項目があります：

5. LSRには、多くの人が見落としているように見える独自のチューニングオプションがあります。
   • 最大に設定できるストライプキャッシュ：echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size—ただし、サイズはチャンクサイズの倍数であり、選択したチャンクサイズに応じて異なる量のRAMを使用するため、注意してこれを行ってください（必要に応じて、より小さい値を使用してください）。
   • それらのミラーリングされたSSDにも存在する可能性のある外部ジャーナル（ただし、現在、ジャーナルなしで作成されたMDデバイスは、1つを使用するように変換できません）。

—これはおそらく、ゼロから再設計せずに改善できることのほとんどです。

ファイルシステム（60TBネット）の使用率が50％を超えたため、パフォーマンスが非常に低下しています。現在、使用率は75％です

ディスク領域の占有率が高いと断片化が悪化するだけなので、これは非常に深刻な問題です。そして、断片化が進むほど、シークも増えます。50％に達する前に、多かれ少なかれ許容できるパフォーマンスが得られた理由はもはや不思議ではありません。多くのマニュアルには、FSが75〜80％を超えて成長しないようにする明確な推奨事項があります。

この場合、RAID6はあまり役に立ちません。ZFSのようなものは、速度をほぼ同じに保ちながら、メタデータとディレクトリへのアクセスをはるかに高速にすることができます。

RAID-6はドライブをストライプ化するため、すべてのIOがすべてのドライブに送られます。これは、多くの小さなファイルではかなり非効率的です。しかし、これはおそらくあなたの主な問題ではありません...

Ext4は、何百万ものファイルがある大きなファイルシステムにはあまり適していません。XFSを使用します。XFSファイルシステムを1,2 PBまで実行していて、10億ものファイルを使用しているため、問題ありません。XFSを使用するだけです。

私の質問に答えてくれたすべての人に感謝します。

これは、私がそれをどのように解決したかです：

まず、ボードに最大量のRAMを追加しました。残念ながら、ボードは最大64GBのRAMしかサポートしていません。拡張後の挙動を観察したが、残念だった。使用可能なすべてのRAMがIOキャッシュに使用されましたが、RSNAPSHOT-Backupのパフォーマンスはそれほど向上しませんでした。

だから私は大きなメイスを引っ張らなければなりませんでした。2つの1TB NVMEディスクを追加し、それらをRAID 1に組み立てました。8x10TB HDDで構成されるRAID 6は、1つのRAID 1（2x 10TB HDD、ext4で構成）と1つのRAID 5（6x10TB HDDで構成）に分解されました。RAID 1には、オペレーティングシステムとサーバーの作業用コピー（このドライブに対して1日に4回rsyncされる）が含まれています。

RAID5は、BCACHEでサポートされたデバイスであり、NVME-RAID 1でサポートされ、ext4でフォーマットされています。このドライブには、RSNAPSHOTコピーが含まれています。毎晩、ファイルはRAID1からRAID5にrsyncされます。これにより、作業コピーとバックアップスナップショットを含む以前のRAID6と比較して、RAID5のIOスループットが半分になります。BCacheのおかげで、文字通りすべての単一ファイルがディスクに書き込まれるわけではありませんが、1つのブロック全体のすべての変更が一度に書き込まれます。これにより、HDDのIOpsがさらに減少しました。

最後に、RSnapshot構成を変更しました。以前は、31の日次スナップショットと18の月次スナップショットがあり、49世代のバックアップが生成されました。今、私は古典的な7d / 4w / 12m / 1y-Designを持っています。これはバックアップ世代の量を24に減らします。

これらの変更後（および上記の64GB RAMを使用）、1つのスナップショットの継続時間が約20時間から1.5時間に短縮されました。BCacheデバイスのキャッシュヒット率は82％です（通常の操作から6週間後）。

任務完了。皆様のご意見、ご感想をありがとうございました。