HestiaCP에서 inode 사용량을 어떻게 확인하나요? 디스크 공간이 충분한데도 파일을 쓸 수 없는 이유는 무엇인가요?

며칠 전 늦은 밤에 친구가 서버가 다운됐다는 메시지를 보냈습니다.

구체적인 증상은 특히 기이했습니다. 웹사이트에서 갑자기 오류가 발생하기 시작했고, 로그를 기록할 수 없었으며, 새 파일을 생성하려고 하면 즉시 디스크 용량이 가득 찼다는 메시지가 나타났습니다.

하지만 `df -h` 명령어로 확인해 보니 디스크에 수십 기가바이트의 여유 공간이 분명히 남아 있는 것을 보고 그는 깜짝 놀랐습니다. 어떻게 디스크가 꽉 찼을 수 있단 말인가?

나는 그 자리에서 바로 그에게 "형님, 저장 공간이 부족한 정도가 아니라, 이노드(Inode)가 과부하 상태입니다."라고 말했습니다.

그는 물음표를 달며 “이노드(Inode)가 정확히 뭔가요?”라고 답했습니다.

사실 많은 사람들이 처음 이 함정에 빠졌을 때 그와 똑같은 반응을 보입니다. 왜냐하면 학교에서 이런 내용을 전혀 가르쳐주지 않았기 때문입니다.

먼저 이노드(Inode)가 무엇인지 명확히 해봅시다.

도서관 색인 카드라고 생각하면 쉽게 이해할 수 있을 거예요.

디스크 공간은 책장과 같습니다. 책장에 얼마나 많은 책을 꽂을 수 있는지는 용량에 따라 달라지는데, 이는 누구나 쉽게 이해할 수 있는 개념입니다.

이노드는 각 책에 대한 색인 카드와 같으며, 책의 이름, 위치 및 이동한 사람을 기록합니다.

리눅스 에서는 파일 크기에 상관없이 모든 파일과 디렉터리는 반드시 inode를 차지해야 합니다.

파일이 비어있더라도 시스템은 해당 파일에 대해 인덱스 카드를 사용합니다.

이 시스템은 생성할 수 있는 총 파일 수에 제한이 있으며, 이 제한은 총 인노드 수와 같습니다.

inode가 모두 소진되면 디스크에 수백 기가바이트의 여유 공간이 남아 있더라도 운영 체제는 새 파일을 생성하지 않습니다.

로그를 기록할 수 없고, 캐시를 생성할 수 없으며, 웹사이트가 완전히 다운되는 이상한 상황을 목격하고 계신 겁니다.

솔직히 말씀드리면, 이 상황은 정말 까다롭습니다. 오류 메시지가 사용자가 보고 있지 않은 곳에서 전송되기 때문입니다.

첫 번째 요령은 `df -i` 명령어를 사용하여 전체적인 개요를 확인하는 것입니다.

HestiaCP 환경 에서는 터미널에 SSH로 접속하여 다음 명령어를 입력하기만 하면 됩니다.

df -i

이 목록에는 마운트된 각 파티션에 대한 전체 인노드 수, 사용된 인노드 수 및 남은 인노드 수가 표시됩니다.

출력 결과에는 IUse%라는 열이 있는데, 이는 여러분이 주의 깊게 살펴봐야 할 핵심 지표입니다.

파티션의 IUse%가 100%에 도달하면 해당 파티션에 디스크 공간이 충분히 남아 있더라도 더 이상 새 파일이나 로그를 생성할 수 없습니다.

저는 친구에게 이 프로그램을 먼저 실행해 보라고 제안했습니다. 그러면 문제가 Inode에 있는지 여부를 단 몇 초 만에 정확히 파악할 수 있을 것이고 , 추측하는 것보다 훨씬 빠를 것이라고 했습니다.

두 번째 방법은 `find` 함수를 사용하여 특정 사용자의 수를 정확하게 세는 것입니다.

문제가 인노드에 있음을 확인한 후, 다음 단계는 인덱스 카드를 과도하게 사용하는 주체가 누구인지 파악하는 것입니다.

HestiaCP는 사용자별로 별도의 홈 디렉토리를 가지고 있습니다. 특정 웹사이트 디렉토리 아래에 있는 파일과 디렉토리의 총 개수를 간단히 셀 수 있습니다.

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

"사용자 이름"과 "도메인 이름"을 실제 경로로 바꾸세요. 터미널에 표시되는 숫자는 해당 디렉터리에 있는 모든 파일과 폴더의 합계입니다.

각 파일 또는 디렉터리는 하나의 inode에 대응하므로 이 숫자는 inode 사용량을 나타냅니다.

각 항목을 개별적으로 확인하기 귀찮고 전체 사이트의 모든 사용자 사용 분포를 한 번에 보고 싶다면, 단일 루프 명령도 있습니다.

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

이 명령줄은 /home 아래의 각 사용자 디렉터리에 있는 파일의 총 개수를 출력하여 어떤 사용자 디렉터리에 비정상적으로 많은 파일이 있는지 쉽게 파악할 수 있도록 합니다.

세 번째 전략은 요오드를 가장 많이 소비하는 하위 디렉토리를 식별하는 것입니다.

웹사이트의 Inode 값이 터무니없이 높다는 것을 알면서도, 파일로 가득 찬 화면에서 무엇이 문제인지 도무지 파악할 수 없을 때가 있습니다.

이러한 경우에는 캐시 디렉터리, 세션 디렉터리, 로그 디렉터리와 같이 작은 파일이 많이 포함된 하위 폴더를 찾기 위해 한 단계 더 아래로 내려가야 합니다. 이러한 폴더가 가장 문제가 되는 영역입니다.

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

이 명령은 가장 많은 파일을 사용하는 상위 10개 하위 폴더를 나열합니다.

목록 맨 위에 있는 경로는 수많은 작은 파일들이 모여 있는 곳입니다.

나는 친구에게 아마도 어떤 캐싱 플러그인이 몰래 작은 파일을 생성하는 것일 거라고 말했고, 이 명령어를 실행하면 그것이 사실임을 확인할 수 있을 거라고 했다.

네 번째 팁은 repquota를 사용하여 할당량 제한을 확인하는 것입니다.

서버에 Linux 파일 시스템 할당량이 활성화되어 있는 경우, 문제를 다른 관점에서 살펴볼 수 있습니다.

repquota -a

이 명령어를 실행하면 모든 사용자의 파일 제한량과 실제 파일 사용량을 확인할 수 있습니다.

출력 결과의 파일 제한 섹션을 주의 깊게 살펴보십시오. 사용량 열에는 사용된 파일 수가 표시됩니다.

"soft" 및 "hard" 열은 소프트 및 하드 제한 임계값을 나타냅니다. "used" 값이 "hard" 값에 도달하면 시스템은 새 파일 생성을 즉시 거부합니다.

이는 디스크에 남은 공간이 얼마나 되는지와는 완전히 별개의 문제입니다.

이제 마무리로, 이번 수사의 모든 단서를 종합해 보겠습니다.

처음에 한밤중에 서버를 다운시킨 친구 이야기로 돌아가 보죠.

그는 제가 설명한 네 단계를 따랐는데, 첫 단계로 `df -i` 명령어를 사용하여 inode가 실제로 가득 찼는지 확인했습니다.

그런 다음, find 메서드를 사용하여 버려진 오래된 웹사이트의 캐시 디렉터리가 엄청난 양의 작은 파일을 생성하고 있다는 것을 발견했습니다.

마지막으로 `repquota`를 확인해 보니 실제로 하드 리밋에 도달했음을 알 수 있었습니다.

그 쌓여있던 불필요한 캐시 파일을 삭제하자마자 웹사이트가 즉시 다시 작동하기 시작했습니다.

그러니 다음에 "디스크에 공간은 충분한데 파일을 쓸 수 없다"는 이상한 상황에 직면하더라도 하드 드라이브를 서둘러 추가하지 마세요.

먼저 `df -i` 명령어를 사용하여 inode를 확인해 보세요. 진실은 당신이 이전에 눈여겨보지 않았던 그 색인 카드에 숨겨져 있을지도 모릅니다.

저는 시스템의 핵심에 숨겨진 이러한 사소한 상식들이 100개의 최적화 목록을 암기하는 것보다 훨씬 더 유용하다고 진심으로 믿습니다.