Varsayılan seçeneklerle donatılmış ext3 dosya sistemine sahibim. Üzerinde bazı ~ 100GB dosyaları var.
Bu tür dosyalardan herhangi birinin kaldırılması uzun zaman alır (8 dakika) ve sunucuda yükü artıran çok fazla io trafiğine neden olur.
RPM'yi yıkıcı değil yapmak için herhangi bir yolu var mı?
Yanıtlar:
En ilginç cevap, asıl soru üzerine yapılan bir yorumda toprağa verildi. İşte daha görünür hale getirmek için birinci sınıf bir cevap olarak:
Temelde buradan hiçbir yöntem işe yaramadı, biz de kendimizi geliştirdik. Burada açıklanmıştır: http://www.depesz.com/index.php/2010/04/04/how-to-remove-backups/ - depesz 6 Nisan, 15: 15
Bu bağlantı uygulanabilir bir çözüm için keşif ve keşiflerin son derece kapsamlı bir analizidir.
Ayrıca not:
Makale diyor ki:
Gördüğünüz
-c2 -n7gibi, aklı başında görünen iyonlaştırmaya ilişkin seçenekleri kullandım .
bu doğru, ancak kullanıcı TafT diyor ki, eğer bir aksama istemiyorsanız, -c3'boşta', -c2'en iyi çabadan' daha iyi bir seçim olacaktır . -c3Arka planda inşa etmeye alışmış ve yapının sonsuza dek beklemesine neden olmadan iyi çalıştığını buldu. Eğer gerçekten% 100 kullanım kullanıyorsanız -c3, silme işleminin hiç bitmesine izin vermeyecektir, ancak çalışılan teste dayanarak ne olduğunu beklememektedir.
Sen verebilir ionice bir deneyin. Daha hızlı hale getirmeyecek, ancak daha az yıkıcı olabilecektir.
Verimlilik açısından, dosya başına bir rm kullanmak, her bir rm için bir çatal ve çalıştırmayı gerektirdiğinden en uygun değildir.
Bunu kaldırmak istediğiniz dosyaları içeren bir list.txt dosyanız olduğunu varsayarsak daha verimli olur, ancak yine de yavaş olacaktır:
xargs -i rm {} < list.txt
Başka bir yaklaşım ise:
nice -20 xargs -i rm {} < list.txt
(bu daha az zaman alacaktır, ancak sisteminizi büyük ölçüde etkileyecektir :)
veya
Bunun ne kadar hızlı olacağını bilmiyorum ama:
mv <file-name> /dev/null
veya
Hızlı dosya sistemli (bir döngü aygıtı kullanarak?) Özel bir bağlama noktası oluşturun, Huge dosyalarınızı saklamak ve silmek için kullanın.
(belki de dosyaları silmeden önce oraya taşıyın, belki daha hızlıdır veya dosyaların gitmesini istediğinizde belki de çıkarmanızı sağlar)
veya
cat /dev/null > /file/to/be/deleted(yani şimdi sıfır boyuttadır) ve rm -rf <file>şimdi kaybolmasını istiyorsanız
veya daha da iyi
kediyi bırak ve sadece yap # > /file/to/be/emptied
Dizinin makul bir hızda silinmesini sağlamada sorun yaşadım, işlemin diski kilitlediğini ve diske erişmeye çalışırken bir yığın işlem oluşturduğunu gördüm. ionice işe yaramadı, sadece diskin IO'sunun% 99'unu kullanmaya devam etti ve diğer tüm işlemleri kilitledi.
İşte benim için çalışan Python kodu. Bir seferde 500 dosyayı siler, sonra diğer işlemlerin işlerini yapması için 2 saniye ara verir, sonra devam eder. Harika çalışıyor.
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
Benim iki Sentim.
Bu sorunu zaten aldım. "Hızlı çalışması gereken sıralı komut dosyasında, işlem çok fazla dosyayı kaldırıyor" .. Böylece "rm" bu komut dosyası hızını GÇ bekleme / çalıştırma zamanına yakın hale getirir.
Böylece, işleri daha hızlı yapmak için, cron başına başlatılan başka bir işlem (bash betiği) ekledim .. çöp toplayıcıları gibi, belirli bir dizindeki tüm dosyaları siler.
Sonra orijinal betiği "rm" yi bir mv ile "çöp klasörüne" değiştirerek güncelledik (çarpışmayı önlemek için adının sonuna bir sayaç ekleyerek dosyayı yeniden adlandırın).
Bu benim için çalışıyor, senaryo en az 3 kez daha hızlı çalışıyor. ancak, dosya kopyalamadan kaçınmak için yalnızca çöp klasörü ve orijinal dosya aynı bağlama noktasının (aynı aygıt) altındaysa işe yarar. (aynı cihazdaki mv, rm'den daha az IO tüketir)
Umarım bu yardım ..
Ayrıca iyonice'yi yük için geçici bir çözüm olarak öneren Dennis Williamson'ın cevabının yalnızca blok cihazınız CFQ io zamanlayıcı kullanıyorsa işe yarayacağını unutmayın.
Yedeklerinizi depolamak için bir döngü dosya sistemi oluşturmayı deneyebilirsiniz.
# 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
Ardından, yedekleri silmek istediğinizde:
# umount /mnt/backups
# mke2fs /path/to/virtualfs
# mount -t ext2 /path/to/virtualfs /mnt/backups -o loop
Presto! Tüm sanal dosya sistemi birkaç dakika içinde temizlenir.
Multitheading'i xargs ile kullanabilirsiniz
find . -type f | xargs -P 30 rm -rf
30 oluşturmak istediğiniz iş parçacığı sayısıdır. Sıfır kullanıyorsanız, sistem görevi yürüten kullanıcının kullanabileceği maksimum iş parçacığı oluşturur.
find-deleteçok daha iyi bir alternatif olan bir seçeneğe sahiptir.
mv <dosya- adı> / dev / null
/ dev / null bir dizin değil bir dosyadır. Bir dosyayı, bir dosyaya taşıyamıyor veya üzerine yazma riskini taşıyorsunuz.
Hızlı dosya sistemli (bir döngü aygıtı kullanarak?) Özel bir bağlama noktası oluşturun, Huge dosyalarınızı saklamak ve silmek için kullanın. (belki de dosyaları silmeden önce oraya taşıyın, belki daha hızlıdır veya dosyaların gitmesini istediğinizde belki de çıkarmanızı sağlar)
Bunun pratik olduğunu sanmıyorum. OP'nin istediğinden, gereksiz yere daha fazla G / Ç kullanacaktır.
/ dev / null bir dizin değil bir dosyadır. Bir dosyayı, bir dosyaya taşıyamıyor veya üzerine yazma riskini taşıyorsunuz.
Aslında bu bir cihaz ve ona yazılan tüm veriler atılıyor, yani mv <file> /dev/nullmantıklı geliyor.
Vikipedi'den, özgür ansiklopedi
Unix benzeri işletim sistemlerinde, / dev / null veya null aygıtı, kendisine yazılmış tüm verileri (ancak yazma işleminin başarılı olduğunu bildiren) silen ve hiçbir işlem için veri sağlamayan özel bir dosyadır. ondan okur (derhal EOF'yi verir). [1]