排查资源分配问题

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

Note

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

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

有关详细信息，请参阅“关于 web 挂钩”。

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

对于系统关键问题，在对设备进行修改之前，强烈建议通过访问 GitHub Enterprise 支持并附上支持包来与我们联系。有关详细信息，请参阅“将数据提供给 GitHub Enterprise 支持”。

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

实例的内存预配不足。
针对 Git 或 API 的提升请求。由于各种因素（如存储库克隆过多、CI/CD 进程或 API 脚本或新工作负载意外使用），对 Git 或 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/ 装载，以便在必要时更容易回退。有关详细信息，请参阅“系统概览”。

通过运行 (sudo du -csh /var/log/*) 或手动强制日志轮换 (sudo logrotate -f /etc/logrotate.conf) 来检查 /var/log 文件夹的磁盘使用况。
检查磁盘中是否存在已被删除但仍有打开的文件句柄 (ghe-check-disk-usage) 的大文件。
增加磁盘存储容量 - 请参阅“增加存储容量”。

针对 Git 或 API 的提升请求。由于各种因素（如存储库克隆过多、CI/CD 进程或 API 脚本或新工作负载意外使用），对 Git 或 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 的提升请求。由于各种因素（如存储库克隆过多、CI/CD 进程或 API 脚本或新工作负载意外使用），对 Git 或 API 的请求可能会增加。
haproxy 服务失败或单个服务不可用。
随着时间的推移，存储库网络维护失败。