ออกจากพื้นที่ดิสก์แหล่งที่มาคืออะไร


17
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 gigs แต่ฉันไม่สามารถตรวจสอบทุกโฟลเดอร์

แก้ไข ไปถึง

/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 สำหรับ /

คำตอบ:


16

ฉันคิดว่าคุณมีบางอย่างที่เขียนไปยังไฟล์ที่ถูกลบออกจากไดรฟ์ แต่ยังไม่ได้ปิดโดยแอปพลิเคชัน / เซิร์ฟเวอร์ดังนั้นพื้นที่ยังคงถูกจัดสรรไว้ในดิสก์ แต่ไม่สามารถมองเห็นได้duตั้งแต่ไฟล์ถูกลบออกจากระบบไฟล์ lsofกระบวนการรายการโปรแกรมที่มีไฟล์เปิด หากคุณติดตั้งระบบไฟล์เพิ่มเติมและจำนวนไม่ผันผวนมากดังนั้นฉันขอแนะนำให้คุณติดตั้งระบบไฟล์ที่ด้านบนของไดเรกทอรีที่ไม่ว่างเปล่า (แม้ว่าคุณจะลองumount /var/lib/ureadahead/debugfsและทำให้แน่ใจว่าไดเรกทอรีนั้นว่างเปล่าและ ไม่มีกลุ่มของขยะที่เขียนไปยังไดเรกทอรีที่ซ่อนอยู่ใต้จุดเมานท์นั้น)

sudo lsof | grep deletedหากเป็นกรณีนี้แล้วคุณจะพบเหล่านี้ด้วย lsofรวม(deleted)อยู่ในคอลัมน์สุดท้ายหากไฟล์ถูกลบในขณะที่กระบวนการยังคงเปิดอยู่ คอลัมน์แรกคือชื่อของคำสั่งคอลัมน์ที่สองคือ PID คุณสามารถดูรายละเอียดเพิ่มเติมที่คำสั่งโดยใช้psตัวอย่างps auxww | grep PIDหรือps auxwwf | less -Sเพื่อดูรายการกระบวนการในโหมด "ฟอเรสต์" เพื่อให้คุณสามารถดูกระบวนการที่ PID มาจาก เมื่อคุณติดตามกระบวนการที่เก็บไฟล์ยักษ์ไว้คุณสามารถหยุดมันเพื่อเพิ่มพื้นที่ว่างในไดรฟ์แล้วหาวิธีแก้ไขมันเพื่อปิดไฟล์อย่างถูกต้อง สาเหตุปกติของการทำเช่นนี้คือสคริปต์ logrotate ที่เปลี่ยนชื่อ / ลบไฟล์บันทึก แต่ไม่ได้แจ้งแอปพลิเคชันว่าทำเช่นนั้น (ผ่านสัญญาณที่เหมาะสมด้วยkill หรือโดยการรีสตาร์ทแอปพลิเคชัน) ดังนั้นแอปพลิเคชั่นจะยังคงเปิดล็อกไฟล์เก่าอยู่


ขอบคุณ ฉันวิ่งlsof | grep deletedและสังเกตเห็นไฟล์บันทึก 33GB! ฆ่ากระบวนการและพื้นที่ดิสก์กลับมา
ekawas

ขอบคุณ! ในช่วงเวลาที่ฉันลบฐานข้อมูล mongodb บางส่วน แต่ mongodb ไม่ปล่อย ฉันเพิ่งเริ่ม mongodb และตอนนี้ฉันมี 35GB เพิ่มเติม \ o /
iurisilvio

7

วิ่ง

du -h --max-depth=1 /

และควรให้ภาพที่ชัดเจนยิ่งขึ้น หากไฟล์มาและไปจะมีเสียงเหมือนไฟล์ temp ที่สร้างขึ้นและจะไม่ถูกลบเมื่อดำเนินการจนเสร็จสิ้นกระบวนการใดก็ตามที่ทำให้เกิดปัญหา เซิร์ฟเวอร์นี้ใช้ระบบปฏิบัติการรุ่นใดและใช้งานอะไรเป็นพิเศษ


มันเป็นอูบุนตูที่ใช้หลอดไฟและไม่มากไปกว่านี้
Moak

5

/var/lib/ureadahead/debugfsดูเหมือนว่าปัญหาคือ มันจะปรากฏขึ้นนี้เป็นปัญหาที่รู้จักกันนี่คือการเชื่อมโยงไป ubuntuforums มีข้อมูลมากขึ้น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


ใช่ฉันกำลังคิดถึง Lucid Lynx 10.04 ขอบคุณ
Moak

หลังจากอ่านข้อความนี้ดูเหมือนว่าไม่ควรลบคุณลักษณะนั้นออกไป มีวิธี จำกัด ขนาดที่เพิ่มขึ้นหรือไม่?
Moak

หลังจากที่มีการค้นหามากขึ้นเล็ก ๆ น้อย ๆ ผมพบว่านี้somewhereville.com/?p=1370ซึ่งอ้างอิงเป็นที่รู้จักและได้รับการแก้ไขข้อผิดพลาดใน mountall นี่bugs.launchpad.net/ubuntu/+source/mountall/+bug/736512
slillibri

3

ฉันเดาว่าเป็นไฟล์บันทึก; ฉันมีคำเตือน "เลิกใช้" PHP 5.3 จำนวนมากในบันทึก Apache ของฉันบนเซิร์ฟเวอร์ dev ที่ฉันไม่ได้สนใจว่ามันเคี้ยวพื้นที่ 8GB ทั้งหมดในพาร์ติชัน var ของฉัน (เป็นแถบด้านข้างกับปัญหา: คุณควรเสมอ ใส่ / var ในพาร์ติชันแยกต่างหากที่พาร์ติชันรูทของคุณซึ่งมีเนื้อที่ไม่เพียงพออาจทำให้เกิดปัญหาระบบไม่เสถียร)


3

หากมีการใช้พื้นที่อย่างรวดเร็ว (ไม่ใช่ในอายุ) อาจเป็นเพียงการจัดสรรไฟล์

สาเหตุอาจเป็นการสลับขนาดใหญ่หรือไฟล์ชั่วคราวสำหรับบางแอปพลิเคชันซึ่งจะถูกทำให้ว่างเปล่าหลังจากกระบวนการ

ทำdu --max-length=1เมื่อมีการใช้พื้นที่มาก

หากคุณคิดว่าโฟลเดอร์รูทของคุณใช้เวลามากเกินไป (3.3 GB) ให้ลอง-a /และโพสต์ผลลัพธ์


1
อันที่จริงแล้วรูทนั้นเป็นผลรวมของโฟลเดอร์เหล่านั้น
Moak

1

ดูเหมือนว่า/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/debugfsและ/

$ 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 ของคุณก่อน


อ่าถูกต้องทั้งหมด ฉันพลาดความสัมพันธ์! น่าเสียดายที่ฉันยุติอินสแตนซ์ดังนั้นฉันไม่สามารถตรวจสอบสิ่งที่เติบโตเร็วเกินไป
แอรอน Gibralter

0

ปัญหาเริ่มต้นโดยงาน cron ที่ดำเนินการคำสั่ง php CLI ทุกนาที โค้ด PHP ดูเหมือนจะติดอยู่ในวงวนบ้าคลั่งของข้อผิดพลาดที่จับได้และข้อมูลการดีบักจำนวนมากที่เติบโตด้วยความเร็วของโปรเซสเซอร์

เมื่อโค้ด php ที่ถูกประหารใช้เวลานานกว่าหนึ่งนาทีมันไม่ได้พิจารณาว่างานเสร็จสิ้นแล้วมันยังคงดำเนินการอีกครั้งและอีกครั้งเพิ่มความเร็วของการเติบโตของข้อมูล (ชั่วคราว?)

งานเดิมได้ทำงานมาเกือบเดือนโดยไม่มีปัญหาดังนั้นฉันจึงไม่ได้เป็นต้นเหตุ

สิ่งที่แปลกคือสคริปต์ 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

มันบอกว่าค่าจะถูก hardcoded ให้ไม่ จำกัด สำหรับ CLI! O_o

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.