Restic: 復元はさらに高速になる可能性があります

160メガビット/秒は確かに遅く見えます。 私は、onedriveから1Gbps ftth接続を介してダウンロードする小さなmacbookproで200Mbpsに近づいていました。 システムとリポジトリにアクセスしないと、具体的なことは何も言えませんが、問題を特定の順序で絞り込むために実行したいことがいくつかあります。

• シングルスレッドでシングルパックファイルをダウンロードするのにかかる時間を見積もります。 これはrclone32xダウンロードテストから計算できますが、httpリクエストのオーバーヘッドも見積もることができるように、curlを使用して個々のパックをダウンロードする時間を知りたいと思います。
• 復元中にS3から実際にダウンロードされるresticの量をOSの統計情報で確認します。 これにより、復元によって個々のパックファイルが複数回ダウンロードされるかどうかがわかります（これは可能ですが、何かを見落としている場合を除いて、それほど頻繁には発生しないはずです）。
• S3の同時実行レベルは5接続に制限されているようです。 これは、上からのシングルスレッド速度の見積もりで見られる復元速度を説明できますか？ S3バックエンドの接続制限を復元者の制限と一致するように増やすとどうなりますか？
• 復元中のネットワーク使用率をグラフ化して、ギャップや速度低下がないかどうかを確認します。
• その364GBファイルを復元から除外し、何が起こるかを確認します。 現在、個々のファイルは順番に復元されるため、この1つのファイルは平均ダウンロード速度を大幅に歪める可能性があります。

やあ！

返信いただきありがとうございます。 これは掘り下げるのが面白かった

tl; dr：s3接続を増やすことが重要ですが、それが提供するパフォーマンスの向上は、奇妙なことに一時的なものです。

1. 単一ディレクトリに相当するパック（合計13GBの3062ファイル）/ rclone --transfers 1の転送は、233メガビット/秒で実行されます。 lsofを使用して、そのモードで単一のスレッドと単一のhttps接続でのみ実行されていることを確認しました。 ピーク速度は--transfers32（8.5 gbit / sec、基本的にこのi3.8xlarge ec2インスタンスの回線速度）で達成されます。 どちらの場合も、ストライプのnvme配列に書き出しています。
2. いくつかの統計を収集できてうれしいですが、具体的には何を見たいですか？ （ただし、必須ではない場合があります。以下を参照してください）
3. ここで一石二鳥！ 復元中のネットワーク使用率のグラフは次

• このPRがマージされた株式ストック（コミットc0572ca15f946c622d9c4009347dc4d6c31cba4c）
• workerCountが32にバンプされ、filesWriterCountが128にバンプされたrestic
• 以前の変更に加えて、s3接続が32に増加しました。
• 以前の変更を加えたresitc + s3接続が64に増加しました。
• --transfers 32を使用したrcloneは、データ/ディレクトリを移動します

帯域幅の数値はkbps単位であり、3秒間隔で10分間にわたって取得されました。 Resticの実行では、resticが実際にファイルの復元を開始した後のデータの収集を開始しました（つまり、起動時間と、実行の開始時にディレクトリ階層を再作成するためにresticが費やした時間を除外します。すべての実行中、インスタンスは25％を超えませんでした。

workerCountを増やすことでわずかなバンプが発生しますが、S3の同時実行性は実際の勝利のように見えます。 しかし、最初は強力ですが（rcloneの速度に近づくこともあります！）、レートは急激に低下し、残りの実行の間は低下し続けます。 また、resticは、「[パス編集済み]のエラーを無視します：十分なキャッシュ容量がありません：要求された2148380、利用可能な872640」のようなエラーをスローしますが、s3の同時実行性が低くてもスローされません。

ご覧のとおり、rcloneのパフォーマンスは高く開始され、高いままであるため、書き込みがインスタンスのバッファキャッシュに送られ、ディスクにフラッシュされたときに停止する状況ではありません。 nvmeアレイは、スループットの点でネットワークパイプよりも高速です。

1. 復元中にディスク/ネットワークIOを測定しているので、単一の大きなファイルが要因であるとは思わないので、その単一のファイルが完全に復元されるまでに時間がかかる可能性があるという事実は、私たちの数に影響を与えませんここを見ています。

上記を考えると、S3の同時実行性を上げることは、ここで妥当なレートを取得するために必要なことのように見えますが、パフォーマンスが低下している理由（およびそれがキャッシュエラーに関連しているかどうか）を理解する必要があります。

高速なi3インスタンスと、テストに使用できるs3スペースと帯域幅を作成することが役立つ場合は、お知らせください。スポンサーになります。

1. 233mbit / sec x 32は7456であり、8.5 gbit / secよりかなり小さいです。 これは奇妙です。 シングルスレッドのダウンロードは、マルチスレッドのダウンロードのストリームごとのスループットよりも高速であると期待していました。 ただし、これが何を意味するのかはわかりません。

2. 私は、resticが同じパックを何度も再ダウンロードしないことを確認しようとしていました。 グラフは再ダウンロードが問題ではないことを示していると思うので、少なくとも今は、これ以上の統計は必要ありません。

3. グラフの目盛りを確認できますか？ rcloneは、「1000000 kbps」というラベルの付いた行の周りをホバリングします。これは、「1gbps」を意味し、前述の「8.5gbit / sec」の数値と一致しないと思います。

4. 私が言ったように、個々のファイルは順番に復元されます。 233mbit / sでの364GBのダウンロードには約3.5時間かかりますが、パックごとのオーバーヘッドと復号化のために、おそらくそれより長くかかります。これらはすべて順番に行われます。 3.5時間は、残りの復元にかか​​る時間を知らなければ、取るに足らないものとして破棄できるものかどうかわかりません。

not enough cache capacityエラーについては、 averagePackSizeをリポジトリ内の最大のパックファイルのサイズに増やします（それはどれくらいの大きさですか？）そして、キャッシュのサイズをより適切に設定する方法を考える必要があります。準備ができていません。まだ答えます。

やあ！

おっと、ごめんなさい。 グラフのスケールは、キロビット/秒ではなくキロバイト/秒です。 したがって、最初の行の1,012,995は8.1ギガビット/秒です。

ファイルが順番に復元されることは理解しましたが、単一のファイルのパック取得に並列性がないことを理解していませんでした。 それが制限要因になるので、それは間違いなく大きなファイルを含むバックアップのちょっとした障害です。 そのため、ここに並列処理があると便利です。

10個のランダムバケットをサンプリングすると、最大パックサイズは12MBをわずかに下回り、平均パックサイズは4.3MBです。

おそらく、より多くのワーカーとS3接続があるため、packCacheCapacity（workerCount + 5）* averagePackSizeを超えています。 それを上げて、エラーがなくなるかどうかを確認します。

おそらく、より多くのワーカーとS3接続があるため、packCacheCapacity（workerCount + 5）* averagePackSizeを超えています。 それを上げて、エラーがなくなるかどうかを確認します。

キャッシュサイズは、5MBのパックファイルサイズとworkerCount基づいて計算されます。 workerCount増やすと、キャッシュサイズが増えます。 したがって、メモリリークが発生するか、復元で12MBのファイルを偶然にキャッシュする必要があります。 averagePackSizeを12MBに増やすと、どちらかがわかります。

averagePackSizeを12に設定すると、キャッシュエラーは発生しません。

私たちが提供できる他の役立つ情報があれば、私に知らせてください！ 再度、感謝します。

復元が進むにつれて並列処理が失われているように見え、大きなファイルに関連しているようには見えません。 テストケースをまとめて報告します。

やあ！

3つの異なる人工ファイルミックスを使用して、プロダクションファイルミックスで見られたパフォーマンスの低下を再現しようとしました。

すべてのテストで、c0572ca15f946c622d9c4009347dc4d6c31cba4cを使用し、S3接続を128に増やし、workerCountを128に増やし、filesWriterCountを128に増やし、averagePackSizeを12 * 1024 * 1024に増やしました。

すべてのテストでは、重複排除による影響を回避するために、ランダムデータを含むファイルを使用しました。

最初のテストでは、4,000個の100MBファイルを作成してバックアップし、100個のディレクトリに均等に分割しました（合計で最大400GB）。 バックアップと復元は、i3.8xlargeインスタンスのストライプされたnvmeボリュームから実行されました。 バックアップバケットは、インスタンス（us-west-1）と同じリージョンにありました。

このファイルミックスでは、平均速度が9.7ギガビ​​ット/秒（！）であり、完全な復元全体で並列処理や速度が失われることはありませんでした。 これらの数値はrcloneの数値と同等かそれ以上であり、基本的に回線速度であり、これは素晴らしいことです。

その後、400,000個の1MBファイルを作成してバックアップし、100個のディレクトリに均等に分割しました（ここでも、合計で最大400GB）。

上記と同じ（優れた）結果。

最後に、ディレクトリごとに1つの10GBファイルで40のディレクトリを作成しました。 ここで、物事は面白くなりました。

ResticはS3への40の接続で40の同時復元しか実行できないため、この復元は少し遅くなると予想しました。

代わりに、Resticは書き込み用に40ファイルすべてを開き、40ファイルすべてに同時に書き込みますが、S3へのTCP接続は40ではなく、一度に1つだけ開いたままにします。

見たい統計や計装を教えてください。

「高速」テスト中に128のS3接続があったことを確認できますか？

はい、ありました。

好奇心が強い...正直なところ、ラージファイルサポートは私の優先リストの上位にはありませんが、今後数週間でこれを検討する時間が見つかるかもしれません。 私がする前に誰かがこれを掘り下げたいと思うなら、私に知らせてください。

さらにテストを行いましたが、実際にはファイルサイズが赤ニシンのように見えます。これは、AWS接続数を促進しているのはファイル数です。

4つのディレクトリに128個の10MBファイルがあるため、resticは128個のファイルすべてに書き込みを行っている場合でも、AWSへの接続を6個しか開きません。

4つのディレクトリに512個の10MBファイルがある場合、一度に128個のファイルが開いていても、resticはその存続期間中に18個の接続を開きます。

4つのディレクトリに5,120個の10MBファイルがあるため、resticはその存続期間中にAWSへの接続を75個だけ開き、一度に128個のファイルを開いたままにします。

奇数！

Go S3クライアントがhttp接続をプールして再利用しなかったとしたら、私は本当に驚きます。 ほとんどの場合、同時ワーカーの数と開いているTCPソケットの間に1対1の相関関係はありません。 そのため、たとえば、何らかの理由でダウンロードしたパックの処理が復元で遅い場合、同じS3接続が複数のワーカーによって共有されます。

現在の同時復元機能には、実装の複雑さの大部分を担い、ここで報告されている速度低下の原因となる可能性が非常に高い2つのプロパティがあります。

• 個々のファイルは最初から最後まで復元されます
• 進行中のファイルの数は最小限に抑えられます

ファイルBLOBを任意の順序で書き込み、進行中のファイルをいくつでも許可することに同意した場合、実装ははるかに簡単になり、使用するメモリが少なくなり、多くの場合、高速になります。

欠点は、復元が終了するまで、特定のファイルですでに復元されたデータの量を知ることができないことです。 これは、特に復元がクラッシュしたり、強制終了されたりした場合に、混乱を招く可能性があります。 したがって、ファイルシステムに10GBのファイルが表示される場合がありますが、実際にはファイルの最後に数バイトしか書き込まれていません。

@ fd0現在の最初から最後までの復元を改善する価値があると思いますか？ 個人的には、それが私の側のエンジニアリングを超えていたことを認める準備ができており、同意すれば、より単純な順不同の実装を提供できます。

Resticが標準出力への復元をサポートしているかどうかは覚えていません。 もしそうなら、あなたは明らかにそれのために最初から最後までの復元を維持する必要があるでしょう（おそらく特別な場合として）。

@ifedorenko私は個人的に、特にパフォーマンスの向上が伴う場合は、単純化に賛成です。 ただし、トレードオフを理解しようとしています。

欠点は、復元が終了するまで、特定のファイルですでに復元されたデータの量を知ることができないことです。

ここで同時に書き込まれる何千ものファイルについて話していない場合は、ファイル名から書き込まれたバイトへのマップを使用できますか？ 明らかに、ファイルシステムで情報を利用できるようにすることはありませんが、進捗状況を報告するために、それでも実行できますか？ （そして、中断された復元を再開するには、おそらくファイルのblobとオフセットをチェックしてnull以外のバイトがないかどうかを確認しますか？私にはわかりません。）

Resticが標準出力への復元をサポートしているかどうかは覚えていません。 もしそうなら、あなたは明らかにそれのために最初から最後までの復元を維持する必要があるでしょう（おそらく特別な場合として）。

とにかくそれがどのように機能するかはわかりません。復元は複数のファイルであるため、何らかの方法でそれらをエンコードし、何らかの方法で分離する必要があると思います。

ここで同時に書き込まれる何千ものファイルについて話していない場合は、ファイル名から書き込まれたバイトへのマップを使用できますか？

最も簡単な実装は、ファイルを開いたり閉じたりして、個々のBLOBを書き込むことです。 これが遅すぎることが判明した場合は、たとえば、開いているファイルハンドルをキャッシュし、すでに開いているファイルを優先するようにパックのダウンロードを注文するなどして、複数のBLOB書き込みに対してファイルを開いたままにする方法を見つける必要があります。

Restoreは、どのBLOBがどのファイルに書き込まれ、何がまだ保留中であるかをすでに追跡しています。 この部分が大きく変わることはないと思います。 進捗状況は別のデータ構造で追跡され、それも変わるとは思わない。

そして、中断された復元を再開するには、おそらくファイルのblobとオフセットでnull以外のバイトをチェックするだけですか？

Resumeは、ディスク上のファイルのチェックサムを確認して、どのblobをまだ復元する必要があるかを判断する必要があります。 これは、復元がシーケンシャルであるか順不同であるかに関係なく当てはまると思います。 たとえば、レジ​​ュームが停電から回復した場合、停電前にすべてのファイルブロックがディスクにフラッシュされたとは考えられません。つまり、ファイルにギャップや部分的に書き込まれたブロックが含まれている可能性があります。

@pmkaneは＃2101を試すことができるかどうか疑問に思いますか？ 個々のファイルへの書き込みは引き続きシリアル化されており、大きなファイルの復元パフォーマンスは依然として最適ではない可能性がありますが、順不同の復元を実装します。 以前と同じようにワーカーの数を微調整する必要があります。

絶対。 私は今週旅行していますが、できるだけ早くテストして報告します。

@ifedorenkoこのPRを試したところ、ディレクトリ構造が正常に作成されましたが、すべてのファイルの復元が次のようなエラーで失敗します。

ロード（、3172070、0）エラーが返され、12.182749645s後に再試行しました：EOF

マスターは正常に復元します。

私の復元コマンドは次のとおりです。

/usr/local/bin/restic.outoforder -r s3：s3.amazonaws.com/ [編集済み] -p /root/.restic_pass restore [snapshotid] -t。

デバッグに役立つ追加情報を教えてください。

いくつの同時S3ダウンロードリクエストを許可しますか？ 128の場合、32に制限できますか（動作することがわかっています）。

半関連...実際のリポジトリにインデックスファイルがいくつあるか知っていますか？ メモリ復元に必要な量を見積もろうとしています。

接続制限を指定しなかったので、デフォルトで5に設定されていたと思います。

-o s3.connections = 2および-os3.connections = 1でも同じエラーが発生します。

現在、index /フォルダーに85個のインデックスBLOBがあります。 合計サイズは745MBです。

うーん。 今日の後半に自分のコンピューターにたどり着いたときに、別の見方をします。 ところで、「返されたエラー、再試行」は警告であり、エラーではないため、復元の失敗に関連している可能性があります。または、単なる赤いニシンである可能性があります。

どのようにそれを見逃したのかわかりません...ほとんどの場合、復元者はバックエンドからすべてのパックファイルを完全に読み取っていませんでした。 今すぐ修正する必要があります。 @pmkaneもう一度テストを試すことができますか？

ぐるぐる回します！

この修正により、ファイルが正常に復元されることを確認しました。 今すぐパフォーマンスをテストしています。

残念ながら、マスターよりも遅いようです。 すべてのテストは、上記のi3.8xlargeインスタンスで実行されます。

workerCountが8（デフォルト）の場合、アウトオブオーダーブランチは86mbit /秒で復元されました。

workerCountが32にバンプされたため、少し良くなりました。平均で160mbit /秒です。

このブランチのCPU使用率は、マスターの場合よりも大幅に高くなりますが、どちらの場合もインスタンスのCPUを最大化することはありません。

ちなみに、復元UIは、どこかでロックを求めてそれ自体と競合しているように、何かが「くっついている」ように見えます。

複製する詳細、プロファイリング、またはテストインスタンスを喜んで提供します。

確認のために、restorerとs3バックエンドワーカーの数を32に設定しましたね。

あなたが観察した行動を説明するかもしれないいくつかの考え：

• 個々のファイルへの書き込みは引き続きシリアル化されます。 私はこれは高速のターゲットファイルシステムでは問題にならないだろうと_推測_しましたが、測定したことはありませんでした。
• 各blobの周囲でファイルを開いたり閉じたりすると、復元機能のオーバーヘッドが確実に発生します。 macosでこれを測定したところ、約70秒で「ファイルを開く; 1バイトを書き込む;ファイルを閉じる」ことができました。これは、100Kのblobを書き込むオーバーヘッドとほぼ同じです。 テストは非常に単純で、実際のオーバーヘッドは大幅に高くなる可能性があります。
• 現在、CPU使用率が高いことについてのもっともらしい説明はありません。 アウトオブオーダー実装は、各BLOBを1回だけ復号化し（マスターは各ターゲットファイルのBLOBを復号化します）、マスターと比較して簿記がはるかに少なくなります。 たぶん、「スパース」ファイルの書き込みは実際にはスパースではなく、GoまたはOSがCPUに負荷のかかる処理を実行する必要があります。 本当にわからない。

ちょっと、そこ！

それは正しい。 どちらの場合も、internal / restorer / filerestorer.goでworkerCountが8または32に設定され、-o s3.connections = 32がresticcliを介して渡されました。

これは、アウトオブオーダーブランチが8人のワーカーでファイルを復元している間のトレースデータのトップレベルのビューです。

作業者が頻繁にヒットする重大な（> 500-1000ms）一時停止があるようです。

私はこれにもう少し時間を費やすことに決め、4KiBブロックで10GiBのランダムバイトを生成する単純なスタンドアロンテストを書くことから始めました。 私の目標は、システムがバイトを移動できる速度を評価することでした。 驚いたことに、このテストは私のmacbook pro（2018、2.6 GHz Intel Core i7）で実行するのに18.64秒かかりました。 これは、約4.29ギガビット/秒、つまり10Gイーサネットの約半分に相当します。 そして、これは暗号またはネットまたはディスクI / Oなしです。 そして、私はXoshiro256 ** prngを使用していましたが、 math/randは約2倍遅く、もちろん完全に問題を超えています。 重要なのは、復元者は10Gネットワ​​ークを飽和させるために、複数のスレッドでBLOBを処理する必要があるということです。マルチスレッドのネットI / Oだけでは十分ではありません。

そして、楽しみのために、同等のrust implは3.1秒で10GiBのランダムバイトを生成し、10.77秒でjavaを生成します。 図を見てください:-)

面白いテスト！

現在、resticは、最大のファイルを復元するのにかかる時間によってレート制限されることを理解しています。

ただし、現時点では、これはブロッカーではありません。resticは、ここに表示されている160メガビット/秒よりもはるかに高速に単一のファイルを復元できることを知っています。

高速SSDとS3で10MBのファイルで構成される100GBのテストリポジトリをまとめ、いくつかの数値を実行して、マスターとこのブランチで現在のベストケースシナリオを取得します。

みなさん、こんにちは。パラメータを使用してワーカーの数を変更する方法はありますか、それともコードで直接実行する必要がありますか？ 復元が遅いという問題もあります。どうにかして改善したいと思います...この部分の改善に役立つテストに貢献できるかどうか教えてください。

ありがとう！

@robvalcaどのバックエンドを使用していますか？ rcloneはどのくらいの速さでリポジトリをターゲットシステムにコピーしますか？ Resticの復元速度とは何ですか？

現在、何が起こっているのかわからないので、問題をローカルで再現するために使用できるテストリポジトリと手順を提供できれば非常に便利です（「テストリポジトリ」とは、プライベートではなく、ジャンク/ランダムデータを意味します）。データをお願いします）。

@ifedorenko S3（ceph + radosgw）をバックエンド（私たちが管理）として使用しています。 rcloneを使用してリポジトリをコピーしようとしましたが、結果は次のとおりです。

rclone copy -P remote：cboxback-aabbcc / / var / tmp / restic / aabbcc /
転送済み：127.309G / 127.309 Gバイト、100％、45.419 Mバイト/秒、ETA 0
エラー：0
チェック：0/0、-
転送：25435 / 25435、100％
経過時間：47分50.2秒

「ストック」restic0.9.4を使用したリポジトリの復元には、約8時間かかりました。 どちらの場合も、32個のS3接続と同じターゲットホストを使用しています。 このフォーラムスレッドにもう少し情報を載せました。

テスト用のレポを準備し、準備ができたらお知らせします。
どうもありがとうございました！

@robvalca out-order-restoreブランチを使用して復元を試すことができますか？ ブランチは非常に大きなファイルの復元パフォーマンスを改善することになっていますが、これはあなたが直面している問題のようです。

ブランチで復元のパフォーマンスが向上しない場合は、テストリポジトリをパブリックs3バケットにアップロードし、バケット名とリポジトリパスワードをここに投稿してください。

@pmkane多数の同一またはほぼ同一のファイルを復元することは可能ですか？ それは労働者間の論争を説明するだろうと私は思います。

編集：実際、最新の＃2101を使用して復元パフォーマンステストを再試行できますか？ 同じファイルへの同時書き込みと複数のファイルへの同じBLOBをより適切に処理できるようになりました。

@ifedorenkoは確かに、アウトオーダーバージョンではるかに優れています！ 所要時間は1時間未満で、これはrcloneで得たものに近いものです。 私のテストから抽出できるいくつかのコメントは、usefuを見つけることができるかもしれません（添付のプロットも参照してください！）：

• 通常のrestic 0.9.4では、プロセスはより速く開始され、ピークは200MB/sec 、S3側では毎秒ほぼ50 requests取得しています。 ほんの数分後、劣化が発生し、リクエストは1程度に低下し、残りのプロセスでは速度が約5MB/secになります。
• 「ooo」バージョンでは、転送速度は40MB/secようなものであり、〜 8 S3リクエストはすべてのプロセスで安定しています。
• 私が気付いたもう一つのことは、S3接続を増やすことでほとんど改善が見られないということです、これは予想されますか？

32接続：

Created 2197 directories, listed 171.141 GiB in 20930 files
Restored 171.136 GiB in 170258 files

real    57m54.588s
user    229m25.229s
sys 6m51.763s

64接続

real    53m13.876s
user    242m57.081s
sys 7m12.455s

• 最後に、別の異なるリポジトリ（51G、1.3Mの小さなファイル、多数の重複）を使用してテストを行いましたが、それでも0.9.4よりもかなり高速です。

0.9.4

real    16m6.966s
user    25m4.116s
sys 4m19.424s

0.9.4-ooo：

real    8m14.375s
user    14m30.107s
sys 3m41.538s

つまり、大きなファイルで改善するだけでなく、すべてのケースを改善します!!

そしてところで、復元の新しい進行状況ビューは素晴らしいです！ 8）

他のテストをしてほしい場合はお知らせください。

ありがとう！

フィードバックをありがとう、 @ robvalca 、それは非常に便利です。

• 私が気付いたもう一つのことは、S3接続を増やすことでほとんど改善が見られないということです、これは予想されますか？

申し訳ありませんが、同時復元ワーカーの数を増やすにはコードを変更する必要があることを忘れてしまいました。 現在、8にハードコードされています。
https://github.com/ifedorenko/restic/blob/099f51c01c189a84b96be86ce6be61a45e3705fc/internal/restorer/filerestorer.go#L22

他のテストをしてほしい場合はお知らせください。

この問題https://github.com/restic/restic/issues/2074#issuecomment-443759511で前述した、順不同の復元中に明らかなワーカーの競合を引き起こしている原因はまだわかりません。 この特定のコミットをテストできますか
https://github.com/ifedorenko/restic/commit/d410668ce3a8c7284d86a2b06bf42a0e654d43bc？ リポジトリとの競合を観察した場合、それはpmkaneのデータに固有のものではなく、最近の変更で競合が修正されたことを意味します。

よろしくお願いします。

みなさん、こんにちは。まだこれを監視していますが、完全に圧倒されています。 私は今週末に追いつき、 ifedorenko @ d410668でまだ再現できるかどうかを

@ifedorenkoありがとうございます。32人のワーカーがいるため、プロセスは30分まではるかに速くなり、すばらしい結果になります。 また、workers /s3.connectionsを64 / 64、128 / 128に増やしてみましたが、改善が見られず、ほぼ同じ結果が得られました。 とにかく、私は現在の結果に満足しています。

私はあなたが私を指摘したhttps://github.com/ifedorenko/restic/commit/d410668のバージョンも試しました。これがトレースのスクリーンショットです。 私はこの種のツールの経験はあまりありませんが、 @ pmkaneの結果に似ているようです。 私は8人の労働者と-o s3.connections=32それを実行しました

@robvalcaなので、 ifedorenko @ d410668は、ブランチのヘッドに比べて大幅に遅くなりましたね。 これは朗報です。つまり、すべての既知の問題に対処した可能性があります。 更新していただきありがとうございます。

@ifedorenkoいいえ、言及するのを忘れました。パフォーマンスは、同じ数のワーカー（8）とS3.connections（32）を持つブランチのヘッド（順不同）とほぼ同じです。 両方とも約55mかかりました。これは、リポジトリをrcloneで転送する時間（〜47m）と一致しています。

他のパラメータでテストしたい場合はお知らせください;）

ユースケースでパフォーマンスの問題のトリガーを見つけました。 大きなファイルの復元パフォーマンスは、特定のファイルサイズを超えると非線形になります。

テストするために、S3で新しいリポジトリを作成し、ランダムデータを含む6つのファイルをリポジトリにバックアップしました。 ファイルのサイズは1、5、10、20、40、80GBでした。

以前のテストと同様に、テストはi3.8xlargeインスタンスで実行され、バックアップと復元は高速のストライプSSDで行われました。

予想どおり、バックアップ時間は直線的でした（8、25、46、92、177、および345秒）。

ただし、復元時間は次のとおりではありませんでした。

1GB、5秒
5 GB、17秒
10 GB、33秒
20 GB、85秒
40 GB、256秒
80 GB、807秒

そのため、大きなファイルと復元のパフォーマンスで何か奇妙なことが起こっています。

バケットの名前はpmk-large-restic-testで、バケットとその内容は公開されています。 それはus-west-1にあり、resticリポジトリのパスワードはpasswordです

ファイルのスナップショットIDは次のとおりです。

1GB：0154ae25
5GB：3013e883
10GB：7463efa8
20GB：292650c6
40GB：5acb4bee
80GB：d1b7e323

提供できるデータが他にもあるかどうか教えてください。

@pmkane https://github.com/ifedorenko/restic/tree/out-order-restoreブランチの最新のヘッドを使用したことを確認できますか（具体的にはhttps://github.com/ifedorenko/restic/commit/ead78b375f2efed6de57c99b6766edbe9322e009） ？

はい、しました。 それについて言及しなくてすみません。

（ead78b3を使用したすべての実行で32のワーカーと32のs3接続を使用）

そのバケットにアクセスするために何か特別なことをする必要があるかどうか知っていますか？ 私はこれまでパブリックバケットを使用したことがないので、何か間違ったことをしているのか、ユーザーがアクセスできないのかわかりません。 （チームのバケットに問題なくアクセスできるので、システムは一般的にs3にアクセスできることがわかっています）

ねえ@ifedorenko 、ちょっと

申し訳ありませんが、パブリックバケットポリシーを適用しましたが、バケット自体のオブジェクトを更新していませんでした。 これでアクセスできるようになります。 読み取り権限のみを付与しているため、-no-lockを使用する必要があることに注意してください。

うん。 これでリポジトリにアクセスできます。 今夜遅くにそれで遊ぶでしょう。

また、テストが役立つ/簡単な場合は、高速SSDのリポジトリとの間で同じファイルを復元し、S3を方程式から外すと、同様のパフォーマンス特性が見られます。

@pmkane問題をローカルで再現でき、そのバケットにアクセスする必要がなくなりました。 これはとても役に立ちました、ありがとう。

@ifedorenko 、素晴らしい。 バケットを削除します。

@pmkane時間があるときに、最新の注文復元ブランチをもう一度試してください。 ec2でこれをテストする時間がありませんでしたが、私のmacbookの復元では、ディスクの書き込み速度によって制限されているようで、rcloneと一致するようになりました。

@ifedorenko 、それは非常に有望に聞こえます。 私は今テストを開始しています。

@ifedorenko 、ビンゴ。

ファイルサイズの混合を表す133GB相当のblobを復元しました。最大のものは78GBで、16分弱で復元されました。 以前は、この復元は1日の大部分を占めていました。 多数のrestoreWorkersを試してみると、これをさらに速くできると思いますが、現状では十分に高速です。

これにあなたのハードワークをありがとう！

そして後世のために：私たちの復元パフォーマンスは8-> 16から2倍になり、16-> 32復元ワーカーから再び2倍になります。 32-> 64は、32の上に約50％のバンプがある場合にのみ有効であり、その時点で約3gbit /秒で復元しています。 rcloneとほぼ同等です。

Resticから最高のパフォーマンスを引き出すために必要な構成の量を最小限に抑えたいという要望があることは知っていますが、これは、特に大きなファイルセットを持つユーザーにとっては十分に大きなジャンプであり、実行時のワーカー数。

復元がまだフルワイヤスピードを取得できない理由がわかりません。 コメントアウトして責任があるかどうかを確認できる冗長な

やってみます。

みなさん、こんにちは。最新のプルリクエスト＃2195を使用していくつかのテストを実行しましたが、パフォーマンスは向上し続けています。

（20kの小さなファイル、2x70Gファイル、合計170G）

8w_32c

real    27m46.185s
user    24m31.290s
sys 3m55.153s

32w_32c

real    15m30.904s
user    24m1.982s
sys 4m55.128s

64w_32c

real    18m37.566s
user    23m33.684s
sys 5m3.024s

64w_64c

real    17m12.314s
user    23m44.318s
sys 4m43.090s

32wから64wへのパフォーマンスの低下についてはよくわかりません（数回テストされ、正当なようです）。 プロセス中にいくつかのグラフを添付しますが、劣化または制限があるようですが、このようにする必要がありますか？ たとえば、64人のワーカーの場合、プロセスは6gbit /秒で開始しますが、その後、プロセスが終了するまで1gbit /秒未満に低下します（これは、これらの大きなファイルを処理する時間に相当すると思います）。 最初のスクリーンショットは32w、32cで、2番目のスクリーンショットは64w、32cです。

@pmkaneにも同意します。コマンドラインからワーカー番号を変更すると便利です。 データをできるだけ速く復元したい場合は、ディザスタリカバリのシナリオで非常に役立ちます。 私の同僚＃2178からこれに関するプルリクエストがあります

とにかく、私は行われた改善に本当に感銘を受けました！ どうもありがとう@ifedorenko

++。 ありがとう@ifedorenko 、これはresticのためのゲームを変えるものです。

詳細レポート@robvalcaありがとうございます。 AWS（またはGCPまたはAzure）またはローカルでテストリポジトリを提供できる可能性はありますか？ テストで大きなファイルの復元速度の低下は見られなかったので、そこで何が起こっているのかを理解したいと思います。

@pmkane私も実行時にこれらをます。 私の提案は、それらを--optionオプションにして、通常のフラグやコマンドを乱雑にしないようにすることでしたが、実験したり、異常な状況に合わせたりしたい「上級」ユーザー向けです。 それらは文書化する必要さえなく、 --option experimental.fooCount=32ように、信頼できないことを明確にする名前を付けることができます。

こんにちは@ifedorenko 、 s3.cern.ch/restic-testrepoジャンクデータを含む公開リポジトリを作成しました。 それは私が試していたもの（たくさんの小さなファイルといくつかの非常に大きなファイル）とほぼ同じ形であり、またこれで同じ動作を再現することができました（添付のプロット）。 リポジトリのパスワードはresticです。 アクセスに問題がある場合はお知らせください。

@robvalcaテストリポジトリを使用して問題を再現できません。 AWS（us-east-2、s3リポジトリ、 i3.4xlarge 2x nvme raid0 target）では、32個のワーカーと32個の接続を使用した場合に0.68 GB / sの安定した復元速度が見られます（合計復元時間6分20秒）。 ターゲットシステムは10GB / sを長期間維持できません。推測すると、これをさらにトラブルシューティングする場合は、少なくともそれを最初に確認します。

@pmkane興味深いことに、私もあなたの観察を確認することはできません。 上で述べたように、最新のout-of-order-restore-no-progressブランチを使用すると0.68 GB / sの復元速度が見られ（復元はCPUにバインドされているように見えます）、冗長ブロブハッシュチェックを無効にすると0.81 GB / sになります（復元はCPUに見えませんでした-バウンド）。 「最大10Gbps」のネットワークがどれだけ高速になるかはわかりませんが、すでに「収穫逓減」の領域にいると思います。

@ifedorenko私は心から同意します：収穫逓減。 そのままでも十分高速です。

@ifedorenko興味深い、私はこれを私たちの側で調査します。 とにかくそれは私たちにとっても十分に速いです、あなたの努力に感謝します。

これをマージするステータスに興味があります。このブランチは、プルーンの高速化に関する

すぐに...👀

＃2195がマージされたので、これを閉じます。 この問題に関する詳細が解決されていない場合は、完全に自由に再開してください。 この号で説明されているタイプではない改善がまだ行われている場合は、新しい号を開いてください。 ありがとう！