Soru Alt ağaç kaldırma ("rm -rf") Disk I / O için diğer işlemleri açmayı nasıl önler?


Yoğun bir site için çok büyük (çoklu GB) bir Nginx önbellek dizinimiz var. Bunu geçmişte, önbellek klasörünü yeni bir yola taşıyarak, eski yolda yeni bir önbellek klasörü oluşturarak ve sonra çözdüm rm -rfeski önbellek klasörü.

Son zamanlarda, yoğun bir sabah önbelleği temizlemem gerektiğinde, I / O rm -rf hem Nginx hem de onun önünü açtığı sunucu çok yoğun olduğu için sunucu disk erişim süreçlerimi açıyor. CPU'lar boşta otururken, ortalama yükün tırmanmasını izleyebilirim ve rm -rf Disk IO'nun% 98-99'unu alır iotop.

denedim ionice -c 3 çağırırken rmAncak gözlemlenen davranış üzerinde kayda değer bir etkisi yoktur.

Evcilleştirmek için herhangi bir yolu var mı rm -rf diski daha fazla paylaşmak için? İpuçlarını alacak farklı bir teknik kullanmam gerekiyor mu? ionice?

Güncelleştirme:

Söz konusu dosya sistemi bir AWS EC2 örnek deposudur (birincil disk EBS'dir). /etc/fstab giriş böyle görünüyor:

/dev/xvdb       /mnt    auto    defaults,nobootwait,comment=cloudconfig 0       2

8
2017-10-15 16:32


Menşei


Muhtemelen kullandığınız dosya sistemini ve nasıl olduğunu da eklemelisiniz (mount options). - Cristian Ciupitu
Güncellenmiş. Ayrıca, önemli olması durumunda, bu Ubuntu 12.04 üzerinde. - David Eyk
Amazon EBS'deki IO performansının oldukça kötü olabileceğini unutmayın. Görmek perfcap.blogspot.com/2011/03/... 1000 kadar kısa süreli (1 dakika) patlama ile 100 iops uzun vadeli önerir. Bu sizin durumunuz bir dakika içinde daha yüksek, bu nedenle sorun gibi geliyor. - Moshe Katz
Doğru, bu yüzden önbellek için EBS değil bir örnek deposu kullanıyoruz. Güncelleme yorumuma bakın. Üzgünüm, açık değildi. - David Eyk
Üzgünüm geciktim ama gruplarını ve blkio kontrolörünü araştırabilirsin: kernel.org/doc/Documentation/cgroups/blkio-controller.txt - AndreasM


Cevaplar:


Bu sayfadan toplanan tüm veriler.   Aşağıda büyük dosya dizini silmek için bazı seçenekler vardır. Bunun nasıl üretildiğine dair ayrıntılar için kayıtlara göz atın.

Komut Geçen Sistem Süresi% CPU cs1 * (Vol / Invol)
rsync -a –delete boş / 10.60 1.31% 95 106/22
b / -type f -delete 28.51 14.46 52% 14849/11'i bulun
c / -type f bulmak | xargs -L 100 rm 41.69 20.60 54% 37048/15074
d / -type f öğesini bulun. xargs -L 100 -P 100 rm 34.32 27.82 89% 929897/21720
rm -rf f 31.29 14.80 47% 15134/11

* cs1, içerik anahtarları gönüllü ve istemsizdir


3
2017-10-22 20:00



Bu teorik olarak soruyu cevaplayabilirken, tercih edilirdi Burada cevabın önemli kısımlarını dahil etmek ve referans için bağlantıyı sağlamak. - Tom O'Connor
Büyüleyici! Deneyeceğim. - David Eyk
rsync şu anda koşuyor. Belki de söylemek için çok erken ve yoğun bir sabahın ortasında koşmama yardımcı olabilir, ancak sunucu hala duyarlı ve yük ortalaması yönetilebilir. - David Eyk
Kullandığım tam çağrı: ionice -c 3 nice -19 rsync -a --delete /mnt/empty/ /mnt/nginx-cache-old - David Eyk
Eh, sadece 4 saat sürdü. ;) Bu cevabı (üzgünüm @aferber) kabul edeceğim, çünkü doğrudan doğruya çağrışımdan hoşlanıyorum. nice ve ioniceya da en azından sunucuyu rm -rf yaptı. - David Eyk


Dosyaları kaldırmak, yalnızca iyon sisteminden etkilenmeyen dosya sistemindeki meta veri işlemlerini gerçekleştirir.

En kolay yol, şu anda disk alanına ihtiyacınız yoksa, rm yoğun olmayan saatlerde.

MIGHT'un çalışmasının daha karmaşık yolu, silmeleri zamanla yaymaktır. Aşağıdaki gibi bir şey deneyebilirsiniz (yollarınızın ve dosya adlarınızın hiçbir boşluk içermediğini varsayalım!):

while find dir -type f | head -n 100 | xargs rm; do sleep 2; done
while find dir -type d -depth | head -n 100 | xargs rmdir; do sleep 2; done

Ayrıca kullanamayacağınızı unutmayın rm -f İlk komutta, çünkü döngü duramazdı (hata kodu rm argüman olmadığı zaman).

Çevrim başına silmelerin sayısını (örnekte 100) ve uyku süresini değiştirerek ayarlayabilirsiniz. Ancak, dosya sistemi hala meta veri güncellemelerini IO yükünüzle ilgili sorunlara yol açabileceği için gerçekten işe yaramayabilir. Sadece denemelisin.


9
2017-10-15 17:17



Çok fazla dosyanın kaldırılması uzun zaman alıyor, bu yüzden bunu kapsayacak hiçbir "yoğun olmayan" dönem yok. :( - David Eyk
while döngü zaman hile yapmak gibi görünüyor head -n 50. 100 hala yavaşça yük ortalamasını yükseltti, bu da bana çok fazla kaynak çekişmesinin devam ettiğini gösteriyor. - David Eyk
Adamım, koşmak uzun zaman alır! - David Eyk
Bul, dizin içindeki tüm dosyaları ve while döngüsünün her yinelemesi için tüm alt dizinleri listeleyecek. Muhtemelen böyle bir şeyle daha iyisini yapabilirsin - Randy Orrison
Bul, dizin içindeki tüm dosyaları ve while döngüsünün her yinelemesi için tüm alt dizinleri listeleyecek. Dir-tip f -print0 | rmwait'in rm "$ @" değerini veren bir betik olduğu xargs -l50 -0 rmwait; uyku 2. dosya adları ile boşlukları işlemek için -print0 ve -0 kullanımına dikkat edin. -L50, xargs'a sadece bir seferde 50 yapmasını söyler. - Randy Orrison


"Güzel" komutuyla eşleştirebilirsiniz. ionice -c 3 nice -19 rm -rf /some/folder

Bu, işlemin önceliğini makinede değiştirir.


-1
2017-10-15 17:44



Ne yazık ki, nice kadar çok etkiye sahip gibi görünüyor ioniceyani, kayda değer bir şey yok. - David Eyk
@DavidEyk. Hoş ve iyonlu “fark edilebilir” bir etkiye sahip değilse, ya başka bir şey için kayda değer bir şekilde kaynaklar için yarışıyor demektir, ya da sadece çıplak gözle etkiyi fark etmiyorsunuz demektir. Gerçek etkiyi görmek için iostat ve vmstat kullanarak gerçekten kıyaslamalısınız. - Michael Martinez
@Aferber'in cevabında buna değindiğine inanıyorum: "Dosyaları kaldırmak, yalnızca iyon sisteminden etkilenmeyen dosya sistemindeki meta veri işlemlerini gerçekleştirir." Çekişimi gördüm - sunucu süreçler CPU loafed ve okuma süre boyunca açlıktan rm -rf % 99 oranında vardı iotop. - David Eyk