バックアップのメインストレージ用にハードウェアRAID5を備えたBackupPCサーバーを実行しています。マシンはわずかな予算で作成されたため、コントローラーはPCIポート用の3Ware 9500S-4LPであり、ドライブは低速の200 GBSATAタイプです。
ただし、このハードウェアを使用しても、予想よりもはるかにパフォーマンスが低下します。クライアントとバックアップサーバーは、ギガビットネットワークを介したトランスポートとしてrsyncを使用しますが、これは飽和状態に近づくことはありません。約5GBの通常のLinuxインストールのバックアップには3時間以上かかります。
そこで、atop
プロセスモニターを使用してサーバーを監視しました。プロセッサもメモリの使用も重要ではないことが示されましたが、RAIDへの読み取りアクセスがボトルネックです。
サーバーを構築したとき、RAID 5を選択しました。これは、 RAID特性のこの表形式の概要 によると、4ポートコントローラーでの読み取りパフォーマンスとスペース効率の間の最良の妥協点のように思われたためです。
ちなみに、これはバックアップサーバーですが、rsyncを使用すると、ここでの書き込みよりも読み取りがはるかに多くなります。現在、約1000倍です。 BackupPCの古いバックアップの階層で古いファイルを移動してリンクすることも、これに大きく貢献していると思います。
では、このマシンのパフォーマンスをどのように最適化しますか?私は次の調整可能なものを持っています:
ここに短い小さなランダムがありますIO入門書:7200RPMディスクドライブは約100IOPSを実行します。15kRPMドライブはその2倍の約200IOPSです。RAID-5アレイでは、達成可能な最高のIOPSは数値です。データデータドライブの時間はシングルドライブのパフォーマンスです。3つのデータドライブがあるため、これまでに得られる最高の持続値は300IOPSです。
使用する iostat -mx 5
バックアップの実行中。 300の範囲に多数の読み取りまたは書き込み操作(3列目と4列目)が表示される場合は、基本的にセットアップを最大限に活用しています。
注:最新のSSDドライブのほとんどは20000IOPSを達成しています。 RAID-1のSSDのペアは、ラックを回転でいっぱいにすることができますRust恥ずべきことです。SSDはすべてを変えます。IOPSの問題に直面した場合、99%の確率でソリューションは「SSD」と呼ばれます。 。
現在RAIDアレイ出力を最大にしていない場合は、次のことができます。
キューの深さを拡張します。標準のカーネルキューの深さは、キャッシュが小さい古い単一ドライブでは問題ありませんが、最新のドライブやRAIDアレイでは問題ありません。
エコー512>/sys/block/sda/queue/nr_requests
別のIOスケジューラーを試してください。CFQ(最新のカーネルのデフォルトのスケジューラー)は、サーバー操作に失敗することがよくあります。
echo'noop '>/sys/block/sda/queue/scheduler
rAID-10を試してください。 RAID-10は、書き込みをまとめて折りたたむ必要がなく、シングルスレッド操作ではRAID-5よりも優れています。
まず、レイドのパフォーマンスをローカルでベンチマークして、それが本当にレイドの問題であるかどうかを確認します。あなたも使用することができます:
dd if=/dev/zero of=/your/raid/zerofile bs=16M
そして約10秒後
killall -SIGUSR1 dd
別の端末でローカル書き込み速度を確認します。速度が十分に良い場合は、他のネットワーク方法を試してください(最初にnetcatで試してください(最初のコマンドのマニュアルページを確認してください。一部のdistosでは「-p」フラグは必要ありません)
pc 1: nc -l -p 12345 > /your/raid/file
pc 2: cat /some/big/file | nc ip.of.pc.1 12345
Sshを介したrsyncの速度が遅いという問題がありました(ギガビットリンクでは12〜15MBpsですが、比較的遅いPCでは)。
問題がディスクにあるのか、rsync/ssh速度にあるのかがわかったら、デバッグを続行できます。
BackupPCは非常にI/Oを集中的に使用するプログラムであり、大量のディスクシークを引き起こす可能性があります。ローエンドのハードウェアでは、できることはたくさんありますが、次のことを試してください。
BackupPC自体の最適化
同時バックアップと管理操作の最大数は、BackupPCのパフォーマンスに大きな影響を及ぼします。これを高く設定しすぎると、ローエンドのハードウェア(または高価なハードウェアでさえ...)が停止します。設定が低すぎると、ハードウェア機能を最大限に活用できません。コモディティハードウェアを使用して、2〜6の同時バックアップを試して、何が効果的かを確認してください。
不要な場合は、BackupPCプールの圧縮を無効にします。
BackupPC Perlrsyncライブラリがrsyncv3.xを完全に利用していない場合でも、rsyncv3.xが使用されていることを確認してください。
最適化サーバー
正しいI/Oエレベーターを選択していることを確認してください。 RAIDと多くの同意がある場合、デフォルトのcfq
はくだらない選択になる可能性があります。ほとんどの場合、RAIDコントローラーは物事をよく知っており、noop
が適切である可能性があります。特定のワークロードと安価なRAIDコントローラーを使用すると、deadline
も適切な場合があります。
ファイルシステムを変更したくないことは承知していますが、XFS
はBackupPCで優れていることがわかりました。 (警告:私の場合のハードウェアはかなり良いです)
あなたがそれに十分なRAMを与えるならば、BackupPCはあなたを愛しています。サーバーのRAM)はどれくらいですか?サーバーがほとんどのディレクトリ構造をメモリに保持できる場合、BackupPCが行う読み取り操作は、必要がなければはるかに高速になります。物理的なプラッターを打つ。
私があなたなら、最初にサーバーをアップグレードしますRAMそしてBackupPC設定もチェックします。それでも十分に役に立たない場合は、ファイルシステムとRAID設定をいじくりまわします。
したがって、ランダム読み取りのパフォーマンスが問題であると思われます。その解決策は、より優れたIOPS(SSD、より高い回転速度のHDD、またはより多くのスピンドルを備えたRAID)を備えたストレージを取得することです。ワーキングセット(iノードキャッシュ)がメモリに収まる場合は、さらにRAM(キャッシュ)も役立ちます。
1つは、これが当てはまることを確認することです。 dstat出力とiotop出力を見てください。また、backuppcのファイルシステムがrelatimeまたはnoatimeでマウントされていることを確認して、すべてのファイルアクセスが書き込みに変換されないようにします。