排查设备上的常见资源分配问题
注意:从持续集成 (CI) 系统、生成服务器或任何其他客户端(如 Git 或 API 客户端)定期向 你的 GitHub Enterprise Server 实例 发出重复的请求(轮询)可能会使系统不堪重负。 这可能会导致拒绝服务 (DoS) 攻击,造成严重的性能问题和资源饱和。
为避免这些问题,强烈建议使用 Webhook 接收更新。 Webhook 允许系统自动推送更新,而无需不断轮询。 此外,考虑使用条件请求和缓存策略来尽量减少不必要的请求。 避免同时大批量运行作业(惊群效应),而是等待 Webhook 事件触发操作。
有关详细信息,请参阅“关于 web 挂钩”。
建议使用监视仪表板来随时了解设备的资源运行状况,并决定如何解决高使用率问题,例如本页概述的问题。
对于系统关键问题,在对设备进行修改之前,强烈建议通过访问 GitHub Enterprise 支持 并附上支持包来与我们联系。 有关详细信息,请参阅“将数据提供给 GitHub Enterprise 支持”。
CPU 使用率高
可能的原因
- 实例的 CPU 配置不足,无法满足工作负载的要求。
- 升级到新的 GitHub Enterprise Server 版本通常会因新功能而增加 CPU 和内存使用量。 此外,升级后的迁移或协调后台作业可能会暂时降低性能,直至完成。
- 针对 Git 或 API 的提升请求。 由于各种因素(如存储库克隆过多、CI/CD 进程或 API 脚本或新工作负载意外使用),对 Git 或 API 的请求可能会增加。
- GitHub Actions 作业数增加。
- 在大型存储库中执行的 Git 命令数量增加。
建议
- 确保正确预配 CPU 核心。
- 设置警报阈值。
- 升级后,通过运行
ghe-check-background-upgrade-jobs
来检查后台升级作业是否已完成。 - 使用 Webhook 而不是拉取。
- 使用 API 速率限制。
- 通过检查当前操作和 Git 流量来分析 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
服务失败或单个服务不可用。- 随着时间的推移,存储库网络维护失败。
建议
- 检查“应用请求/响应”面板,查看是否只有某些服务受到影响。
- 查看
haproxy
日志,尝试确定是否是错误的执行组件造成的。 - 检查失败的存储库网络维护作业(请访问
http(s)://[hostname]/stafftools/networks
)。