Ia adalah 3:14 AM dan alat kelui dimatikan. `/var` berada pada 97% dan mendaki. Pada masa anda log masuk, aplikasi telah berhenti menerima penulisan, pangkalan data telah bertukar ke mod baca sahaja, dan papan pemuka pemantauan anda berwarna merah. Anda SSH masuk, jalankan `df -h`, dan terdapat: volum 200 GB, 100% digunakan.
Jadi anda jalankan `du -sh /var/*` dan nombornya tidak bertambah. Direktori menyumbang mungkin 60 GB. 140 GB yang lain nampaknya telah sejat.
Ia belum. Di Linux, ruang cakera sentiasa dilampirkan pada sesuatu โ fail, inod, pemegang fail yang dipadam tetapi masih terbuka, lapisan bekas, kernel lama, syot kilat atau aliran log yang tidak diputar oleh sesiapa pun. Kemahiran forensik ialah mengetahui di mana hendak melihat, dalam susunan apa, dan perintah mana yang memberitahu kebenaran.
Panduan ini menelusuri urutan diagnostik yang benar-benar menemui pelakunya, perangkap yang memperbodohkan pentadbir berpengalaman, dan rutin pembersihan yang selamat dijalankan pada jam 3 pagi.
Langkah 1: Baca df Dengan Betul โ Ruang dan Inoda
Setiap penyiasatan bermula dengan dua arahan, bukan satu:
```bash
df -h
df -i
```
`df -h` menunjukkan bait yang digunakan bagi setiap sistem fail yang dipasang. `df -i` menunjukkan penggunaan inod. Inode ialah rekod bersaiz tetap yang menyimpan metadata fail, dan sistem fail boleh kehabisan inod sementara masih melaporkan banyak ruang kosong. Direktori yang menyimpan dua juta fail sesi kecil boleh mencapai 100% inod manakala hanya 30% daripada baitnya digunakan โ dan ralat "Tiada ruang tersisa pada peranti" yang anda dapat akan mengelirukan semua orang yang hanya menyemak `df -h`.
Tiga perkara yang perlu dicari:
- Lekapan mana yang penuh. `df -h` melaporkan setiap titik lekap. `/var`, `/home` dan `/` selalunya merupakan jilid yang berasingan dan mengisi satu tidak mengisi yang lain.
- Sama ada pemasangan rangkaian. Lekapan NFS atau CIFS pada 100% adalah masalah orang lain, tetapi ia masih merosakkan aplikasi anda. Semak lajur peranti sebelum memadamkan apa-apa.
- Sama ada inod ialah had sebenar. Jika `df -h` menunjukkan ruang kosong tetapi penulisan masih gagal, `df -i` ialah jawapan anda.
Jika sistem fail penuh ialah `/` tetapi data anda berada di bawah `/var`, masalah ruang anda berada di dalam `/var` walaupun `df` menyalahkan `/`. Susun atur pelekap lebih penting daripada baris pertama output arahan.
Langkah 2: Perangkap โ Fail Dipadamkan Yang Masih Dibuka
Ini ialah satu-satunya sebab yang paling biasa `df` dan `du` tidak bersetuju, dan itulah sebabnya cakera "penuh" kekal penuh walaupun selepas anda memadamkan punca yang jelas.
Apabila proses mempunyai fail terbuka dan anda mengalih keluar fail itu, entri direktori hilang tetapi inod dan blok datanya tidak dikeluarkan sehingga proses menutup pemegangnya. `du` berjalan pada pokok direktori dan tidak dapat melihat fail, jadi ia melaporkan kurang penggunaan. `df` meminta sistem fail dan masih mengira blok. Ruang itu nyata, diduduki dan tidak dapat dilihat sepenuhnya oleh `du`.
Pembaikan adalah satu arahan:
```bash
lsof +L1
```
`+L1` menyenaraikan fail dengan kiraan pautan di bawah satu โ dengan kata lain, fail dipadam yang masih dibuka. Output menunjukkan proses pemilikan, deskriptor fail, dan saiz. Satu fail log lari yang dibuka oleh pelayan web boleh menahan berpuluh-puluh gigabait sebagai tebusan selama berminggu-minggu.
Sebaik sahaja anda telah mengenal pastinya, anda mempunyai dua pilihan selamat:
- Mulakan semula atau muat semula proses supaya ia melepaskan pemegangnya. Pilih tambah nilai yang anggun, dan hanya dalam tetingkap penyelenggaraan jika prosesnya kritikal.
- Potong fail pada tempatnya melalui laluan deskriptor fail. Ini menulis kepada inod yang sama, membebaskan blok data, dan memastikan deskriptor sah:
```bash
truncate -s 0 /proc/12345/fd/7
```
Gantikan `12345` dengan PID daripada `lsof` dan `7` dengan nombor deskriptor fail. Sahkan dengan `df -h` serta-merta selepas itu โ ruang kosong akan muncul dalam beberapa saat.
Langkah 3: Cari Hogs Angkasa Sebenar dengan du dan ncdu
Dengan kes fail hantu diketepikan, berjalan di atas pokok:
```bash
du -xh --max-depth=1 / | sort -rh | kepala -20
```
Bendera `-x` penting: ia menghentikan `du` daripada menyeberang ke sistem fail lain, jadi volum sandaran yang dipasang atau tmpfs tidak mencemarkan hasil anda. Isih mengikut saiz yang boleh dibaca manusia dan mengambil baris teratas memberikan anda direktori terbesar pada setiap peringkat. Latih tubi dengan mengulangi arahan pada pemenang.
Pada pelayan yang sibuk, `du` berjalan pada pokok berjuta-juta fail mengambil masa lebih lama daripada gangguan yang anda cuba selesaikan. Jalankannya dengan `masa tamat` supaya imbasan tidak boleh menggantung sesi anda:
```bash
tamat masa 120 du -xh --max-depth=1 /var | sort -rh | kepala
```
Untuk memburu interaktif, pasang `ncdu`. Ia mengindeks pepohon sekali dan kemudian membolehkan anda menavigasi, mengisih dan memadam dengan papan kekunci โ jauh lebih pantas daripada hantaran `du` berulang:
```bash
ncdu -x /var
```
Pada volum 500 GB, `ncdu` lazimnya menamatkan indeksnya dalam masa kurang seminit dan mengekalkan indeks tersebut dalam ingatan antara latih tubi menjimatkan masa yang besar semasa kejadian. Kedua-dua alatan adalah baca sahaja sehingga anda menekan kekunci padam, yang menjadikannya selamat untuk dijalankan pada pelayan langsung.
Langkah 4: Suspek Biasa
Sebaik sahaja anda mengetahui direktori itu, soalan seterusnya ialah apa di dalamnya. Kategori ini menyumbang sebahagian besar daripada kejutan dunia sebenar:
| Suspek | Lokasi biasa | Apa yang perlu dilakukan |
|---|---|---|
| jurnal systemd | /var/log/jurnal | Tutup dengan vakum journalctl |
| Log permohonan | /var/log, dir apl | Putar dan mampatkan |
| Lapisan bekas | /var/lib/docker | Pangkas imej berjuntai |
| Cache pakej | /var/cache | Bersihkan pengurus pakej |
| Biji lama | /boot | Simpan dua, bersihkan selebihnya |
| Lambakan teras | kedai coredump | Lumpuhkan atau hadkannya |
Jurnal systemd ialah pesalah tunggal yang paling biasa dalam pengedaran moden. Ia tidak diuruskan oleh `logrotate`; ia mempunyai pengekalan tersendiri. Semak dengan `journalctl --disk-usage` dan tutup dengan `journalctl --vacuum-size=500M` atau `journalctl --vacuum-time=14d`. Jurnal yang berterusan di bawah `/var/log/journal` boleh mencapai puluhan gigabait secara senyap pada pelayan yang cerewet.
Penyimpanan bekas ialah yang kedua. Imej yang dipadamkan dan bekas yang dihentikan meninggalkan lapisan di belakang. `sistem docker df` menunjukkan pecahan, dan pemangkasan menuntutnya semula โ tetapi baca gesaan pengesahan dengan teliti, kerana memasukkan bendera volum juga memadamkan volum yang tidak digunakan.
Inti lama ialah pengisi `/boot` klasik, dan `/boot` biasanya hanya 500 MB. Pastikan kernel berjalan ditambah satu sandaran dan bersihkan yang lain. Saat yang anda perhatikan biasanya semasa peningkatan kernel yang gagal, apabila partition tidak mempunyai ruang untuk membongkar imej baharu.
Timbunan teras adalah tempat yang tenang. Jika perkhidmatan ranap dalam gelung, coredumpsnya boleh belon. Semak saiz kedai dan sama ada lumpuhkan coredumps untuk unit itu atau tutup storan.
Langkah 5: Buku Main Pembersihan Selamat
Urusan pesanan. Memadamkan perkara yang salah pada pukul 3 PG akan mengubah kejadian menjadi gangguan. Bekerja dalam urutan ini:
- Sahkan pelekap yang gagal dengan `df -h` dan `df -i`.
- Singkirkan fail hantu dengan `lsof +L1`.
- Cari direktori teratas dengan `du -xh --max-depth=1`.
- Kosongkan ruang paling selamat dahulu โ hamparkan jurnal, kosongkan cache pakej, keluarkan log berputar yang sudah dimampatkan dan dihantar di luar kotak.
- Tuntut semula ruang kontena hanya selepas mengesahkan tiada apa yang berjalan memerlukan imej tersebut.
- Sahkan dengan `df -h` serta-merta, kemudian sekali lagi sepuluh minit kemudian untuk menangkap fail yang masih berkembang.
Urutan padat yang menuntut semula ruang jurnal, membersihkan cache pakej dan mengesahkan hasilnya:
```bash
journalctl --saiz-vakum=300M
apt-get clean
df -h /
```
Jangan sekali-kali padam fail yang anda tidak boleh namakan. Menjalankan arahan pengalihan keluar terhadap kad bebas pada pukul 3 PG ialah cara orang memadamkan log audit yang mereka perlukan untuk menjelaskan kejadian itu. Jika fail terbuka dan berkembang, betulkan penulis โ putaran log, tahap log atau pepijat asas โ bukan hanya gejala.
Pencegahan: Hentikan Halaman 3 Pagi Seterusnya
Memulihkan daripada cakera penuh adalah satu kemahiran. Mencegah halaman seterusnya adalah satu disiplin, dan kebanyakannya adalah konfigurasi:
- Pantau kedua-dua ruang dan inod, dan amaran pada 80% berbanding 95%. Pada 95% anda mempunyai minit; pada 80% anda mempunyai hari bekerja.
- Putar setiap log aplikasi. Satu fail log yang tidak terurus mengalahkan konfigurasi logrotate keseluruhan pelayan. Uji peraturan anda dengan larian kering.
- Hadkan jurnal dalam fail konfigurasinya menggunakan tetapan saiz maksimum, jadi mengosongkan adalah jaring keselamatan dan bukannya ritual setiap malam.
- Beri storan kontena kelantangannya sendiri. Apabila imej belon, anda kehilangan hos kontena โ bukan pangkalan data pada cakera yang sama.
- Jangan sekali-kali menyimpan sandaran pada hos yang sama, dan jangan sekali-kali dalam sistem fail yang sama. Sandaran tempatan menjadikan kegagalan cakera menjadi kehilangan total dan masalah ruang menjadi dua.
- Laporkan pengguna teratas setiap minggu. Laporan berjadual pendek bagi lima direktori terbesar di gunung paling sibuk anda menukar kecemasan kepada garis arah aliran.
Kesimpulan
Cakera penuh bukan misteri โ ia adalah pertanyaan. `df` memberitahu anda di mana, `lsof +L1` memberitahu anda sama ada ruang itu adalah hantu, `du` dan `ncdu` memberitahu anda apa, dan perintah pembersihan berdisiplin memberitahu anda perkara yang selamat untuk dibebaskan. Kuasai empat gerakan tersebut dan halaman 3 AM menjadi penyelesaian sepuluh minit dan bukannya pertempuran selama empat jam.
Kosongkan ruang dahulu, kemudian betulkan sebab ia diisi. Itulah perbezaan antara pentadbir yang bertahan dari kelui dan orang yang akhirnya menyenyapkannya.

Infografik: Cakera Linux Anda Penuh โ Mencari Babi Angkasa Sebenar
💬 0 Comments