Website Báo Lỗi 503 Dù Còn Dung Lượng? Thủ Phạm Là Inode Đầy

Khi quản trị VPS, chúng ta thường có thói quen kiểm tra:

CPU
RAM
Dung lượng ổ cứng
Load Average

Nhưng có một chỉ số rất quan trọng lại thường bị bỏ qua: Inode.

Trong bài viết này, Cocosoft chia sẻ một sự cố thực tế mà chúng tôi vừa xử lý trên máy chủ.

Nội dung bài viết

Hiện tượng

Một VPS chạy:

Ubuntu
CyberPanel
OpenLiteSpeed
MariaDB
Nhiều website WordPress

Bỗng nhiên xuất hiện hàng loạt lỗi:

CyberPanel (cổng 8090) báo 500 Internal Server Error
Toàn bộ website trả về 503 Service Unavailable
MariaDB không thể khởi động lại
OpenLiteSpeed hoạt động không ổn định

Điều đáng nói là khi kiểm tra tài nguyên:

CPU chỉ khoảng 1%
RAM vẫn còn
Ổ cứng vẫn còn GB trống

Mọi thứ đều có vẻ bình thường.

Bước đầu chẩn đoán

Thông thường chúng ta sẽ kiểm tra:

df -h

Kết quả cho thấy ổ cứng vẫn còn dung lượng.

Nếu chỉ nhìn vào đây, rất dễ kết luận rằng nguyên nhân không nằm ở hệ thống lưu trữ.

Tuy nhiên, trong log của CyberPanel lại xuất hiện thông báo:

No space left on device

Trong khi ổ cứng vẫn chưa đầy.

Đó là dấu hiệu cho thấy vấn đề có thể không nằm ở dung lượng lưu trữ mà nằm ở inode.

Kiểm tra Inode

Chỉ cần chạy:

df -i

Kết quả:

IUse% 100%
IFree 0

Điều này đồng nghĩa với việc hệ điều hành không còn khả năng tạo thêm file mới.

Một server Linux hoàn toàn có thể:

Còn hàng chục GB dung lượng
Nhưng vẫn không thể hoạt động nếu inode đã sử dụng hết

Tiếp tục điều tra

Thay vì kiểm tra dung lượng thư mục, chúng tôi kiểm tra số lượng file.

for d in /var/*; do
    echo -n "$d: "
    find "$d" -xdev | wc -l
done | sort -k2 -nr

Kết quả thật bất ngờ:

/var/spool
≈ 9.4 triệu file

Tiếp tục phân tích:

for d in /var/spool/*; do
    echo -n "$d: "
    find "$d" | wc -l
done | sort -k2 -nr

Kết quả:

/var/spool/postfix/maildrop
≈ 9.4 triệu file

Thủ phạm đã lộ diện.

Điều thú vị

Server này không hề sử dụng Postfix.

Postfix đã được vô hiệu hóa (masked).
Nhà cung cấp VPS cũng chặn cổng 25 nên không thể gửi email trực tiếp.

Tuy nhiên, thư mục maildrop vẫn còn tồn tại từ trước và tích lũy hàng triệu file nhỏ.

Chính số lượng file khổng lồ này đã làm cạn toàn bộ inode của hệ thống.

Cách xử lý

Sau khi xác định nguyên nhân, chúng tôi:

Gỡ hoàn toàn Postfix.
Xóa mail queue còn tồn đọng.
Kiểm tra lại inode.
Khởi động lại MariaDB.
Khởi động lại OpenLiteSpeed.
Khởi động lại CyberPanel.

Ngay sau đó toàn bộ website hoạt động bình thường trở lại.

Kết quả

Trước khi xử lý

CPU: ~1%
Disk: 97%
Inode: 100%
CyberPanel: 500
Website: 503

Sau khi xử lý

Disk: 54%
Inode: 25%
CyberPanel hoạt động bình thường.
MariaDB hoạt động bình thường.
Tất cả website hoạt động trở lại.

Bài học rút ra

Rất nhiều quản trị viên chỉ kiểm tra:

df -h

Trong khi lại quên:

df -i

Nếu chỉ nhìn vào dung lượng ổ cứng, bạn có thể mất rất nhiều thời gian để tìm nguyên nhân.

Trong trường hợp này, vấn đề không phải CPU, không phải RAM, cũng không phải ổ cứng đầy, mà là hệ thống đã hết inode.

Checklist khi gặp lỗi 500 hoặc 503

Nếu VPS hoặc website đột nhiên trả về lỗi 500/503, hãy kiểm tra theo thứ tự:

✅ CPU

✅ RAM

✅ Disk Usage

✅ Inode (df -i)

✅ MariaDB

✅ OpenLiteSpeed

✅ Log hệ thống

✅ Mail Queue

Kết luận

Đây là một trong những sự cố hiếm gặp nhưng rất đáng nhớ.

Một thư mục chứa khoảng 9,4 triệu file nhỏ đã khiến toàn bộ VPS gần như tê liệt, dù CPU chỉ sử dụng khoảng 1%.

Hy vọng case study này sẽ giúp bạn tiết kiệm nhiều thời gian nếu một ngày nào đó gặp thông báo:

No space left on device

trong khi ổ cứng vẫn còn rất nhiều dung lượng.

Nếu bạn đang vận hành VPS, hãy bổ sung Inode vào danh sách các chỉ số cần giám sát. Đôi khi đây chính là “mắt xích còn thiếu” để giải quyết những lỗi tưởng chừng rất khó hiểu.

Tác giả: Cocosoft Team