서버에서 큰 파일을 삭제했는데도 df -h 용량이 그대로인 경우가 있습니다.
분명히 파일은 지웠는데 디스크 사용률은 줄지 않습니다.
처음 보면 이런 생각이 듭니다.
“삭제가 안 된 건가?”
“df -h가 바로 반영되지 않는 건가?”
“다른 큰 파일이 또 있는 건가?”
저도 처음에는 파일을 삭제하면 바로 용량이 줄어드는 줄 알았습니다.
하지만 리눅스에서는 파일을 삭제했더라도 어떤 프로세스가 그 파일을 계속 잡고 있으면 디스크 공간이 바로 반환되지 않을 수 있습니다.
이럴 때 확인하는 명령어가 있습니다.
lsof | grep deleted
파일을 삭제했는데 용량이 그대로인 상황
예를 들어 서버 디스크 사용률을 확인했더니 / 또는 /var 영역이 90% 이상이라고 가정해보겠습니다.
df -h그래서 큰 로그 파일을 찾아 삭제했습니다.
rm -f app.log그런데 다시 확인해도 용량이 줄지 않습니다.
df -h파일은 삭제했는데 Use%가 그대로인 상황입니다.
이럴 때 무작정 다른 파일을 계속 삭제하면 위험합니다.
먼저 삭제한 파일을 어떤 프로세스가 아직 사용 중인지 확인해야 합니다.
왜 삭제했는데 용량이 안 줄어들까?
리눅스에서는 파일을 삭제해도, 그 파일을 사용 중인 프로세스가 있으면 디스크 공간이 바로 반환되지 않을 수 있습니다.
쉽게 말하면 이렇습니다.
파일 이름은 삭제됨
하지만 프로세스는 아직 파일을 열고 있음
그래서 디스크 공간이 바로 비워지지 않음사용자 입장에서는 파일이 사라진 것처럼 보입니다.
하지만 운영체제 입장에서는 해당 파일을 잡고 있는 프로세스가 남아 있어서 완전히 정리되지 않은 상태일 수 있습니다.
특히 아래 상황에서 자주 발생할 수 있습니다.
- 애플리케이션 로그 파일을 삭제한 경우
- 웹/WAS 서버가 로그 파일을 계속 쓰고 있는 경우
- Java 프로세스가 오래된 로그 파일을 잡고 있는 경우
- 로그 로테이션이 꼬인 경우
- 대용량 파일을 삭제했는데 프로세스가 종료되지 않은 경우확인 명령어: lsof | grep deleted
이럴 때 사용하는 명령어는 아래와 같습니다.
lsof | grep deletedlsof는 현재 시스템에서 열려 있는 파일을 확인하는 명령어입니다.
여기서 deleted가 붙은 항목은 파일은 삭제됐지만 아직 프로세스가 잡고 있는 파일을 의미합니다.
즉, 삭제했는데도 디스크 용량이 줄지 않을 때 원인을 확인하는 데 사용할 수 있습니다.
결과 예시
아래는 실제 서버 정보가 아닌 예시입니다.
java 12345 tomcat 10w REG 253,0 2147483648 123456 /app/logs/app.log (deleted)대략 이렇게 볼 수 있습니다.
java → 파일을 잡고 있는 프로세스
12345 → PID
tomcat → 실행 계정
/app/logs/app.log (deleted) → 삭제됐지만 아직 사용 중인 파일여기서 중요한 값은 PID입니다.
위 예시에서는 12345 프로세스가 삭제된 로그 파일을 계속 잡고 있는 상태입니다.
바로 kill 해도 될까?
주의해야 할 점이 있습니다.
lsof | grep deleted로 프로세스를 찾았다고 해서 바로 kill -9를 실행하면 안 됩니다.
운영 서버에서는 해당 프로세스가 실제 서비스 프로세스일 수 있습니다.
예를 들어 아래와 같은 프로세스라면 바로 종료했을 때 서비스 장애로 이어질 수 있습니다.
java
tomcat
nginx
httpd
mysqld
postgres그래서 먼저 아래 순서로 확인하는 것이 안전합니다.
1. 어떤 프로세스인지 확인
2. 어떤 서비스와 연결되어 있는지 확인
3. 재기동해도 되는 상황인지 확인
4. 담당자 또는 운영 절차 확인
5. 필요 시 정상 재기동운영 환경에서는 혼자 판단해서 프로세스를 종료하기보다,
서비스 담당자나 솔루션 담당자에게 확인 후 조치하는 것이 안전합니다.
PID로 프로세스 확인하기
lsof 결과에서 PID를 확인했다면 아래 명령어로 프로세스를 한 번 더 확인할 수 있습니다.
ps -fp 12345예를 들어 Java 프로세스라면 아래 명령어도 도움이 될 수 있습니다.
jps -lv다만 jps는 Java가 설치되어 있고, 실행 권한이 맞을 때만 정상적으로 보입니다.
프로세스가 어떤 서비스인지 모르겠다면 바로 종료하지 말고, 실행 계정과 실행 경로를 먼저 확인하는 것이 좋습니다.
조치는 보통 재기동이 필요할 수 있음
삭제된 파일을 잡고 있는 프로세스가 확인되면, 보통은 해당 프로세스를 재기동해야 디스크 공간이 반환됩니다.
예를 들어 애플리케이션 로그 파일을 Tomcat이나 Java 프로세스가 잡고 있다면, 해당 서비스를 재기동해야 할 수 있습니다.
하지만 운영 서버에서 재기동은 단순한 명령어 실행이 아닙니다.
서비스 영향이 있을 수 있기 때문에 아래 순서가 중요합니다.
확인 → 판단 → 조치무조건 삭제하거나 무조건 재기동하는 것이 아니라, 먼저 원인을 확인하고 서비스 영향도를 판단한 뒤 조치해야 합니다.
df -h와 du -sh 결과가 다를 때도 의심
이 문제는 df -h와 du -sh 결과가 다르게 보일 때도 의심할 수 있습니다.
예를 들어 df -h에서는 디스크 사용률이 90% 이상인데,
du -sh *로 폴더별 용량을 확인해보면 그만큼 큰 파일이 보이지 않는 경우가 있습니다.
이때 삭제된 파일을 프로세스가 잡고 있을 가능성이 있습니다.
확인 흐름은 이렇게 잡을 수 있습니다.
df -h전체 파일시스템 사용률 확인
du -sh * | sort -rh현재 위치의 큰 폴더 확인
lsof | grep deleted삭제됐지만 아직 사용 중인 파일 확인
이 순서로 보면 조금 더 안전하게 원인을 좁혀갈 수 있습니다.
실무에서 조심할 점
운영 서버에서 디스크 용량이 부족할 때 가장 위험한 행동은 원인을 제대로 확인하지 않고 바로 삭제하는 것입니다.
특히 아래 행동은 조심해야 합니다.
- /var/log 전체를 무작정 삭제
- 서비스 로그를 바로 rm 처리
- PID 확인 없이 kill -9 실행
- DB/WAS/Web 프로세스 임의 종료
- 고객사명, 실제 IP, 실제 로그 원문 외부 공유디스크 용량 부족은 단순한 파일 정리 문제처럼 보이지만, 실제로는 서비스 장애와 연결될 수 있습니다.
그래서 명령어를 아는 것보다 중요한 건 순서입니다.
확인 → 판단 → 조치정리
파일을 삭제했는데도 서버 용량이 줄어들지 않는다면, 삭제된 파일을 프로세스가 계속 잡고 있을 수 있습니다.
이때는 아래 명령어로 확인합니다.
lsof | grep deleted결과에서 PID와 프로세스명을 확인한 뒤, 바로 종료하지 말고 서비스 영향도를 먼저 판단해야 합니다.
핵심은 이것입니다.
삭제했는데 용량이 그대로라면
lsof deleted를 확인한다.
하지만 바로 kill 하지 않는다.
확인 → 판단 → 조치관련 글 연결 문구
디스크 용량 문제를 처음 확인하는 순서가 궁금하다면 아래 글도 함께 보면 좋습니다.
리눅스 서버 디스크 용량 90% 돌파? 당황하지 말고 이 순서로 확인하세요df -h 결과를 볼 때 Use%만 보면 안 되는 이유는 아래 글에서 정리했습니다.
리눅스 df -h 결과, Use%만 보면 안 되는 결정적인 이유다음 글에서는 /var/log 용량이 커졌을 때 어떤 순서로 확인하면 좋은지 정리해보겠습니다.
'리눅스' 카테고리의 다른 글
| 리눅스 서버 로그 파일이 계속 커질 때 바로 비우지 말고 확인하는 법 (0) | 2026.05.08 |
|---|---|
| 리눅스 서버 /var/log 용량이 갑자기 커졌을 때 확인하는 법 (0) | 2026.05.06 |
| 리눅스 서버 디스크 용량을 잡아먹는 큰 파일 find 명령어로 찾는 법 (0) | 2026.05.05 |
| 리눅스 서버 디스크 용량이 찼을 때 du -sh로 큰 폴더 찾는 법 (0) | 2026.05.03 |
| 리눅스 서버 df -h 결과, Use%만 보면 안 되는 이유와 확인 순서 (0) | 2026.05.02 |