Skip to main content

升级前检查系统容量

在升级 GitHub Enterprise Server 之前,你应执行这些容量检查并执行建议的步骤。

升级到较新版本的 GitHub Enterprise Server 通常会增加资源消耗。 每个功能版本都增加了新的功能,其中有些功能默认启用,其它功能则选择加入,这需要更多的处理能力。 客户使用模式也会影响需求;例如,拥有数万个组织的企业的资源使用量可能会更高。

资源增加通常表现为 CPU 利用率更高、每秒 I/O 操作数 (IOPS) 更多、内存使用率更高或 Aqueduct 队列积压工作更大。 若要为这些更改做好准备,请在升级前检查系统的可用容量并应用任何修正建议。 在一天和一周中最繁忙的时间运行这些检查,以获得最准确的结果。

资源要求

升级实例之前,请务必验证系统是否满足必要的资源要求:

  1. CPU 使用率低于 70%
  2. 内存使用率低于 70%
  3. 磁盘未饱和
  4. Unicorn 队列低于 200-300 个
  5. Aqueduct 积压工作低于 1-2 小时

CPU 使用率低于 70%

  1. 检查 CPU 利用率****。 在 管理控制台 中,转到监视页 (https://HOSTNAME.com:8443/setup/monitor) 并查看 CPU 图。

    • 如果利用率通常低于 70%,请继续检查内存使用率****。
    • 如果利用率通常高于 70%,则系统不符合升级条件****。
  2. 将利用率与 CPU 负载平均值进行比较****。 该比较有助于确认可能的磁盘饱和。

    • 转到“Operational Health view”并检查 Load 图****。

    • 在矩阵中,找到 shortterm 行与 avg 列相交的值。

    • 计算负载平均值百分比:

      (short-term avg ÷ number of vCPUs) × 100
      
    • 在同一视图中,检查 CPU 图。 在矩阵中,找到 idle 行与 avg 列相交的值。 从 100 中减去这个值得到利用率。

  3. 解释结果****。

    如果 CPU 负载平均值百分比高于利用率 50% 以上,这可能表示资源争用。 在调查可能的磁盘饱和之前,请勿继续升级(请参阅“磁盘未饱和”)。

内存使用率低于 70%

  1. 检查内存使用率****。 在 管理控制台 中,转到监视页 (https://HOSTNAME.com:8443/setup/monitor) 并查看 Memory 图。

  2. 解释结果****。

    • 如果内存使用率通常低于 70%,则继续检查“磁盘未饱和”要求****。
    • 如果内存使用率通常高于 70%,则系统不符合升级条件****。

磁盘未饱和

  1. 检查提供程序规范。**** 如果云或硬件提供商提供了磁盘利用率指标,请使用这些指标来确认磁盘是否饱和。

    • 如果指标不可用,请从提供商请求磁盘规范,包括最大吞吐量和最大 IOPS。
    • 将这些限制与观察到的磁盘使用情况进行比较。 如果使用量接近最大值,则磁盘已饱和。
  2. 检查 管理控制台 中的磁盘图。**** 转到监视页 (https://HOSTNAME.com:8443/setup/monitor)。

    • 查看 Disk OperationsDisk Traffic 图。

    • 将 Y 轴值与提供商的规范(而非图上显示的最大比例)进行比较。

    • 查看数据磁盘和根磁盘。

这些图在“System & Application Insights”视图中可用。

  1. 解释结果****。 如果磁盘使用量接近提供商定义的最大值,则磁盘已饱和。 在这种情况下,系统不符合升级条件。

Unicorn 队列低于 200-300 个

  1. 检查“排队的请求”图。**** 在 管理控制台 中,转到监视页 (https://HOSTNAME.com:8443/setup/monitor) 并查看 Queued Requests 图。

此图在“System & Application Insights”视图中可用。

  1. 解释结果****。

    • 如果排队的请求始终低于 200 个,则继续检查“Aqueduct 积压工作低于 1-2 小时”要求****。
    • 如果排队的请求经常达到或超过 200-300 个,则系统不符合升级条件****。
  2. 可选:检查 Unicorn 辅助角色利用率。**** 在管理 shell 中,运行:

    ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git
    

    查看输出的最后一列。 如果所有进程都显示 > 90% utilization,则需要更多 Unicorn 辅助角色。

Aqueduct 积压工作低于 1-2 小时

  1. 检查 Aqueduct 队列深度。**** 在 管理控制台 中,转到监视页 (https://HOSTNAME.com:8443/setup/monitor) 并查看 Aqueduct queue depth 图。

此图在“System & Application Insights”视图中可用。

  1. 解释结果****。

    • 如果积压工作持续时间少于 1–2 小时,则你满足此要求****。
    • 如果积压工作持续时间通常超过 1–2 小时,则系统不符合升级条件****。
  2. 监视 index_high 队列。**** 大型部署可能会经历 index_high 队列深度的显著增加,这可能使积压情况加剧。 监视时,请特别注意此队列。

如果所有条件(CPU、内存、磁盘、Unicorn 队列、Aqueduct 积压工作)都得到满足,则你可以继续升级到目标功能版本****。 升级后,预计资源消耗会进一步增加。

如果任何条件未得到满足,请在尝试升级之前解决基础问题****。

升级硬件并微调辅助角色

如果系统不满足一个或多个资源要求,你需要在升级之前增加容量。 以下各节介绍如何添加硬件资源并调整辅助角色配置以解决常见瓶颈。

  1. CPU 超过 70%
  2. 内存超过 70%
  3. 磁盘饱和
  4. Unicorn 队列超过 200-300 个
  5. Aqueduct 积压工作超过 1-2 小时

CPU 超过 70%

如果 CPU 利用率经常超过 70%:

  • 增加 CPU 资源。**** 至少再添加 20% 的 vCPU。
  • 将新辅助角色考虑在内。**** 为每个辅助角色分配 1 个 vCPU。 例如,如果你添加 5 个 Unicorn 辅助角色和 10 个 Resque 辅助角色,请将 vCPU 增加至少 15 个。

内存超过 70%

如果内存使用率经常超过 70%:

  • 增加内存****。 添加额外的 RAM 以将平均使用率降低到 70% 以下。
  • 将新辅助角色考虑在内。**** 为每个辅助角色分配 1 GB 内存。 例如,如果你添加 5 个 Unicorn 辅助角色和 10 个 Resque 辅助角色,请将内存增加至少 15 GB。

磁盘饱和

如果磁盘饱和检查指示“饱和”,请升级到具有更高吞吐量和最大 IOPS 的磁盘。

Unicorn 队列超过 200-300 个

如果排队的 Unicorn 请求始终超过 200-300 个,你可能需要添加更多 Unicorn 辅助角色。 按照以下步骤,确定辅助角色的总目标数并更新配置。

1.估计其他辅助角色

在高峰时段运行以下命令,查看每个辅助角色的利用率:

ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git

示例输出:

git      3048972 3045762  0 Aug01 ?        00:07:47 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[00]: 20491 reqs,  10.8 req/s,   13ms avg,   85.2% util
git      3048979 3045762  0 Aug01 ?        00:07:53 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[01]: 20951 reqs,  12.5 req/s,   13ms avg,   80.3% util
git      3048985 3045762  0 Aug01 ?        00:08:04 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[02]: 21502 reqs,  10.5 req/s,   15ms avg,   76.5% util
git      3048992 3045762  0 Aug01 ?        00:07:45 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[03]: 20249 reqs,  14.2 req/s,   15ms avg,   86.9% util

平均请求数/秒为 12 req/s。

根据此输出,计算每秒的平均请求数 (req/s)。

  • 在上面的示例中:12 req/s。

  • 目标是将排队的请求数减少到 ≤100 个。

  • 公式:

    (Queued requests – 100) ÷ avg req/s
    
  • 示例:(280 – 100) ÷ 12 = 15 个额外需要的辅助角色。

    提示

    如果要确认你的发现结果,可以通过访问 GitHub Enterprise 支持、上传捆绑包并询问 Unicorn 辅助角色的总目标数来与我们联系。

2.检查当前配置

确保辅助角色(Unicorn + Resque)总数不超过 vCPU 数。 为每个辅助角色分配至少 1 个 vCPU。

检查当前数量:

  • Unicorn 辅助角色

    ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git | wc -l
    

    将计算出的新辅助角色数量与此值相加,得到总目标。

  • Resque 辅助角色

    ps -ef | grep aqueduct-1.1.0 | grep -v "grep aqueduct-1.1.0" | wc -l
    

3.调整配置

如果 Unicorn + Resque 辅助角色的总和超过 vCPU 数,请在继续之前添加更多 vCPU。

更新 Unicorn 辅助角色的数量:

ghe-config app.github.github-workers <NUM-WORKERS>
ghe-config-apply

替换为 Unicorn 辅助角色的总目标数。

Aqueduct 积压工作超过 1-2 小时

如果 Aqueduct 作业经常积压超过 1-2 小时,则添加低 Resqued 的辅助角色以降低队列备份的风险。 升级后,此问题通常会更严重。

1.添加低 Resqued 的辅助角色

  • 增加 5-10 个辅助角色****。 注意 CPU 容量 - 每个辅助角色至少需要 1 个 vCPU****。
ghe-config app.github.resqued-low-workers <NUM-WORKERS>
ghe-config-apply

替换为新的低 Resqued 的辅助角色的总数。

2.验证总辅助角色计数

确保 Unicorn + Resque 辅助角色的总数不超过 vCPU 总数。 有关检查当前辅助角色配置的说明,请参阅“Unicorn 队列超过 200-300 个”。