Disk alanı yetersiz, kaynak nedir?

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

çağlar gibi görünen şeylerden sonra cevap aramaya paniğe kapılırken kullanım azaldı

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

Şimdiye kadar hiçbir şeyi silmedim ve şimdi bunu yazdığım için

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

Ne oldu?? Nedeni nasıl araştırabilirim ve bir daha nasıl olmayacak şekilde ayarlayabilirim, bunun tekrar olmasını önlerim

Masaj kullanımı sırasında / var klasörünün boyutunun 1.8 konserde sabit olduğunu gördüm, ancak tüm klasörleri kontrol edemedim

düzenlemek gone up to

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

* güncelleme 2 * Tekrar yükseliyor

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

Ve bana verilen komutu kontrol ettim

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 için /

Sürücüden silinmiş ancak uygulama / sunucu tarafından henüz kapatılmamış bir dosyaya yazdığınız bir şey olduğunu düşünüyorum, bu yüzden alan diskte ayrılmış kalır ancak dudosya dosya sisteminden kaldırıldığından beri görülemez . lsofDosyaları var Program listeleri süreçleri açın. Daha fazla dosya sisteminiz varsa ve sayı çok fazla dalgalanmadıysa, boş olmayan bir dizinin üzerine monte edilmiş bir dosya sisteminiz olmasını önerirdim (ancak umount /var/lib/ureadahead/debugfsdizinin boş olduğundan emin olabilirsiniz ve bu bağlama noktasının altında saklanan dizine yazılmış önemsiz bir grup yoktur).

Bu durumda, bunları kolayca bulmalısınız sudo lsof | grep deleted. lsofiçeren (deleted)bir süreç hala açık varken bir dosya silinmiş ise son sütunda. İlk sütun komutun adı, ikinci sütun PID'dir. psÖrneğin kullanarak komutu daha ayrıntılı olarak inceleyebilir ps auxww | grep PIDveya ps auxwwf | less -SPID'nin hangi işlemden geldiğini görebilmeniz için işlem listesini "orman" modunda görebilirsiniz. Açık dev dosyaları tutan işlemleri izledikten sonra, sürücü alanını boşaltmak için durdurabilir, ardından dosyayı düzgün bir şekilde kapatmak için nasıl düzeltileceğini anlayabilirsiniz. Bunun genel nedeni, günlük dosyalarını yeniden adlandıran / silen ancak uygulamaya bunu bildirmediği bir logrotate betiğidir (uygun bir sinyal ilekill veya uygulamayı yeniden başlatarak), böylece uygulama eski günlük dosyasını açık tutmaya devam eder.

Çalıştırmak

du -h --max-depth=1 /

Ve daha net bir resim vermeli. Geliyor ve gidiyorsa, geçici dosyalar oluşturuluyor ve sonra bir kez tamamlandığında silinmiyorsa, hangi işlem çöktüğüne kadar. Bu sunucu hangi işletim sistemidir ve özellikle herhangi bir şey çalıştırıyor mu?

Sorun öyle görünüyor /var/lib/ureadahead/debugfs. Bu bilinen bir sorun gibi görünüyor, burada daha fazla bilgi ile ubuntuforums bir bağlantı http://ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrading-to-ubuntu-10-04 . Tl; dr güncelleme ve yükseltme gibi görünüyor sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabled, sonra yeniden başlatın. Tabii ki, 10.04 kullandığınızı varsayıyorum.

Benim tahminim günlük dosyaları; Bir dev sunucusunda Apache günlüklerimde çok fazla PHP 5.3 "kullanımdan kaldırıldı" uyarısı aldım, gerçekten var bölümümdeki tüm 8GB alanını (soruna bir kenar çubuğu olarak) çiğnediğine dikkat etmiyordum: her zaman ayrı bir bölüme koymak / kök bölümünüzde yer kalmamış olarak sistem kararsızlığı sorunlarına neden olabilir).

Alan çok hızlı tüketilirse (çağlarda değil), Muhtemelen sadece dosya tahsisi.

Nedeni, işleminden sonra boşaltılan bazı uygulamalar için büyük takas veya geçici dosyalar olabilir.

Bir Do du --max-length=1uzay çok tüketildiğinde.

Kök klasörünüzün çok fazla sürdüğünü düşünüyorsanız (3,3 GB) ll -a / komutunu deneyin ve sonuçları gönderin.

/var/lib/ureadahead/debugfsKırmızı bir ringa balığı olabilir gibi görünüyor . İşte nedeni ...

/var/lib/ureadahead/debugfsVar olmasına rağmen , içinde /etc/mtabbulunmaz /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

dfKomut için tam olarak aynı şeyi raporlama gibi görünüyor /var/lib/ureadahead/debugfsve/

$ 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 dosya oluşturma /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

Her iki yerde de bildirilen boyutu gösterir:

$ 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

Yani, /var/lib/ureadahead/debugfscihaz sadece istatistikleri yansıttığı için kırmızı bir ringa balığı gibi görünüyor /. Alanınız bitiyorsa, bunun nedeni kök dosya sisteminizi dolduran bir şeydir. Önce / var / log'unuzu kontrol ederdim.

Sorun, her dakika bir php CLI komutu yürüten bir cron görevi tarafından başlatıldı. PHP kodu, yakalanan hataların bir çeşit delilik döngüsünde sıkışmış gibi görünüyordu ve işlemcinin hızında büyüyen büyük miktarda hata ayıklama verisi.

Yürütülen php kodu bir dakikadan daha uzun sürdüğü için yapılan işi dikkate almadı, tekrar tekrar yürütmeye devam etti (geçici?) Verilerin büyüme hızını artırdı.

Aynı görev bir aya yakın bir süredir sorunsuz çalışıyor, bu yüzden bir sebep olarak aklımda değildi.

Garip şey, php betiğinin maksimum yürütme süresini manuel olarak ayarlamasıdır

Php.ini'yi ipuçları için kontrol ettim

; 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 için değerlerin sınırsız olarak sabit kodlanmış olduğunu söylüyor! O_o