Was ist die erwartete Leistung von obnam? Oder: warum ist es so langsam?

Ich habe in den letzten Tagen mit obnam herumgespielt, und obwohl es sehr vielversprechend aussieht und im Grunde alles zu bieten scheint, was ich jemals von einem Backup-Tool wollte, bin ich ziemlich enttäuscht von seiner Leistung. Tatsächlich ist es so langsam, dass ich vermute, dass obnam hier nicht einmal schuld ist, aber etwas in meiner Umgebung verursacht es.

Ich frage mich also hauptsächlich, ob jemand anderes obnam verwendet oder dessen Interna gut genug kennt, um das Problem möglicherweise zu identifizieren.

Nach allem, was ich bisher sagen konnte, scheint obnam für jede gesicherte Datei einen individuellen GPG-Prozess zu erstellen. Gemessen an htop, strace und iostat wird die Geschwindigkeit einer ersten Sicherung hauptsächlich durch das ständige Gabeln begrenzt, während die CPU und die Laufwerke (es ist kein Netzwerk beteiligt) im Leerlauf unter 20% ausgelastet sind.

Mein Backup beläuft sich auf ungefähr 500.000 Dateien mit insgesamt 170 GiB Daten. Für jeden Sicherungslauf wird gpg also 500.000 Mal gegabelt. Ich bin eigentlich nicht einmal überrascht, dass dies für den ersten Lauf fast einen ganzen Tag und für einen weiteren Lauf über drei Stunden dauert, wobei die meisten Dateien unverändert bleiben. Aber ist dies wirklich die Leistung, die Benutzer von obnam erwarten sollten? Zum Vergleich: Ein inkrementeller Lauf von rsnapshot (gleiche Daten, gleicher Computer, gleiche Laufwerke) dauert ungefähr vier Minuten. Zugegeben, es gibt keine Verschlüsselung beteiligt, aber dies sollte nicht sein , dass signifikant.

Um es klar zu sagen: Kann der Computer aller anderen nicht mehr als 50 Mal pro Sekunde gpg (Verschlüsselung eines kleinen Datenblocks) ausführen, was obnam letztendlich zu einem fast ungewöhnlich langsamen Tool macht? Oder bin es nur ich?

(FWIW, mein Computer ist ein Core i5-2500 mit 8 GB RAM und SSD-Laufwerken, auf dem Gentoo ausgeführt wird. Die Sicherung erfolgt auf einer Festplatte, aber ich konnte keinen Unterschied zum Sichern auf der SSD feststellen, da es sich nicht um E / A handelt -gebunden.)

Hier finden Sie eine gute Lektüre zur Beschleunigung von obnam (kann bis zu zehnmal schneller ausgeführt werden): http://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html

Zusammenfassung: Fügen Sie Ihrer Befehlszeilen- oder Konfigurationsdatei "--lru-size = 1024 --upload-queue-size = 512" hinzu. Beachten Sie, dass dadurch die Speichernutzung von obnam etwas erhöht wird.

Ich denke, ich würde dieses Problem auf verschiedene Arten angreifen. Für den Anfang würde ich versuchen, es selbst mit den folgenden Methoden zu diagnostizieren.

1. obnam logs

Für den Anfang können Sie Nachrichten obnamwie folgt protokollieren :

$ obnam --log obnam.log

Sie können die Protokollierungsstufe auch über den --log-levelSchalter erhöhen , um weitere Details zu erhalten.

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

obnamAus diesem Auszug in den FAQs des Projekts können Sie auch ein Profil der folgenden Aktionen abrufen :

Wenn die OBNAM_PROFILEUmgebungsvariable einen Dateinamen enthält, werden die Profildaten dort gespeichert und können später angezeigt werden mit obnam-viewprof:

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

Leistungsprobleme, die nicht mit einem bestimmten Setup zusammenhängen, können auch mithilfe von beobachtet werden obnam-benchmark tool.

3. Öffnen Sie ein Ticket

Wenn die Leistung bei einer selbstgesteuerten Untersuchung immer noch nicht bestimmt ist, würde ich ein Ticket auf der Website des Projekts öffnen . Nach allem, was ich sammeln konnte, sind die Entwickler etwas reaktionsschnell und sie sind wahrscheinlich am besten in der Lage, Probleme mit ihrem Projekt auszurotten.

obnamscheint nur SFTP zu verwenden, daher sollte es ziemlich offensichtlich sein, was das Problem verursacht. Ich würde auch in Betracht ziehen, die SFTP-Leistung selbst zu bestimmen, damit Sie sehen können, wie hoch das theoretische Maximum für Ihre System- und Netzwerkverbindung sein sollte, bevor Sie versuchen, diese Informationen aus den obnamTests selbst herauszuholen .

Zusätzliche Datenpunkte

Ich habe diesen Blog-Beitrag gefunden, in dem der Autor mehrere Optionen in dieser Kategorie verglichen hat. Der Artikel trägt den Titel: Vergleichen von rsnapshot und obnam für geplante große Sicherungen .

Der Artikel hob eine sehr schlechte Leistung hervor, IMO, die mit dem obnam, was Sie beschreiben, zu leben scheint.

obnam leistung

Nach dem vollständigen Sichern / Home (was mehrere Tage dauerte!) Erhielt einige Tage später ein neuer Lauf (Timing mit dem Linux-Zeitbefehl):

Gesicherte 3443706 Dateien, hochgeladen 94.0 GiB in 127h48m49s mit 214.2 KiB / s Durchschnittsgeschwindigkeit830 Dateien; 1,24 GiB (0 B / s) real 7668m56.628s Benutzer 4767m16.132s sys 162m48.739s

Aus der obname-Protokolldatei:

   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

Also: ~ 5 Tage für die Sicherung von ~ 100 GB geänderter Daten… Die Auslastung der Computer war weder in Bezug auf die CPU noch in Bezug auf den Arbeitsspeicher hoch. Die Festplattennutzung in / backups / backup_home betrug 5,7 t, die Festplattenauslastung in / home betrug 6,6 t, daher scheint es einige Dedups zu geben.

rsnapshot Leistung

Eine vollständige Sicherung von / home to (gemäß Protokolldatei):

   [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

Also: ~ 1,5 Tage für eine vollständige Sicherung von 6,3 TB. Ein inkrementelles Backup einen Tag später dauerte:

     [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

Also: 15 Minuten ... und die geänderten Daten betrugen 21 GB.

Nicht so gründlich , sondern macht erwähnen , dass einer der Nachteile obnamist , dass es sehr langsam im Vergleich attic.

Obnam Profis:

• gut dokumentiert
• aktive Mailingliste
• Pakete verfügbar

Obnam Nachteile:

• sehr langsam
• große Backups

Dachbodenprofis:

• viel kleinere Backups (auch ohne Deduplizierung)
• viel bessere Deduplizierung
• viel schneller

Dachboden Nachteile:

• Repository-Format nicht dokumentiert
• keine große Benutzergemeinschaft

Es werden einige Testdaten angezeigt, die darauf hinweisen, dass dies obnamnur sehr langsam ist.

Von der lokalen SSD zur Remote-Festplatte über eine mittelmäßige WLAN-Verbindung:

    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

Verweise

• Obnam optimiert den Blog-Beitrag

Die Standardkonfiguration von Obnam (Stand 08.02.2015) eignet sich nicht zum Sichern von Verzeichnissen mit einer großen Anzahl kleiner Dateien. Ich hatte genau das gleiche Problem wie oben erwähnt.

Die Lösung für mich bestand darin, der Befehlszeile --lru-size = 8192 --upload-queue-size = 8192 hinzuzufügen. Dies löste das Problem und verwandelte einen frustrierten in einen sehr glücklichen Obnam-Benutzer. (Ich habe diese Einstellungen jetzt in meinen Standardkonfigurationsdateien.)

Leider wird in Obnams Tutorial nicht im Voraus erwähnt, wie wichtig diese Einstellungen sind. Die FAQ enthält weitere Details. Das Einstellen der Leistungsparameter ist auf Systemen mit vielen kleinen Dateien wirklich obligatorisch.