Büyük bir dizin ağacında rm -rf yapmak saatler sürer


20

Yedeklemeler için rsnapshot kullanıyoruz. Yedeklenen dosyanın çok sayıda anlık görüntüsünü tutar, ancak eskilerini siler. Bu iyi. Ancak rm -rfbüyük bir dizin ağacında bir işlem yapmak yaklaşık 7 saat sürüyor . Dosya sistemi XFS'dir. Orada kaç dosya olduğundan emin değilim, ama muhtemelen milyonlarca numara.

Hızlandırmak için yine de var mı? Aynı rm -rfve saatlerce süren bir komut var mı ?


1
Kullandım find . -delete -name directoryve bundan çok daha hızlı rm -rf.
Paolo

Yanıtlar:


38

Yok hayır.

rm -rfunlink()her dosyayı çağırarak dosya sisteminizde özyinelemeli bir derinlik ilk geçişi yapar . Sürecin yavaş gitmesine neden olan iki işlem opendir()/ readdir()ve şeklindedir unlink(). opendir()ve readdir()dizindeki dosya sayısına bağlıdır. unlink()silinmekte olan dosyanın boyutuna bağlıdır. Bunu daha hızlı yapmanın tek yolu, dosyaların boyutunu ve sayısını azaltmaktır (ki bu şüpheli değilim) veya dosya sistemini bu işlemler için daha iyi özelliklere sahip bir sistemle değiştirmek. XFS'nin büyük dosyadaki unlink () için iyi olduğuna, ancak büyük dizin yapıları için o kadar iyi olmadığına inanıyorum. Ext3 + dirindex veya reiserfs'nin daha hızlı olduğunu görebilirsiniz. JFS'nin ne kadar iyi bildiğinden emin değilim, ancak farklı dosya sistemi performansının birçok ölçütü olduğundan eminim.

Düzenleme: Görünüşe göre XFS ağaçları silmede korkunç , bu yüzden kesinlikle dosya sisteminizi değiştirin.


1
Birkaç yıl önce benzer bir kullanım durumunda reiserfs kullanarak korkunç bir performans fark ettim.
knweiss

1
Muhteşem yazı!
wzzrd

2
Neredeyse "hayır" dedi :)
David Pashley

2
Bağlantı hızının dosyanın boyutuna bağlı olduğunu ifade etmek dışında burada her şeyi kabul ediyorum. unlink sadece dosyanın bağlantısını kaldırır ve asıl içeriğe hiçbir şey yapmaz. Farklı boyuttaki dosyalar arasında fark edilebilir bir fark olmamalıdır (bunu kendiniz test edebilirsiniz).
Kamil Kisiel

@KamilKisiel unlinkGerçek içeriğe hiçbir şey yapmadığını doğru söylüyorsunuz , ancak bir unlinksistem çağrısı yapmak için, kaldırılan bağlantı dosyanın sonuncusu ve şu anda açık değilse, dosya sistemi kodunun daha fazla işi vardır. Bu elbette dosya sistemine bağlıdır, ancak kaldırılan dosya çok büyük olduğunda çok fark edilebilir bir fark olabilir.
jlliagre

22

Alternatif olarak, dizini bir kenara taşıyın, aynı ad, izinler ve sahiplikle yeniden oluşturun ve bu dizine önem veren uygulamaları / hizmetleri yeniden başlatın.

Daha sonra genişletilmiş bir kesinti hakkında endişelenmenize gerek kalmadan arka planda orijinal dizini "nice rm" yapabilirsiniz.


Bir mv çok hızlı olduğu için bu işe yarayabilir.
Rory

Evet - iyi çalışıyor. Bu tekniği bir e-posta istemcisinin beyni kaybettiği ve diskte bir karmaşa bıraktığı maildir tabanlı posta kutularını "düzeltmek" için birçok kez kullandım. Bu şekilde sabitlediğim en büyük (tek) dizin yaklaşık 1.5 veya 2 milyon dosya IIRC'ye sahipti. Son kullanıcıya toplam kesinti süresi ~ 3 dakikaydı, çoğu posta istemcisi ve imap işlemlerinin ölmesini bekliyordu.
Greg Work

7

XFS için doğru montaj seçeneklerinin ayarlandığından emin olun.

XFS ile -ologbufs = 8 kullanıldığında logbsize = 256k, silme performansınızı üç katına çıkarır.


2
Bu ipucu için +1 ... Bir başka performans artışı için tembel sayaçları da etkinleştirmelisiniz.
hurikhan77

1
Bu ayarlarla ilgili bazı açıklamalar gelecekteki okuyucular için yararlı olacaktır.
Aron Rotteveel

5

Eğer rm'yi dosya düzeyinde etkili bir şekilde yapıyorsanız, uzun zaman alacaktır. Bu yüzden blok tabanlı anlık görüntüler çok iyi :).

RM'yi ayrı alanlara ayırmayı ve paralel olarak yapmaya çalışmayı deneyebilirsiniz, ancak herhangi bir iyileştirme yapmasını beklemeyebilirim. XFS'nin dosyaları silmeyle ilgili sorunları olduğu biliniyor ve bu, yaptığınız işin büyük bir parçasıysa, bunun için farklı bir dosya sistemi fikir olabilir.


Blok tabanlı anlık görüntüler bu durumda benzersiz bir şekilde iyi değildir. Bir dizi dosya sistemi - WAFL ve ZFS hemen akla geliyor --- ayrıca anlık görüntü silme için iyi performans sağlar. Anlık görüntüleri birinci sınıf dosya sistemi nesneleri olarak görürler. Bu nedenle, hangi blokların serbest bırakılacağını belirlemek için milyonlarca dosyayı tekrarlamak (yavaşça) yerine, yalnızca anlık görüntü ile ilişkili bir blok listesine bakmak zorundalar.
Keith Smith

Hmm. Muhtemelen yukarıda çok zıt olarak çıktım. Orijinal poster Linux kullanıyor olmalı ve gerçekten iyi kanıtlanmış bir Linux dosya sistemi yok - btrfs ve nilfs gelecek için ilginç görünse de. Pratik bir mesele olarak, katılıyorum --- blok tabanlı anlık görüntüleri kullanmak daha iyi.
Keith Smith

İpucu iş yükünü bölmek ve paralelleştirmek için: xfs gücünü paralel iş yüklerinde oynatır.
hurikhan77

5

Kullanılan dosya sistemine bakılmaksızın IO yoğun işlemlerde iyonice kullanmak iyidir.
Bu komutu öneririm:

ionice -n7 güzel rm -fr dir_name

Ağır IO yükü olan sunucuda arka plan işlemleri için güzel bir şekilde oynar.


2

Bu eski olduğunu biliyorum, ama bir öneri atmak düşündüm. Bu dosyaları sırayla siliyorsunuz, paralel rm işlemleri yapmak işleri hızlandırabilir.

http://savannah.nongnu.org/projects/parallel/ paralel xargs yerine yaygın olarak kullanılabilir

yani tüm dosyaları silerseniz deltedir

find -t f deletedir | parallel -j 10 rm

Bu sadece silmek için boş dizin yapıları ile bırakacak.

Not: Büyük olasılıkla yukarıda belirtildiği gibi dosya sistemi sınırlamalarına ulaşmaya devam edeceksiniz.


Paralel xargs kullanmanın avantajı nedir?
Rory

1

Buradaki alternatif bir seçenek, verileri rm yerine gerçek dosya sistemini gereksiz yere yeniden yapılandıracak şekilde ayırmak mıdır?


3
Ben rsnapshot sabit birden çok anlık görüntüleri verimli bir şekilde bir parçası olarak sabit bağlantılar kullanır düşünüyorum. Dolayısıyla, sorgulayan kişi bu özelliği ayrı dosya sistemleri kullanarak kullanıyorsa çalışmaz (bir dosya sistemi sınırı üzerinde sabit bağlantı
kuramayacağınız için

0

Komutanın güzelliğini azaltmaya ne dersiniz? Sevmek:

nice -20 rm -rf /path/to/dir/

5
Darboğaz zamanlayıcı değil, dosya sistemi olduğunu söyleyebilirim.
Manuel Faux

Zamanlayıcının tıkanıklık olması durumunda, yalnızca G / Ç alt sistemini zorlayarak sunucuyu rm sırasında daha az kullanılabilir hale getirirsiniz.
David Mackintosh
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.