루트 "/" 디렉터리가 100% 소비되고 시스템이 재부팅됩니다. 재부팅 후 사용량이 75%로 떨어지므로 근본 원인을 찾아야 합니다. [닫기]

루트 "/" 디렉터리가 100% 소비되고 시스템이 재부팅됩니다. 재부팅 후 사용량이 75%로 떨어지므로 근본 원인을 찾아야 합니다. [닫기]

다음 오류가 발생한 후 시스템을 재부팅했는데, 재부팅 후 사용량이 75%로 떨어지는 문제가 발생했습니다.

dfmon[16139]: FATAL: 디스크 사용 가능 모니터: 102 #파일 시스템 "/"가 100% 가득 찼습니다.

로그나 다른 곳에서 이 공간을 차지하는 파일을 찾을 수 있는 방법이 있습니까? 어떤 프로세스에서 이러한 파일이 생성될 수 있으며 문제를 해결해야 할 수도 있습니다.

어떤 도움이라도 대단히 감사하겠습니다.

답변1

/tmp 또는 시작 시 비워졌을 수 있는 기타 디렉터리에 의심스러울 정도로 큰 파일이 표시되지 않으면 파일이 연결되지 않았지만 여전히 열려 있기 때문일 수 있습니다.

이는 일반적으로 다른 프로세스에 전달될 수 있지만 관련되지 않은 프로세스에서 파일 이름으로 액세스하는 공유 메모리를 생성하는 등 일부 프로그램에 의해 의도적으로 발생합니다. 예를 들어 로그 파일이 회전/삭제되었지만 로깅 프로세스에서 파일을 열어 둔 경우에도 이런 일이 실수로 발생할 수 있습니다.

예를 들어 , 파일을 열어 둔 모든 프로세스가 종료되거나(늦어도 시스템이 완전히 종료될 때) fsck정전 후 실행될 때 이러한 파일은 더 이상 존재하지 않습니다. 따라서 이러한 파일은 재부팅 후 사용량 감소를 설명할 수 있습니다.

삭제되었지만 마운트 지점에 생성된 아직 열려 있는 모든 파일을 보려면 루트로 다음을 시도하십시오 /.

lsof -s -- / | grep -e '^COMMAND \| (deleted)' | less

이 열에는 COMMAND파일을 열어 둔 프로세스의 이름, SIZE파일 크기(바이트), NAME파일이 삭제되기 전의 원래 경로가 포함됩니다.

목록에 매우 큰 파일이나 일반적인 로그 파일 이름이 표시되면 범인을 찾은 것일 수 있습니다.

답변2

다음을 시도해 보세요. 드라이브가 꽉 차서 시간이 걸릴 수 있습니다. 루트 디렉터리 아래의 모든 파일을 확인한 다음 크기별로 정렬합니다.

du / | sort -n

시간이 오래 걸리면 요약을 받아 자세히 알아볼 수 있을 때까지 반복하세요.

du -s /* | sort -n

답변3

패키지 관리자에는 일반적으로 약간의 공간이 필요한 캐시가 있습니다. sudo yum clean all아니면 sudo apt-get clean all뭔가를 청소할 수도 있습니다.

du훌륭한 도구입니다. 나는 사용할 것이다du -xhd1 /

-x, --one-file-system -h, --human-readable -d, --max-depth=N

하지만 물건을 삭제하는 데 열중하지 마십시오. 귀하의 서버 애플리케이션이 데이터를 쓰는 위치를 찾아 해당 로그가 손에 잡히지 않는지 확인합니다.

관련 정보