„No space left on device" არასდროს ჩნდება ხელსაყრელ დროს. მონაცემთა ბაზა წყვეტს ჩაწერის მიღებას, apt ვერ ასრულებს განახლებას, Docker კი უარს ამბობს სწორედ იმ 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 ძველ ბირთვებსაც შლის. ხალხს ყველაზე მეტად systemd-ის journal აკვირვებს — თუ თავის ნებაზე მიუშვებთ, შეიძლება რამდენიმე გიგაბაიტამდე გაიზარდოს. სამუდამოდ შესაზღუდად /etc/systemd/journald.conf-ში დააყენეთ SystemMaxUse=200M და გაუშვით systemctl restart systemd-journald.
4. Docker-ის ნარჩენები
თუ Docker-ს იყენებთ, ჯერ აქ შეიხედეთ. ძველი image-ები და build-ქეში ყოველ deploy-ზე გროვდება:
docker system df
docker image prune -a
docker builder prune
docker image prune -a შლის image-ებს, რომლებსაც არც ერთი გაშვებული კონტეინერი არ იყენებს. ჩვეულებრივ სწორედ ეს გინდათ, მაგრამ შემდეგი deploy მათ ისევ ჩამოტვირთავს.
საშიში ბრძანებაა docker system prune -a --volumes. ვოლიუმებში თქვენი მონაცემებია, ხოლო გაჩერებულ კონტეინერზე მიბმული ვოლიუმი გამოუყენებლად ითვლება. ასე კარგავენ ადამიანები მონაცემთა ბაზებს. ფორუმის პასუხიდან ნუ ჩასვამთ.
მეორე ფარული ადგილის მჭამელი კონტეინერების ლოგებია. შეზღუდეთ ისინი /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-სტეკის სახელმძღვანელო გაჩვენებთ, როგორ დაიჭიროთ image-ები კონტროლქვეშ.
ჩვევა, რომელიც ამ ყველაფერს აცილებს: პირველივე დღეს შეზღუდეთ journal და Docker-ის ლოგები. კონფიგურაციის ორი ხაზი — და „დისკი სავსეა" თითქმის აღარ ხდება.
კომენტარები
ჯერ არ არის კომენტარები. იყავით პირველი.