Destekle iletişim

E-postayla, genellikle iki gün içinde yanıt veririz.

Google reCAPTCHA, kötüye kullanıma karşı bu gönderimi denetler; bu sırada veriler Google'a aktarılır. Komut dosyası yalnızca bu form açıldığında yüklenir.

← Tüm yazılar

Bir tmpfs içinde 870 MB'lık dosya ve ardından gelen yeniden başlatma

28 Ağustos saat 19.35'te, iki günü tek seferde okuyabilmek için bir günlük erişim kaydını /tmp içine açtım. Saat 19.44'te makine yeniden başladı.

makinede ne var ve tek bir dosya ne kadarını aldı 3.794 MB bellek; /tmp en fazla 1.900 MB tutabilir 19.35'te içine 870 MB yazıldı 19.35 — iki günü birden okumak için bir günlük kayıt /tmp içine açılıyor 19.44 — SSH yanıt vermiyor, site 0,1 sn yerine 11 sn sürüyor 19.47 — makine yeniden ayakta, çalışma süresi 0 dakika MariaDB çökme sonrası kurtarmayla açılıyor: kapanış düzgün değildi sistem günlüğü yeniden başlatmayı atlatmıyor; bu yüzden kanıtlanamaz — yalnızca zamanı saptanabilir

Kontrol edilmeyen özellik

Bu makinede /tmp bir tmpfs. Yani bellek. df 1,9 GB boş alan gösteriyor ama bu alanın nereden geldiğine dair hiçbir şey söylemiyor; makinenin toplam belleği ise 3.794 MB.

Yani 870 MB'lık bir dosya, aynı anda bir siteye hizmet veren ve başka birinin test işini çalıştıran küçük bir sunucunun belleğinin dörtte birine yerleşti. Dokuz dakika sonra SSH bağlantı kabul etmeyi bıraktı, site 0,1 saniye yerine 11 saniyede yanıt verdi ve kısa bir süre sonra makine sıfır dakikalık çalışma süresiyle geri döndü.

Söylenebilecekler ve söylenemeyecekler

MariaDB çökme sonrası kurtarmayla açıldı; bu da kapanışın düzgün olmadığı anlamına geliyor. Bunun ötesinde dürüst yanıt, işin kanıtlanamayacağıdır: bu makinedeki sistem günlüğü kalıcı değil, yani yeniden başlatmayı atlatmıyor ve elde bellek yetersizliği satırı içeren bir kern.log yok. Kanıt, olaydan dokuz dakika önceki bir zaman damgası ile yanlış yerdeki bir dosyadan ibaret.

Bunu bir sonuç olarak değil, olduğu gibi yazmaya değer. «Belleği doldurdu, çekirdek de pes etti» akla yatkın bir hikâye. Ama ölçülmüş bir hikâye değil ve burada bu fark, kesinlikten daha önemli.

Hasarın boyutu

Bulunabilen hiçbir hasar yok. CHECK TABLE en önemli beş tabloda OK sonucunu verdi, satır sayıları değişmemişti, sayım aynı gün de kayıt tutmayı sürdürüyordu ve zamanlanmış on altı işin tamamı yerli yerindeydi. Site yeniden 0,14 saniyede yanıt veriyordu.

Bir şey kayboldu: aynı makinede başka bir oturuma ait, uzun süredir çalışan bir iş. Bu çalışmayla hiçbir ilgisi yoktu ve her şeyle birlikte o da çöktü; bu da bir kesintinin hiçbir yerel kontrolün bildirmediği kısmıdır.

Bundan çıkan kural

Buradaki kayıt dosyaları günde 700 ile 900 MB arasında tutuyor. Birini /tmp içine açmak, makinenin belleğinin dörtte birini disk gibi görünen ama RAM gibi davranan bir yere koymak demektir.

Büyük ara dosyalar /var/tmp ya da bir ev dizinine yazılır; ikisi de diskte durur. Daha da iyisi, hiç açılmazlar: zcat -f file.gz | awk ... akış hâlinde okur ve bir hedefe ihtiyaç duymaz. Sonraki yazılardaki bütün ölçümler bu yolla yapıldı.

Genel ders

Bir dosya sistemi ne kadar yeri olduğunu bildirir. O yerin neyden yapıldığını bildirmez ve bu iki soru, tam da bunun en çok önem taşıdığı sistemlerde farklı yanıtlar alır.

Kontrol tek satırlık bir iş ve dosya «geçici» olduğu için atlandı. Geçici olduğu doğruydu. Ama düşünülmesi gereken özellik bu değildi.

Reklam