7
Oracle VPN Performance 64 bit vs. 32bit
Hallo zusammen,
wir haben einen VPN von Seite A zu Seite B via IPsec.
Seite A hat eine WAN Bandreibte von 800Mbit/s, Seite B 250Mbit/s
Über den VPN (zB. bei Filecopy) bekommen wir stabile 70Mbit/s an Bandbreite.
Nun haben wir auf Seite B eine 32bit Applikationen mit 32bit Oracle Client 19c die auf die DB auf Seite A zugreifen soll.
Zum Test haben wir eine große Tabelle abgefragt, ca. 900MB, und festgestellt: die Bandbreite wird nur mit rund 16Mbit/s ausgelastet.
Wenn wir eine (Test)App sowie den Oracle Client 19c auf 64bit umstellen, können wir die 70MBit/s volle nutzen - gleicher SQL usw.
Unser Problem ist, dass wir leider die genannte 32bit Applikationen nicht einfach auf 64bit umstellen können.
Hat jemand damit Erfahrung, gerade im Bezug auf Oracle Client und VPN.
In Verwendung ist Oracle Direct Access mit wie oben beschrieben Oracle 19c
LG
wir haben einen VPN von Seite A zu Seite B via IPsec.
Seite A hat eine WAN Bandreibte von 800Mbit/s, Seite B 250Mbit/s
Über den VPN (zB. bei Filecopy) bekommen wir stabile 70Mbit/s an Bandbreite.
Nun haben wir auf Seite B eine 32bit Applikationen mit 32bit Oracle Client 19c die auf die DB auf Seite A zugreifen soll.
Zum Test haben wir eine große Tabelle abgefragt, ca. 900MB, und festgestellt: die Bandbreite wird nur mit rund 16Mbit/s ausgelastet.
Wenn wir eine (Test)App sowie den Oracle Client 19c auf 64bit umstellen, können wir die 70MBit/s volle nutzen - gleicher SQL usw.
Unser Problem ist, dass wir leider die genannte 32bit Applikationen nicht einfach auf 64bit umstellen können.
Hat jemand damit Erfahrung, gerade im Bezug auf Oracle Client und VPN.
In Verwendung ist Oracle Direct Access mit wie oben beschrieben Oracle 19c
LG
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669110
Url: https://administrator.de/forum/oracle-vpn-performance-64-bit-vs-32bit-669110.html
Ausgedruckt am: 21.12.2024 um 17:12 Uhr
7 Kommentare
Neuester Kommentar
Moin.
Ich würde mal checken ob die PMTU über den Tunnel funktioniert, d.h. ICMP von Client zu Server durchgängig in den Firewalls zugelassen ist oder ob MSS Clamping an den Tunnelendpunkten funktional ist. Und wie immer mal mittels Wireshark prüfen ob Pakete über den Tunnel fragmentieren.
Gruß catrell
Über den VPN (zB. bei Filecopy) bekommen wir stabile 70Mbit/s an Bandbreite.
Wenn man den kleinsten gemeinsamen Nenner bei 250MBit/s bedenkt ist das aber sehr dürftig auch wenn man den Overhead abzieht. Oder ist das ein asymmetrischer Anschluss und der Upload liegt nicht bei 250MBit/s oder schafft eure Hardware einfach nicht mehr?Ich würde mal checken ob die PMTU über den Tunnel funktioniert, d.h. ICMP von Client zu Server durchgängig in den Firewalls zugelassen ist oder ob MSS Clamping an den Tunnelendpunkten funktional ist. Und wie immer mal mittels Wireshark prüfen ob Pakete über den Tunnel fragmentieren.
Gruß catrell
1
Seite A hat eine WAN Bandreibte von 800Mbit/s, Seite B 250Mbit/s
Das ist aber jeweils bestimmt keine symmetrische Anbindung, oder?Die 800/ 250 Mbit beziehen sich sicherlich auf den Download der jeweiligen Seite. Was habt ihr denn für einen Upload auf den Leitungen?
Denn wenn Standort B nur 20Mbit Upload hat, kann A ja unmöglich mit 800 Mbit runterladen…
Moin,
Ist das so ein externer VPN Blödsinn? Dann ist das ganze doch kein Wunder und bedarf keiner Diskussion. (Was soll "Filecopy" sein?)
Gruß
Spirit
Ist das so ein externer VPN Blödsinn? Dann ist das ganze doch kein Wunder und bedarf keiner Diskussion. (Was soll "Filecopy" sein?)
Gruß
Spirit
Zitat von @em-pie:
Die 800/ 250 Mbit beziehen sich sicherlich auf den Download der jeweiligen Seite. Was habt ihr denn für einen Upload auf den Leitungen?
Denn wenn Standort B nur 20Mbit Upload hat, kann A ja unmöglich mit 800 Mbit runterladen…
Seite A hat eine WAN Bandreibte von 800Mbit/s, Seite B 250Mbit/s
Das ist aber jeweils bestimmt keine symmetrische Anbindung, oder?Die 800/ 250 Mbit beziehen sich sicherlich auf den Download der jeweiligen Seite. Was habt ihr denn für einen Upload auf den Leitungen?
Denn wenn Standort B nur 20Mbit Upload hat, kann A ja unmöglich mit 800 Mbit runterladen…
Seite A hat 800 Down / 800 Up
Seite B hat 250 Down / 100 Up
Somit sehe ich die 70 Mbits über den VPN als okay mal an
Ist das so ein externer VPN Blödsinn? Dann ist das ganze doch kein Wunder und bedarf keiner Diskussion. (Was soll "Filecopy" sein?)
Es ist ein IPSec VPN Site to Stite
FileCopy soll einfach beschreiben, wenn wir Bsp. ein .iso von A nach B kopieren, wir 70Mbits über den VPN bekommen
Zitat von @150940:
Über den VPN (zB. bei Filecopy) bekommen wir stabile 70Mbit/s an Bandbreite.
Wenn man den kleinsten gemeinsamen Nenner bei 250MBit/s bedenkt ist das aber sehr dürftig auch wenn man den Overhead abzieht. Oder ist das ein asymmetrischer Anschluss und der Upload liegt nicht bei 250MBit/s oder schafft eure Hardware einfach nicht mehr?Ich würde mal checken ob die PMTU über den Tunnel funktioniert, d.h. ICMP von Client zu Server durchgängig in den Firewalls zugelassen ist und ob MSS Clamping an den Tunnelendpunkten funktional ist. Und wie immer mal mittels Wireshark prüfen ob Pakete über den Tunnel fragmentieren.
Das Problem scheint ja nur, bei genannter 32 bit Umgebung vor zu kommen.
LG
Moin @MarkBeaker,
ähm, nein, die 1472 Bytes die du max. mit dem Ping durchbekommen hast, ist nicht die Ethernet MTU, sondern die ICMP MSS. 🙃
Wenn du zu dieser jedoch die 20Bytes für den IP-Header und 8 Bytes für den ICMP-Header wieder dazuzählst, sprich, 1472+20+8=1500, dann hast du schon eher die MTU. 😉
Und genau deshalb, sagt mir meine Kristallkugel, dass das Problem nicht wirklich etwas mit der MSS oder MTU zu tun hat, weil eine 32Bit Anwendung ihre Pakete 1:1 auf dieselbe Art und weise über das Netzwerk versendet wie auch eine 64Bit Anwendung.
Eine 64Bit Anwendung kann jedoch von sich aus um einiges performanter sein, weil sie schlichtweg gleichzeitig auf mehr Ressourcen zugreifen kann.
Ferner kann auch eine auf dem DB Server und oder Client laufende AV oder FW wie z.B. Defender & Co, sowas auch verursachen, sprich, überprüf mal bitte die entsprechenden Regeln/Ausnahmen.
Gruss Alex
ICMP geht durch den ganzen Tunnel sauber durch. Also kleinste MTU haben wir 1472 festgestellt.
ähm, nein, die 1472 Bytes die du max. mit dem Ping durchbekommen hast, ist nicht die Ethernet MTU, sondern die ICMP MSS. 🙃
Wenn du zu dieser jedoch die 20Bytes für den IP-Header und 8 Bytes für den ICMP-Header wieder dazuzählst, sprich, 1472+20+8=1500, dann hast du schon eher die MTU. 😉
Das Problem scheint ja nur, bei genannter 32 bit Umgebung vor zu kommen.
Und genau deshalb, sagt mir meine Kristallkugel, dass das Problem nicht wirklich etwas mit der MSS oder MTU zu tun hat, weil eine 32Bit Anwendung ihre Pakete 1:1 auf dieselbe Art und weise über das Netzwerk versendet wie auch eine 64Bit Anwendung.
Eine 64Bit Anwendung kann jedoch von sich aus um einiges performanter sein, weil sie schlichtweg gleichzeitig auf mehr Ressourcen zugreifen kann.
Ferner kann auch eine auf dem DB Server und oder Client laufende AV oder FW wie z.B. Defender & Co, sowas auch verursachen, sprich, überprüf mal bitte die entsprechenden Regeln/Ausnahmen.
Gruss Alex
1
