Microsoft MVP성태의 닷넷 이야기
Linux: 41. 리눅스 환경에서 디스크 용량 부족 시 원인 분석 방법 [링크 복사], [링크+제목 복사],
조회: 10446
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)

리눅스 환경에서 디스크 용량 부족 시 원인 분석 방법

리알못이라, 같은 처지의 분들에게 도움이 될 수 있도록 기록을 남깁니다. ^^

우선, 디스크 용량이 부족해서 응용 프로그램들이 오류가 발생하는 상황이었습니다. 그렇다면 이제 할 일은, 도대체 어떤 응용 프로그램에서 디스크 용량을 과다하게 사용하는지 알아내야 합니다. 제 경우 기존의 윈도우 환경이라면, 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%"를 찍고 있을 것입니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 3/2/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 46  47  48  49  50  51  52  53  54  55  56  [57]  58  59  60  ...
NoWriterDateCnt.TitleFile(s)
12217정성태5/24/20209982오류 유형: 615. Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 0, current count = 1.
12216정성태5/15/202013165.NET Framework: 904. USB/IP PROJECT를 이용해 C#으로 USB Keyboard 가상 장치 만들기 [14]파일 다운로드1
12215정성태5/12/202018275개발 환경 구성: 490. C# - (Wireshark의) USBPcap을 이용한 USB 패킷 모니터링 [10]파일 다운로드1
12214정성태5/5/202010543개발 환경 구성: 489. 정식 인증서가 있는 경우 Device Driver 서명하는 방법 (2) - UEFI/SecureBoot [1]
12213정성태5/3/202012214개발 환경 구성: 488. (User-mode 코드로 가상 USB 장치를 만들 수 있는) USB/IP PROJECT 소개
12212정성태5/1/20209850개발 환경 구성: 487. UEFI / Secure Boot 상태인지 확인하는 방법
12211정성태4/27/202012169개발 환경 구성: 486. WSL에서 Makefile로 공개된 리눅스 환경의 C/C++ 소스 코드 빌드
12210정성태4/20/202012623.NET Framework: 903. .NET Framework의 Strong-named 어셈블리 바인딩 (1) - app.config을 이용한 바인딩 리디렉션 [1]파일 다운로드1
12209정성태4/13/202010654오류 유형: 614. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우 (2)
12208정성태4/12/202010084Linux: 29. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우
12207정성태4/2/20209061스크립트: 19. Windows PowerShell의 NonInteractive 모드
12206정성태4/2/202011376오류 유형: 613. 파일 잠금이 바로 안 풀린다면? - The process cannot access the file '...' because it is being used by another process.
12205정성태4/2/20208748스크립트: 18. Powershell에서는 cmd.exe의 명령어를 지원하진 않습니다.
12204정성태4/1/20208550스크립트: 17. Powershell 명령어에 ';' (semi-colon) 문자가 포함된 경우
12203정성태3/18/202010639오류 유형: 612. warning: 'C:\ProgramData/Git/config' has a dubious owner: '...'.
12202정성태3/18/202013196개발 환경 구성: 486. .NET Framework 프로젝트를 위한 GitLab CI/CD Runner 구성
12201정성태3/18/202011011오류 유형: 611. git-credential-manager.exe: Using credentials for username "Personal Access Token". [1]
12200정성태3/18/202011430VS.NET IDE: 145. NuGet + Github 라이브러리 디버깅 관련 옵션 3가지 - "Enable Just My Code" / "Enable Source Link support" / "Suppress JIT optimization on module load (Managed only)"
12199정성태3/17/20209265오류 유형: 610. C# - CodeDomProvider 사용 시 Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '...\f2_6uod0.tmp'.
12198정성태3/17/202012043오류 유형: 609. SQL 서버 접속 시 "Cannot open user default database. Login failed."
12197정성태3/17/202011186VS.NET IDE: 144. .NET Core 콘솔 응용 프로그램을 배포(publish) 시 docker image 자동 생성 - 두 번째 이야기 [1]
12196정성태3/17/20209088오류 유형: 608. The ServicedComponent being invoked is not correctly configured (Use regsvcs to re-register).
12195정성태3/16/202010852.NET Framework: 902. C# - 프로세스의 모든 핸들을 열람 - 세 번째 이야기
12194정성태3/16/202013129오류 유형: 607. PostgreSQL - Npgsql.NpgsqlException: sorry, too many clients already
12193정성태3/16/20209878개발 환경 구성: 485. docker - SAP Adaptive Server Enterprise 컨테이너 실행 [1]
12192정성태3/14/202012305개발 환경 구성: 484. docker - Sybase Anywhere 16 컨테이너 실행
... 46  47  48  49  50  51  52  53  54  55  56  [57]  58  59  60  ...