Hết dung lượng là nguyên nhân phổ biến nhất khiến máy chủ ngừng hoạt động mà chẳng có ý đồ xấu nào tham gia. Trang web trả về 500, cơ sở dữ liệu không ghi được, thư không gửi đi — còn df -h trong lúc đó báo còn vài gigabyte trống. Hãy đi qua cả ba trường hợp khiến điều đó xảy ra, và qua những gì đáng biết về SMART.

Trường hợp một: hết inode

Một hệ thống tệp có hai tài nguyên giới hạn: chỗ cho nội dung và các bản ghi về tệp. Cái thứ hai cạn kiệt độc lập với cái thứ nhất:

df -h
df -i

Nếu IUse% trong lệnh thứ hai bằng 100 thì vấn đề là inode. Chỗ thì có, nhưng không tạo được dù chỉ một tệp, kể cả tệp rỗng.

Thủ phạm luôn là những cái quen thuộc: hàng triệu tệp nhỏ xíu. Các phiên PHP trong /var/lib/php/sessions có cơ chế thu gom rác bị hỏng. Bộ nhớ đệm của ứng dụng chẳng bao giờ được dọn. Hàng đợi thư bị kẹt. Một thư mục ảnh thu nhỏ. Có thể tìm chúng thế này:

sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

Lệnh này liệt kê các thư mục có nhiều tệp nhất. Trên hệ thống lớn nó chạy vài phút — đó là bình thường.

Trường hợp hai: tệp đã xóa mà chỗ không trở lại

Tình huống còn xảo quyệt hơn. Ai đó đã gỡ một nhật ký phình to bằng rm, nhưng tiến trình đang ghi vào nó vẫn giữ nó mở. Tệp không còn trong thư mục, chỗ vẫn bị chiếm, và sẽ như vậy cho tới khi tiến trình được khởi động lại.

sudo lsof +L1

Lệnh này cho thấy các tệp có số liên kết bằng không trong hệ thống tệp nhưng vẫn bị một tiến trình giữ. Cách chữa là khởi động lại hoặc nạp lại nhẹ nhàng tiến trình đó, chứ không phải đi săn xem «gigabyte biến đi đâu».

Từ đó mà có quy tắc: một nhật ký phình to thì không xóa mà cắt về rỗng, nhờ đó descriptor đang mở vẫn dùng được:

sudo truncate -s 0 /var/log/huge.log

Và ngay sau đó hãy thiết lập việc xoay vòng — nếu không tất cả sẽ lặp lại trong vòng một tuần.

Trường hợp ba: nhật ký đã ngốn hết

Chỗ đã đi đâu chính xác thì thấy được bằng cách đi xuống từng mức:

sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -h

Cờ -x giữ cho nó không lang thang sang các hệ thống tệp khác; thiếu nó thì phép đếm bò vào /proc và các mount mạng. Tất cả những việc này làm trong ncdu thì thoải mái hơn, nếu có sẵn.

Những kẻ ngốn quen thuộc:

  • journald. Một lệnh giải quyết xong: journalctl --disk-usage. Nó được giới hạn bằng dòng SystemMaxUse=500M trong /etc/systemd/journald.conf và được dọn một lần bằng journalctl --vacuum-size=200M;
  • nhật ký của các công cụ bảo mật. Suricata với cấu hình mặc định ghi ba chục loại sự kiện và không tự thiết lập việc xoay vòng — trên một máy chủ thật nó tạo ra 15 GB trong hai ngày. Điều tương tự xảy ra với audit.log và với nhật ký debug trong nginx;
  • bản sao lưu được ghi lên cùng đĩa và không bao giờ bị gỡ;
  • bộ nhớ đệm của apt — apt clean thỉnh thoảng trả lại vài gigabyte.

Đôi lời về /boot

Một phân vùng nhỏ đầy lên vì các nhân cũ. Tự nó không làm sập trang web, nhưng nó chặn đứng việc cập nhật: nhân mới sẽ không cài được, và cả hàng đợi gói kẹt lại phía sau nó. Chữa bằng apt autoremove --purge, và phòng ngừa bằng cách bật việc tự động gỡ các nhân không dùng trong cấu hình cập nhật tự động.

SMART: thuộc tính nào quan trọng

Một lưu ý trước: trên máy chủ ảo thì SMART thường không dùng được — đĩa là ảo và bạn không thấy đĩa vật lý bên dưới. Đó không phải lỗi, đơn giản là không có dữ liệu. Mọi thứ tiếp theo liên quan đến máy chủ riêng và phần cứng của chính bạn.

sudo smartctl -a /dev/sda

Dòng SMART overall-health self-assessment test result: PASSED không phải lý do để yên tâm: nó vẫn xanh gần như cho tới lúc ổ đĩa chết. Thứ cần xem là các bộ đếm cụ thể:

  • 5, Reallocated_Sector_Ct — số sector đã tái phân bổ. Khác không nghĩa là ổ đĩa đã bắt đầu suy thoái; tăng dần theo thời gian nghĩa là hãy thay ngay đừng chần chừ;
  • 197, Current_Pending_Sector — các sector không đọc được và đang chờ quyết định. Đáng lo nhất trong nhóm: nó thường có nghĩa một phần dữ liệu đã không thể khôi phục;
  • 198, Offline_Uncorrectable — điều tương tự, đã được xác nhận bằng kiểm tra;
  • SSD: Percentage Used / Media_Wearout_Indicator — độ bền ghi đã tiêu hao. Một con số dự đoán được, và là cái để lên kế hoạch thay thế.

Ngược lại, nhiệt độ và số giờ hoạt động tự chúng chẳng nói lên gì: một ổ đĩa chạy năm năm với các bộ đếm lỗi bằng không đáng tin cậy hơn một ổ mới có số 1 ở thuộc tính 197.

Ý nghĩa của việc theo dõi

Tất cả những điều trên là phản ứng với chuyện đã xảy ra rồi. Trong khi cả việc đĩa đầy dần lẫn sự hao mòn SSD đều là những quá trình chậm và hoàn toàn dự đoán được: biểu đồ mức chiếm dụng trong hai tuần cho thấy ngày hết chỗ từ rất lâu trước đó. Khác biệt giữa «trang web sập từ ba giờ sáng» và «thứ Năm phải dọn nhật ký» chỉ là ở chỗ con số ấy có ở trước mắt bạn hay không. Khi ghép lại thì nó trông ra sao — xem ở trang demo bên dưới.