df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/vda1 30830588 22454332 6787120 77% /
none 4 0 4 0% /sys/fs/cgroup
udev 1014124 4 1014120 1% /dev
tmpfs 204996 336 204660 1% /run
none 5120 0 5120 0% /run/lock
none 1024976 0 1024976 0% /run/shm
none 102400 0 102400 0% /run/user
그 77 %는 어제 60 %에 불과했으며 며칠 안에 최대 100 %까지 채울 것입니다.
나는 한동안 파일 크기를 모니터링 해왔다.
sudo du -sch /*
9.6M /bin
65M /boot
224K /build
4.0K /dev
6.5M /etc
111M /home
0 /initrd.img
0 /initrd.img.old
483M /lib
4.0K /lib64
16K /lost+found
8.0K /media
4.0K /mnt
4.0K /opt
du: cannot access ‘/proc/21705/task/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/task/21705/fdinfo/4’: No such file or directory
du: cannot access ‘/proc/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/fdinfo/4’: No such file or directory
0 /proc
21M /root
336K /run
12M /sbin
8.0K /srv
4.1G /swapfile
0 /sys
4.0K /tmp
1.1G /usr
7.4G /var
0 /vmlinuz
0 /vmlinuz.old
14G total
매일 같은 숫자를주고 있습니다. 총 14G는 디스크 크기의 절반보다 작습니다. 나머지는 어디로 가고 있습니까?
내 리눅스 지식은 더 깊이 들어 가지 않습니다.
파일이 여기에 표시되지 않을 수 있습니까? 다른 방법으로 공간을 할당 할 수 있습니까?
답변
디스크 공간이 눈에 띄게 증가하면 파일을 삭제하는 원인이 될 수 있습니다. Windows에서 무언가에 의해 열린 파일을 삭제하려고하면 오류가 발생합니다. Linux에서는 파일이 삭제 된 것으로 표시되지만 응용 프로그램이 이동할 때까지 데이터가 유지됩니다. 경우에 따라, 이것은 자신을 정리하는 깔끔한 방법 으로 사용될 수 있습니다 응용 프로그램 충돌로 인해 임시 파일을 정리하지 못할 수도 있습니다.
삭제 된 여전히 사용중인 파일을 보려면
lsof -b 2>/dev/null | grep deleted
많은 수의 삭제 된 파일이있을 수 있습니다. 그 자체로는 문제가되지 않습니다. 삭제 된 단일 파일이 커지는 것은 문제입니다.
재부팅하면이 문제가 해결되지만 재부팅하지 않으려면 관련된 응용 프로그램을 확인하십시오 (첫 번째 열 lsof 출력의 )을 확인하고 합리적인 것으로 보이는 다시 시작하거나 닫습니다.
다음과 같은 것을 본 적이 있다면 :
zsh 1724 muru txt REG 8,17 771448 1591515 /usr/bin/zsh (deleted)
응용 프로그램과 삭제 된 파일이 동일한 경우 응용 프로그램이 업그레이드되었음을 의미합니다. 디스크 사용량이 많은 소스는 무시해도됩니다 (하지만 버그 수정이 적용되도록 프로그램을 다시 시작해야합니다).
파일 /dev/shm은 공유 메모리 객체이며 디스크의 많은 공간을 차지하지 않습니다 (최대 inode 번호). 또한 무시해도됩니다. 이름 vteXXXXXX이 지정된 파일은 VTE 기반 터미널 에뮬레이터 (GNOME 터미널, 터미네이터 등)의 로그 파일입니다. 이들은 수 당신이 터미널 창에 열려있는 경우, 클 수 많은 (그리고 나는 평균 많은 물건 인 출력을).
답변
muru의 훌륭한 답변을 추가하려면 :
- df는 디스크의 크기를 보여줍니다.
- du는 파일 내용의 전체 크기를 보여줍니다.
아마도 du로 보지 못하는 것은 많은 작은 파일의 모습 일 것입니다. df -i 볼 경우 아이 노드 (즉, 파일) 초과 너무 많이 증가의 수)
예를 들어, 1’000’000 (1 백만) 개의 작은 1 바이트 파일이 있으면 du 이 있으면 총 1,000,000 바이트로 계산합니다. 1Mb라고 말합시다 (순교자, 울부 짖지 마십시오).
그러나 디스크에서 각 파일은 다음 두 가지로 구성됩니다.
- 1 inode (파일의 데이터를 가리킴)이며 inode 자체는 16kb (!) 일 수 있습니다.
- 그리고 각 파일의 데이터 (= 파일의 내용)는 디스크 블록에 저장되며 해당 블록은 여러 파일의 데이터 (일반적으로 …)를 포함 할 수 없으므로 1 바이트의 데이터는 적어도 1 블록을 차지합니다
따라서 1 바이트 파일 1 백만 개 파일 1'000'000'000 * size_of_a_block은 데이터의 전체 공간 1'000'000'000 * size_of_an_inode과 inode 크기 를 차지 합니다. 1 백만 “1 바이트”파일의 디스크 사용량은 몇 Gb에 달할 수 있습니다.
1024 바이트 블록과 또 다른 256 바이트의 inode 크기가있는 경우, 1’000’000 파일은 대략 1Mb로보고 du되지만 디스크에서 대략 1.25Gb로 계산됩니다 (로 df표시됨)! (또는 각 inode가 하나의 전용 디스크 블록에 있어야하는 경우 2Gb조차도 … 그 경우인지 모르겠습니다)
답변
/dev/vda1채우는 경우 Jenkins 또는 Docker (또는 기타)로 인한 것일 수 있으며 로그lsof 를 정리하고 크기를 설정 하려면 명령 을 사용해야 할 수도 있습니다 .