-
SAVF CPY OBJ extrem langsam
Guten Abend,
eine Verständnisfrage, ein Restore vom Band, das verpacken der Objekte in eine SAVF geht schnell (<5 Minuten) für 4 GB, allerdings das kopieren (letzte Zeile) ins IFS aus der LIB heraus zieht sich dann 20 Minuten...
Code:
RSTOBJBRM OBJ(mes01p teb01p) SAVLIB(mdblib) DEV(TAPMLB01) SAVLVL(*SAVDATE) SAVDATE(05022021 111500) PVTAUT(*YES) RSTLIB(RSTLIB)
CRTSAVF FILE(RSTLIB/SAV223754) TEXT('RstObj2Prod vom 05.02.2021 11:15:00') AUT(*ALL)
SAVOBJ OBJ(mes01p teb01p) LIB(RSTLIB) DEV(*SAVF) SAVF(RSTLIB/SAV223754) DTACPR(*LOW) PVTAUT(*YES) OUTPUT(*PRINT)
CPY OBJ('/QSYS.LIB/RSTLIB.LIB/SAV223754.FILE') TOOBJ('/transfer/savrst/SAV223754.savf')
Kann man das irgendwie beschleunigen bzw. einen anderen Befehl verwenden um den Copy zu beschleunigen?
-
Zitat von Gutmann
Kann man das irgendwie beschleunigen bzw. einen anderen Befehl verwenden um den Copy zu beschleunigen?
Da dürfte die Integritätsprüfung des Savfiles noch zuschlagen (evtl. siehst Du im WRKSYSACT auch LO* Jobs)
Die Frage ist aber - wozu das CPY?
-h
-
IFS ist nicht das schnellste ...
Hast du mal FTP Versucht?
Robi
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
IFS ist zwar nicht schnell, aber das sind schon zu große Unterschiede.
Vielleicht hast du ein Problem mit unterschiedlichen Disk Blockgrößen auf deiner IBM i Partition.
Verwendet ihr zur Virtualisierung VIOS oder eine IBM i Hostpartition?
-
Hallo Zusammen, ja ich habe es nun per FTP gemacht, nachdem mir das mit der Geschwindigkeit nicht gefallen hat (10s vs. 1 Std).
Der Grund warum zunächst C(IFS) verwendet werden wollte:
Übertragung findet über PC-Programm statt, d.h. SAVF, per COPY in IFS um es abzugreifen u. zu übertragen. Mir geht es eher darum zu verstehen, warum es langsam ist. Das es über Umwege ist war mir im Vorfeld klar, nicht aber das die Performance hier wesentlich schlechter ist.
Zitat von Andreas_Prouza
IFS ist zwar nicht schnell, aber das sind schon zu große Unterschiede.
Vielleicht hast du ein Problem mit unterschiedlichen Disk Blockgrößen auf deiner IBM i Partition.
Verwendet ihr zur Virtualisierung VIOS oder eine IBM i Hostpartition?
Ja das wird verwendet - wie sehe ich die Thematik mit den Blockgrößen und wie könnte man das "korrigieren", z.B. auf der Ordnerebene im IFS? Ich sehe per WRKLNK etwas von Dateiformat = *Type2 - meinst du das oder wo sieht man die Blockgröße der LIB vs. dem IFS?
-
Die Blockgröße ist eine Eigenschaft der Disk und ist für alle Systeme (QSYS, IFS, QDLS) daher identisch und liegt bei 4K.
Das Dateiformat *Type2 unterstützt lange Dateinamen, *Type1 nur 8.3, das gibts ja fast nirgendwo mehr.
Ich nehme mal an, dass das Anfügen an IFS-Dateien jenseits der 2GB halt etwas langsamer realisiert ist. Das könnte an dem Unix-ähnlichen Dateisystem liegen. Näheres dazu kann wohl nur die IBM aussagen.
Da du die SAVF ja sowieso auf dem PC haben willst, ist der Zugriff per FTP sowieso der bessere Weg. Zumal die FTP-Adresse im Windowsexplorer wie UNC-Pfade per Link inzwischen direkt ansprechen kannst.
-
Das Problem liegt darin, dass das VIOS und die IBM i mit unterschiedlichen Blockgrößen bei den Disks arbeiten.
Ich weiß die Zahlen jetzt nicht mehr genau auswendig, deshalb nagel mich bitte nicht auf die genauen Werte fest.
Angenommen das VIOS verwendet 500K und die IBM i 512K.
Das Lesen geht sehr schnell, die Daten werden von der Disk mit 500K gelesen und an die IBM i weitergeleitet.
Da die IBM i 512K verwendet gibt es hier kein Problem.
Möchte die IBM i nun Daten mit 512K auf die Disk schreiben lassen, muss das VIOS dieses zerlegen, da das VIOS nur 500K unterstützt.
Da man am System sowieso meist Leseoperationen hat und im Vergleich nur verhältnismäßig wenig schreibt, fällt es in Summe nicht so auf.
Erst durch solche Aktionen wo sehr viele Schreibvorgänge benötigt werden, fällt es dann tatsächlich ins Gewicht.
Ich habe damit sehr lange (viele Monate) versucht eine Lösung zu finden.
Zusammenfassung der IBM: Es ist halt so. Viele, wenn nicht sogar die meisten Unternehmen betrifft es. Von denen die es betrifft, wissen/bemerken es die meisten gar nicht oder leben einfach damit.
Meine Lösung:
Ich habe das VIOS gekübelt und eine IBM i Host Partition verwendet.
Damit hat dann wieder alles geflutscht und es gab diese Probleme nicht mehr.
Außerdem find ich die Verteilung der Virtuellen Laufwerke hier viel besser (einfacher und schneller) als beim VIOS.
lg Andreas
-
Zitat von Andreas_Prouza
Ich habe das VIOS gekübelt und eine IBM i Host Partition verwendet.
Damit hat dann wieder alles geflutscht und es gab diese Probleme nicht mehr.
Außerdem find ich die Verteilung der Virtuellen Laufwerke hier viel besser (einfacher und schneller) als beim VIOS.
Ähm... IBM i als Host-LPAR ist nur in einem Fall schneller als VIOS: Wenn man lokale Disks oder NVMe verwendet und gleichzeitig das auch beim VIOS versucht. VIOS selbst kann für lokale Disks nur RAID1 und keinen Schreibcache.
Wenn man VIOS macht (und dafür gibt es viele gute Gründe), hat man externes SAN per NPIV (was sehr flott sein kann) oder zur Not iSCSI. Und VIOS ist für redundante Umgebungen besser als eine einzelne IBM i Host-LPAR.
Die Problematik der 512b / 522b / 528b Sektoren (je nach Umgebung und RAID-Controller) kann inzwischen fast vernachlässigt werden, die Caching-Algorithmen gleichen das schon recht gut aus. Und gerade hier schneidet man sich mit i on i Hosting ein Loch ins Knie:
Der IBM i - Host hat 522b Disks (in der Regel, wenn man nicht 4k Einheiten nimmt), auf denen auch nur 512b Nutzdaten verwendet werden. Für den IBM i Client muss aber auch wieder jeder Plattenblock als 522b Block bereit gestellt werden, so daß man auch hier einen Versatz hat - im Vergleich zu VIOS genau das gleiche in grün, nur gelb.
Zum Ursprungspost: der Schreibzugriff beim CPY sieht für mich lokal aus - das Problem ist, daß SAVF immer (!) in ihrer Konsistenz geprüft werden. Daher macht es auch überhaupt keinen Sinn, das lokal zu erledigen. Wenn das SAVF von der i auf einen PC muss, schiebt oder holt man das per IFS und Namensformat 1 direkt aus der Library. Alles andere ist Gefrickel.
-
Danke soweit!
Zitat von holgerscherer
Die Problematik der 512b / 522b / 528b Sektoren (je nach Umgebung und RAID-Controller) kann inzwischen fast vernachlässigt werden, die Caching-Algorithmen gleichen das schon recht gut aus. Und gerade hier schneidet man sich mit i on i Hosting ein Loch ins Knie:
Der IBM i - Host hat 522b Disks (in der Regel, wenn man nicht 4k Einheiten nimmt), auf denen auch nur 512b Nutzdaten verwendet werden. Für den IBM i Client muss aber auch wieder jeder Plattenblock als 522b Block bereit gestellt werden, so daß man auch hier einen Versatz hat - im Vergleich zu VIOS genau das gleiche in grün, nur gelb.
Gibts da etwas Richtung "Alignment", damit man nicht diese negativen Einflüsse hat?
Zitat von holgerscherer
Zum Ursprungspost: der Schreibzugriff beim CPY sieht für mich lokal aus - das Problem ist, daß SAVF immer (!) in ihrer Konsistenz geprüft werden. Daher macht es auch überhaupt keinen Sinn, das lokal zu erledigen. Wenn das SAVF von der i auf einen PC muss, schiebt oder holt man das per IFS und Namensformat 1 direkt aus der Library. Alles andere ist Gefrickel.
Das herausholen meinst du z.B. über ein *.BAT-Skript per
Code:
copy \\10.1.2.1\root\QSYS.LIB\meine.LIB\meine.savf C:\Temp\meine.savf /B
NAMEFMT 1 kenne ich nur vom FTP Befehl. Ist die Root-Freigabe bei uns "normal", siehe UNC Pfad oberhalb?
Zitat von Fuerchau
Da du die SAVF ja sowieso auf dem PC haben willst, ist der Zugriff per FTP sowieso der bessere Weg. Zumal die FTP-Adresse im Windowsexplorer wie UNC-Pfade per Link inzwischen direkt ansprechen kannst.
Danke - daran habe ich gar nicht gedacht. Die Authentifizierung mit dem Windows-User über UNC Pfad spinnt bei uns seit... XP... ohnehin herum u. keiner weiß warum.
So klappts mit FTP
Code:
ftp://user:password@DNSNAME_ODER_IP/qsys.lib/meine.LIB/meine.savf
-
Zitat von Gutmann
Gibts da etwas Richtung "Alignment", damit man nicht diese negativen Einflüsse hat?
* Alignment - äh, das ist schwierig, da das je nach Virtualisierungsstufe anders aussehen muss. Im Zweifel (bei berechtigten Performance-Problemen) muss die Architektur genau betrachtet werden, denn nicht alles ist sinnvoll. Was hab ich schon gesehen: IBM i > VIOS > SVC > DSxxxx (zusammen mit 20 VMWare-Servern in einem Pool)...
* Root freigegeben? BITTE NICHT! Sofort stoppen. Schlechte Idee. Ein PC mit Ransomware und RWX-Zugriff auf QSYS.LIB ist immer ein Garant der Freude. Datenaustausch mit dem PC lieber mit FTP statt SMB, weils schneller ist und weniger CPU auf der IBM i zieht.
* Wenn der Netserver Authentifizierungsprobleme hat, sollte man sich die Kompatibilität Windows mit IBM i anschauen: https://www.ibm.com/support/pages/wh...bm-i-netserver
-
Zitat von holgerscherer
Ähm... IBM i als Host-LPAR ist nur in einem Fall schneller als VIOS: Wenn man lokale Disks oder NVMe verwendet und gleichzeitig das auch beim VIOS versucht. VIOS selbst kann für lokale Disks nur RAID1 und keinen Schreibcache.
Stimmt, die internen Platten waren hier das Problem.
Similar Threads
-
By rr2001 in forum IBM i Hauptforum
Antworten: 11
Letzter Beitrag: 02-03-20, 14:30
-
By mahones in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 13-05-16, 10:07
-
By bussibaer in forum IBM i Hauptforum
Antworten: 11
Letzter Beitrag: 01-10-15, 11:40
-
By Mr-Ferret in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 28-02-14, 10:35
-
By Robi in forum IBM i Hauptforum
Antworten: 7
Letzter Beitrag: 29-10-01, 13:22
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks