排除资源分配问题

排查应用设备上的常见资源分配问题

注意

从持续集成 (CI) 系统、构建服务器或任何其他客户端（例如 Git 或 API 客户端）定期向你的 GitHub Enterprise Server 实例发出重复请求（轮询）可能会使系统不堪重负。这可能会导致拒绝服务 (DoS) 攻击，造成严重的性能问题和资源饱和。

为避免这些问题，强烈建议使用 Webhook 接收更新。 Webhook 允许系统自动推送更新，而无需不断轮询。此外，考虑使用条件请求和缓存策略来尽量减少不必要的请求。避免以大型同时批处理（惊群效应）运行作业，而是等待 Webhook 事件触发操作。

有关详细信息，请参阅“关于网络钩子”。

建议使用监视仪表板来随时了解设备的资源运行状况，并决定如何解决高使用率问题，例如本页概述的问题。

对于系统关键问题，以及在修改设备之前，我们强烈建议你通过访问 GitHub Enterprise 支持联系我们并包含你的支持捆绑包。有关详细信息，请参阅“向GitHub支持提供数据”。

实例的 CPU 配置不足，无法满足工作负载的要求。
升级到新的 GitHub Enterprise Server 版本通常会因新功能而增加 CPU 和内存使用量。此外，升级后的迁移或协调后台作业可能会暂时降低性能，直至完成。
针对 Git 或 API 的高级请求。对 Git 或 API 的请求增加可能由于多种因素发生，例如过度的存储库克隆、CI/CD 进程或 API 脚本或新工作负荷的无意使用。
增加了GitHub Actions作业的数量。
在大型存储库中执行的 Git 命令数量增加。

        [设置警报阈值](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/recommended-alert-thresholds)。

实例的内存预配不足。
针对 Git 或 API 的高级请求。对 Git 或 API 的请求增加可能由于多种因素发生，例如过度的存储库克隆、CI/CD 进程或 API 脚本或新工作负荷的无意使用。
单个服务超出其预期的内存使用量并出现内存不足 (OOM)。
增加了后台任务处理。

实例的内存预配不足，无法满足工作负载的要求，鉴于一段时间内的使用量，数据量可能会超过最低推荐要求。
在 Nomad 图表中，识别那些具有内存耗尽趋势的服务，这些服务在重启后通常会出现空闲内存增加的趋势。有关详细信息，请参阅“关于监控仪表板”。
通过运行 rg -z 'kernel: Out of memory: Killed process' /var/log/syslog* 检查日志中是否存在内存不足的进程（为此，首先使用 SSH 登录到管理 shell - 请参阅访问管理 shell (SSH)。）
确保满足内存与 CPU 服务的正确比率（至少 6.5:1）。
查看排队等待后台处理的任务数量 - 请参阅关于监控仪表板。

这两个存储卷（一个装载到根文件系统路径 (/)，另一个装载到用户文件系统路径 (/data/user)）如果可用磁盘空间不足，则可能会导致实例的稳定性出现问题。

请记住，根存储卷拆分为两个大小相等的分区。其中一个分区将装载为根文件系统 (/)。另一个分区仅在升级和升级回滚期间作为/mnt/升级挂载，以便在必要时更轻松地回滚。有关详细信息，请参阅“系统概览”。

通过运行 (/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 配额和/或存在严重的 IO 争用。
劳动力饱和。
Webhook 传输延迟。

查找磁盘待处理操作：排队操作数图表中的峰值或持续数字。
检查“应用请求/响应”面板，查看是否只有某些服务受到影响。
升级后，通过运行 ghe-check-background-upgrade-jobs 来检查后台升级作业是否已完成。
查看 /var/log/github/exceptions.log 中的数据库日志，了解是否存在慢速查询（为此，首先使用 SSH 登录到管理 shell - 请参阅访问管理 shell (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` 服务失败或单个服务不可用。