升级前检查系统容量

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

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

资源要求

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

       [CPU 使用率低于 70%](#cpu-usage-below-70)

       [内存使用率低于 70%](#memory-usage-below-70)

       [磁盘未饱和](#disk-not-saturated)

       [Unicorn 队列低于 200-300 个](#unicorn-queue-under-200300)

       [Aqueduct 积压少于 1-2 小时](#aqueduct-backlog-under-12-hours)

CPU 使用率低于 70%

检查 CPU 利用率****。在管理控制台中，转到监视页 (https://HOSTNAME.com:8443/setup/monitor) 并查看 CPU 图。
- 如果利用率通常低于 70%，请继续检查内存使用率。
- 如果利用率通常高于 70%，则系统不符合升级条件****。
将利用率与 CPU 负载平均值进行比较****。该比较有助于确认可能的磁盘饱和。
- 进入操作健康视图并检查图Load。
- 在矩阵中，找到 shortterm 行与 avg 列相交的值。
- 计算负载平均值百分比：
```
(short-term avg ÷ number of vCPUs) × 100
```
- 在同一视图中，检查 CPU 图表。在矩阵中，找到 idle 行与 avg 列相交的值。从 100 中减去这个值得到利用率。
解析结果****。

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

内存使用率低于 70%

检查内存使用率****。在管理控制台中，转到监视页 (https://HOSTNAME.com:8443/setup/monitor) 并查看 Memory 图。
解释结果****。
- 如果内存使用率通常低于 70%，则继续至磁盘未饱和。
- 如果内存使用率通常高于 70%，则系统不符合升级条件****。

磁盘未饱和

检查供应商规范。**** 如果云或硬件提供商提供了磁盘利用率指标，请使用这些指标来确认磁盘是否饱和。
- 如果指标不可用，请从提供商请求磁盘规范，包括最大吞吐量和最大 IOPS。
- 将这些限制与观察到的磁盘使用情况进行比较。如果使用量接近最大值，则磁盘已饱和。
检查管理控制台中的磁盘图。**** 转到监视页 (https://HOSTNAME.com:8443/setup/monitor)。
- 查看 Disk Operations 和 Disk Traffic 图。
- 将 Y 轴值与提供商的规范（而非图上显示的最大比例）进行比较。
- 查看数据磁盘和根磁盘。

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

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

Unicorn 队列低于 200-300 个

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

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

解释结果****。
- 如果排队的请求始终低于 200 个，则继续处理积压工作低于 1-2 小时。
- 如果排队的请求经常达到或超过 200-300 个，则系统不符合升级条件****。
可选：检查 Unicorn 辅助角色利用率。**** 在管理 shell 中，运行：
```
ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git
```
查看输出的最后一列。如果所有进程都显示 > 90% utilization，则需要更多 Unicorn 辅助角色。

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

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

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

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

如果满足所有条件（CPU、内存、磁盘、Unicorn 队列、Aqueduct 任务积压），就可以升级到目标版本。升级后，预计资源消耗会进一步增加。

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

升级硬件并微调辅助角色

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

```
       [CPU 超过 70%](#cpu-above-70)
```

       [内存超过 70%](#memory-above-70)

```
       [磁盘饱和](#disk-saturated)
```

       [Unicorn 队列超过 200-300 个](#unicorn-queue-above-200300)

       [Aqueduct 积压量超过 1至2 小时](#aqueduct-backlog-above-12-hours)

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。

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 个请求/秒。
目标是将排队的请求数减少到 ≤100 个。
公式：
```
(Queued requests – 100) ÷ avg req/s
```
示例：(280 – 100) ÷ 12 = 15 个额外需要的工人。

提示

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

2.检查当前配置

确保辅助角色（Unicorn + Resque）总数不超过 vCPU 数。为每个工作节点分配至少 1 个 vCPU。

检查当前数字：

独角兽员工

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 queue above 200–300中的说明以检查当前工作进程配置。

在本文中