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

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