Bagaimana membuat `rm` lebih cepat di ext3 / linux?

32

Saya memiliki filesystem ext3 yang terpasang dengan opsi default. Di atasnya saya punya beberapa file ~ 100GB.

Penghapusan file semacam itu membutuhkan waktu lama (8 menit) dan menyebabkan banyak lalu lintas io, yang meningkatkan beban di server.

Apakah ada cara untuk membuat perusahaan tidak mengganggu?


sumber
4
Pada dasarnya tidak ada metode dari sini yang berhasil, jadi kami mengembangkannya sendiri. Dijelaskan di sini: depesz.com/index.php/2010/04/04/how-to-remove-backups

Jawaban:

14

Jawaban yang paling menarik pada awalnya dimakamkan di komentar pada pertanyaan. Ini dia sebagai jawaban kelas satu untuk membuatnya lebih terlihat:

Pada dasarnya tidak ada metode dari sini yang berhasil, jadi kami mengembangkannya sendiri. Dijelaskan di sini: http://www.depesz.com/index.php/2010/04/04/how-to-remove-backups/ - depesz 6 Apr 10 pada 15:15

Tautan itu adalah analisis yang sangat menyeluruh untuk eksplorasi dan penemuan solusi yang bisa diterapkan.

Perhatikan juga:

Artikel itu mengatakan:

Seperti yang Anda lihat, saya menggunakan -c2 -n7opsi untuk ionice, yang tampaknya waras.

yang benar, tetapi TafT pengguna mengatakan jika Anda ingin tidak ada gangguan maka -c3'idle' akan menjadi pilihan yang lebih baik daripada -c2'upaya terbaik'. Dia telah terbiasa -c3membangun di latar belakang dan menemukannya bekerja dengan baik tanpa menyebabkan bangunan menunggu selamanya. Jika Anda benar-benar memiliki 100% penggunaan io maka -c3tidak akan membiarkan penghapusannya selesai tetapi dia tidak berharap itu adalah apa yang Anda miliki berdasarkan tes yang dikerjakan.

Matt McClure
sumber
18

Tingkatkan ke ext4 atau sistem file modern lain yang menggunakan luasan. Karena ext3 menggunakan skema blok tidak langsung daripada ekstensi, menghapus file-file besar pasti membutuhkan banyak pekerjaan.

janneb
sumber
6

Anda dapat mencoba ionice . Itu tidak akan membuatnya lebih cepat tetapi mungkin membuatnya kurang mengganggu.

Dijeda sampai pemberitahuan lebih lanjut.
sumber
4

Dalam hal efisiensi, menggunakan satu rm per file tidak optimal, karena memerlukan garpu dan eksekutif untuk setiap rm.

Dengan asumsi Anda memiliki list.txt yang berisi file yang ingin Anda hapus ini akan lebih efisien tetapi masih akan lambat:

xargs -i rm {} < list.txt

Pendekatan lain adalah: nice -20 xargs -i rm {} < list.txt
(ini akan memakan waktu lebih sedikit tetapi akan sangat mempengaruhi sistem Anda :)

atau

Saya tidak tahu seberapa cepat ini tetapi:

mv <file-name> /dev/null 

atau

Buat titik pemasangan khusus dengan sistem file cepat (menggunakan perangkat loop?), Gunakan itu untuk menyimpan dan menghapus file besar Anda.
(mungkin memindahkan file di sana sebelum Anda menghapusnya, mungkin lebih cepat atau mungkin hanya melepasnya ketika Anda ingin file hilang)

atau

cat /dev/null > /file/to/be/deleted (Jadi ukurannya nol sekarang) dan jika Anda ingin menghilang begitu saja rm -rf <file> sekarang

atau bahkan lebih baik

jatuhkan kucing dan lakukan saja # > /file/to/be/emptied


sumber
baik, saya menghapus 1 file, jadi tidak ada overhead.
1

Saya mengalami masalah dalam mendapatkan direktori untuk dihapus pada kecepatan yang masuk akal, ternyata proses itu mengunci disk dan membuat tumpukan proses mencoba mengakses disk. ionice tidak berfungsi, hanya terus menggunakan 99% dari IO disk dan mengunci semua proses lainnya.

Inilah kode Python yang bekerja untuk saya. Menghapus 500 file sekaligus, kemudian mengambil jeda 2 detik untuk membiarkan proses lain melakukan pekerjaan mereka, lalu melanjutkan. Bagus sekali.

import os, os.path
import time

for root, dirs, files in os.walk('/dir/to/delete/files'):
    file_num = 0
    for f in files:
        fullpath = os.path.join(root, f)
        os.remove(fullpath)
        if file_num%500 == 1:
            time.sleep(2)
            print "Deleted %i files" % file_num
        file_num = file_num + 1
Nick Woodham
sumber
1
Cobalah pada file 100G + pada sistem file ext3. Masalahnya adalah dalam ukuran file tunggal, bukan jumlah file.
Dalam kasus Anda, sepertinya itu tidak akan berhasil. Tapi saya punya banyak file kecil. Terima kasih untuk umpan baliknya.
Nick Woodhams
1

Dua sen saya.

Saya sudah mendapatkan masalah ini. "Dalam skrip berurutan yang harus berjalan cepat, prosesnya menghapus banyak file" .. Jadi "rm" akan membuat kecepatan skrip itu dekat dengan waktu tunggu / eksekutif IO.

Jadi untuk membuat segalanya lebih cepat, saya telah menambahkan proses lain (skrip bash) diluncurkan per cron .. seperti pengumpul sampah, ini menghapus semua file dalam direktori tertentu.

Lalu saya telah memperbarui skrip asli dengan mengganti "rm" dengan mv ke "folder sampah" (ganti nama file dengan menambahkan penghitung di akhir namanya untuk menghindari tabrakan).

Ini berfungsi untuk saya, skrip berjalan setidaknya 3 kali lebih cepat. tetapi hanya berfungsi baik jika folder sampah dan file asli berada di bawah titik pemasangan yang sama (perangkat yang sama) untuk menghindari penyalinan file. (mv pada perangkat yang sama mengkonsumsi lebih sedikit IO daripada rm)

Semoga itu bisa membantu ..

Emmanuel Devaux
sumber
0

Perhatikan juga bahwa jawaban oleh Dennis Williamson, yang menyarankan ionice sebagai solusi untuk beban, hanya akan berfungsi jika perangkat blok Anda menggunakan penjadwal io CFQ.

famzah
sumber
0

Anda dapat mencoba membuat sistem file loop untuk menyimpan cadangan Anda.

# dd if=/dev/zero of=/path/to/virtualfs bs=100M count=1024 # 100 MB * 1024 = 100 GB
# mke2fs /path/to/virtualfs
# mount -t ext2 /path/to/virtualfs /mnt/backups -o loop

Lalu, saat Anda ingin menghapus cadangan:

# umount /mnt/backups
# mke2fs /path/to/virtualfs
# mount -t ext2 /path/to/virtualfs /mnt/backups -o loop

Presto! Seluruh sistem file virtual dihapus dalam beberapa saat.

amphetamachine
sumber
tidak menyelesaikan masalah, karena hanya akan berfungsi jika saya ingin menghapus semua cadangan pada sistem file yang diberikan.
0

Anda dapat menggunakan multitheading xargs whith

find . -type f | xargs -P 30 rm -rf 

di mana 30 adalah jumlah utas yang ingin Anda buat. Jika Anda menggunakan nol, sistem akan membuat utas maksimum yang tersedia bagi pengguna yang menjalankan tugas.

Juan Carlos
sumber
1
findmemiliki -deleteopsi yang merupakan alternatif yang jauh lebih baik.
Ariel
0

mv <file-name> / dev / null

/ dev / null adalah file bukan direktori. Tidak dapat memindahkan file, ke file, atau Anda berisiko menimpanya.

Buat titik pemasangan khusus dengan sistem file cepat (menggunakan perangkat loop?), Gunakan itu untuk menyimpan dan menghapus file besar Anda. (mungkin memindahkan file di sana sebelum Anda menghapusnya, mungkin lebih cepat atau mungkin hanya melepasnya ketika Anda ingin file hilang)

Saya rasa ini tidak praktis. Itu akan menggunakan I / O lebih banyak daripada yang diinginkan OP.

Felipe Alvarez
sumber
-1

/ dev / null adalah file bukan direktori. Tidak dapat memindahkan file, ke file, atau Anda berisiko menimpanya.

Sebenarnya itu adalah perangkat dan semua data yang ditulis untuk itu akan dibuang begitu mv <file> /dev/nullmasuk akal

Dari Wikipedia, ensiklopedia gratis
Dalam sistem operasi mirip Unix, / dev / null atau perangkat nol adalah file khusus yang membuang semua data yang ditulis padanya (tetapi melaporkan bahwa operasi penulisan berhasil), dan tidak menyediakan data untuk proses apa pun yang membaca dari itu (menghasilkan EOF segera). [1]


sumber
1
Itu salah dan sangat berbahaya. / dev / null adalah perangkat, yang merupakan objek seperti file khusus. Jika Anda root, "mv / some / file / dev / null" akan HAPUS perangkat khusus / dev / null dan pindahkan file Anda ke sana! Jadi pada saat seseorang mencoba menggunakan / dev / null mereka akan menggunakan file nyata sebagai ganti perangkat, dan bencana terjadi kemudian. (Ketika Wikipedia mengatakan bahwa ia "membuang semua data yang ditulis kepadanya", itu berarti bahwa "cat / some / file> / dev / null" akan membaca / some / file dan membuang data yang Anda baca, tetapi itu tidak akan mempengaruhi file asli).
user9876