พื้นที่หมดคือสาเหตุที่พบบ่อยที่สุดที่เซิร์ฟเวอร์หยุดทำงานโดยไม่มีเจตนาร้ายใดเข้ามาเกี่ยวข้อง เว็บไซต์คืน 500 ฐานข้อมูลเขียนไม่ได้ เมลไม่ออก — และในระหว่างนั้น df -h รายงานว่ามีว่างอยู่หลายกิกะไบต์ มาดูทั้งสามกรณีที่เรื่องแบบนั้นเกิดขึ้น และสิ่งที่ควรรู้เกี่ยวกับ SMART

กรณีที่หนึ่ง: inode หมด

ระบบไฟล์มีทรัพยากรจำกัดสองอย่าง: พื้นที่สำหรับเนื้อหาและรายการเกี่ยวกับไฟล์ อย่างที่สองหมดได้อย่างเป็นอิสระจากอย่างแรก:

df -h
df -i

ถ้า IUse% ในคำสั่งที่สองเป็น 100 ปัญหาคือ inode มีพื้นที่ แต่สร้างไฟล์ไม่ได้แม้แต่ไฟล์เดียว แม้แต่ไฟล์ว่าง

ผู้ร้ายมักเป็นตัวเดิม: ไฟล์เล็ก ๆ นับล้าน เซสชัน PHP ใน /var/lib/php/sessions ที่การเก็บขยะพัง แคชของแอปพลิเคชันที่ไม่เคยถูกล้าง คิวเมลที่ค้าง ไดเรกทอรีภาพย่อ หาพวกมันได้แบบนี้:

sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

คำสั่งนี้แสดงไดเรกทอรีที่มีไฟล์มากที่สุด บนระบบใหญ่มันรันเป็นนาที — นั่นเป็นเรื่องปกติ

กรณีที่สอง: ไฟล์ถูกลบแล้วแต่พื้นที่ไม่คืนมา

สถานการณ์ที่ทรยศยิ่งกว่า มีคนลบล็อกที่โตเกินด้วย rm แต่กระบวนการที่เขียนลงไปยังถือมันเปิดอยู่ ไฟล์ไม่อยู่ในไดเรกทอรีแล้ว พื้นที่ยังถูกยึดไว้ และจะเป็นเช่นนั้นจนกว่ากระบวนการจะถูกรีสตาร์ต

sudo lsof +L1

คำสั่งนี้แสดงไฟล์ที่มีลิงก์เป็นศูนย์ในระบบไฟล์แต่ยังมีกระบวนการถือไว้ การรักษาคือรีสตาร์ตหรือโหลดกระบวนการนั้นใหม่อย่างนุ่มนวล ไม่ใช่การตามหาว่า «กิกะไบต์หายไปไหน»

จากตรงนี้จึงเกิดกฎ: ล็อกที่โตเกินไม่ได้ถูกลบแต่ถูกตัดให้ว่าง ซึ่งทำให้ descriptor ที่เปิดอยู่ยังใช้งานได้:

sudo truncate -s 0 /var/log/huge.log

และทันทีหลังจากนั้นให้ตั้งค่าการหมุนเวียน — มิฉะนั้นทั้งหมดนี้จะเกิดซ้ำภายในหนึ่งสัปดาห์

กรณีที่สาม: ล็อกกินไปหมด

พื้นที่หายไปไหนกันแน่ดูได้จากการไล่ลงทีละระดับ:

sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -h

ธง -x กันไม่ให้มันเดินไปยังระบบไฟล์อื่น ถ้าไม่มี การนับจะคลานเข้าไปใน /proc และ mount ของเครือข่าย ทั้งหมดนี้ทำใน ncdu สบายกว่า ถ้ามีให้ใช้

ตัวกินตามปกติ:

  • journald คำสั่งเดียวจบ: journalctl --disk-usage จำกัดมันด้วยบรรทัด SystemMaxUse=500M ใน /etc/systemd/journald.conf และล้างครั้งเดียวด้วย journalctl --vacuum-size=200M;
  • ล็อกของเครื่องมือความปลอดภัย Suricata ด้วยการตั้งค่ามาตรฐานเขียนเหตุการณ์สามสิบประเภทและไม่ตั้งค่าการหมุนเวียนให้ตัวเอง — บนเซิร์ฟเวอร์จริงมันสร้าง 15 GB ในสองวัน เรื่องเดียวกันเกิดกับ audit.log และกับล็อกดีบักใน nginx;
  • สำรองข้อมูล ที่เขียนลงดิสก์เดียวกันและไม่เคยถูกลบ;
  • แคชของ apt — apt clean บางครั้งคืนมาสองสามกิกะไบต์

สองคำเกี่ยวกับ /boot

พาร์ทิชันเล็ก ๆ ที่เต็มไปด้วยเคอร์เนลเก่า มันไม่ได้ทำให้เว็บไซต์ล่มด้วยตัวเอง แต่มันหยุดการอัปเดตสนิท: เคอร์เนลใหม่จะติดตั้งไม่ได้ และคิวแพ็กเกจทั้งหมดก็ค้างอยู่ข้างหลังมัน รักษาด้วย apt autoremove --purge และป้องกันด้วยการเปิดการลบเคอร์เนลที่ไม่ใช้อัตโนมัติในการตั้งค่าอัปเดตอัตโนมัติ

SMART: แอตทริบิวต์ไหนสำคัญ

ข้อควรระวังก่อน: บนเซิร์ฟเวอร์เสมือน SMART มักใช้ไม่ได้ — ดิสก์เป็นเสมือนและคุณไม่เห็นดิสก์จริงที่อยู่ข้างใต้ นั่นไม่ใช่ข้อบกพร่อง เพียงแต่ไม่มีข้อมูล ทุกอย่างต่อจากนี้ว่าด้วยเซิร์ฟเวอร์เฉพาะและฮาร์ดแวร์ของคุณเอง

sudo smartctl -a /dev/sda

บรรทัด SMART overall-health self-assessment test result: PASSED ไม่ใช่เหตุให้วางใจ: มันยังเขียวอยู่แทบจนกระทั่งไดรฟ์ตาย สิ่งที่ควรดูคือตัวนับที่เจาะจง:

  • 5, Reallocated_Sector_Ct — เซกเตอร์ที่ถูกย้าย ถ้าไม่เป็นศูนย์แปลว่าไดรฟ์กำลังเสื่อมแล้ว ถ้าเพิ่มขึ้นตามเวลาแปลว่าให้เปลี่ยนโดยไม่ต้องรอ;
  • 197, Current_Pending_Sector — เซกเตอร์ที่อ่านไม่ได้และรอการตัดสินใจ น่าเป็นห่วงที่สุดในกลุ่ม: ปกติมันแปลว่าข้อมูลบางส่วนกู้ไม่ได้แล้ว;
  • 198, Offline_Uncorrectable — เรื่องเดียวกัน ยืนยันด้วยการตรวจ;
  • SSD: Percentage Used / Media_Wearout_Indicator — ความทนทานในการเขียนที่ใช้ไปแล้ว ตัวเลขที่คาดการณ์ได้ และเป็นตัวที่ใช้วางแผนการเปลี่ยน

ในทางกลับกัน อุณหภูมิและชั่วโมงการทำงานไม่ได้บอกอะไรในตัวเอง: ไดรฟ์ที่ทำงานมาห้าปีโดยตัวนับข้อผิดพลาดเป็นศูนย์นั้นน่าเชื่อถือกว่าไดรฟ์ใหม่ที่มีเลข 1 ในแอตทริบิวต์ 197

ความหมายของการเฝ้าดู

ทุกอย่างข้างต้นคือการตอบสนองต่อสิ่งที่เกิดขึ้นแล้ว ทั้งที่ดิสก์ที่ค่อย ๆ เต็มและการสึกหรอของ SSD ต่างเป็นกระบวนการที่ช้าและคาดการณ์ได้อย่างสมบูรณ์: กราฟการใช้พื้นที่สองสัปดาห์บอกวันที่พื้นที่จะหมดล่วงหน้านานมาก ความต่างระหว่าง «เว็บไซต์ล่มตั้งแต่ตีสาม» กับ «วันพฤหัสต้องล้างล็อก» ก็เพียงแค่ว่าตัวเลขนั้นอยู่ตรงหน้าคุณหรือไม่ ภาพเมื่อประกอบเข้าด้วยกันเป็นอย่างไรดูได้ที่หน้าเดโมด้านล่าง