目录

简介

先决条件

要求

使用的组件

概述

分析和观察

磁盘利用率快照

故障排除过程

步骤 1：使用journalctlVacuum清理旧日志

第2步：配置日志保留以备将来防御

可选步骤3:解决重新启动错误

变更后验证

建议

简介

本文档介绍如何解决RCM中/dev/vda3文件系统的高磁盘空间利用率问题。

先决条件

要求

思科建议您了解以下内容：

- StarOS控制和用户平面分离(CUPS)系统架构和管理。

- 用于监视文件系统和磁盘使用情况的基本Linux/Unix命令。

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

概述

在具有控制和用户平面分离(CUPS)的思科超数据包核心部署中，冗余控制管理器(RCM)在控制平面操作和管理中扮演着关键角色。在RCM节点上稳定的文件系统利用率对于确保日志记录、监控和用户会话管理顺利运行非常重要。

根文件系统(/dev/vda3)上的高磁盘空间利用率可能导致系统不稳定、日志写入失败，甚至服务重新启动（如果未选中）。这篇文章概括介绍了为解决RCM节点中的高磁盘利用率而做的分析、故障排除步骤和预防措施。

分析和观察

在监控期间，发现RCM节点在其根文件系统上达到了72%的利用率。

磁盘利用率快照

df -kh

Filesystem Size Used Avail Use% Mounted on

tmpfs 6.3G 9.7M 6.3G 1% /run

/dev/vda3 39G 27G 11G 72% /

tmpfs 32G 4.0K 32G 1% /dev/shm

tmpfs 5.0M 0 5.0M 0% /run/lock

/dev/vda2 488M 48K 452M 1% /var/tmp

/dev/vda1 488M 76K 452M 1% /tmp

在进一步调查中，发现/var/log/journal/下的日志记录已显着增长。仅在7月生成的日志就占有约3 GB的空间。

故障排除过程

要控制磁盘利用率，需要应用所需的更改实施步骤：

步骤 1：使用journalctl Vacuum清理旧日志

仅保留最近2周的日志：

sudo journalctl --vacuum-time=2weeks

或限制日志大小（例如，仅保留600 MB）：

sudo journalctl --vacuum-size=600M

第2步：配置日志保留以备将来防御

编辑日志配置：

vi /etc/systemd/journald.conf

添加/修改参数：

MaxRetentionSec=2week

应用配置：

sudo systemctl restart systemd-journald

可选步骤3:解决重新启动错误

在第2步中重新启动systemd-journald服务时，可能会出现以下错误：

Error : Failed to allocate directory watch: Too many open files

1. systemd-journald使用inotify监视日志目录是否存在更改。

2. 每个watch或monitor设置计数达到特定内核限制。

有问题的RCM中定义的当前限制为：

cat /proc/sys/fs/inotify/max_user_watches

501120

cat /proc/sys/fs/inotify/max_user_instances

128

ulimit -n

1024

从收集的输出中：

- 最大识别监视：501120

- 最大inotify实例数：128

日志的打开文件描述符限制：1024

输出值限制中的任一（或全部）都可能已命中，导致错误。因此，我们收集了当前使用值，并将其与收集的输出限制进行比较：

sudo lsof -p $(pidof systemd-journald) | wc -l

65

echo "Root inotify instances: $(sudo find /proc/*/fd -user root -type l -lname 'anon_inode:inotify' 2>/dev/null | wc -l) / $(cat /proc/sys/fs/inotify/max_user_instances)"

Root inotify instances: 126 / 128

- 当前通知实例：126

- 当前打开的文件描述符：65

似乎根已使用126个（共128个）允许的inotify实例。这使journald在重新启动时几乎没有空间创建新的inotify实例。

要解决错误，请执行以下操作：我们可以增加max_user_instances值，然后重新启动服务：

# Temporarily increase the limit (until next reboot)

echo 256 > /proc/sys/fs/inotify/max_user_instances

sudo systemctl restart systemd-journald

# Temporarily increase the limit (until next reboot)

echo 256 > /proc/sys/fs/inotify/max_user_instances

sudo systemctl restart systemd-journald

变更后验证

应用更改后，磁盘利用率降至61%，节点将恢复到正常运行状态。

df -kh

Filesystem      Size  Used Avail Use% Mounted on

tmpfs           6.3G  9.7M  6.3G   1% /run

/dev/vda3        39G   23G   15G  61% /

tmpfs            32G  4.0K   32G   1% /dev/shm

tmpfs           5.0M     0  5.0M   0% /run/lock

/dev/vda2       488M   48K  452M   1% /var/tmp

/dev/vda1       488M   76K  452M   1% /tmp

建议

- 在部署中的所有RCM节点上实施相同的配置，以将磁盘利用率保持在安全限制内。

- 在执行更改之前，始终将目标RCM设置为standby mode，以避免影响实时流量。

- 作为主动系统运行状况检查的一部分，定期监控/dev/vda3利用率和日志日志日志增长。