Cara menghapus jutaan file tanpa mengganggu server

Solusi 1:

Buat skrip bash seperti ini:

#!/bin/bash
rm -- "$*"
sleep 0.5

Simpan dengan nama deleter.sh Misalnya. Jalankan chmod u+x deleter.sh untuk membuatnya dapat dieksekusi.

Skrip ini menghapus semua file yang diteruskan sebagai argumen, lalu tidur selama 0,5 detik.

Kemudian, Anda dapat menjalankan

find cache.bak -print0 | xargs -0 -n 5 deleter.sh

Perintah ini mengambil daftar semua file di cache.bak dan meneruskan lima nama file sekaligus ke skrip hapus.

Jadi, Anda dapat menyesuaikan berapa banyak file yang dihapus sekaligus, dan berapa lama penundaan antara setiap operasi penghapusan.

Solusi 2:

Anda harus mempertimbangkan untuk menyimpan cache Anda pada sistem file terpisah yang dapat Anda mount/unmount seperti yang dinyatakan seseorang dalam komentar. Sampai Anda melakukannya, Anda dapat menggunakan satu liner /usr/bin/find /path/to/files/ -type f -print0 -exec sleep 0.2 \; -exec echo \; -delete ini dengan asumsi biner find Anda terletak di bawah /usr/bin dan Anda ingin melihat progresnya di layar. Sesuaikan mode tidur sebagaimana mestinya, sehingga Anda tidak terlalu membebani HDD Anda.

Solusi 3:

Anda mungkin ingin mencoba ionice pada skrip yang menggunakan output dari perintah find. Sesuatu seperti berikut:

ionice -c3 $(
for file in find cache.bak -type f; do
    rm $file
done
for dir in find cache.bak -depthe -type d -empty; do
    rmdir $dir
done
)

Bergantung pada sistem file, setiap penghapusan file dapat mengakibatkan penulisan ulang seluruh direktori tersebut. Untuk direktori besar itu bisa sangat sukses. Ada pembaruan tambahan yang diperlukan untuk tabel inode, dan mungkin daftar ruang kosong.

Jika sistem file memiliki jurnal, perubahan akan ditulis ke jurnal; terapan; dan dikeluarkan dari jurnal. Hal ini meningkatkan persyaratan I/O untuk aktivitas intensif penulisan.

Anda mungkin ingin menggunakan sistem file tanpa jurnal untuk cache.

Alih-alih ionice, Anda dapat menggunakan perintah tidur untuk membatasi tindakan tindakan. Ini akan berfungsi bahkan jika ionice tidak, tetapi akan memakan waktu lama untuk menghapus semua file Anda.

Solusi 4:

Saya mendapat banyak jawaban/komentar yang berguna di sini, yang ingin saya simpulkan sekaligus menunjukkan solusi saya.

1. Ya, cara terbaik untuk mencegah hal yang terjadi adalah menyimpan direktori cache pada sistem file yang terpisah. Nuking/pemformatan cepat sistem file selalu memakan waktu paling lama beberapa detik (mungkin beberapa menit), tidak terkait dengan berapa banyak file/direktori yang ada di dalamnya.

2. ionice / nice solusi tidak melakukan apa-apa, karena proses penghapusan sebenarnya menyebabkan hampir tidak ada I/O. Apa yang menyebabkan I/O adalah saya yakin antrian/buffer tingkat kernel/sistem file terisi ketika file dihapus terlalu cepat oleh proses penghapusan.

3. Cara saya menyelesaikannya mirip dengan solusi Tero Kilkanen, tetapi tidak perlu memanggil skrip shell. Saya menggunakan --bwlimit bawaan rsync alihkan untuk membatasi kecepatan penghapusan.

Perintah lengkapnya adalah:

mkdir empty_dir
rsync -v -a --delete --bwlimit=1 empty_dir/ cache.bak/

Sekarang bwlimit menentukan bandwidth dalam kilobyes, yang dalam hal ini diterapkan pada nama file atau jalur file. Dengan menyetelnya ke 1 KBps, itu menghapus sekitar 100.000 file per jam, atau 27 file per detik. File memiliki jalur relatif seperti cache.bak/e/c1/db98339573acc5c76bdac4a601f9ec1e , yang panjangnya 47 karakter, jadi akan menghasilkan 1000/47 ~=21 file per detik, sangat mirip dengan dugaan saya tentang 100.000 file per jam.

Sekarang mengapa --bwlimit=1 ? Saya mencoba berbagai nilai:

• 10000, 1000, 100 -> sistem melambat seperti sebelumnya
• 10 -> sistem bekerja cukup baik untuk sementara waktu, tetapi menghasilkan pelambatan parsial sekitar satu menit sekali. Waktu respons HTTP masih <1 detik.
• 1 -> tidak ada pelambatan sistem sama sekali. Saya tidak terburu-buru dan 2 juta file dapat dihapus dalam <1 hari dengan cara ini, jadi saya memilihnya.

Saya suka kesederhanaan metode bawaan rsync, tetapi solusi ini bergantung pada panjang jalur relatif. Bukan masalah besar karena kebanyakan orang akan menemukan nilai yang tepat melalui coba-coba.