S3 でデータをレプリケートしようとしています。ここでは、数十万個の適度に大きなブロブ (多くは 1GB から 100GB の範囲) について話しています。操作は、米国標準の S3 BLOB の場合、米国東部のマシンから実行されます。
gsutil 3.34 は、数時間実行した後でも、下りよりも上りの方がはるかに多くかかるようです。いくつかのオプションを微調整しようとしましたが、どこにも行きませんでした。
測定例: 78387.82 KB/秒の入力と 3154.36 KB/秒の出力。比率が 2 倍になれば問題ありませんが、10 倍以上はあまり適切ではありません。
何が起こっているのでしょうか？
うーん、ウォームアップ時間が思ったより長かった。どの操作が非常に長い間、非常に多くのイングレスを必要とするかはわかりません。多くのブロブリストのようなもの（プロセスごとに1つ、またはそのようなもの）を疑うでしょうか？
下のグラフでは、12:00頃に同期を開始しました。
再起動しようとしたところgsutil -m cp -Rn s3://foo gs://bar、同じ I/O パターンが観察されました (送信よりも大量の受信から開始し、最初の 10 ～ 20 時間で徐々に改善されるかどうかを確認します)。
iostatログで説明できない書き込みアクティビティは表示されないため (非常に数 KB/秒)、ディスクにバッファリングされていません。
アップロードよりもダウンロードの方が 10 倍多いというのは、かなり奇妙なことです。つまり、データはどこかに行かなければなりませんよね？
いくつかの潜在的な提案:
帯域幅の問題でしょうか？gsutil cp は、ファイルを S3 からローカル マシンにコピーし、そこから GCS にコピーします。ISP がアップロード速度を制限している場合、それが原因である可能性があります。おそらく、GCS はデータを正常にダウンロードしていますが、再度アップロードする際に調整されています。
「-m」フラグを試しましたか? gsutil のデフォルトでは、一度に 1 つのファイルをコピーします。-m を使用すると、多数のファイルを並行してアップロードできるため、速度が大幅に向上する可能性があります。