目錄

簡介

必要條件

需求

採用元件

概觀

分析和觀察

磁碟利用率快照

疑難排解程式

步驟 1:使用journalctlVacuum清理舊日誌

第2步：配置日誌保留以備將來防禦

可選步驟3:解決重新啟動錯誤

變更後驗證

建議

簡介

本文檔介紹如何解決RCM中/dev/vda3檔案系統的高磁碟空間利用率問題。

必要條件

需求

思科建議您瞭解：

- StarOS控制和使用者平面分離(CUPS)系統架構和管理。

- 用於監視檔案系統和磁碟使用情況的基本Linux/Unix命令。

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

概觀

在具有控制和使用者平面分離(CUPS)的思科Ultra資料包核心部署中，冗餘控制管理器(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真空清理舊日誌

僅保留最近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

看起來根已經使用了128個允許的inotify例項中的126個。這樣，在重新啟動日誌時，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置於備用模式，以避免影響即時流量。

- 作為主動系統運行狀況檢查的一部分，定期監視/dev/vda3利用率和日誌日誌日誌增長。