磁盘使用量已达到或接近容量上限

警告

仅删除本文中所述的文件。删除任何其他内容可能会导致数据丢失或使你的 GitHub Enterprise Server 实例无法使用。增加磁盘的大小需要停机，因此在开始之前规划维护时段。

症状

GitHub Enterprise Server 将数据存储在两个磁盘上：根磁盘，装载在 /；数据磁盘，装载在 /data/user。当任一磁盘已满时，服务无法再写入该磁盘，你可能会看到以下任一内容。

Web 界面返回 500 错误。
git push 操作失败。
服务无法启动，或在重启后停止响应。
配置运行会失败，包括在管理控制台中保存设置或升级实例时触发的运行。有关详细信息，请参阅“命令行实用程序”。

Elasticsearch 还会在磁盘写满之前对数据磁盘使用情况作出响应。使用达到 85%后，Elasticsearch 可以停止分配分片，群集运行状况变为红色。处于红色状态的群集会阻止配置运行，进而阻止升级以及在副本上启动或停止复制。将数据磁盘使用率保持在 85%以下，并在达到该阈值前很早就发出警报，将 60% 视为警告，将 75% 视为关键。有关详细信息，请参阅“建议的警报阈值”。

原因

当操作系统 GitHub Enterprise Server 和服务写入的文件累积速度快于清除速度时，根磁盘会被占满。最常见的原因是快速增长的日志文件（包括轮换日志），以及通过自动更新检查下载的升级包，或存储在手动下载到的位置，例如 /home/admin/。

随着存储库、包和 GitHub Actions 数据的增长超出预配的容量，数据磁盘会被填满。

如果 GitHub Actions 已启用，MSSQL 事务日志是数据磁盘填满的常见原因。在高可用性配置中，数据库在 FULL 恢复模式下运行，这是复制所必需的，因此日志空间仅在备份运行时才可重新使用。如果备份不经常运行或失败，日志会一直扩展，直到它们填满数据磁盘，或者某个日志达到每个文件 2 TB 的限制，这也会导致 runner 无法注册。

确认该问题

通过 SSH 连接到管理 shell。有关详细信息，请参阅“访问管理 shell (SSH)”。

检查每个本地磁盘上使用的空间量。

df -h -t ext4

读取装载在 /（即根磁盘）和装载在 /data/user（即数据磁盘）上的行对应的 Use% 列。

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              98G   93G  1.1G  99% /
/dev/mapper/ghe_user  251G   50G  189G  21% /data/user

如果两个磁盘都报告可用空间，但服务仍无法写入，请检查 inode 使用情况。具有可用空间的磁盘仍可能 inode 耗尽。
```
df -i -t ext4
```
确定使用空间的内容，以及可释放部分空间的机会。此报告涉及根磁盘和数据磁盘。
```
ghe-check-disk-usage
```

解决问题

根据 ghe-check-disk-usage 输出进行操作。回收空间比调整大小更快，且无需停机，因此在输出结果能提供可采取操作的信息时，请先尝试这种方法。如果不是这样，则该实例需要更多存储空间。

回收根磁盘上的空间

如果输出在 /var/lib/ghe-updates 下列出了升级包，请删除其中已安装版本对应的升级包，或者不打算安装的版本对应的升级包。每个包都有数 GB 大小。用文件名替换 PACKAGE。
```
sudo rm /var/lib/ghe-updates/PACKAGE
```
如果输出列出的升级包位于 /home/admin 以下位置，或你手动下载到的其他任何位置，请删除已安装或不再需要的任何包。将 PACKAGE 替换为各自的路径。
```
sudo rm PACKAGE
```
如果输出在/var/log下列出了以.gz或.1结尾的大型日志文件，请将其删除。这些已轮换，不再被写入。将 LOG-FILE 替换为每个路径。
```
sudo rm LOG-FILE
```
警告

将此视为快速释放空间的紧急措施。它无法解决导致日志量产生的根本原因，因此，如果这种情况持续下去，轮换后的日志还会再次出现，磁盘也会再次被填满。如果在删除它们后空间再次被占用，请联系 GitHub 支持而不是重复此步骤。
确认已回收空间。
```
df -h /
```

回收数据磁盘上的空间

仅当启用 GitHub Actions 时，这才适用，因为 MSSQL 仅在这种情况下运行。

检查输出中的 ghe-check-disk-usage MSSQL 事务日志分析，其中列出 /data/user/mssql/data 下以 .ldf 结尾的文件，并标记任何异常大的文件。这些日志在备份不经常运行时增长，无法释放其中的空间，并且是导致数据磁盘占满的常见原因。

如果输出标记大型事务日志，请参阅截断 MSSQL 事务日志，了解如何确认原因并截断它们。

增加存储容量

如果 ghe-check-disk-usage 未识别轮换的日志文件、升级包、/data/user/tmp 下的旧文件或超大的 MSSQL 事务日志，则没有可安全回收的内容，并且实例需要更多的存储。如果回收空间后不久，使用量将返回到同一级别，则同样适用。

按照增加存储容量增加根磁盘或数据磁盘的大小。

防止再次发生

一旦磁盘使用率达到容量上限，通常还会再次达到容量上限，因此要同时监控两个磁盘，并在它们被写满之前采取行动。

针对根磁盘和数据磁盘使用情况发出警报，以便在任一磁盘被写满前有时间做出响应。
查看使用情况实际需要的存储量，而不是调整到最低大小。有关详细信息，请参阅“排除资源分配问题”。
减少源头的日志量，以便轮换的日志不会重新占满根磁盘。轮询 REST API 的客户端经常生成大量日志数据，而 Webhook 是一种更高效的替代方法。有关详细信息，请参阅“关于网络钩子”。
如果 GitHub Actions 已启用，请按计划运行备份并检查它们是否正在完成，以免 MSSQL 事务日志无限增长。有关详细信息，请参阅“配置备份计划”。

联系 GitHub 支持

如果这些步骤无法解决问题，或者您不确定其中任何一步该如何操作，请联系 GitHub 支持，而不要继续。有关详细信息，请参阅“创建支持工单”。

如果已打开支持工单，附加支持包有助于 GitHub 支持更快地诊断问题。有关详细信息，请参阅“向GitHub支持提供数据”。

注意

默认情况下，支持包将写入数据磁盘。如果数据磁盘已满，则生成一个可能会失败。

在本文中

症状

原因