"No space left on device" ไม่เคยโผล่มาในจังหวะที่ดี ฐานข้อมูลหยุดรับการเขียน apt อัปเกรดไม่จบ และ Docker ไม่ยอม pull image ตัวที่คุณต้องใช้ตอนนี้พอดี ข่าวดีคือ บน VPS เล็กๆ ตัวการเกือบทุกครั้งคือหนึ่งในห้าสิ่ง และคุณหาเจอได้ในสองนาที
1. หนักแค่ไหน?
df -h /
df -i /
บรรทัดแรกแสดงพื้นที่ที่ใช้ไป บรรทัดที่สองแสดง inode — ถ้า inode แตะ 100% ทั้งที่พื้นที่ยังดูเหลือ แปลว่าคุณมีไฟล์จิ๋วเป็นล้านไฟล์ (ไฟล์เซสชัน คิวอีเมล โฟลเดอร์แคช) ปัญหาต่างกัน อาการเหมือนกัน
2. หาว่าอะไรใหญ่
ไล่ดูต้นไม้โฟลเดอร์จากบนลงล่างแล้วเรียงตามขนาด:
du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15
-x จะอยู่แค่ในระบบไฟล์เดียว ไม่หลงเข้าไปใน /proc จากนั้นเจาะลงไปในตัวที่ใหญ่ที่สุด ถ้าจะดูแบบโต้ตอบ ncdu สะดวกกว่ามาก:
apt install -y ncdu
ncdu -x /
ปุ่มลูกศรไว้เลื่อน d ไว้ลบ ระวังปุ่มหลังให้ดี
3. ชัยชนะแบบเร็ว
คำสั่งเหล่านี้ปลอดภัยบนเซิร์ฟเวอร์ Ubuntu หรือ Debian ทุกเครื่อง:
apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M
apt autoremove จะลบเคอร์เนลเก่าด้วย journal ของ systemd คือสิ่งที่ทำให้หลายคนตกใจ — ถ้าปล่อยไว้มันโตได้หลายกิกะไบต์ หากจะจำกัดถาวร ให้ตั้ง SystemMaxUse=200M ใน /etc/systemd/journald.conf แล้วรัน systemctl restart systemd-journald
4. เศษของ Docker
ถ้าคุณใช้ Docker ให้มาดูตรงนี้ก่อน image เก่าและแคชบิลด์พอกพูนขึ้นทุกครั้งที่ deploy:
docker system df
docker image prune -a
docker builder prune
docker image prune -a ลบ image ที่ไม่มีคอนเทนเนอร์ที่กำลังรันใช้อยู่ ส่วนใหญ่นั่นคือสิ่งที่ต้องการ แต่การ deploy ครั้งถัดไปจะ pull กลับมาอีก
ตัวอันตรายคือ docker system prune -a --volumes volume เก็บข้อมูลของคุณ และ volume ที่ผูกกับคอนเทนเนอร์ที่ หยุดอยู่ ถือว่าไม่ได้ใช้ หลายคนเสียฐานข้อมูลไปแบบนี้ อย่าก๊อปคำสั่งนี้มาจากคำตอบในฟอรัม
ตัวกินพื้นที่ที่ซ่อนอยู่อีกตัวคือล็อกของคอนเทนเนอร์ จำกัดมันใน /etc/docker/daemon.json:
{
"log-driver": "json-file",
"log-opts": { "max-size": "10m", "max-file": "3" }
}
จากนั้นรีสตาร์ต Docker ขีดจำกัดนี้มีผลกับคอนเทนเนอร์ที่สร้างหลังจากนั้นเท่านั้น ให้สร้างตัวที่เขียนล็อกเยอะใหม่ด้วย docker compose up -d --force-recreate
5. ล็อกและไฟล์ที่ถูกลืม
หาไฟล์ใหญ่จากทุกที่บนดิสก์:
find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null
ของที่เจอบ่อย: backup.tar.gz เมื่อหกเดือนก่อนใน /root, ไฟล์ dump ฐานข้อมูลที่ใครสักคนตั้งใจจะดาวน์โหลด, ล็อกแอปที่ไม่เคยถูกหมุนเวียน
ล็อกที่เซอร์วิสยังเขียนอยู่ อย่าลบด้วย rm — ให้ล้างข้างในแทน:
truncate -s 0 /var/log/myapp/app.log
ถ้าลบไปแล้วแต่พื้นที่ไม่กลับมา แปลว่ายังมีโปรเซสเปิดไฟล์นั้นค้างอยู่:
lsof +L1
รีสตาร์ตเซอร์วิสที่แสดงในรายการนั้น แล้วพื้นที่จะกลับมา
เมื่อการเคลียร์ยังไม่พอ
บางครั้งข้อมูลก็เป็นของจริง — ฐานข้อมูลที่โตขึ้นเรื่อยๆ ไฟล์ที่ผู้ใช้อัปโหลด ไฟล์โมเดล ถึงตอนนั้นทางออกที่ตรงไปตรงมาคือเพิ่มดิสก์ การอัปเกรดแพ็กเกจขยายดิสก์ในที่เดิมและเก็บทุกอย่างไว้: Nano มี 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB เซิร์ฟเวอร์รีสตาร์ตหนึ่งครั้ง รายละเอียดอยู่ในเอกสารแพ็กเกจ
อีกอย่างที่แอบกินพื้นที่เงียบๆ คือไฟล์ swap ถ้าคุณทำตามคู่มือ swap ของเรา 1–2 GB นั้นถูกกันไว้โดยตั้งใจ และถ้า Docker คือตัวกินพื้นที่หลัก คู่มือติดตั้ง Docker กับคู่มือ Compose stack จะบอกวิธีคุมจำนวน image ให้อยู่
นิสัยที่ป้องกันเรื่องทั้งหมดนี้: จำกัด journal และล็อกของ Docker ตั้งแต่วันแรก การตั้งค่าแค่สองบรรทัด แล้วเรื่อง "ดิสก์เต็ม" ก็แทบไม่เกิดอีก
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกสิ