トラブルシューティングモノレポのパフォーマンス
モノレポのパフォーマンス問題について、これらの提案を確認してください。
git cloneまたはgit fetch中の遅延
クローンとフェッチにおける遅延の主な原因がいくつかあります。
高いCPU使用率
GitalyノードのCPU使用率が高い場合、特定の値をフィルタリングしてクローンによって消費されるCPU量をチェックすることもできます。
特に、command.cpu_time_msフィールドは、クローンとフェッチによってどれくらいのCPUが消費されているかを示します。
ほとんどの場合、サーバー負荷の大部分は、クローンとフェッチ中に開始されるgit-pack-objectsプロセスから生成されます。モノレポは非常に頻繁に使用され、CI/CDシステムは多くのクローンおよびフェッチコマンドをサーバーに送信します。
高いCPU使用率は、パフォーマンス低下の一般的な原因です。以下の相互排他的ではない原因が考えられます:
原因: 大規模なクローンが多すぎる
Gitalyが処理するには、大規模なクローンが多すぎる可能性があります。Gitalyは、いくつかの要因により対応が困難になることがあります:
- リポジトリのサイズ。
- クローンとフェッチの量。
- CPU容量の不足。
Gitalyが多数の大規模なクローンを処理できるようにするには、以下のような最適化戦略によってGitalyサーバーへの負荷を軽減する必要があるかもしれません:
git-pack-objectsの作業を減らすには、パックオブジェクトキャッシュをオンにします。- CI/CD設定でGit戦略を
cloneからfetchまたはnoneに変更します。 - テストで必要な場合を除き、タグのフェッチを停止します。
- 可能な限りシャロークローンを使用します。
もう1つの選択肢は、GitalyサーバーのCPU容量を増やすことです。
原因: 読み取り分散の不備
Gitalyクラスター (Praefect) における読み取り分散が不十分な場合があります。
ほとんどの読み取りトラフィックがクラスター全体に分散されずにプライマリGitalyノードに向かっているかどうかを観察するには、読み取り分散Prometheusメトリクスを使用します。
セカンダリGitalyノードが多くのトラフィックを受信していない場合、セカンダリノードが永続的に同期が取れていない可能性があります。この問題はモノレポで悪化します。
モノレポは、大規模で頻繁に使用される傾向があります。これは2つの影響をもたらします。まず、モノレポには頻繁にプッシュされ、多くのCIジョブが実行されています。ブランチの削除などの書き込み操作が、セカンダリノードへのプロキシ呼び出しを失敗させることがあります。これにより、Gitalyクラスター (Praefect) でレプリケーションジョブがトリガーされ、セカンダリノードはいずれ追いつきます。
レプリケーションジョブは、本質的にセカンダリノードからプライマリノードへのgit fetchであり、モノレポは非常に大規模であるため、このフェッチには長い時間がかかることがあります。
前のレプリケーションジョブが完了する前に次の呼び出しが失敗し、これが継続的に発生する場合、モノレポのセカンダリが常に遅れている状態になる可能性があります。これにより、すべてのトラフィックがプライマリノードに送られます。
これらの失敗したプロキシ書き込みの1つの理由は、Git $GIT_DIR/packed-refsファイルに関する既知の問題です。ファイルをロックしてファイル内のエントリを削除する必要がありますが、これにより競合状態が発生し、同時削除が発生した場合に削除が失敗する可能性があります。
GitLabのエンジニアは、参照削除をバッチ処理する軽減策を開発しました。
GitLabが参照削除をバッチ処理できるように、以下の機能フラグをオンにします。これらの機能フラグを有効にするためにダウンタイムは必要ありません。
merge_request_cleanup_ref_worker_asyncpipeline_cleanup_ref_worker_asyncpipeline_delete_gitaly_refs_in_batchesmerge_request_delete_gitaly_refs_in_batches
エピック4220は、GitLabにreftableサポートを追加することを提案しており、これは長期的なソリューションと見なされています。