Menghapus file yang sangat besar tanpa pembekuan server web

11

Di server web saya (apache sedang berjalan, Linux CentOS), ada file log yang sangat besar ( 50 Gbyte ). Server web ini memiliki beberapa layanan web dalam produksi.

Ketika saya mencoba menghapus file log, server web tidak memiliki respons sekitar 10 detik. (Waktu layanan habis.)

rm -f monthly.log

Apakah ada cara untuk menghapus file besar ini tanpa pembekuan apache?

linux apache-2.2 centos

— Jinbom Heo
sumber

23

Putar dulu melalui logrotate, menggunakan konfigurasi seperti ini:

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

lalu buat pekerjaan cron di tengah malam untuk menghapus file yang diputar:

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

— kuanta
sumber

Bisakah Anda jelaskan apa artinya ini?

— mowwwalker

1

Anda 'nicing' dan 'ionicing' penghapusan. Bagus digunakan untuk mencegah overusage CPU, tetapi yang paling penting di sini adalah ionice, di mana Anda sebenarnya memberitahu scheduler untuk menghapus file dengan prioritas yang lebih rendah. -c adalah untuk kelas, di mana 1 adalah real time, 2 normal, dan 3 idle. Dalam kelas 2, Anda memiliki dari 0 hingga 7 (IRRC) di mana 7 adalah yang terendah. JIKA itu masih menciptakan masalah, jalankan dengan 'ionice -c3' dan itu akan baik-baik saja.

— golan

5

Untuk penghapusan file besar yang lebih cepat, Anda dapat menggunakan truncateperintah - Say untuk mengecilkannya ke ukuran nol dan kemudian menghapusnya:

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

Seperti yang direkomendasikan oleh quanta, Anda harus logrotate terlebih dahulu.

— Daniel t.
sumber

Bagaimana truncatebedanya >?

— kojiro

hmm pertanyaan bagus. Hasilnya sama, tetapi saya tidak punya jawaban bagaimana mereka berbeda dalam implementasi.

— Daniel t.

Lebih truncatemudah digunakan sudodaripada >. Ini juga lebih mudah dengan find -exec.

— kubanczyk

3

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

— Amit Biyani
sumber

3

Anda hanya bisa melakukan >logfiletidak perlu untuk gema

— user9517

3

Saya akan memotong / nol file dengan : > /path/to/monthly.logoperasi. Kemudian mungkin restart proses Apache dan mengatur rotasi log untuk mencegah hal ini terjadi di masa depan ...

Ini sering muncul, meskipun:

Lihat: Apakah ada cara untuk menghapus file 100GB di Linux tanpa meronta-ronta IO / load?

Di unix, apa cara terbaik untuk mengurangi ukuran file log besar yang sedang ditulis secara aktif?

Server Linux kehabisan ruang

— putih
sumber

Tidak perlu untuk :. Anda bisa melakukannya> /path/to/monthly.log

— kojiro

Saya tahu itu adalah noop, tetapi lebih masuk akal dari perspektif pengajaran.

— ewwhite

... tapi kemudian beberapa instruktur masa depan harus mengoreksi bahwa kesalahpahaman. Oh well, kurasa itu keamanan pekerjaan.

— kojiro

Tidak akan true > /path/to/monthly.logmelakukan hal yang sama, dan itu kurang kuno :?

— Stefan Lasiewski

Mungkin benar ...

— ewwhite

3

Jika Anda tidak membutuhkan data, potong menggunakan / dev / null:

cat /dev/null > monthly.log

Server web akan terus menulis data ke file setelah pemotongan, yang menghindari kebutuhan untuk me-restart server web (tidak seperti rm monthly.log, yang menghapus file).

Setelah menyelesaikan krisis langsung, pertimbangkan logrotasi seperti yang disarankan Quanta. Anda tidak ingin ini terjadi lagi. Perhatikan bahwa file log Apache sudah diputar secara default pada CentOS

Juga pertimbangkan untuk mengirim log web melalui syslog (menggunakan /usr/bin/logger, misalnya). Log yang dibuat menggunakan syslog juga biasanya sudah disiapkan logrotation.

— Stefan Lasiewski
sumber

5

Anda tidak dapat melakukan apa >logfilepun untuk kucing

— user9517

2

Jika Anda menggunakan sistem file ext3, pertimbangkan untuk beralih ke ext4.

Ext3 bisa lambat menghapus file besar karena menyimpan lokasi setiap blok 4k individu: file 50GiB (50 * 1024 ^ 3 byte) menempati 13107200 blok, yang masing-masing dicatat dalam tabel inode sebagai nomor blok 32-bit , untuk total 50MiB data pembukuan hanya untuk melacak di mana konten file berada di disk. Daftar blokir besar itu dapat tersebar di banyak blok tidak langsung , yang semuanya harus diperbarui ketika file dihapus. Mencari disk untuk mengakses semua blok tidak langsung itu mungkin yang menyebabkan penundaan.

Ext4, di sisi lain, mengalokasikan file dalam "luasan" hingga 128MiB. File 50GiB itu dapat direkam dalam tabel inode menggunakan hanya 400 catatan tingkat, daripada 13107200 nomor blok individu, yang secara dramatis mengurangi jumlah disk I / O yang diperlukan ketika menghapus file.

Perhatikan bahwa jika Anda mengonversi sistem file ext3 yang ada di tempat menjadi ext4, file baru akan dialokasikan menggunakan extents, tetapi file yang ada masih akan menggunakan daftar blokir. Anda dapat menggunakan chattr +eperintah untuk merealokasi file yang sudah ada menggunakan extents; Dari segi kinerja, ini sebanding dengan membuat salinan file dan kemudian menghapus yang asli.

— Wyzard
sumber

1

Ini bermuara pada masalah kinerja sistem file. Ada jawaban yang menarik untuk ini pada pertanyaan SO ini tetapi ini lebih tergantung pada sistem file apa yang Anda gunakan. Saya menggunakan XFS ketika membuat sistem file untuk menyimpan ratusan file MPEG2 multi-gigabyte untuk MythTV karena pada saat itu kinerja hapus XFS jauh lebih unggul daripada ext3. Segalanya mungkin telah banyak berubah di tahun-tahun berikutnya.

Saya suka jawaban @ quanta. Memisahkan file menjadi bagian-bagian yang lebih kecil akan menyebabkan penghapusan lebih cepat.

— Tim Potter
sumber

1

Masalahnya berasal dari, saya kira, bahwa Anda menghapus file dari pengguna istimewa yang lebih memprioritaskan operasi disk daripada pengguna apser webserver. Tidak masalah bagaimana Anda memilih untuk menghapus file log (rm -f atau terpotong oleh>), Anda harus menurunkan operasi prioritas disk-nya ke minumum:

  ionice -c3 rm -f filename.log

— Andrei Mikhaltsov
sumber