obnamの期待されるパフォーマンスはどれくらいですか？または：なぜそんなに遅いのですか？

ここ数日間、obnamをいじってみましたが、非常に有望に見え、基本的にバックアップツールに必要なすべてを提供しているように見えますが、そのパフォーマンスにはかなりがっかりしています。実際、それは非常に遅いので、obnamはここでさえ故障ではないのではないかと疑っていますが、私の環境の何かが原因です。

他の誰かがobnamを使用しているか、問題を特定するのに十分その内部を知っているのかどうか、私は主に疑問に思っています。

私がこれまでに言ったことから、obnamはバックアップされたファイルごとに個別のgpgプロセスをフォークしているようです。htop、strace、およびiostatから判断すると、最初のバックアップの速度は、ほとんど一定のフォークによって制限されますが、CPUとドライブ（ネットワークが関与していない）は、ほとんど使用率が20％未満です。

私のバックアップは約500.000ファイルで、合計で170 GiBのデータです。したがって、バックアップを実行するたびに、gpgは500.000回フォークされます。これが最初の実行にほぼ1日かかり、ほとんどのファイルが変更されていない別の実行に3時間以上かかることは、実際には驚くこともありません。しかし、これは本当にobnamユーザーが期待するパフォーマンスでしょうか？比較のために、rsnapshot（同じデータ、同じマシン、同じドライブ）の増分実行には約4分かかります。もちろん、暗号化は含まれていませんが、それほど重要なことではありません。

だから、はっきりと尋ねると：他のすべての人のマシンは、毎秒50回を超えるgpg（データの小さなチャンクの暗号化）を実行できず、最終的にobnamはほとんど使用できないほど遅いツールになりますか？それとも私だけですか？

（FWIW、私のマシンは、Gentooを実行する8GのRAMとSSDドライブを備えたCore i5-2500です。バックアップはHDDで行われますが、I / Oではないため、SSDへのバックアップに違いはありませんでした。 -バウンド。）

obnamを高速化する方法（10倍高速になる可能性があります）の良い読みは次のとおりです：http : //listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html

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

私はいくつかの方法でこの問題を攻撃すると思います。手始めに、私は以下の方法論を使用して自分で試して診断します。

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.チケットを開く

何らかの自己主導の調査を行ってもパフォーマンスがまだ決定されていない場合は、プロジェクトのWebサイトでチケットをオープンします。開発者を集めることができたことから、開発者はいくぶん反応がよく、彼らは彼らのプロジェクトの問題を根絶するのに最高だろう。

obnamはSFTPのみを使用しているように見えるため、何が問題の原因であるかはかなり明白です。また、obnamテスト自体からこの情報を取得する前に、システム+ネットワーク接続の理論的な最大値を確認できるように、SFTPパフォーマンス自体をベースライン化することも検討します。

追加のデータポイント

著者がこのカテゴリのいくつかのオプションを比較したこのブログ投稿を見つけました。記事のタイトル：スケジュールされた大規模バックアップのrsnapshotとobnamの比較。

この記事では、パフォーマンスが非常に低いIMOを強調しましobnamたが、それはあなたが説明していることとはうまくいきません。

obnamパフォーマンス

/ homeを完全にバックアップした後（数日かかりました！）、数日後の新しい実行（Linuxのtimeコマンドによるタイミング）：

3443706ファイルのバックアップ、94.0 GiBを127h48m49s、214.2 KiB /秒の平均速度でアップロード830ファイル。1.24 GiB（0 B /秒）実際の7668m56.628sユーザー4767m16.132s sys 162m48.739s

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だったため、重複があったようです。

rsnapshotパフォーマンス

/ 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.3 TBの完全バックアップの場合、最大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です。

Obnamの長所：

• 十分に文書化された
• アクティブなメーリングリスト
• 利用可能なパッケージ

Obnamの短所：

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

屋根裏のプロ：

• はるかに小さいバックアップ（重複排除なしでも）
• はるかに優れた重複除外
• はるかに高速

屋根裏の短所：

• 文書化されていないリポジトリ形式
• 大規模なユーザーコミュニティではない

一部のテストデータが表示されていますが、これはobnam本当に遅いことを示しているようです。

ローカルSSDからリモートHDへ、まあまあのwifi接続で：

    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

参考文献

• Obnam微調整のブログ投稿

Obnamのデフォルト設定（2015-02-08現在）は、多数の小さなファイルを含むディレクトリのバックアップには適していません。上記と全く同じ問題がありました。

私にとっての解決策は、コマンドラインに--lru-size = 8192 --upload-queue-size = 8192を追加することでした。これで問題が解決し、イライラしたユーザーは非常に満足のいくObnamユーザーになりました。（現在、これらの設定は私の標準構成ファイルにあります。）

残念なことに、Obnamのチュートリアルでは、これらの設定がいかに重要であるかを事前に述べていません。FAQに詳細が記載されています。小さなファイルが多数あるシステムでは、パフォーマンスパラメータの設定は本当に必須です。