☰

オブナムはどんな活躍を繰り広げると予想されますか？または：なぜそんなに遅いのですか？

tag-icon • tag-icon backup performance
オブナムはどんな活躍を繰り広げると予想されますか？または：なぜそんなに遅いのですか？

私は過去数日間obnamを使用してきましたが、非常に有望に見え、基本的にバックアップツールで必要なすべての機能を提供しているようですが、そのパフォーマンスには非常に失望しました。実際、スピードが遅すぎるので、ここではobnamが間違っているわけではないと思いますが、私の環境の何かが問題を引き起こしています。

だから私は他の人がobnamを使用しているか、問題を識別するのに十分な内部について知っているかどうか疑問に思います。

これまでのところ、私が知っているように、obnamはバックアップされた各ファイルに対して別々のgpgプロセスを作成するようです。 htop、strace、iostatを見ると、最初のバックアップ速度は主に持続的なブランチのために制限されますが、CPUとドライブ（ネットワークには関係ありません）はほとんど使用率が20％未満でアイドル状態です。

私のバックアップには約500,000個のファイルがあり、総データ容量は170GiBです。したがって、バックアップ実行ごとにgpgは500,000回フォークされます。実際、最初の実行にはほぼ1日かかり、2番目の実行にはほとんどのファイルが変更されていない状態で3時間以上かかったという事実も驚くことはありません。しかし、これは本当にobnamユーザーが期待するパフォーマンスですか？比較のために、rsnapshot（同じデータ、同じシステム、同じドライブ）の増分実行には約4分かかります。もちろん、暗号化は必要ありませんが、そうしてはいけません。それ重要。

率直に言えば、他人のコンピュータもgpg（小さなデータ塊暗号化）を毎秒50回以上実行することができず、最終的にobnamをほとんど使用できない遅いツールにするのでしょうか？それとも私だけそうなのだろうか？

（FWIW、私のコンピュータは8G RAMとSSDドライブを搭載したCore i5-2500で、Gentooを実行します。バックアップはHDDで行われますが、SSDのバックアップはI / Oではないため違いはありません。

答え1

以下は、obnamをスピードアップする方法の良い内容です（たぶん10倍速く実行できます）。http://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html

要約：コマンドラインまたは設定ファイルに "--lru-size=1024 --upload-queue-size=512" を追加します。 obnamのメモリ使用量がわずかに増加することに注意してください。

答え2

私はこの問題にいくつかの方法でアクセスすると思いました。まず、次のような方法で直接診断してみましょう。

1.obnamログ

obnamまず、次のメッセージを記録できます。

$ obnam --log obnam.log

スイッチを使用してロギングレベルを上げることで、--log-level詳細を得ることもできます。

--log=FILE          write log entries to FILE (default is to not write log
                    files at all); use "syslog" to log to system log, or
                    "none" to disable logging
--log-level=LEVEL   log at LEVEL, one of debug, info, warning, error,
                    critical, fatal (default: info)

2. 分析

obnam次の抜粋で実行されている作業の概要を確認することもできます。プロジェクトに関するFAQ:

環境変数にファイル名が含まれている場合は、OBNAM_PROFILE分析データがここに保存され、後で以下を使用して表示できます obnam-viewprof。

  $ OBNAM_PROFILE=obnam.prof obnam ... obnam-viewprof obnam.prof | less

特定の設定に関連しないパフォーマンスの問題も使用できますobnam-benchmark tool。

3. 請求書発行

自己調査でパフォーマンスを判断できない場合は、次の手順を実行します。プロジェクトのウェブサイトでチケットを開く。私が知っている限り、開発者は一定のレベルの対応力を持っており、おそらくプロジェクトのトラブルシューティングに最適です。

obnamSFTPだけを使用しているようで、問題の原因は明らかです。またobnam、テスト自体からこの情報を取得しようとする前に、システム+ネットワーク接続の理論上の最大値が何であるかを知るために、SFTPパフォーマンスの基本的な分析を別々に実行することも検討します。

追加データポイント

#1 - obnamとrsnapshotを比較するブログ投稿

著者は、このカテゴリのさまざまなオプションを比較するこのブログ投稿を見つけました。記事のタイトルは次のとおりです。rsnapshotとobnamのスケジュールされた大規模バックアップの比較。

obnamこの記事では、IMOが説明する内容と一致するように見える非常に低いパフォーマンスを強調します。

オナンパフォーマンス

/homeのフルバックアップを実行してから（数日かかります）、数日後に再度実行します（Linux timeコマンドで時間を測定）。

3443706ファイルのバックアップ、127時間48分49秒で94.0GiBアップロード、平均速度214.2KiB / s830ファイル1.24GiB（0B / s）実際の7668m56.628sユーザー4767m16.132sシステム

obnameログファイルから：

   2012-11-17 12:41:34 INFO VFS: baseurl=/home read=0 written=0
   2012-11-21 23:09:36 INFO VFS: baseurl=/backups/backup_home read=2727031576964 written=150015706142 
   2012-11-21 23:09:36 INFO Backup performance statistics: 
   2012-11-21 23:09:36 INFO * files found: 3443706 
   2012-11-21 23:09:36 INFO * uploaded data: 100915247663 bytes (93.9846482715 GiB) 2012-11-21 23:09:36 INFO * duration: 460128.627629s 
   2012-11-21 23:09:36 INFO * average speed: 214.179341663 KiB/s
   2012-11-21 23:09:36 INFO Backup finished. 2012-11-21 23:09:36 INFO Obnam ends
   2012-11-21 23:09:36 INFO obnam version 1.2 ends normally

したがって、約100 GBの変更されたデータのバックアップには約5日かかります。 CPUやRAM側では、マシンの負荷は高くありません。 /backups/backup_homeのディスク使用量は5.7T、/homeは6.6Tなので、いくつかの重複排除があるようです。

スナップショットのパフォーマンス

/homeのフルバックアップ（ログファイルに応じて）：

   [27/Nov/2012:12:55:31] /usr/bin/rsnapshot daily: started   
   [27/Nov/2012:12:55:31] echo 17632 > /var/run/rsnapshot.pid 
   [27/Nov/2012:12:55:31] mkdir -m 0700 -p /backups/backup_home_rsnapshot/    
   [27/Nov/2012:12:55:31] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/ 
   [27/Nov/2012:12:55:31] /usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /home /backups/backup_home_rsnapshot/daily.0/localhost/
   [28/Nov/2012:23:16:16] touch /backups/backup_home_rsnapshot/daily.0/
   [28/Nov/2012:23:16:16] rm -f /var/run/rsnapshot.pid
   [28/Nov/2012:23:16:16] /usr/bin/rsnapshot daily: completed successfully

したがって、6.3TBのフルバックアップには約1.5日かかります。 1日後の増分バックアップには、次のものが必要です。

     [29/Nov/2012:13:10:21] /usr/bin/rsnapshot daily: started
     [29/Nov/2012:13:10:21] echo 20359 > /var/run/rsnapshot.pid
     [29/Nov/2012:13:10:21] mv /backups/backup_home_rsnapshot/daily.0/ /backups/backup_home_rsnapshot/daily.1/
     [29/Nov/2012:13:10:21] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:10:21] /usr/bin/rsync -a --delete --numeric-ids -- relative --delete-excluded --link-dest=/backups/backup_home_rsnapshot/daily.1/localhost/ /home/backups/backup_home_rsnapshot/daily.0/localhost/
     [29/Nov/2012:13:25:09] touch /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:25:09] rm -f /var/run/rsnapshot.pid
     [29/Nov/2012:13:25:09] /usr/bin/rsnapshot daily: completed successfully

つまり、15分...21GBの変更されたデータです。

*オナムのあるロフト

それほど徹底的ではありませんが、言及された欠点の1つobnamはattic。

Aubunanの利点:

  • よく記録された
  • アクティブメーリングリスト
  • 利用可能なパッケージ

オブナンの欠点：

  • 非常に遅い
  • 大規模バックアップ

ロフトの利点：

  • バックアップの規模がはるかに小さい（重複排除なしでも）
  • より良い重複排除
  • はるかに早く

ロフトの欠点：

  • ストレージ形式が文書化されていません。
  • 大規模なユーザーコミュニティではない

表示されたテストデータの一部は、実際obnamに速度が遅いことを示すようです。

通常のWiFi接続を介してローカルSSDからリモートHDへ：

    rsync:           0:24  0:01
    Attic ssh:       0:28  0:05
    Attic sshfs:     0:51  0:08
    Obnam sftp:      8:45  0:21
    Obnam sshfs:    25:22  0:22

引用する

答え3

Obnamのデフォルト設定（2015年2月8日現在）は、多数の小さなファイルを含むディレクトリのバックアップには適していません。上記と同じ問題が発生しました。

私の解決策は、コマンドラインに --lru-size=8192 --upload-queue-size=8192 を追加することでした。これにより、問題が解決し、イライラしたObnamユーザーが非常に幸せなユーザーに変わりました。 （現在、標準プロファイルにはこれらの設定があります。）

残念ながら、Obnamのチュートリアルでは、これらの設定の重要性についてあらかじめ言及していません。 FAQに詳細が記載されています。小さなファイルが多いシステムでは、パフォーマンスパラメータの設定は実際には必須です。

関連情報