Bagaimana cara membatasi diska / o saat pencadangan?


14

Saya memiliki cron yang pada dasarnya melakukan "tar zcf" sederhana di malam hari.

Server memiliki:

  • 8 Cores - Intel (R) Xeon (R) CPU E5606 @ 2.13GHz
  • RAM 25GB
  • Ubuntu 12.04.2 LTS
  • Hardware RAID 1 (LSI Logic / Symbios Logic MegaRAID SAS SMC2108) dengan dua hard drive 2.728TB

Seperti yang dapat Anda lihat di screenhost pemantauan:

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

Selama hampir semua waktu tar, disc I / O pergi ke> 90% dan membuat semua aplikasi lain (mysql, apache) untuk memperlambat banyak.

2 pertanyaan:

  • Apakah normal memiliki I / O disk yang begitu tinggi selama pencadangan?
  • Apakah ada cara untuk membatasi disk I / O sehingga aplikasi lain dapat terus bekerja dengan benar?

Terima kasih!

Jawaban:


11

Selain pendekatan yang agak umum dengan ioniceada target mapper perangkat bagus (ioband) yang memungkinkan kontrol yang tepat atas bandwidth ke perangkat blok (DM). Sayangnya ini bukan bagian dari kernel standar.

Selain itu Anda mungkin dapat mempercepat tar

  1. Membaca nama file ke dalam cache disk: find /source/path -printf ""
  2. Membaca inode ke dalam cache disk: find /source/path -perm 777 -printf ""
  3. Membuat tar membaca dan menulis blok yang lebih besar dari dan ke disk dengan misalnya menggunakan pipa dengan mbuffer atau buffer (dengan setidaknya 100 MiB RAM): tar ... | mbuffer -m 256M -P 100 -p 1 ...

Mengapa membaca nama file / inode ke dalam cache mengurangi IO disk saat tar'ing? Saya berharap untuk meningkatkan IO rata-rata sambil mengurangi total waktu hanya sedikit.
scai

3
@scai Ini tidak membantu SSD; rekomendasi saya hanya mengacu pada harddisk berputar. Apa yang membunuh kinerja dengan itu adalah gerakan kepala. Nama file disimpan dalam blok kontinu, inode disimpan dalam blok kontinu dan konten file disimpan dalam blok kontinu. Jika Anda melakukannya dengan cara tar maka Anda membaca nama file (dan subdirektori) dari satu direktori, mengakses inode untuk satu file, lalu file itu sendiri, lalu inode untuk file berikutnya, lalu file berikutnya itu sendiri ... Itu menyebabkan lebih banyak gerakan kepala daripada membaca semua nama dan inode satu sama lain.
Hauke ​​Laging

@scai Dampak kinerja tergantung pada apa yang Anda lakukan. Ini agak kecil untuk backup penuh (mungkin tergantung pada ukuran file) tetapi saya melihat perbedaan besar untuk backup diferensial (bukan untuk tar, karena saya tidak menggunakan itu tetapi ini harus menjadi efek umum).
Hauke ​​Laging

Hanya untuk memastikan saya mengerti dengan benar. Untuk 1. dan 2., kita hanya perlu memanggil perintah find dan Linux akan secara otomatis menyimpannya?
acemtp

@acemtp Itu benar. findtanpa (misalnya) -permtidak akan mengakses inode file. Tapi itu memungkinkan untuk optimasi menggunakan dua findpanggilan. Jika Anda melakukan findpanggilan yang sama dua kali (dengan sedikit waktu di antaranya), yang kedua biasanya akan selesai dalam hitungan detik (atau kurang). Bergantung pada jumlah memori bebas dan jumlah data yang di-cache pada titik tertentu, data dibuang dari cache. Membaca terlalu banyak bisa memperlambat operasi. Jika Anda dapat memberi makan program cadangan dengan nama file melalui stdin maka Anda dapat mencegahnya dengan membaca blok misalnya 100 file.
Hauke ​​Laging

13

Ini diharapkan untuk melihat I / O tinggi selama cadangan karena mereka umumnya dibuat di pohon file besar dengan file besar. Anda dapat menggunakan ioniceuntuk memprioritaskan pekerjaan I / O di Linux dengan kelas dan level. IIRC, kelas 2, level 7 adalah level terendah, non-kelaparan yang secara praktis membuatnya tidak terlihat oleh beban dan pengguna I / O lainnya. Lihat man ioniceuntuk penggunaan dan detailnya.


1

Saya akan merekomendasikan menching tar dan pergi dengan rsync (seperti yang disebutkan oleh Dogsbody). Saya menggunakan BackupPC untuk membuat cadangan file di sistem Windows dan Linux saya dan mendukung penggunaan tar serta rsync dan secara otomatis menangani tautan keras untuk Anda serta menyediakan antarmuka web yang bagus.

http://backuppc.sourceforge.net/


0

Seperti yang orang lain jawab, ya ini normal, dan ionicemerupakan cara umum yang baik untuk tidak membiarkannya memengaruhi sistem Anda.

Beberapa kali saya telah melihat orang-orang tarberes ketika mereka tidak perlu sekalipun. Jika ada persentase data yang Anda salin tidak berubah sejak salinan terakhir maka saya sarankan rsyncmencoba.

Ini akan mengurangi IO dengan hanya menyalin file yang telah berubah sejak salinan terakhir. Anda tidak akan dapat mengurangi IO lebih dari setengah karena semua data masih perlu dibaca tetapi Anda akan secara signifikan mengurangi jumlah data yang ditulis (yang tergantung pada perangkat keras Anda bisa menjadi operasi yang lebih lambat juga).

Jika Anda ingin memisahkan salinan / cadangan setiap kali dijalankan maka opsi yang paling kuat adalah –link-dest yang memungkinkan Anda untuk menautkan file yang tidak diubah ke cadangan sebelumnya. Ini menghemat sejumlah besar ruang pada server cadangan. mis. Saya membuat cadangan mesin (Fred), Fred memiliki HD 20GB dan saya mencadangkan / menyalin seluruh drive tidak termasuk / proc dan / dev. Saya sekarang memiliki direktori 20GB di server cadangan saya. Hari berikutnya saya backup Fred lagi dan –link-dest ke backup kemarin. Rsync membandingkan file jarak jauh dengan salinan lokal dan jika persis sama tidak akan mengganggu mentransfernya tetapi akan sulit menautkan file baru ke file kemarin. Setiap file yang telah diubah disalin ke bawah (jika mungkin sebagian disalin menggunakan cadangan kemarin). Jika hanya 100MB file yang diubah sejak kemarin saya sekarang memiliki dua direktori baik dengan 20GB file tetapi hanya mengambil 20.

Saya harap itu membantu dan masih menjawab pertanyaan Anda.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.