このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となります: 2026-08-25. 廃止されたリリースはサポートされていません。 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 GitHub Enterprise Server のパフォーマンスの向上、セキュリティの向上、新機能については、「アップグレード プロセスの概要を参照してください。 アップグレードに関するサポートについては、GitHub Enterprise Support にお問い合わせください。

GitHub Enterprise Server インスタンスでの Git トラフィックの分析

Governor を使用して、インスタンスの負荷を促進している Git トラフィック パターンを特定し、低速な Git 操作のトラブルシューティングを行い、パフォーマンスへの影響を軽減できるようにします。

この記事で

ガバナーについて

Governor は、インスタンス上の Git アクティビティの組み込みモニターです。 ghe-governor コマンドを使用して、読み込みを作成しているリポジトリ、ユーザー、IP アドレス、Git 操作を確認します。

このデータは、CPU、メモリ、またはディスクの使用量が増加し、Git トラフィックが原因かどうかを確認する必要がある場合に使用します。 コマンド構文とサブコマンドについては、 コマンド ライン ユーティリティ を参照してください。

Governor は Git 操作のみを記録します。 API または Web トラフィックは含まれません。 現在実行中の操作を検査するには、ghe-btop の ユーティリティを参照してください。

ガバナー データ ファイルについて

ガバナーは、そのデータを /data/user/governor/ の下のファイルに格納します。 各ファイルは 1 時間のデータを保持し、2 週間保持されます。 ファイル名には、各ファイルがカバーする期間を示す Unix タイムスタンプが含まれています。

メモ

GitHub Enterprise Server 3.13 以前では、Governor データ ファイルは/data/user/gitmon/の下にあり、名前付けパターンのgitmon.<timestamp>.dbを使用します。

現在ディスクに保持されているデータの範囲を確認するには、最も古いファイル名と最新のファイル名のタイムスタンプを人間が判読できる日付に変換します。

for epoch in $(sudo ls /data/user/governor/ 2>/dev/null | grep '^governor\.' | sort | sed -n '1p;$p' | cut -f2 -d.); do echo "${epoch} = $(date -d @${epoch})"; done

出力には、最も古いデータ ファイルと最新のデータ ファイルの開始時刻が表示されます。

1551186000 = Tue Feb 26 13:00:00 UTC 2019
1552392000 = Tue Mar 12 12:00:00 UTC 2019

開始する前に

Governor クエリを実行する前に、次の情報を収集します。

  • アプライアンスへの SSH アクセス。 ghe-governorを実行するには、管理シェルにアクセスする必要があります。 「管理シェル (SSH) にアクセスする」を参照してください。
  • クエリを実行するノード。 スタンドアロンまたは高可用性のデプロイの場合は、プライマリ ノードから開始します。 クラスターの場合は、すべての Git トラフィックを含むノードが 1 つないため、各 git-server ノードでクエリを実行します。
  • 影響ウィンドウ。 -tと-uを使用してクエリのスコープを設定できるように、報告された低下の開始時刻と終了時刻に注意してください。
  • ユーザーが特定のリポジトリまたは組織に関する問題を報告した場合は、リポジトリまたは組織名。

Git が読み込みに貢献しているかどうかを特定する

概要から始めて、特定のリポジトリまたはプログラムへの属性の読み込みを行います。

  • インスタンス上の最近の Git アクティビティをすべてまとめます。

    ghe-governor health

  • 平均応答時間が最も遅いリポジトリを検索します。

    ghe-governor aggregate repo avg_rt

  • 1 回の操作が最も長いリポジトリを検索します。

    ghe-governor aggregate repo max_rt

  • (グループ化されていない) 最も低速な個々の操作を見つけます。

    ghe-governor top rt -n 50

  • CPU 時間が最も多いリポジトリを検索します。

    ghe-governor aggregate repo cpu

  • 目立つリポジトリの場合は、CPU 使用率を担当する Git サブプログラムを見つけます。

    ghe-governor aggregate program cpu -r OWNER/REPOSITORY

  • 最も CPU 時間 pack-objects 消費したリポジトリを見つけます。 pack-objects プログラムは、クローンとフェッチ中にクライアントに送信されたデータをアセンブルします。高カウントでは、アプライアンスに CPU とメモリの負荷が大きくなります。

    ghe-governor aggregate repo cpu -P pack-objects

  • CPU 時間が最も多く (グループ化されていない) 個々の操作を検索します。

    ghe-governor top cpu -n 50

  • 特定の期間にディスクの書き込みが最も多いリポジトリを検索します。

    ghe-governor aggregate repo disk_write_kb -t START-TIME -u END-TIME

  • 同時に実行されている多くの Git 操作を示す、コンカレンシーが高いかどうかを確認します。

    ghe-governor aggregate repo max_parallelism

結果が特定のリポジトリまたはプログラムを指している場合は、以下の関連セクションに進みます。

上位のクローンおよびフェッチのトラフィックを特定する

upload-pack プログラムは、複製とフェッチ中にクライアントに提供されるデータを処理します。 これらのクエリを使用して、どのリポジトリ、ユーザー、および IP アドレスが最も多くの複製およびフェッチ アクティビティを推進しているかを確認します。

  • リポジトリ別の複製操作とフェッチ操作をカウントします。

    ghe-governor aggregate repo count -P upload-pack

  • 複製とフェッチを実行しているユーザーを特定し、操作をカウントします。

    ghe-governor aggregate user_id count -P upload-pack

  • 最も多くのクローンとフェッチ要求を生成する IP アドレスを特定します。 件数の多い IP アドレスが少数だけ見られる場合、多くは CI ランナー群を示唆します:

    ghe-governor aggregate ip count -P upload-pack

  • リポジトリごとに提供されるデータの合計量を測定します。

    ghe-governor aggregate repo uploaded_kb -P upload-pack

  • ユーザーごとにアップロードされたデータの平均量を測定します。

    ghe-governor aggregate user_id avg_uploaded -P upload-pack

  • リポジトリごとに、ピーク時の複製とフェッチコンカレンシーを検索します。 MAXPL列には、各リポジトリに記録された同時操作の最大数が表示されます。 少数のリポジトリの値が大きいと、雷雨の群れが示されます。

    ghe-governor aggregate repo max_parallelism -P upload-pack

  • グループ化されていない最も大きい個別のクローンまたはフェッチ操作を特定します。

    ghe-governor top uploaded -P upload-pack -n 50

プッシュ負荷の高いトラフィックを特定する

receive-packおよびspokes-receive-pack プログラムは、プッシュ時にクライアントから受信したデータを処理します。 これらのクエリを使用して、最もプッシュ アクティビティを生成しているリポジトリ、ユーザー、および IP アドレスを検索します。

  • リポジトリ別のプッシュ操作をカウントします。

    ghe-governor aggregate repo count -P receive-pack -P spokes-receive-pack

  • 組織にプッシュするユーザーを特定し、プッシュ操作をカウントします。

    ghe-governor aggregate user_id count -o ORGANIZATION -P receive-pack -P spokes-receive-pack

  • リポジトリごとに受信したデータの合計量を測定します。

    ghe-governor aggregate repo received_kb -P receive-pack -P spokes-receive-pack

  • 最も多くのプッシュ データを送信する IP アドレスを特定します。

    ghe-governor aggregate ip received_kb -P receive-pack -P spokes-receive-pack

  • (グループ化されていない) 最大の個々のプッシュ操作を検索します。

    ghe-governor top received -P receive-pack -P spokes-receive-pack -n 50

分析を絞り込む

次のオプションの任意の組み合わせを ghe-governor top または ghe-governor aggregate コマンドに追加して、クエリを特定の時間枠、リポジトリ、所有者、またはプログラムに集中させることができます。

時間フィルター

オプションDescription
-t <timespec>特定の開始時刻以降の操作のみを考慮してください。 既定値は 48 時間前です。
-u <timespec>特定の終了時刻までの操作のみを考慮してください。 既定値は現在の時刻です。

<timespec>では、次の形式を使用できます。

フォーマットExampleMeaning
Unix タイムスタンプ-t 13716144831970 年 1 月 1 日からの秒数
Javaタイムスタンプ-t 13716144836371970 年 1 月 1 日以降のミリ秒
相対日数-t 1d最後の日
相対時間-t 2h過去 2 時間
相対時間 (分)-t 20m過去 20 分間

スコープ フィルター

オプションDescription
-r <owner>/<repository>特定の所有者とリポジトリに一致する操作のみを検討してください。 このオプションを複数回指定して、複数のリポジトリと一致させます。
-o <owner>ユーザーや組織など、特定の所有者と一致する操作のみを検討してください。 複数の所有者と一致するには、このオプションを複数回指定します。
-P <program>
upload-pack、receive-pack、rev-list、pack-objectsなど、特定の Git サブプログラムを実行した操作のみを検討してください。 複数のプログラムと一致するように、このオプションを複数回指定します。
-I <address>特定の IP アドレスからの操作のみを考慮してください。 複数のアドレスと一致するには、このオプションを複数回指定します。

出力オプション

オプションDescription
-jASCII テーブルではなく、出力形式を JSON に設定します。
-n <N>出力を N レコードに制限します。 既定値は、集計クエリの場合は 20、上位クエリの場合は 200 です。
--count-only
KEY列とCOUNT列のみを表示します。 集計クエリにのみ適用されます。

結果列の解釈

結果テーブルには、次の省略形 ghe-governor 表示されます。

ColumnMeaning
AVG RTGit 呼び出しにかかった平均時間 (秒単位)
MAX RT実行時間が最も長い呼び出しの実行時間 (秒) (ホストごと)
MAXPL / AVGPL最大並列処理と平均並列処理: 一度に未処理だった Git 呼び出しの数
CPU/SECGit によって使用される 1 秒あたりの実時間 (秒) の CPU 時間。 CPU コアの数で除算し、100 を乗算して、Git 固有の CPU の割合を取得します。 この値は、CPU コアの数を超えることはできません。
UPLサーバーがクライアントにアップロードしたデータ (フェッチや複製中など)
RECVプッシュ中など、サーバーがクライアントから受信したデータ

READ、WRITE、UPL、RECVの各列はギガバイト (GB) 単位で報告され、対応するレートは MB/秒 (MB/秒) 単位で報告されます。

一般的なパターンを解釈する

次の表は、一般的な Governor 出力パターンとその原因を示しています。

Pattern考えられる原因
少数の IP アドレスからの upload-pack 数が多いCI ランナーフリートは、ローカルのチェックアウト済みコピーを再利用せずに、1 つ以上のリポジトリを繰り返しクローンしている
少数のリポジトリに対する高いmax_parallelismサンダリング・ハード: 多くのランナーが同時にクローンをトリガーすること。多くの場合、スケジュールされたジョブが同時に開始されるために発生します。
リポジトリあたりの大きな uploaded_kb とユーザーあたりの高い avg_uploaded の組み合わせ完全複製を繰り返す。クライアントがローカル チェックアウトを再利用していないか、浅い複製または部分的なクローンを使用していない
高いreceived_kbリポジトリまたは組織向けプッシュ集中型のワークロード。には、大きなバイナリ ファイルや monorepo への頻繁なコミットが含まれる場合があります
中程度の操作数の高い pack-objects CPU高価なオブジェクトパッキング。リポジトリは、メンテナンスの実行や、クライアント側での部分クローンの使用によるメリットを受ける可能性があります。 --filter
リポジトリの高いavg_rtまたはmax_rt値低速な操作。多くの場合、大規模な pack-objects 実行、コンカレンシーの高さ、または別のワークロードからのリソースの競合が原因です

ガバナー データで、リポジトリ、ユーザー、またはランナーフリートが過剰な負荷を発生していることを示している場合、次のアクションによって影響が軽減される可能性があります。

  • ローカル チェックアウトを再利用します。 自動ワークフローで、新しいクローンを git fetch に置き換えます。 これにより、各実行で完全なオブジェクト グラフが転送されるのを回避できます。
  • 浅いクローンを使用してください。 完全なコミット履歴を必要としないワークフローの場合は、 --depth を clone コマンドに渡します (例: git clone --depth 1)。 これにより、転送されるデータと pack-objects する必要がある作業の両方が削減されます。
  • 部分複製を使用します。 大きなバイナリ オブジェクトを含むリポジトリや、特定のワークフローで不要なファイルが多数ある場合は、 --filter を使用して、ワークフローに必要なオブジェクト ( git clone --filter=blob:noneなど) のみを要求します。
  • ローカル ミラーまたはキャッシュ プロキシを追加します。 同じリポジトリを繰り返し複製する大規模なランナー フリートの場合、プルスルー プロキシまたはローカル ミラーはフェッチ トラフィックを吸収し、インスタンスの負荷を軽減できます。
  • スケジュールされたジョブをずらす。 スケジュールに従ってトリガーされるオフセット CI/CD ワークフローにより、すべてのランナーが同時に開始されるわけではないため、同時複製バーストのサイズが小さくなります。
  • ワークフローの並列処理を減らします。 複数のリポジトリを並列に複製するワークフローを再構成して、コンカレンシーを制限し、時間の経過と同時に負荷を分散させることができます。

GitHub サポートに問い合わせるタイミング

次のいずれかに該当する場合は、 GitHub Enterprise サポート に連絡し、サポート バンドルを含めます。

  • 複製の負荷を軽減したり、スケジュールされたジョブをずらしたりした後も、パフォーマンスが低下します。
  • インスタンスで、クライアントのワークロードでは説明できない広範な Git エラーまたは接続障害が発生しています。
  • Governor は、インスタンスが容量の上限に達しているか、その近くにあることを示す max_parallelism 値が継続的に示されており、ワークロードの変更のみでこの問題が解消される可能性は低いことを示しています。
  • Governor の出力には明確なパターンが表示されますが、それを解釈する方法や実行するアクションが不明です。

サポート バンドルの生成の詳細については、 GitHub サポートにデータを提供する を参照してください。

詳細については、次を参照してください。

システム リソースの監視の詳細については、 AUTOTITLE を参照してください。