EC2의 EBS 볼륨을 늘렸는데 서버에서는 여전히 기존 용량만 보이는 경우가 있습니다. 비용을 더 투자해서 스토리지를 늘렸는데 안보이니 우선 파일시스템이 의심갑니다. AWS에서 확보한 저장 공간이 곧바로 파일시스템의 사용 가능 공간이 되는 것은 아니기 때문입니다. Linux 서버에서 볼륨, 파티션, 파일시스템을 어떤 순서로 확인할지 살펴보겠습니다. 확장된 볼륨과 실제 사용 공간의 차이EBS 볼륨은 서버에 연결된 저장 장치이고, 파티션은 그 장치를 나눈 영역입니다. 파일시스템은 그 위에서 파일을 저장하고 관리합니다. 구성에 따라 파티션 없이 볼륨 전체에 파일시스템을 만들거나, 중간에 LVM 논리 볼륨을 둘 수도 있습니다.예를 들어 디스크 볼륨을 50G에서 100G로 늘렸더라도 파티션과 파일시스템이 이전 ..

서버에서 애플리케이션이 갑자기 사라졌는데 재시작 후에는 정상으로 보일 때가 있다. 이때 현재 메모리 사용량만 보면 종료 당시의 상황을 놓칠 수 있다. 커널의 OOM(Out of Memory) 기록을 확인하면 종료 시각과 대상 프로세스를 찾고, 서버 전체의 메모리 압박인지 특정 서비스의 제한인지 조사 범위를 좁힐 수 있다. OOM 기록이 알려주는 것과 알려주지 않는 것 커널은 메모리 확보에 실패한 상황에서 OOM killer를 호출해 프로세스를 종료할 수 있다. 다만 메모리 할당 실패가 모두 OOM killer의 실행으로 이어지는 것은 아니다. 커널 로그에 남은 종료 대상은 그 시점에 선택된 프로세스이지, 메모리 부족을 처음 일으킨 유일한 원인이라는 뜻은 아니다.서버 전체에 여유가 없어 발생하는..

logrotate 실행 뒤 새 로그 파일은 생겼는데 크기가 늘지 않는다면, 파일 생성만으로 순환이 끝났다고 판단하기 어렵습니다. 애플리케이션이 이전 파일에 계속 기록하는지, 새 파일을 열지 못했는지부터 확인하고, 그 다음 log rotate 설정을 점검합니다. 이 점검을 소홀히 한다면 기존 로그파일에 적재되어 초반의 로그는 사라질 수도 있습니다.이 글은 Linux에서 일반 파일에 직접 기록하는 애플리케이션을 대상으로 파일 교체와 로그 재열기 사이의 점검 순서를 설명합니다.파일 이름이 바뀌어도 열린 파일은 유지가정해 보겠습니다. app.log를 app.log.1로 이름 변경하고 같은 경로에 새 app.log를 만들었지만, 서비스는 기존 파일을 계속 열고 있습니다. 프로세스가 사용하는 파일 디스크립터는 열린..

파일을 저장하려는데 “No space left on device”가 나왔지만 디스크에는 여유가 남아 있습니다. 이때 큰 파일부터 지우면 원인을 놓칠 수 있습니다. 파일시스템에는 데이터를 담을 공간과 파일 정보를 관리할 자원이 따로 있기 때문입니다. 이 글은 GNU 도구를 사용하는 Linux 환경에서 두 자원을 구별하는 점검 순서를 설명합니다.파일시스템에서 빈 공간과 inode는 서로 다른 객체inode는 소유자·권한·시간 정보와 데이터 위치 등 파일의 메타데이터를 담는 구조입니다. 파일명은 디렉터리 항목에 기록되고 해당 inode와 연결됩니다. Linux 커널의 ext4 문서도 이 구분을 설명합니다.새 파일이나 디렉터리를 만들려면 이를 위한 inode가 필요합니다. 따라서 작은 파일이 대량으로 쌓이면 데..

큰 로그 파일을 삭제했는데도 디스크 사용률이 그대로라면, 같은 경로에서 파일을 다시 찾는 것만으로는 원인을 확인하기 어렵습니다. 파일명은 사라졌지만 프로세스가 파일을 계속 열고 있을 수 있기 때문입니다. 이때는 삭제 명령의 성공 여부와 저장 공간이 회수되는 조건을 나누어 살펴봐야 합니다.파일명 삭제와 공간 회수의 타임스탬프 차이Linux에서 파일을 삭제하는 동작은 디렉터리에 있는 이름과 파일의 연결을 제거하는 것입니다. 파일을 가리키는 마지막 하드 링크가 없어져도 프로세스가 해당 파일을 열고 있다면, 마지막 파일 디스크립터가 닫힐 때까지 파일이 유지됩니다. 파일 디스크립터는 프로세스가 열린 파일을 다루는 데 사용하는 참조 번호입니다. Linux unlink 매뉴얼이 이 조건을 설명합니다.회사에서 시스템 ..