리눅스 환경에서 디스크 용량 부족 시 원인 분석 방법
리알못이라, 같은 처지의 분들에게 도움이 될 수 있도록 기록을 남깁니다. ^^
우선, 디스크 용량이 부족해서 응용 프로그램들이 오류가 발생하는 상황이었습니다. 그렇다면 이제 할 일은, 도대체 어떤 응용 프로그램에서 디스크 용량을 과다하게 사용하는지 알아내야 합니다. 제 경우 기존의 윈도우 환경이라면, spacesniffer를 곧잘 사용하는데요,
디스크의 폴더별 사용량을 한눈에 보여주는 SpaceSniffer 유틸리티 소개
; https://www.sysnet.pe.kr/1/0/993
리눅스 Guy들은 다음과 같은 명령어를 터미널 화면에서 입력한다고 합니다.
# du -m -d 1 | sort -n -r
676907 .
435643 ./var
118590 ./docker-data
64358 ./home
3914 ./lib
...[생략]...
0 ./proc
0 ./dev
그런데, 저 -m 옵션이 "block-size=1M"라고 하는데요, 그렇다면 ./var가 430GB라는 건가요? 암튼 좀 용량 계산이 직관적이지 않습니다. 와중에 다른 동료가 -h 옵션으로 하라고 해서 돌려보니 이번엔 약간 다릅니다.
# du -h -d 1 2>/dev/null | sort -n -r
957M ./boot
116G ./docker-data
...[생략]...
2.1T .
1.8T ./var
1.3G ./run
0 ./sys
0 ./proc
0 ./dev
아하... ./var가 430GB가 아니라 1.8T였군요. (도대체 어떻게 계산하면 1.8T가 435643으로 나올까요? ^^;)
어쨌든 결과가 잘 나왔지만 이젠 sort의 옵션이 무색하게 되었습니다. 게다가, du에 준 "-d 1" 옵션의 효과가 "depth = 1"입니다. 즉, 저렇게 나왔으면 이제 다시 의심이 되는 "1.8T"의 "/var" 디렉터리로 내려가 추가로 명령을 내려야 합니다.
# du -h -d 1 2>/dev/null
20K ./tmp
...[생략]...
1.8T ./lib
1.8T .
역시나 lib로 내려가 작업을 반복하면,
# du -h -d 1 2>/dev/null
...[생략]...
1.8T ./docker
...[생략]...
1.8T .
범인이 대충 나왔습니다. docker의 overlay2 디렉터리가 원인이었습니다.
# du -h -d 1 2>/dev/null
64M ./image
...[생략]...
199G ./containers
4.0K ./runtimes
1.6T ./overlay2
...[생략]...
20K ./builder
1.8T .
혹시 범인이 현재 사용 중인 log 파일과 같은 경우라면 크기를 0으로 만드는 것도 좋은 방법입니다.
5 Ways to Empty or Delete a Large File Content in Linux
; https://www.tecmint.com/empty-delete-file-content-linux/
# > access.log
# : > access.log
# true > access.log
# cat /dev/null > access.log
# cp /dev/null access.log
# dd if=/dev/null of=access.log
# echo "" > access.log
# echo > access.log
# echo -n "" > access.log
# truncate -s 0 access.log
또는 그냥 간단하게 다음과 같이 명령을 내리는 것도 좋습니다.
$ du -h -t 10G 2>/dev/null
21G ./testdir/dump
22G ./testdir
...[생략]...
25G .
보는 바와 같이, ./testdir/dump 디렉터리의 크기가 비정상적으로 큰 것을 쉽게 인지할 수 있습니다.
회사의 주요 업무가 서비스를 만드는 것이고, 그걸로 docker를 사용한다면 아마도 운영환경을 세심하게 살피는 담당자가 있을 것이므로 이런 문제가 거의 발생하지 않았을 것입니다. 반면, ^^ 우리 회사처럼 docker를 단순히 테스트 환경으로 사용하는 경우라면, 개발자들이 너도나도 생성한 컨테이너는 어느 순간 관리가 안 되는 지경에 이릅니다.
그리고 이렇게 disk full 사태가 발생하는데요. ^^ 원인이 docker라는 것을 알았으니, 이제 docker의 자체 명령어로 실행 중인 컨테이너당 어느 정도의 디스크를 점유하고 있는지 확인하면 됩니다.
# docker ps --format "{{.ID}}\t{{.Names}}\t{{.Size}}" -s
75c0ab7da32d problem_diag_container 653.47GB (virtual 687.6GB)
...[생략]...
// 또는,
# docker ps --size --format '{{.Image}} {{.Size}}'
다행히 저렇게 결과가 나왔으면 이제 해당 컨테이너를 생성한 담당자에게 이 사실을 알리고 조치를 취하면 됩니다. ^^
참고로, 이 외에도 docker system df 명령어도 기억해 둘 만합니다.
# docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 79 19 32.23GB 1.974GB (6%)
Containers 83 33 830.4GB 0B (0%)
Local Volumes 36 32 3.004GB 550.3MB (18%)
Build Cache 0 0 0B 0B
그리고 윈도우 사용자라면 전체적인 디스크 사용량을 탐색기의 "This PC" 레벨에서 확인할 텐데요, 리눅스라면 df 명령어로 유사하게 확인을 합니다.
$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 63G 0 63G 0% /dev
tmpfs 13G 1.3G 12G 11% /run
/dev/mapper/ubuntu--vg-ubuntu--lv 1.7T 563G 1019G 36% /
tmpfs 63G 0 63G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 63G 0 63G 0% /sys/fs/cgroup
...[생략]...
복잡한 구성이 아니라면, 대개의 경우 "Mounted on"이 "/"로 되어 있는 값을 확인하면 됩니다. 위의 경우에는 1.7T 용량의 하드 디스크가 이제 1T 정도의 남은 용량이 있는 것입니다. 만약 디스크가 부족한 상황이라면 "Use%"의 값이 "100%"를 찍고 있을 것입니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]