Yedekleme sırasında disk g / Ç sınırlaması nasıl yapılır?


14

Temelde gece basit bir "tar zcf" yapan bir cron var.

Sunucuda şunlar bulunur:

  • 8 Çekirdek - Intel (R) Xeon (R) CPU E5606 @ 2.13GHz
  • 25GB RAM
  • Ubuntu 12.04.2 LTS
  • İki 2.728 TB sabit sürücüye sahip donanım RAID 1 (LSI Logic / Symbios Logic MegaRAID SAS SMC2108)

İzleme ekran ana bilgisayarında görebileceğiniz gibi:

http://clip2net.com/s/57YRKP

Katranın neredeyse tüm zamanlarında, disk G / Ç>% 90'a gider ve diğer tüm uygulamaları (mysql, apache) çok yavaşlatır.

2 soru:

  • Yedekleme sırasında çok yüksek disk G / Ç'si olması normal mi?
  • Diğer uygulamanın düzgün çalışmaya devam edebilmesi için disk G / Ç'sini sınırlamanın bir yolu var mı?

Teşekkür ederim!

Yanıtlar:


11

Genel yaklaşımın yanında ionice bir (DM) blok cihaza bant genişliği üzerinde hassas kontrol sağlayan güzel bir cihaz haritalayıcı hedefi (ioband) vardır. Ne yazık ki standart çekirdeğin bir parçası değil.

Ayrıca, katranı muhtemelen

  1. Dosya adlarını disk önbelleğine okuma: find /source/path -printf ""
  2. Disklerin önbelleğe okunması: find /source/path -perm 777 -printf ""
  3. Katranı mbuffer veya tamponlu bir boru kullanarak (en az 100 MiB RAM ile) kullanarak diskten ve diske daha büyük blokları okuma ve yazma yapma: tar ... | mbuffer -m 256M -P 100 -p 1 ...

Neden dosya adlarını / düğümleri önbelleğe okumak taring yaparken disk IO'sunu azaltır? Toplam zamanı sadece biraz azaltarak ortalama IO'yu artırmasını beklerim.
scai

3
@scai Bu, SSD'lere yardımcı olmaz; benim tavsiyem sadece sabit diskleri döndürmektir. Bunlarla performansı öldüren şey kafa hareketidir. Dosya adları sürekli bloklar halinde saklanır, düğümler sürekli bloklar halinde saklanır ve dosya içeriği sürekli bloklar halinde saklanır. Bunu tar yolu ile yaparsanız, bir dizinin dosya (ve alt dizin) adlarını okursanız, bir dosyanın inode'una, sonra dosyanın kendisine, ardından bir sonraki dosyanın inode'una, ardından bir sonraki dosyanın kendisine erişirsiniz ... arka arkaya tüm isimleri ve düğümleri okumaktan daha fazla kafa hareketine neden olur.
Hauke ​​Laging

@scai Performans etkisi ne yaptığınıza bağlıdır. Tam yedeklemeler için oldukça küçüktür (muhtemelen dosya boyutlarına bağlıdır), ancak diferansiyel yedeklemeler için büyük bir fark fark ettim (tar için değil, bunu kullanmıyorum, ancak bu genel bir etki olmalı).
Hauke ​​Laging

Sadece doğru anladığımdan emin olmak için. 1. ve 2. için, sadece find komutunu çağırmalıyız ve Linux otomatik olarak önbelleğe alacak mı?
acemtp

@acemtp Doğru. findOlmadan (örneğin) -permdosya inode dosyasına erişmez. Ancak bu, optimizasyonun iki findçağrı kullanmasına izin verir . Aynı findçağrıyı iki kez yaparsanız (aralarında çok az zaman varsa), ikincisi genellikle saniyeler içinde (veya daha kısa sürede) biter. Boş bellek miktarına ve belirli bir noktada önbelleğe alınan veri miktarına bağlı olarak, veriler önbellekten atılır. Çok fazla okumak bu nedenle işlemi yavaşlatabilir. Yedekleme programını stdin aracılığıyla dosya adlarıyla besleyebiliyorsanız, örneğin 100 dosyanın bloklarını okuyarak bunu önleyebilirsiniz.
Hauke ​​Laging

13

Yedeklemeler sırasında yüksek G / Ç görmesi beklenir, çünkü bunlar genellikle büyük dosyalara sahip büyük dosya ağaçlarında yapılır. ioniceLinux'ta G / Ç işlerini sınıflara ve düzeylere öncelik vermek için kullanabilirsiniz . IIRC, sınıf 2, seviye 7, diğer G / Ç yükleri ve kullanıcıları için neredeyse görünmez hale getirecek en düşük, açlıktan ölme seviyesidir. Bkz man ionicekullanımı ve detaylar için.


1

Katran hendek ve rsync (Dogsbody tarafından belirtildiği gibi) ile gidiş tavsiye ederim. Windows ve Linux sistemlerimdeki dosyaları yedeklemek için BackupPC kullanıyorum ve tar yanı sıra rsync kullanmayı destekler ve sizin için otomatik olarak zor bağlantıların yanı sıra güzel bir web arayüzü sağlar.

http://backuppc.sourceforge.net/


0

Diğerlerinin de söylediği gibi, evet bu normaldir ve ionice sisteminizi etkilemesine izin vermemenin iyi bir genel yoludur.

Birkaç kez, insanların tarihtiyaç duymadıkları şeyleri gördüklerini gördüm . Kopyaladığınız verilerin herhangi bir yüzdesi son kopyadan bu yana değişmediyse, vermenizi öneririmrsync denemenizi .

Bu, yalnızca son kopyadan bu yana değişen dosyaları kopyalayarak ES'yi azaltacaktır. tüm verilerin okunması gerektiğinden IO'yu yarıdan fazla azaltamazsınız, ancak yazılan veri miktarını önemli ölçüde azaltırsınız (bu da donanımınıza bağlı olarak daha yavaş bir işlem olabilir).

Her çalıştırıldığında ayrı kopyalar / yedeklemeler istiyorsanız, en güçlü seçenek değiştirilmemiş dosyaları önceki bir yedeğe sabit bir şekilde bağlamanızı sağlayan –link-dest'dir. Bu, yedekleme sunucusunda BÜYÜK miktarda alan tasarrufu sağlar. örneğin bir makineyi (Fred) yedekliyorum, Fred'in 20GB HD'si var ve / proc ve / dev hariç tüm sürücüyü yedekliyorum / kopyalıyorum. Artık yedekleme sunucumda 20GB'lık bir dizin var. Ertesi gün Fred'i tekrar yedekledim ve dün yedeklemeye –link-dest. Rsync uzak dosyaları yerel kopyayla karşılaştırır ve tam olarak aynı ise bunları aktarmaya zahmet etmez, ancak yeni dosyayı dün dosyaya bağlar. Değişen tüm dosyalar yeni bir kopya halinde kopyalanır (veya mümkünse dün yedek kullanılarak kısmen kopyalanır). Dünden beri sadece 100MB dosya değiştirildiyse, şimdi her ikisi de 20GB dosyaya sahip iki dizinim var, ancak sadece 20 tane alıyor.

Umarım bu soruya yardımcı olur ve cevaplar.

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.