디스크가 느리게 채워지지만 눈에 띄는 파일 크기 변경은 없습니다

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 를 정리하고 크기를 설정 하려면 명령 을 사용해야 할 수도 있습니다 .