Qual è la performance prevista di obnam? Oppure: perché è così lento?

Ho giocato con obnam in questi ultimi giorni, e anche se sembra molto promettente e sembra offrire praticamente tutto ciò che ho sempre desiderato in uno strumento di backup, sono piuttosto deluso dalle sue prestazioni. In effetti, è così lento, sospetto che obnam non sia nemmeno in colpa qui, ma qualcosa nel mio ambiente lo sta causando.

Quindi mi chiedo principalmente, se qualcun altro sta usando obnam o conosce i suoi interni abbastanza bene da forse identificare il problema.

Da quello che ho potuto raccontare finora, obnam sembra biforcarsi un singolo processo gpg per ogni file di cui è stato eseguito il backup. A giudicare da htop, strace e iostat, la velocità di un backup iniziale è per lo più limitata dal costante fork, mentre la CPU e le unità (nessuna rete è coinvolta) sono per lo più inattive al di sotto del 20% di utilizzo.

Il mio backup ammonta a circa 500.000 file con 170 GiB di dati in totale. Quindi per ogni esecuzione di backup, gpg viene biforcuta 500.000 volte. In realtà non sono nemmeno sorpreso dal fatto che ciò richieda quasi un'intera giornata per la corsa iniziale e oltre tre ore per un'altra corsa con la maggior parte dei file invariati. Ma è davvero questo il rendimento che gli utenti dovrebbero aspettarsi? Per confronto: una sequenza incrementale di rsnapshot (stessi dati, stessa macchina, stesse unità) richiede circa quattro minuti. Certo, non è prevista alcuna crittografia, ma questo non dovrebbe essere così significativo.

Quindi, per chiedere chiaramente: la macchina di tutti gli altri non è in grado di eseguire gpg (crittografando un piccolo blocco di dati) più di 50 volte al secondo, rendendo obnam uno strumento quasi insolitamente lento? o sono solo io?

(FWIW, la mia macchina è un Core i5-2500 con 8G di RAM e unità SSD, che esegue Gentoo. Il backup viene eseguito su un HDD, ma non ho potuto osservare alcuna differenza nel backup su SSD, poiché non è I / O -limite.)

Ecco una buona lettura su come accelerare obnam (può funzionare fino a 10 volte più veloce): http://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html

Riepilogo: aggiungi "--lru-size = 1024 --upload-queue-size = 512" alla riga di comando o al file di configurazione. Nota che aumenta un po 'l'utilizzo della memoria di obnam.

Penso che avrei attaccato questo problema in un paio di modi. Tanto per cominciare, proverei a diagnosticare me stesso usando le seguenti metodologie.

1. registri obnam

Per cominciare puoi registrare i messaggi in questo obnammodo:

$ obnam --log obnam.log

È possibile aumentare anche il livello di registrazione tramite l' --log-levelinterruttore per ottenere maggiori dettagli.

--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. Profilazione

Puoi anche ottenere un profilo di ciò che obnamsta facendo come segue da questo estratto nelle FAQ del progetto :

Se la OBNAM_PROFILEvariabile di ambiente contiene un nome file, i dati di profilatura vengono memorizzati lì e possono essere visualizzati in seguito con obnam-viewprof:

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

I problemi di prestazioni che non sono correlati a una particolare configurazione possono essere osservati anche usando obnam-benchmark tool.

3. Apri un ticket

Se la performance non fosse ancora determinata facendo delle indagini autoguidate, aprirei un ticket sul sito Web del progetto . Da quello che sono stato in grado di raccogliere, gli sviluppatori sono in qualche modo reattivi e probabilmente sarebbero i migliori a sradicare i problemi con il loro progetto.

obnamsembra utilizzare solo SFTP, quindi dovrebbe essere abbastanza ovvio ciò che sta causando il problema. Vorrei anche considerare di basare le prestazioni SFTP da solo in modo da poter vedere quale dovrebbe essere il massimo teorico con il tuo sistema + connessione di rete prima di provare a ottenere queste informazioni dai obnamtest stessi.

Punti dati aggiuntivi

Ho trovato questo post sul blog in cui l'autore ha fatto un confronto tra diverse opzioni in questa categoria. L'articolo è intitolato: Confronto di rsnapshot e obnam per backup di grandi dimensioni pianificati .

L'articolo ha messo in evidenza alcune prestazioni molto scadenti, IMO, con obnamcui sembrerebbe coincidere con quello che stai descrivendo.

prestazione di obnam

Dopo aver eseguito il backup / home completamente (che ha richiesto diversi giorni!), Una nuova esecuzione, diversi giorni dopo ha preso (il tempo dal comando time di Linux):

Backup di 3443706 file, caricamento di 94,0 GiB in 127h48m49s a 214,2 KiB / s velocità media830 file; 1,24 GiB (0 B / s) reali 7668m56.628s utente 4767m16.132s sys 162m48.739s

Dal file di registro 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

Quindi: ~ 5 giorni per il backup ~ 100 GB di dati modificati ... Il carico non era elevato sulle macchine, né in termini di CPU, né in termini di RAM. L'utilizzo del disco in / backups / backup_home era 5,7 T, l'utilizzo del disco di / home era 6,6 T, quindi sembra che ci sia un po 'di deduplicazione.

prestazioni di rsnapshot

Un backup completo di / home in (secondo il file di registro):

   [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

Quindi: ~ 1,5 giorni per un backup completo di 6,3 TB. Un backup incrementale il giorno dopo ha richiesto:

     [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

Quindi: 15 minuti ... e i dati modificati sono ammontati a 21 GB.

Non come approfondita, ma fa menzione che uno degli svantaggi di obnamè che è molto lento rispetto attic.

Professionisti di Obnam:

• Ben documentato
• mailing list attiva
• pacchetti disponibili

Obnam contro:

• molto lento
• backup di grandi dimensioni

Professionisti della soffitta:

• backup molto più piccoli (anche senza deduplicazione)
• deduplicazione molto migliore
• più veloce

Contro attico:

• formato del repository non documentato
• non una grande comunità di utenti

Vengono mostrati alcuni dati di test che sembrano indicare che obnamè veramente lento.

Dall'SSD locale all'HD remoto, tramite una connessione wifi così così:

    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

Riferimenti

• Post di blog sulle modifiche di Obnam

La configurazione predefinita di Obnam (al 08-02-2015) non funziona bene per il backup di directory con un numero elevato di file di piccole dimensioni. Ho avuto esattamente lo stesso problema di cui sopra.

La soluzione per me era aggiungere --lru-size = 8192 --upload-queue-size = 8192 alla riga di comando. Ciò ha risolto il problema e trasformato un frustrato in un utente Obnam molto felice. (Ora ho queste impostazioni nei miei file di configurazione standard.)

Sfortunatamente, il tutorial di Obnam non menziona in anticipo quanto siano importanti queste impostazioni. Le FAQ forniscono maggiori dettagli. L'impostazione dei parametri delle prestazioni è davvero obbligatoria sui sistemi con molti file di piccole dimensioni.