Apa kinerja yang diharapkan dari obnam? Atau: mengapa sangat lambat?

Saya telah bermain-main dengan obnam beberapa hari terakhir ini, dan meskipun terlihat sangat menjanjikan dan tampaknya pada dasarnya menawarkan semua yang saya inginkan dalam alat cadangan, saya cukup kecewa dengan kinerjanya. Sebenarnya, ini sangat lambat, saya curiga bahwa obnam bahkan bukan salah di sini, tetapi sesuatu di lingkungan saya yang menyebabkannya.

Jadi saya terutama bertanya-tanya, apakah ada orang lain yang menggunakan obnam atau tahu internalnya cukup baik untuk mengidentifikasi masalah.

Dari apa yang saya tahu sejauh ini, Obnam tampaknya melakukan proses gpg individu untuk setiap file yang didukung. Dilihat dari htop, strace, dan iostat, kecepatan cadangan awal sebagian besar dibatasi oleh forking konstan, sedangkan CPU dan drive (tidak ada jaringan yang terlibat) sebagian besar idle di bawah pemanfaatan 20%.

Jumlah cadangan saya sekitar 500.000 file dengan total data 170 GiB. Jadi untuk setiap proses pencadangan, gpg bercabang 500.000 kali. Sebenarnya saya bahkan tidak terkejut bahwa ini membutuhkan hampir satu hari penuh untuk menjalankan awal dan lebih dari tiga jam untuk menjalankan lain dengan sebagian besar file tidak berubah. Tetapi apakah ini benar-benar kinerja yang seharusnya diharapkan oleh pengguna? Sebagai perbandingan: penambahan rsnapshot (data yang sama, mesin yang sama, drive yang sama) memakan waktu sekitar empat menit. Memang, tidak ada enkripsi yang terlibat, tapi ini tidak harus yang signifikan.

Jadi, untuk bertanya dengan gamblang: Apakah mesin orang lain tidak dapat menjalankan gpg (mengenkripsi sebagian kecil data) lebih dari 50 kali per detik, pada akhirnya membuat Obnam menjadi alat yang lambat dan hampir tidak bisa digunakan? Atau hanya aku?

(FWIW, mesin saya adalah Core i5-2500 dengan 8G RAM dan SSD drive, menjalankan Gentoo. Cadangan dilakukan ke HDD, tapi saya tidak bisa melihat perbedaan untuk membuat cadangan ke SSD, karena itu bukan I / O -terikat.)

Berikut ini adalah bacaan yang bagus tentang cara mempercepat obnam (dapat berlari hingga 10 kali lebih cepat): http://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html

Ringkasan: tambahkan "--lru-size = 1024 --upload-queue-size = 512" ke baris perintah atau file konfigurasi Anda. Perhatikan bahwa ini sedikit meningkatkan penggunaan memori obnam.

Saya pikir saya akan menyerang masalah ini dalam beberapa cara. Sebagai permulaan saya akan mencoba dan mendiagnosisnya sendiri menggunakan metodologi berikut.

1. obnam logs

Sebagai permulaan Anda dapat mencatat pesan dari obnamseperti:

$ obnam --log obnam.log

Anda dapat meningkatkan level logging melalui --log-levelsakelar juga untuk mendapatkan detail lebih lanjut.

--log=FILE          write log entries to FILE (default is to not write log
                    files at all); use "syslog" to log to system log, or
                    "none" to disable logging
--log-level=LEVEL   log at LEVEL, one of debug, info, warning, error,
                    critical, fatal (default: info)

2. Profiling

Anda juga bisa mendapatkan profil tentang apa obnamyang dilakukan sebagai berikut dari kutipan ini di FAQ proyek :

Jika OBNAM_PROFILEvariabel lingkungan berisi nama file, data profil akan disimpan di sana, dan dapat dilihat kemudian dengan obnam-viewprof:

  $ OBNAM_PROFILE=obnam.prof obnam ... obnam-viewprof obnam.prof | less

Masalah kinerja yang tidak terkait dengan pengaturan tertentu juga dapat diamati menggunakan obnam-benchmark tool.

3. Buka tiket

Jika kinerja masih belum ditentukan melakukan investigasi self-driven maka saya akan membuka tiket di situs web proyek . Dari apa yang saya dapat kumpulkan pengembang agak responsif dan mereka mungkin akan menjadi yang terbaik dalam membasmi masalah dengan proyek mereka.

obnamtampaknya hanya menggunakan SFTP sehingga harus cukup jelas apa yang menyebabkan masalah. Saya juga akan mempertimbangkan mendasari kinerja SFTP dengan sendirinya sehingga Anda dapat melihat apa yang seharusnya secara teoritis dengan koneksi sistem + jaringan Anda sebelum mencoba untuk mendapatkan info ini dari obnamtes sendiri.

Poin data tambahan

Ditemukan posting blog ini di mana penulis melakukan perbandingan beberapa opsi dalam kategori ini. Artikel itu berjudul: Membandingkan rsnapshot dan obnam untuk cadangan besar terjadwal .

Artikel tersebut menyoroti beberapa kinerja yang sangat buruk, IMO, dengan obnamyang tampaknya cocok dengan apa yang Anda gambarkan.

kinerja obnam

Setelah mencadangkan / home sepenuhnya (yang membutuhkan beberapa hari!), Proses baru, beberapa hari kemudian dilakukan (pengaturan waktu oleh perintah waktu Linux):

Mencadangkan 3443706 file, mengunggah 94,0 GiB dalam 127h48m49d di 214,2 KiB / s rata-rata file speed830; 1,24 GiB (0 B / s) nyata pengguna 7668m56.628s 4767m16.132s sys 162m48.739s

Dari file log obname:

   2012-11-17 12:41:34 INFO VFS: baseurl=/home read=0 written=0
   2012-11-21 23:09:36 INFO VFS: baseurl=/backups/backup_home read=2727031576964 written=150015706142 
   2012-11-21 23:09:36 INFO Backup performance statistics: 
   2012-11-21 23:09:36 INFO * files found: 3443706 
   2012-11-21 23:09:36 INFO * uploaded data: 100915247663 bytes (93.9846482715 GiB) 2012-11-21 23:09:36 INFO * duration: 460128.627629s 
   2012-11-21 23:09:36 INFO * average speed: 214.179341663 KiB/s
   2012-11-21 23:09:36 INFO Backup finished. 2012-11-21 23:09:36 INFO Obnam ends
   2012-11-21 23:09:36 INFO obnam version 1.2 ends normally

Jadi: ~ 5 hari untuk mencadangkan ~ 100 GB data yang berubah ... Beban tidak terlalu tinggi pada mesin, baik dalam hal CPU, maupun dalam hal RAM. Penggunaan disk di / backups / backup_home adalah 5.7T, penggunaan disk / home adalah 6.6T, jadi ada beberapa dedup, tampaknya.

kinerja rsnapshot

Cadangan penuh / home to (sesuai dengan file log):

   [27/Nov/2012:12:55:31] /usr/bin/rsnapshot daily: started   
   [27/Nov/2012:12:55:31] echo 17632 > /var/run/rsnapshot.pid 
   [27/Nov/2012:12:55:31] mkdir -m 0700 -p /backups/backup_home_rsnapshot/    
   [27/Nov/2012:12:55:31] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/ 
   [27/Nov/2012:12:55:31] /usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /home /backups/backup_home_rsnapshot/daily.0/localhost/
   [28/Nov/2012:23:16:16] touch /backups/backup_home_rsnapshot/daily.0/
   [28/Nov/2012:23:16:16] rm -f /var/run/rsnapshot.pid
   [28/Nov/2012:23:16:16] /usr/bin/rsnapshot daily: completed successfully

Jadi: ~ 1,5 hari untuk cadangan penuh 6.3TB. Pencadangan tambahan sehari kemudian mengambil:

     [29/Nov/2012:13:10:21] /usr/bin/rsnapshot daily: started
     [29/Nov/2012:13:10:21] echo 20359 > /var/run/rsnapshot.pid
     [29/Nov/2012:13:10:21] mv /backups/backup_home_rsnapshot/daily.0/ /backups/backup_home_rsnapshot/daily.1/
     [29/Nov/2012:13:10:21] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:10:21] /usr/bin/rsync -a --delete --numeric-ids -- relative --delete-excluded --link-dest=/backups/backup_home_rsnapshot/daily.1/localhost/ /home/backups/backup_home_rsnapshot/daily.0/localhost/
     [29/Nov/2012:13:25:09] touch /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:25:09] rm -f /var/run/rsnapshot.pid
     [29/Nov/2012:13:25:09] /usr/bin/rsnapshot daily: completed successfully

Jadi: 15 menit ... dan data yang diubah berjumlah 21GB.

Tidak menyeluruh tapi merek menyebutkan bahwa salah satu kontra obnamadalah bahwa hal itu sangat lambat vs attic.

Pro Obnam:

• didokumentasikan dengan baik
• milis aktif
• paket tersedia

Obnam kontra:

• sangat lambat
• backup besar

Pro loteng:

• backup yang jauh lebih kecil (bahkan tanpa deduplikasi)
• deduplikasi yang jauh lebih baik
• lebih cepat

Kontra loteng:

• format repositori tidak didokumentasikan
• bukan komunitas pengguna yang besar

Beberapa data pengujian ditampilkan yang tampaknya menunjukkan bahwa obnamitu sangat lambat.

Dari SSD lokal ke HD jarak jauh, melalui koneksi wifi biasa-biasa saja:

    rsync:           0:24  0:01
    Attic ssh:       0:28  0:05
    Attic sshfs:     0:51  0:08
    Obnam sftp:      8:45  0:21
    Obnam sshfs:    25:22  0:22

Referensi

• Obnam tweak posting blog

Konfigurasi default Obnam (per 2015-02-08) tidak berfungsi dengan baik untuk membuat cadangan direktori dengan sejumlah besar file kecil. Saya memiliki masalah yang sama persis seperti yang disebutkan di atas.

Solusi bagi saya adalah menambahkan --lru-size = 8192 --upload-queue-size = 8192 ke baris perintah. Ini memecahkan masalah dan mengubah frustrasi menjadi pengguna Obnam yang sangat bahagia. (Saya memiliki pengaturan ini dalam file konfigurasi standar saya sekarang.)

Sayangnya, tutorial Obnam tidak menyebutkan di muka betapa pentingnya pengaturan ini. FAQ memberikan lebih banyak detail. Pengaturan parameter kinerja sangat wajib pada sistem dengan banyak file kecil.