디스크 공간이 부족하면 소스는 무엇입니까?

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  220G     0 100% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  220G     0 100% /var/lib/ureadahead/debugfs

나이가 들었을 때 답을 찾는 것을 당황스럽게하면서 사용이 감소했습니다.

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  9.3G  200G   5% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  9.3G  200G   5% /var/lib/ureadahead/debugfs

나는 지금까지 아무것도 삭제하지 않았으며 지금은 이것을 다시 쓰고 있습니다.

/dev/sda1             220G   12G  197G   6% /

무슨 일이야 ?? 원인을 조사하고 다시 발생하지 않도록 설정하는 방법

마사지 사용 시간 동안 / var 폴더의 크기가 1.8 기가 일정하다는 것을 알았지 만 모든 폴더를 확인할 수는 없었습니다.

편집 하다

/dev/sda1             220G   18G  192G   9% /

* 업데이트 2 * 다시 올라갑니다

ubuntu /: df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G   43G  167G  21% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G   43G  167G  21% /var/lib/ureadahead/debugfs

그리고 주어진 명령을 확인

ubuntu /: du -h --max-depth=1 /
31M     /boot
4.0K    /selinux
8.0K    /srv
7.4M    /bin
du: cannot access `/proc/9993/task/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/task/9993/fdinfo/4': No such file or directory
du: cannot access `/proc/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/fdinfo/4': No such file or directory
0       /proc
12K     /tmp
2.4G    /var
0       /sys
100K    /root
4.0K    /media
575M    /usr
4.0K    /opt
16K     /lost+found
4.5M    /home
270M    /lib
168K    /dev
4.0K    /mnt
6.7M    /sbin
6.1M    /etc
4.0K    /cdrom
3.3G    /

/의 3.3G에 주목

드라이브에서 삭제되었지만 아직 응용 프로그램 / 서버에서 닫히지 않은 파일에 쓰는 것이 있다고 생각합니다. 따라서 공간은 디스크에 할당 된 상태로 유지되지만 du파일이 파일 시스템에서 제거 된 후에는 볼 수 없습니다 . lsof파일이 프로그램 목록 프로세스를 엽니 다. 더 많은 파일 시스템이 마운트되어 있고 그 수가 크게 변동하지 않았다면, 비어 있지 않은 디렉토리 위에 파일 시스템을 마운트하도록 제안했을 것 umount /var/lib/ureadahead/debugfs입니다. (디렉토리가 비어 있고 해당 마운트 지점 아래에 숨겨져있는 디렉토리에 작성된 정크는 없습니다.)

이 경우으로 쉽게 찾을 수 있습니다 sudo lsof | grep deleted. 프로세스가 여전히 열려있는 동안 파일이 삭제 된 경우 마지막 열에 lsof포함 (deleted)됩니다. 첫 번째 열은 명령의 이름이고 두 번째 열은 PID입니다. ps예를 들어 ps auxww | grep PID,를 사용하여 명령을 자세히 살펴 보거나 ps auxwwf | less -S"포리스트"모드에서 프로세스 목록을 확인하여 PID의 프로세스를 확인할 수 있습니다. 열린 거대한 파일을 보유하고있는 프로세스를 추적 한 후에는 드라이브 공간을 확보하기 위해 파일을 중지 한 다음 파일을 올바르게 닫도록 수정하는 방법을 알아낼 수 있습니다. 이것의 일반적인 원인은 로그 파일의 이름을 바꾸거나 삭제하지만 응용 프로그램에 해당 사실을 알리지 않는 로그 회전 스크립트입니다.kill 또는 애플리케이션을 다시 시작하여 애플리케이션이 이전 로그 파일을 계속 열어 둡니다.

운영

du -h --max-depth=1 /

그리고 더 명확한 그림을 제공해야합니다. 오고가는 임시 파일처럼 들리면 한 번 삭제하면 프로세스가 충돌 할 때까지 삭제되지 않습니다. 이 서버가 운영하는 OS는 무엇이며 특히 실행되고 있습니까?

문제가있는 것 같습니다 /var/lib/ureadahead/debugfs. 이것은 알려진 문제이며 여기에 자세한 정보가있는 우분투 포럼 링크가 있습니다 http://ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrading-to-ubuntu-10-04 . tl; dr이 업데이트 및 업그레이드 된 sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabled다음 재부팅 한 것으로 보입니다 . 물론 10.04를 실행한다고 가정합니다.

내 추측은 로그 파일입니다. 필자는 dev 서버의 Apache 로그에 너무 많은 PHP 5.3 "더 이상 사용되지 않는"경고가있어서 var 파티션에서 8GB의 공간을 모두 씹어 버리는 것에주의를 기울이지 않았습니다 (문제에 대한 사이드 바 : 항상 공간이 부족하여 루트 파티션이 시스템 불안정성 문제를 일으킬 수있는 별도의 파티션에 / var을 넣으십시오).

공간이 오래되지 않은 매우 빠르게 소비 되었다면 아마도 파일 할당 일 것입니다.

원인은 일부 응용 프로그램의 처리량이 많은 빈 스왑 또는 임시 파일 일 수 있습니다.

를 수행 du --max-length=1공간이 많이 소비됩니다.

루트 폴더가 너무 많이 걸린다고 생각되면 (3.3GB) ll -a /를 시도 하고 결과를 게시하십시오.

/var/lib/ureadahead/debugfs붉은 청어 인 것 같습니다 . 이유는 ...

에 /var/lib/ureadahead/debugfs존재 하지만 /etc/mtab다음에 없습니다 /proc/mounts.

$ mount | grep debug
none on /sys/kernel/debug type debugfs (rw)
none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)

$ cat /proc/mounts | grep debug
none /sys/kernel/debug debugfs rw,relatime 0 0

이 df명령은 /var/lib/ureadahead/debugfsand에 대해 똑같은 것을보고하는 것 같습니다/

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   1681128   8115792  18% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   1681128   8115792  18% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

에 1GB 파일 만들기 /tmp:

$ dd if=/dev/zero of=/tmp/carypjunk.out bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 52.7234 s, 20.4 MB/s

두 곳에서보고 된 크기를 표시합니다.

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   2730216   7066704  28% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   2730216   7066704  28% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

따라서 /var/lib/ureadahead/debugfs의 통계를 반영하기 때문에 장치가 빨간색 청각 처럼 보입니다 /. 공간이 부족한 경우 루트 파일 시스템을 채우는 것이 원인입니다. 먼저 / var / log를 확인하겠습니다.

매분마다 php CLI 명령을 실행하는 cron 작업으로 문제가 시작되었습니다. PHP 코드는 잡힌 오류의 일종의 광기 루프와 프로세서 속도로 커지는 대량의 디버그 데이터에 갇혀있는 것처럼 보였습니다.

실행되는 PHP 코드가 1 분 이상 걸렸기 때문에 수행 한 작업을 고려하지 않았으므로 (임시?) 데이터의 증가 속도를 계속해서 반복해서 실행했습니다.

동일한 작업이 한 달 동안 거의 아무런 문제없이 실행되어 왔기 때문에 원인으로 생각하지 않았습니다.

이상한 점은 PHP 스크립트가 최대 실행 시간을 수동으로 설정한다는 것입니다

단서가 있는지 php.ini를 확인했습니다.

; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time = 30

; Maximum amount of time each script may spend parsing request data. It's a good
; idea to limit this time on productions servers in order to eliminate unexpect$
; long running scripts.
; Note: This directive is hardcoded to -1 for the CLI SAPI
; Default Value: -1 (Unlimited)
; Development Value: 60 (60 seconds)
; Production Value: 60 (60 seconds)
; http://php.net/max-input-time
max_input_time = 60

CLI에 대해 값이 무제한으로 하드 코딩되었다고 말합니다! O_o