Berkas 870 MB di tmpfs, dan reboot yang menyusul
Pada 28 Agustus pukul 19:35 saya mengekstrak log akses satu hari ke dalam /tmp agar dua hari bisa dibaca dalam satu kali proses. Pukul 19:44 mesin melakukan reboot.
Sifat yang tidak diperiksa
Di mesin ini, /tmp adalah sebuah tmpfs. Itu adalah memori. df menampilkan 1,9 GB ruang kosong dan sama sekali tidak menyebutkan dari mana ruang itu berasal, dan mesin ini memiliki total 3.794 MB.
Jadi, sebuah berkas 870 MB masuk ke seperempat memori sebuah server kecil yang sekaligus melayani sebuah situs dan menjalankan pekerjaan uji milik orang lain. Sembilan menit kemudian SSH berhenti menerima koneksi, situs merespons dalam 11 detik, bukan 0,1, dan tak lama setelah itu mesin kembali dengan uptime nol menit.
Apa yang bisa dan tidak bisa dikatakan
MariaDB menyala dengan crash recovery, yang berarti mesin tidak dimatikan dengan bersih. Di luar itu, jawaban jujurnya adalah bahwa hal ini tidak bisa dibuktikan: journal di mesin ini bersifat volatil, sehingga tidak bertahan setelah reboot, dan tidak ada kern.log yang memuat baris out-of-memory. Buktinya adalah sebuah stempel waktu sembilan menit sebelum kejadian dan sebuah berkas di tempat yang salah.
Hal itu layak dicatat apa adanya, bukan sebagai kesimpulan. «Memori penuh dan kernel menyerah» adalah cerita yang masuk akal. Tetapi itu bukan cerita yang terukur, dan di sini perbedaan tersebut lebih penting daripada kepastian.
Apa kerusakannya
Tidak ada yang bisa ditemukan. CHECK TABLE pada lima tabel terpenting menghasilkan OK, jumlah baris tidak berubah, penghitungan masih tercatat pada hari yang sama, dan keenam belas pekerjaan terjadwal masih utuh. Situs kembali merespons dalam 0,14 detik.
Ada satu yang hilang: sebuah pekerjaan berdurasi panjang milik sesi lain di mesin yang sama. Pekerjaan itu tidak ada hubungannya dengan pekerjaan ini dan ikut mati bersama semua yang lain, dan itulah bagian dari sebuah gangguan yang tidak dilaporkan oleh pemeriksaan lokal mana pun.
Aturan yang lahir dari kejadian ini
Berkas log di sini berukuran 700 hingga 900 MB per hari. Mengekstrak satu berkas ke /tmp berarti menaruh seperempat memori mesin di tempat yang tampak seperti disk tetapi berperilaku seperti RAM.
Berkas perantara yang besar disimpan di /var/tmp atau di direktori home, yang keduanya berada di disk. Lebih baik lagi, berkas itu tidak diekstrak sama sekali: zcat -f file.gz | awk ... membaca secara streaming dan tidak memerlukan tujuan. Semua pengukuran dalam tulisan-tulisan berikutnya dilakukan dengan cara itu.
Yang berlaku umum
Sebuah sistem berkas melaporkan berapa banyak ruang yang dimilikinya. Ia tidak melaporkan terbuat dari apa ruang itu, dan kedua pertanyaan tersebut punya jawaban yang berbeda justru pada sistem tempat hal itu paling penting.
Pemeriksaannya hanya satu baris, dan dilewati karena berkas itu «sementara». Sementara memang benar. Tetapi itu sifat yang salah untuk dipikirkan.