アプライアンスにおける一般的なリソース割り当ての問題のトラブルシューティング
Note
継続的インテグレーション (CI) システム、ビルド サーバー、またはその他のクライアント (Git や API クライアントなど) から お使いの GitHub Enterprise Server インスタンス に対して一定の間隔で要求 (ポーリング) を繰り返すと、システムに負荷が掛かりすぎる可能性があります。 これがサービス拒否 (DoS) 攻撃になり、重大なパフォーマンスの問題とリソース不足が発生する可能性があります。
これらの問題を回避するために、Webhook を使用して更新プログラムを受信することを強くお勧めします。 Webhook を使用すると、システムは更新プログラムを自動的にプッシュできるため、常にポーリングする必要がなくなります。 さらに、条件付き要求とキャッシュ戦略を使用して、不要な要求を最小限に抑えることも検討してください。 大規模な同時バッチ (Thundering Herd) でジョブを実行しないようにして、webhook イベントがアクションをトリガーするのを待ちます。
詳しくは、「webhook について」をご覧ください。
モニター ダッシュボードを使用してアプライアンス リソースの健全性を常に把握して、このページで説明している問題などの高利用率の問題の解決方法を判断することをお勧めします。
システム クリティカルな問題については、アプライアンスを変更する前に、GitHub Enterprise サポート にアクセスし、サポート バンドルを含めて、Microsoft にお問い合わせいただくことを強くお勧めします。 詳細については、「GitHub Enterprise サポートへのデータの提供」を参照してください。
CPU 使用率が高い
考えられる原因
- インスタンスの CPU がワークロードに対して適切にプロビジョニングされていません。
- 新しい GitHub Enterprise Server リリースにアップグレードすると、多くの場合、新機能により CPU とメモリの使用量が増加します。 さらに、アップグレード後の移行または調整のバックグラウンド ジョブが完了するまで、パフォーマンスが一時的に低下する可能性があります。
- Git または API に対する要求の増加。 Git または API への要求の増加は、過剰なリポジトリの複製、CI/CD プロセス、API スクリプトや新しいワークロードによる意図しない使用など、さまざまな要因によって発生する可能性があります。
- GitHub Actions ジョブの数の増加。
- 大量の Git コマンドによる大規模なリポジトリの実行。
推奨事項
- CPU コアが適切にプロビジョニングされていることを確認します。
- アラートのしきい値を設定します。
- アップグレード後、
ghe-check-background-upgrade-jobsを実行して、バックグラウンド アップグレード ジョブが完了したかどうかを確認します。 - プルする代わりに Webhook を使用します。
- API レート制限を使用します。
- 現在の操作と Git トラフィックを確認して、Git の使用状況を分析します。
メモリ使用量が多い
考えられる原因
- インスタンスのメモリが適切にプロビジョニングされていません。
- Git または API に対する要求の増加。 Git または API への要求の増加は、過剰なリポジトリの複製、CI/CD プロセス、API スクリプトや新しいワークロードによる意図しない使用など、さまざまな要因によって発生する可能性があります。
- 個々のサービスが予想されるメモリ使用量を超え、メモリ不足 (OOM) になっている。
- バックグラウンド ジョブ処理の増加。
推奨事項
- 時間の経過に伴う使用量が最小推奨要件を超える可能性があるため、インスタンスのメモリがワークロードやデータ ボリュームに対して適切にプロビジョニングされていません。
- Nomad グラフ内で、メモリ不足の傾向を持つサービスを特定します。その後に、多くの場合、再起動後に空くメモリが示されています。 詳しくは、「モニター ダッシュボードについて」をご覧ください。
rg -z 'kernel: Out of memory: Killed process' /var/log/syslog*を実行してメモリ不足になるプロセスのログを調べます (このためには、まず SSH を使って管理シェルにログインします。「管理シェル (SSH) にアクセスする」をご覧ください)。- CPU サービスに対するメモリの正しい比率が満たされていることを確認します (少なくとも
6.5:1)。 - バックグラウンド処理のためにキューに登録されているタスクの量を調べます。「モニター ダッシュボードについて」をご覧ください。
ディスクの空き容量の低下
1 つはルート ファイルシステム パス (/) にマウントされ、もう 1 つはユーザー ファイルシステム パス (/data/user) にマウントされている 2 つストレージ ボリュームは、ディスク領域が不足している場合にインスタンスの安定性に問題が発生する原因になる可能性があります。
ルート ストレージ ボリュームは、同じサイズの 2 つのパーティションに分割されることに注意してください。 パーティションの 1 つがルート ファイルシステム (/) としてマウントされます。 もう 1 つのパーティションは、必要に応じて簡単にロールバックできるように、アップグレード中とアップグレードのロールバック中にのみ /mnt/ アップグレードとしてマウントされます。 詳しくは、「システムの概要」をご覧ください。
考えられる原因
- ログの量が増加するサービス エラー
- オーガニック トラフィックによるディスク使用量の増加
推奨事項
- (
sudo du -csh /var/log/*) を実行するか、手動でログのローテーション (sudo logrotate -f /etc/logrotate.conf) を実行して、/var/logフォルダーのディスク使用量を確認します。 - 削除されているがファイル ハンドルがまだ開いている大きなファイルがないか、ディスクをチェックします (
ghe-check-disk-usage)。 - ディスク ストレージの容量を増やします。「ストレージ容量の増加」をご覧ください。
通常よりも長いレスポンスタイム
考えられる原因
- Git または API に対する要求の増加。 Git または API への要求の増加は、過剰なリポジトリの複製、CI/CD プロセス、API スクリプトや新しいワークロードによる意図しない使用など、さまざまな要因によって発生する可能性があります。
- データベース クエリの速度低下。
- アップグレード後の ElasticSearch の昇格されたサービス リソースの使用。
- ディスク上の IOPS クォータに達している、または IO の競合が多い。
- ワーカーの飽和。
- Webhook の配信遅延。
推奨事項
- 「ディスク保留中の操作: キューに入った操作の数」グラフでスパイクまたは持続する数値を探します。
- [アプリケーションの要求/応答] パネルで、特定のサービスのみが影響を受けるかどうかを確認します。
- アップグレード後、
ghe-check-background-upgrade-jobsを実行して、バックグラウンド アップグレード ジョブが完了したかどうかを確認します。 - データベース ログの
/var/log/github/exceptions.logで遅いクエリを調べます (このためには、まず SSH を使って管理シェルにログインします。「管理シェル (SSH) にアクセスするgrep SlowRequest github-logs/exceptions.log | jq '.url' | sort | uniq -c | sort -rn | head」をご覧ください)。たとえば、URL で遅い要求の上位 10 件を調べます: 。 - 「キューに入った要求」グラフで特定のワーカーを確認し、アクティブなワーカー数の調整を検討します。
- IOPS/スループットが高いストレージ ディスクを増やします。
- バックグラウンド処理のためにキューに登録されているタスクの量を調べます。「モニター ダッシュボードについて」をご覧ください。
エラーレートの増大
考えられる原因
- Git または API に対する要求の増加。 Git または API への要求の増加は、過剰なリポジトリの複製、CI/CD プロセス、API スクリプトや新しいワークロードによる意図しない使用など、さまざまな要因によって発生する可能性があります。
haproxyサービスが失敗したか、個々のサービスが使用できません。- 時間の経過に伴うリポジトリ ネットワークのメンテナンスに失敗しました。
推奨事項
- [アプリケーションの要求/応答] パネルで、特定のサービスのみが影響を受けるかどうかを確認します。
haproxyログを確認し、不適切なアクターが原因であるかどうかの特定を試みます。- 失敗したリポジトリ ネットワーク メンテナンス ジョブを確認します (
http(s)://[hostname]/stafftools/networksにアクセスしてください)。