Wie kann das sein?
Das Ausführen eines cp oder rsync (mit -W --inplace) dauert für 93 GB zwei Stunden; eine Bandwiederherstellung über das dedizierte Backup-Netzwerk dauert 41 Minuten. Die Bandwiederherstellung beträgt 50 Mbit/s; von Festplatte zu Festplatte wurde gemessen und mit maximal 16 Mbit/s berechnet – 2 Mbit/s, wenn die CPU ausgelastet ist.
Die Wiederherstellungssoftware ist Veritas NetBackup; die Festplatten befinden sich auf einem EMC Symmetrix-Array über Glasfaser. Die Box ist ein HP rx6600 (Itanium) mit 16 Gb und läuft unter HP-UX 11i v2. Alle Festplatten befinden sich auf einer Glasfaserkarte, aufgelistet als:
HP AD194-60001 PCI/PCI-X Fibre Channel 2-port 4Gb FC/2-port 1000B-T Combo Adapter (FC Port 1)
Die Festplatten verwenden außerdem alle Veritas Volume Manager (anstelle von HP LVM).
Aktualisieren:Mir fällt ein, dass diesnichtnur eine direkte Kopie von Disk zu Disk; in Wirklichkeit ist es eineSchnappschusszum Kopieren auf die Festplatte. Könnte das Lesen des Snapshots die Dinge so sehr verlangsamen? Der Snapshot ist ein HP VxFS-Snapshot (kein vxsnap); vielleicht führt die Interaktion zwischen dem Snapshot und VxVM zu Geschwindigkeitseinbußen?
Aktualisieren:Bei Verwendung von fstyp -v scheint die Blockgröße (f_bsize) 8192 zu sein; die Standardblockgröße unter UNIX ist 512 (oder 8192/16). Beim Testen mit dd habe ich eine Blockgröße von 1024k (oder 1048576 oder 8192*128) verwendet.
Ich frage mich wirklich, ob es an der Blockgröße liegt. Ich habe bei PerlMonks gelesen, dass das Perl-Modul File::Copy schneller ist als cp; das ist faszinierend: Ich frage mich.
Wenn NetBackup tar verwendet, dann ist esnichtVerwendung von cp: das könnte auch die Geschwindigkeitssteigerung erklären.
Aktualisieren:Es scheint, dass das Lesen vom Snapshot fast doppelt so langsam ist wie das Lesen vom eigentlichen Gerät. Das Ausführen von cp ist langsam, ebenso wie das Schreiben von tar in die Befehlszeile. Die Verwendung von tar ist etwas besser (bei Verwendung einer Datei), ist jedoch auf 8-GB-Dateien beschränkt (die betreffende Datei ist etwa 96 GB groß). Die Verwendung von File::Copy von Perl mit einem Nicht-Snapshot-Volume scheint eine der schnellsten Möglichkeiten zu sein.
Ich werde das versuchen und hier berichten, was ich bekomme.
Antwort1
Eine weitere Frage ist, ob Sie innerhalb des FC-Netzwerks IO-gebunden sind. Bitten Sie die SAN-Leute,zeigen(Grafiken sind gut)tatsächlichfreie Bandbreite verfügbar (und wenn es sich bei den FC-Switches um Cisco-Switches handelt, wie stellen sie sicher, dass sie die Bandbreitenprobleme innerhalb des Switches vermeiden)
Antwort2
Sind Sie durch das Lesen und Schreiben auf dieselbe Festplatte im Array eingeschränkt?
Antwort3
Wenn sich Ihr Band auch im SAN befindet, ist es möglich, dass die Übertragung direkt vom Band auf die Festplatte erfolgt, während eine Kopie über den Host geleitet werden muss, der die Kopie erstellt, und daher langsamer ist.
Antwort4
Wenn die Festplatten an verschiedene Busse auf Ihrer Hauptplatine angeschlossen sind, werden die Daten möglicherweise über drei oder mehr interne Busse kopiert, und die Latenzzeit beeinträchtigt Ihre IO beim Kopieren von Festplatte zu Festplatte. In diesem Fall ist es durchaus möglich, dass das Netzwerkbandlaufwerk einen Pfad mit höherer Bandbreite zur Zielfestplatte hat als die Quellfestplatte.