2.9.2. 성능 및 장애 관리
서버 파티션, 특히 로그가 기록되는 파티션은 좀 더 세밀한 관리가 필요한 것 같습니다.
어느 날 갑자기 DB서버의 로그기록(/var/log) 파티션이 99% 차지했다는 메시지를 받았습니다. 그래서 해당 서버에 접근해서 df -h로 확인해 보면 역시나 99% 차지하고 있습니다. 그런데 해당 파티션을 du -h /var/log로 확인해 보면 2.2G 밖에 안됩니다. 원래 적용한 용량은 1TB인데 말이죠. lsof | grep deleted로 확인해 보니 mysql 데몬에서 오래전에 삭제한 mysql-query.log를 잡고 있었습니다. 그래서 파일은 삭제되었지만 mysql 데몬에서는 mysql-query.log를 접근하고 있는 상황인지라 우선 mysql을 재시작해야 했습니다. ( 그래야 mysql 데몬에서 로그파일을 새로 만들어서 접근하기 때문에 기존의 deleted 된 로그 파일이 완전히 unlink 되게 됩니다. )
그러나, 바로 mysql을 재시작할 수는 없고 운영서버와 연결된 DB다 보니 우선 서비스 쪽에서 mysql 접근을 막아야 했습니다. 우선 일시적으로 DB접속을 차단하고 systemctl restart mysql 처리를 하고 DB서버의 로그기록(/var/log) 파티션은 du -h /var/log 와 동일하게 2.2G로 2% 정도 차지하게 되었습니다.
리눅스의 ext 파일시스템을 이해해야 알 수 있었습니다.
소개
Linux 사용자라면 큰 파일이나 폴더를 삭제하고 즉시 디스크 공간을 회수할 것으로 예상하다가 사용 가능한 저장소에 여유 공간이 반영되지 않는 당황스러운 상황을 겪었을 수도 있습니다. 이 수수께끼 같은 현상은 많은 사용자들에게 좌절감과 혼란을 줄 수 있습니다. 이 글에서는 Linux에서 파일을 삭제한 후에도 공간이 즉시 확보되지 않는 이유에 대한 미스터리를 풀고 파일 시스템의 내부 작동 방식을 살펴보겠습니다.
파일 시스템 기본 이해
구체적인 내용을 자세히 살펴보기 전에 리눅스 파일 시스템이 데이터를 관리하는 기본 원리를 이해하는 것이 중요합니다. 대부분의 리눅스 시스템은 파일과 디렉터리를 저장하기 위해 계층 구조를 사용하는 "ext" (ext2, ext3, ext4) 파일 시스템 계열을 사용합니다. 각 파일 시스템은 데이터 블록으로 구성되며, 이러한 블록의 관리는 디스크 공간의 동작을 이해하는 데 중요한 역할을 합니다.
Linux에서 파일 삭제
Linux에서 파일을 삭제하면 파일의 실제 데이터가 즉시 디스크에서 제거되지 않습니다. 대신 파일 시스템은 해당 데이터 블록을 재사용 가능한 것으로 표시합니다. 파일의 디렉터리 항목이 삭제되어 파일이 사라진 것처럼 보입니다. 그러나 파일의 내용은 새로운 데이터를 위한 공간이 필요할 때까지 디스크에 그대로 남아 있습니다.
root@localhost ~ % df -h
Filesystem Size Used Avail %iused Mounted on
/dev/disk3s1s1 400Gi 384Gi 16Gi 96% /
devfs 215Ki 215Ki 0Bi 100% /dev
이 예제에서는 디렉터리에서 약 40GB를 차지하는 애플리케이션에서 생성된 파일을 찾을 수 있습니다. 따라서 공간을 해제하기 위해 다음 작업을 수행합니다
1. access_log 파일을 삭제합니다.
rm -frv /var/log/apache2/access_log
2. 파일 시스템 디스크 공간 사용량을 확인합니다.
root@localhost ~ % df -h
Filesystem Size Used Avail %iused Mounted on
/dev/disk3s1s1 400Gi 384Gi 16Gi 96% /
devfs 215Ki 215Ki 0Bi 100% /dev
그러나 출력 결과에 따르면 루트 볼륨에서 사용량이 여전히 96%에 달합니다.
"Unlink"의 역할
Linux에서 파일을 삭제하는 과정은 "unlink" 또는 "unlinking"로 알려진 작업을 포함합니다. 이 작업은 파일 이름과 해당 inode(파일에 대한 정보를 포함하는 데이터 구조) 사이의 링크를 제거합니다. 파일이 연결 해제되면 해당 파일의 inode는 free로 표시되며, 관련된 데이터 블록은 재사용할 수 있게 됩니다.
지연된 디스크 공간 회수
이제 파일 삭제의 기본 사항을 이해했으니 디스크 공간이 즉시 복구되지 않는 이유를 살펴보겠습니다. 파일이 여전히 열려 있습니다. 삭제 시 프로그램에 파일이 열려 있으면 파일이 닫힐 때까지 공간이 확보되지 않습니다. Linux는 프로세스에서 여전히 사용 중인 파일을 연결 해제한 후에도 열려 있는 상태로 유지할 수 있도록 합니다. 이 기능은 프로세스가 파일 사용을 완료할 때까지 파일 작업을 계속할 수 있도록 보장합니다. 이를 확인하려면 lsof 명령을 실행하여 어떤 프로세스가 access_log 파일에 데이터를 계속 쓰고 있는지 확인합니다. lsof와 같은 도구는 열려 있는 파일 핸들을 식별하는 데 도움이 될 수 있습니다.
root@localhost ~# lsof -n | grep deleted
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
httpd 13423 root 5u REG 253,3 42949672960 17 (deleted)
mysqld 13423 mysql 6u REG 253,3 0 18 (deleted)
mysqld 13423 mysql 7u REG 253,3 0 19 (deleted)
명령어 출력에서 볼 수 있듯이, access_log 파일은 여전히 httpd 프로세스에 의해 사용되고 있으며, 이 프로세스는 데이터를 파일에 계속 씁니다. 괄호 안의 값이 삭제되었다는 것은 로그 파일이 삭제되었음을 나타냅니다. 하지만 httpd가 파일에 데이터를 계속 쓰기 때문에 공간이 해제되지 않습니다.
강제 디스크 공간 회수
그렇다면 를 위해 이 문제를 어떻게 해결할 수 있을까요? Linux는 효율성과 성능을 위해 디스크 공간을 자동으로 관리하지만, 특정 상황에서는 수동으로 디스크 공간을 강제로 복구할 수 있습니다. 일부 기술에는 다음이 포함됩니다:
1. 삭제된 파일을 붙잡고 있을 수 있는 열려 있는 파일 핸들을 식별하고 닫습니다. httpd 프로세스를 재시작하거나 시스템을 재시작하면 해결됩니다.
root@localhost ~ % systemctl restart apache2
이렇게 하면 디스크 공간이 즉시 해제되고 프로세스가 파일에 데이터를 계속 쓸 수 있습니다. 이제 df -h 명령을 실행하여 공간 사용량을 다시 확인해 보세요. 이제 10%의 디스크 공간이 확보된 것을 확인할 수 있습니다.
root@localhost ~ % df -h
Filesystem Size Used Avail Used Mounted on
/dev/disk3s1s1 400Gi 344Gi 56Gi 86% /
devfs 215Ki 215Ki 0Bi 100% /dev
스냅숏 및 백업
일부 파일 시스템은 스냅숏을 지원하거나 삭제된 파일을 일정 기간 동안 보관하는 백업 메커니즘을 가지고 있습니다. 이러한 기능은 데이터 복구 및 버전 제어 목적으로 필수적이지만 디스크 공간의 즉각적인 릴리스를 일시적으로 방지할 수 있습니다.
결론
결론적으로, 리눅스에서 파일을 삭제한 후에도 디스크 공간이 즉시 해방되지 않는 이유는 파일 시스템의 설계와 다양한 시스템 구성에 기인할 수 있습니다. 파일 시스템이 데이터를 관리하는 방식을 이해하고 공간 회수를 지연시키는 잠재적 요인을 인식하면 사용자가 혼란을 피하고 저장 자원을 더 잘 활용하는 데 도움이 됩니다. 리눅스의 디스크 공간 자동 관리는 효율적인 성능을 보장하지만, 사용자는 필요할 때 수동 기술을 사용하여 공간을 확보할 수 있습니다.