Làm thế nào để kiểm tra mức sử dụng inode trong HestiaCP? Nguyên nhân nào gây ra tình trạng không thể ghi tệp ngay cả khi dung lượng ổ đĩa còn nhiều?

Vài ngày trước, một người bạn nhắn tin cho tôi vào đêm khuya nói rằng máy chủ của anh ấy bị sập.

Các triệu chứng cụ thể đặc biệt kỳ lạ: trang web đột nhiên bắt đầu báo lỗi, không thể ghi nhật ký và việc tạo tệp mới ngay lập tức báo rằng ổ đĩa đã đầy.

Nhưng khi kiểm tra bằng lệnh `df -h`, anh ta đã rất sốc khi phát hiện ra rằng ổ đĩa rõ ràng vẫn còn hàng chục gigabyte dung lượng trống. Làm sao nó có thể đầy được?

Tôi nói với anh ấy ngay lúc đó, "Anh bạn, không chỉ là ổ cứng của anh đầy dung lượng lưu trữ, mà Inode của anh còn bị quá tải nữa."

Anh ta trả lời bằng một dấu chấm hỏi: Inode chính xác là gì?

Thực tế, nhiều người phản ứng y hệt như anh ấy khi lần đầu tiên mắc phải sai lầm này, bởi vì không ai ở trường từng dạy họ những điều này.

Trước tiên, hãy làm rõ Inode là gì.

Hãy coi nó như một tấm thẻ chỉ mục trong thư viện, và bạn sẽ dễ dàng hiểu được.

Dung lượng ổ đĩa giống như một giá sách; bạn có thể để bao nhiêu cuốn sách lên đó tùy thuộc vào dung lượng của nó, điều này ai cũng dễ hiểu.

Inode giống như một thẻ chỉ mục cho mỗi cuốn sách, ghi lại tên, vị trí và người đã di chuyển nó.

Trong Linux , mọi tập tin và mọi thư mục đều phải chiếm một inode, bất kể kích thước của tập tin đó nhỏ đến đâu.

Ngay cả khi đó là một tập tin trống, hệ thống vẫn sẽ tiêu tốn một thẻ chỉ mục cho nó.

Hệ thống có giới hạn về tổng số lượng tệp mà nó có thể tạo; giới hạn này chính là tổng số lượng innode.

Khi inode được sử dụng hết, ngay cả khi ổ đĩa của bạn vẫn còn hàng trăm gigabyte dung lượng trống, hệ điều hành sẽ từ chối tạo bất kỳ tập tin mới nào.

Không thể ghi nhật ký, không thể tạo bộ nhớ đệm và trang web bị sập hoàn toàn - đó là cảnh tượng kỳ lạ mà bạn đang chứng kiến.

Thành thật mà nói, đây là một tình huống thực sự khó xử vì thông báo lỗi được gửi từ một vị trí mà bạn không hề để ý đến.

Mẹo đầu tiên là sử dụng lệnh `df -i` để có cái nhìn tổng quan nhanh chóng.

Trong môi trường HestiaCP , bạn chỉ cần SSH vào terminal và gõ dòng lệnh này.

df -i

Nó sẽ liệt kê tổng số innode, số lượng đã sử dụng và số lượng còn lại cho mỗi phân vùng được gắn kết.

Trong kết quả đầu ra, có một cột gọi là IUse%, đây là chỉ số quan trọng mà bạn nên theo dõi.

Nếu IUse% của một phân vùng đạt 100%, ngay cả khi phân vùng đó vẫn còn nhiều dung lượng trống, nó sẽ không thể tạo thêm bất kỳ tập tin hoặc nhật ký mới nào nữa.

Tôi đề nghị bạn tôi chạy thử cái này trước, để nó có thể xác định chính xác xem vấn đề có phải do Inode gây ra hay không chỉ trong vài giây , điều này sẽ nhanh hơn nhiều so với việc đoán mò.

Phương pháp thứ hai là sử dụng lệnh `find` để đếm chính xác số lượng người dùng cụ thể.

Sau khi xác nhận vấn đề nằm ở innode, bước tiếp theo là tìm ra ai đang tiêu thụ thẻ chỉ mục quá mức.

HestiaCP có một thư mục chính riêng biệt cho mỗi người dùng. Bạn có thể dễ dàng đếm tổng số tệp và thư mục nằm trong một thư mục trang web cụ thể.

find /home/用户名/web/你的域名/public_html | wc -l

Hãy thay thế "username" và "your domain name" bằng đường dẫn thực tế của bạn. Con số thuần túy được trả về bởi thiết bị đầu cuối là tổng số tất cả các tệp và thư mục trong thư mục đó.

Mỗi tập tin hoặc thư mục tương ứng với một inode, vì vậy con số này thể hiện mức độ sử dụng inode.

Nếu bạn quá lười kiểm tra từng mục một và muốn xem phân bố sử dụng của tất cả người dùng trên toàn bộ trang web cùng một lúc, thì cũng có một lệnh vòng lặp duy nhất.

for d in /home/*; do echo -n "$d: "; find "$d" 2>/dev/null | wc -l; done

Dòng lệnh này sẽ in ra tổng số lượng tệp trong mỗi thư mục người dùng nằm dưới /home, giúp dễ dàng phát hiện thư mục người dùng nào có số lượng tệp cao bất thường.

Chiến lược thứ ba là xác định các thư mục con tiêu thụ nhiều iốt nhất.

Đôi khi bạn biết một trang web có giá trị Inode cao đến mức vô lý, nhưng bạn vẫn không thể tìm ra vấn đề với màn hình đầy ắp các tệp tin.

Trong những trường hợp như vậy, bạn cần phải đi sâu xuống một cấp để tìm các thư mục con chứa nhiều tệp nhỏ, chẳng hạn như thư mục bộ nhớ đệm, thư mục phiên và thư mục nhật ký — đây là những khu vực gây ra nhiều vấn đề nhất.

find /home/用户名/web/你的域名/public_html -type d -exec sh -c 'echo -n "{}: "; find "{}" -maxdepth 1 | wc -l' \; | sort -n -r -k 2 | head -n 10

Lệnh này sẽ liệt kê 10 thư mục con có dung lượng chứa nhiều tập tin nhất.

Đường dẫn ở đầu danh sách là nơi tập trung rất nhiều tệp nhỏ.

Tôi nói với bạn tôi rằng có lẽ đó là một plugin bộ nhớ đệm nào đó đang âm thầm tạo ra các tập tin nhỏ, và chạy dòng lệnh này về cơ bản sẽ xác nhận điều đó.

Mẹo thứ tư là kiểm tra giới hạn hạn ngạch bằng cách sử dụng repquota.

Nếu máy chủ của bạn đã bật hạn ngạch hệ thống tập tin Linux, bạn có thể xem xét vấn đề từ một góc độ khác.

repquota -a

Lệnh này sẽ hiển thị giới hạn tệp và mức sử dụng tệp thực tế cho tất cả người dùng.

Hãy chú ý kỹ đến mục Giới hạn tệp trong kết quả; cột đã sử dụng cho biết có bao nhiêu tệp đã được sử dụng.

Các cột "mềm" và "cứng" thể hiện ngưỡng giới hạn mềm và cứng. Khi "đã sử dụng" đạt đến "cứng", hệ thống sẽ từ chối tạo tệp mới ngay lập tức.

Đây là một câu chuyện hoàn toàn khác so với việc bạn còn bao nhiêu dung lượng trống trên ổ đĩa.

Để kết thúc, chúng ta hãy cùng xâu chuỗi các manh mối của cuộc điều tra.

Hãy quay lại với người bạn đã làm sập máy chủ giữa đêm ở phần đầu.

Anh ấy đã thực hiện bốn bước mà tôi đã mô tả, bắt đầu bằng lệnh `df -i` để xác nhận rằng inode thực sự đã đầy.

Sau đó, bằng cách sử dụng lệnh find, chúng tôi đã định vị được thư mục bộ nhớ cache của một trang web cũ bị bỏ hoang, nơi liên tục tạo ra các tập tin nhỏ.

Cuối cùng, kiểm tra `repquota` đã xác nhận rằng nó thực sự đã đạt đến giới hạn tối đa.

Sau khi xóa sạch đống bộ nhớ cache rác đó, trang web đã hoạt động trở lại ngay lập tức.

Vì vậy, lần tới nếu bạn gặp phải tình huống kỳ lạ "ổ đĩa rõ ràng còn dung lượng nhưng bạn không thể ghi tệp", đừng vội vàng thêm ổ cứng.

Đầu tiên, hãy sử dụng lệnh `df -i` để xem inode; sự thật rất có thể đang ẩn giấu trên tấm thẻ ghi chú mà bạn chưa từng để ý đến trước đây.

Tôi thực sự tin rằng những điều nhỏ nhặt mang tính thực tiễn ẩn sâu trong hệ thống này hữu ích hơn nhiều so với việc ghi nhớ hàng trăm danh sách tối ưu hóa.