다음 오류가 발생한 후 시스템을 재부팅했는데, 재부팅 후 사용량이 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
하지만 물건을 삭제하는 데 열중하지 마십시오. 귀하의 서버 애플리케이션이 데이터를 쓰는 위치를 찾아 해당 로그가 손에 잡히지 않는지 확인합니다.