web-dev-qa-db-ja.com

非常に大きなファイルシステムと高いIOWAITでのパフォーマンス向上のためのオプション

私は、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アセンブリで非常に大量の小さなファイルをどのように処理しますか？

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

ubuntu-16.04ext4performance-tuning
10
t2m

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

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

まず、ボードに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週間後）。

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

0
t2m

RAID6アレイに12x 2TBのディスクを使用し、非常に同じ目的で（rsnapshotバックアップサーバー）使用する、同様の（小さいですが）セットアップがあります。

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

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

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

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

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

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

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

????

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

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

UPD。： LinuxソフトウェアRAID （LSR）RAID-6であることが判明したため、ここに移動します追加アイテム：

  1. LSRには、多くの人が見落としているように見える独自のチューニングオプションがあります

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

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

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

6
poige

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

0
John Keates

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

Ext4は、数百万のファイルがある大きなファイルシステムにはあまり適していません。 [〜＃〜] xfs [〜＃〜]を使用します。私はXFSファイルシステムを1,2 PBまで実行しており、10億ものファイルがあり、問題ありません。 単純にXFSを使用。

0
wazoox