Web sunucusu donmadan çok büyük dosyaları silme

Web sunucumda (apache çalışıyor, Linux CentOS) çok büyük bir günlük dosyası var ( 50 Gbyte ). Bu web sunucusunun üretimde bazı web hizmetleri vardır.

Günlük dosyasını silmeye çalıştığımda, web sunucusunun yaklaşık 10 saniye boyunca hiçbir yanıtı yoktu. (Servis çıkış zamanı.)

rm -f monthly.log

Apache donmadan bu büyük dosyayı silmenin bir yolu var mı?

logrotateAşağıdaki gibi bir yapılandırma kullanarak önce döndürün :

/path/to/the/log {
    missingok
    notifempty
    sharedscripts
    daily   
    rotate 7
    postrotate
        /sbin/service httpd reload > /dev/null 2>/dev/null || true
    endscript
    compress
}

ardından döndürülen dosyayı silmek için gece yarısı bir cron işi oluşturun:

30 2 * * * nice -n 19 ionice -c2 -n7 rm -f /path/to/the/log/file.1

Büyük dosyaların daha hızlı silinmesi için, truncateSöyle komutunu kullanarak sıfır boyutuna küçültün ve silin:

 truncate -s 0  monthly.log && rm -f monthly.log

Quanta'nın önerdiği gibi, önce logrotate olmanız gerekir.

echo "0" > monthly.log && rm -f monthly.log

İşlemle dosyayı keser / sıfırlarım : > /path/to/monthly.log. Daha sonra muhtemelen Apache işlemini yeniden başlatın ve gelecekte olmasını önlemek için günlük rotasyonunu ayarlayın ...

Bu sık sık ortaya çıkıyor:

Bkz: Linux'ta 100 GB'lık bir dosyayı, GÇ / yüklemeyi azaltmadan silmenin bir yolu var mı?

Unix'te, aktif olarak yazılan büyük bir günlük dosyasının boyutunu azaltmanın en iyi yolu nedir?

Linux sunucusu boş

Verilere ihtiyacınız yoksa, / dev / null kullanarak kesin:

cat /dev/null > monthly.log

Web sunucusu, kesme işleminden sonra dosyaya veri yazmaya devam eder, bu da web sunucusunu yeniden başlatma ihtiyacını rm monthly.logortadan kaldırır (aksine , dosyayı kaldırır).

Acil krizi çözdükten sonra, Quanta'nın önerdiği gibi logrotasyonu düşünün. Bunun bir daha olmasını istemiyorsun. Apache günlük dosyalarının CentOS'ta varsayılan olarak zaten döndürüldüğünü unutmayın

Ayrıca, web günlüklerini syslog üzerinden göndermeyi düşünün ( /usr/bin/loggerörneğin kullanarak ). Syslog kullanılarak oluşturulan günlüklerde genellikle önceden ayarlanmış günlük kaydı bulunur.

Ext3 dosya sistemini kullanıyorsanız ext4'e geçmeyi düşünün.

Ext3, her bir 4k bloğun konumunu depoladığı için büyük dosyaları silmede yavaş olabilir: 50GiB dosyası (50 * 1024 ^ 3 bayt), her biri inode tablosuna 32 bit blok numarası olarak kaydedilen 13107200 blokları kaplar , toplam 50MiB defter tutma verisi için sadece dosyanın içeriğinin diskte nerede bulunduğunu takip etmek. Bu büyük blok listesi , dosya silindiğinde güncellenmesi gereken birçok dolaylı blok içine dağılmış olabilir . Tüm bu dolaylı bloklara erişmek isteyen disk muhtemelen gecikmeye neden olan şeydir.

Öte yandan Ext4, dosyaları 128 MB'a kadar olan "uzantılar" da tahsis eder. Bu 50GiB dosyası, 13107200 ayrı blok numarası yerine sadece 400 genişlikli kayıtlar kullanılarak inode tablosuna kaydedilebilir; bu, dosyayı silerken gereken disk G / Ç miktarını önemli ölçüde azaltır.

Varolan bir ext3 dosya sistemini yerinde ext4'e dönüştürürseniz, uzantılar kullanılarak yeni dosyaların ayrılacağını, ancak varolan dosyaların yine de engelleme listelerini kullanacağını unutmayın. chattr +eKomutları, varolan bir dosyayı uzantıları kullanarak yeniden tahsis etmek için kullanabilirsiniz ; performans açısından, bu dosyanın bir kopyasını oluşturmak ve ardından orijinali silmekle karşılaştırılabilir.

Bu, bir dosya sistemi performans sorunuyla ilgilidir. Bu SO sorusunda buna ilginç bir cevap var, ancak bu hangi dosya sistemini kullandığınıza bağlı. XFS'yi MythTV için yüzlerce çoklu gigabayt MPEG2 dosyasını saklamak için bir dosya sistemi oluştururken kullandım çünkü o zaman XFS'nin silme performansı ext3'ten çok daha üstündü. Aradan geçen yıllarda işler önemli ölçüde değişmiş olabilir.

@ Quanta'nın cevabını seviyorum. Dosyayı daha küçük parçalara bölmek daha hızlı silinmeye neden olur.

Sorun, sanırım, disk işlemleri için apache web sunucusu kullanıcısından daha fazla önceliğe sahip olan ayrıcalıklı kullanıcıdan dosyayı siliyorsunuz. Günlük dosyasını silmeyi seçtiğiniz yol ne olursa olsun (rm -f veya kısalt>) disk öncelik işlemlerini minumuma düşürmelisiniz:

  ionice -c3 rm -f filename.log