Enterprise Server 3.20 は、現在リリース候補として使用できます。

リソースの割り当てに関する問題のトラブルシューティング

GitHub Enterprise Server アプライアンスで発生する可能性がある一般的なリソース割り当ての問題のトラブルシューティング。

この記事で

アプライアンスにおける一般的なリソース割り当ての問題のトラブルシューティング

メモ

継続的インテグレーション (CI) システム、ビルド サーバー、またはその他のクライアント (Git や API クライアントなど) から お使いの GitHub Enterprise Server インスタンス に対して一定の間隔で要求 (ポーリング) を繰り返すと、システムに負荷が掛かりすぎる可能性があります。 これがサービス拒否 (DoS) 攻撃になり、重大なパフォーマンスの問題とリソース不足が発生する可能性があります。

これらの問題を回避するために、Webhook を使用して更新プログラムを受信することを強くお勧めします。 Webhook を使用すると、システムは更新プログラムを自動的にプッシュできるため、常にポーリングする必要がなくなります。 さらに、条件付き要求とキャッシュ戦略を使用して、不要な要求を最小限に抑えることも検討してください。 大規模な同時バッチ (thundering herds、つまり雷鳴の群れ) の中でジョブを実行することを避け、代わりに Webhook イベントがアクションをトリガーするのを待ちます。

詳しくは、「webhook について」をご覧ください。

モニター ダッシュボードを使用してアプライアンス リソースの健全性を常に把握して、このページで説明している問題などの高利用率の問題の解決方法を判断することをお勧めします。

システム クリティカルな問題については、アプライアンスを変更する前に、GitHub Enterprise サポート にアクセスし、サポート バンドルを含めて、Microsoft にお問い合わせいただくことを強くお勧めします。 詳しくは、「GitHub サポートにデータを提供する」をご覧ください。

CPU 使用率が高い

考えられる原因

  • インスタンスの CPU がワークロードに対して適切にプロビジョニングされていません。
  • 新しい GitHub Enterprise Server リリースにアップグレードすると、多くの場合、新機能により CPU とメモリの使用量が増加します。 さらに、アップグレード後の移行または調整のバックグラウンド ジョブが完了するまで、パフォーマンスが一時的に低下する可能性があります。
  • Git または API に対する要求の増加。 Git または API への要求の増加は、過剰なリポジトリの複製、CI/CD プロセス、API スクリプトや新しいワークロードによる意図しない使用など、さまざまな要因によって発生する可能性があります。
  •         [GitHub Actions ジョブ](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/about-the-monitor-dashboards#actions)の数が増加しました。
  • 大量の Git コマンドによる大規模なリポジトリの実行。

推奨事項

  • CPU コアが適切にプロビジョニングされていることを確認します。
  •         [アラートのしきい値を設定します](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/recommended-alert-thresholds)。
  • アップグレード後、ghe-check-background-upgrade-jobs を実行して、バックグラウンド アップグレード ジョブが完了したかどうかを確認します。
  • プルする代わりに Webhook を使用します。
  •         [API レート制限](/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-rate-limits)を使用します。

  •         [現在の操作](/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities#ghe-btop)と [Git トラフィック](/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities#ghe-governor)を確認して、Git の使用状況を分析します。

メモリ使用量が多い

考えられる原因

  • インスタンスのメモリが適切にプロビジョニングされていません。
  • Git または API に対する要求の増加。 Git または API への要求の増加は、過剰なリポジトリの複製、CI/CD プロセス、API スクリプトや新しいワークロードによる意図しない使用など、さまざまな要因によって発生する可能性があります。
  • 個々のサービスが予想されるメモリ使用量を超え、メモリ不足 (OOM) になっている。
  • バックグラウンドのジョブ処理が増加しました。

推奨事項

  • 時間の経過に伴う使用量が最小推奨要件を超える可能性があるため、インスタンスのメモリがワークロードやデータ ボリュームに対して適切にプロビジョニングされていません。
  • Nomad グラフ内で、メモリ不足の傾向を持つサービスを特定します。その後に、多くの場合、再起動後に空くメモリが示されています。 詳しくは、「モニター ダッシュボードについて」をご覧ください。
  •         `rg -z 'kernel: Out of memory: Killed process' /var/log/syslog*` を実行してメモリ不足になるプロセスのログを調べます (このためには、まず SSH を使って管理シェルにログインします。「[AUTOTITLE](/enterprise-server@3.14/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh)」をご覧ください)。
  • CPU サービスに対するメモリの正しい比率が満たされていることを確認します (少なくとも 6.5:1)。
  • バックグラウンド処理のためにキューに登録されているタスクの量を調べます。「モニター ダッシュボードについて」をご覧ください。

ディスクの空き容量の低下

1 つはルート ファイルシステム パス (/) にマウントされ、もう 1 つはユーザー ファイルシステム パス (/data/user) にマウントされている 2 つストレージ ボリュームは、ディスク領域が不足している場合にインスタンスの安定性に問題が発生する原因になる可能性があります。

ルート ストレージ ボリュームは、同じサイズの 2 つのパーティションに分割されることに注意してください。 パーティションの 1 つがルート ファイルシステム (/) としてマウントされます。 もう 1 つのパーティションは、アップグレード時およびロールバック時にのみ /mnt/upgrade としてマウントされ、必要に応じて簡単にロールバックできるようになります。 詳しくは、「システムの概要」をご覧ください。

考えられる原因

  • ログの量が増加するサービス エラー
  • オーガニック トラフィックによるディスク使用量の増加

推奨事項

  • (/var/log) を実行するか、手動でログのローテーション (sudo du -csh /var/log/*) を実行して、sudo logrotate -f /etc/logrotate.conf フォルダーのディスク使用量を確認します。
  • 削除されているがファイル ハンドルがまだ開いている大きなファイルがないか、ディスクをチェックします (ghe-check-disk-usage)。
  • ディスク ストレージの容量を増やします。「ストレージ容量の増加」をご覧ください。

通常よりも長いレスポンスタイム

考えられる原因

  • Git または API に対する要求の増加。 Git または API への要求の増加は、過剰なリポジトリの複製、CI/CD プロセス、API スクリプトや新しいワークロードによる意図しない使用など、さまざまな要因によって発生する可能性があります。
  • データベース クエリの速度低下。
  • アップグレード後、ElasticSearch のサービスリソースの使用量が増加しました。
  • ディスク上の IOPS クォータに到達している、または入力出力の競合が多い。
  • 過負荷のワーカー。
  • Webhook の配信遅延。

推奨事項

  • 「ディスク保留中の操作: キューに入った操作の数」グラフで急激な上昇や持続する数値を確認します。
  •         **[アプリケーションの要求/応答]** パネルで、特定のサービスのみが影響を受けるかどうかを確認します。
  • アップグレード後、ghe-check-background-upgrade-jobs を実行して、バックグラウンド アップグレード ジョブが完了したかどうかを確認します。
  • データベース ログの /var/log/github/exceptions.log で遅いクエリを確認します (このためには、まず SSH を使って管理シェルにログインします。詳細については、管理シェル (SSH) にアクセスするを参照してください)。例えば、URLによるトップ10の遅延リクエストを確認することができます: grep SlowRequest github-logs/exceptions.log | jq '.url' | sort | uniq -c | sort -rn | head。
  •         **キューに入った要求**グラフで特定のワーカーを確認し、稼働中のワーカー数の調整を検討します。
  • IOPS/スループットが高いストレージ ディスクを増やします。
  • バックグラウンド処理のためにキューに登録されているタスクの量を調べます。「モニター ダッシュボードについて」をご覧ください。

エラーレートの増大

考えられる原因

  • Git または API に対する要求の増加。 Git または API への要求の増加は、過剰なリポジトリの複製、CI/CD プロセス、API スクリプトや新しいワークロードによる意図しない使用など、さまざまな要因によって発生する可能性があります。
  •         `haproxy` サービスが失敗したか、個々のサービスが使用できません。
  • 時間の経過に伴うリポジトリ ネットワークのメンテナンスに失敗しました。

推奨事項

  •         **[アプリケーションの要求/応答]** パネルで、特定のサービスのみが影響を受けるかどうかを確認します。

  •         `haproxy` ログを確認し、不適切なアクターが原因であるかどうかの特定を試みます。
  • 失敗したリポジトリ ネットワーク メンテナンス ジョブを確認します (http(s)://[hostname]/stafftools/networks にアクセスしてください)。