Das Mysterium aus dem Gedächtnis in Notizen 11

Bei einigen unserer Kunden, die auf Notes 11 aktualisiert haben, sind im Notes-Client Fehler wegen unzureichenden Speichers aufgetreten.

Manchmal war es ein Meldungsfeld, das besagte, dass nicht genügend freier Speicher vorhanden ist, manchmal war es ein Hängenbleiben mit Fehlern im Ablaufverfolgungsprotokoll. Dies geschah im Allgemeinen, nachdem der Client eine Weile geöffnet war, und oft beim Öffnen von MIME-E-Mails, die aus dem Internet gesendet wurden, oder beim Klicken auf Links, um einen externen Browser zu öffnen. Wenn Benutzer bei Sametime angemeldet waren, war die Wahrscheinlichkeit höher.

Das Seltsame daran:

Was zum Teufel war los und was können wir tun, um es zu beheben?

Der erste Hinweis ist, dass der Task-Manager nur die Workingset Speicher für eine Anwendung: im Wesentlichen die Menge des verwendeten Speichers. Das ist eine gute Zahl, die man kennen sollte, und in den meisten Fällen ist das die Zahl, die wichtig ist, aber es gibt andere Möglichkeiten, den Speicher zu knapp zu machen. Wir haben den Windows-Leistungsmonitor geöffnet, um einen genaueren Blick darauf zu werfen.

Der Systemmonitor verfügt über einen Abschnitt Prozesse mit zusätzlichen Speichermessungen, die Sie verfolgen können. Konkret haben wir uns „Private Bytes“ (die Menge an begangen Speicher, den die Anwendung verwendet) und „Virtuelle Bytes“ (die Menge an virtueller Adressraum die Anwendung reserviert hat). Hier ist ein Screenshot von Systemmonitor und Task-Manager nebeneinander, während der Notes-Client ausgeführt wird:

Sie können sehen, dass der Task-Manager zwar 215 MB belegten Speicher anzeigt, der Leistungsmonitor uns jedoch mitteilt, dass dies vorhanden ist fast 2 GB virtueller Adressraum sind reserviert. Beim Testen stellten wir fest, dass zu dem Zeitpunkt, an dem der Client die 2 GB-Marke im Monitor für den virtuellen Adressraum erreichte, Fehler wegen unzureichenden Arbeitsspeichers auftraten.

Diese 2 GB-Markierung ist wichtig, da der Notes-Client immer noch eine 32-Bit-Anwendung ist. Einer der Nebeneffekte davon ist, dass nur 2 GB virtuellen Adressraum zum Spielen zur Verfügung stehen (eigentlich 4 GB, aber die Hälfte davon wird vom Kernel beansprucht). 64-Bit-Anwendungen haben einen viel, viel größeren virtuellen Adressraum (sie reservieren manchmal Terabyte Speicherplatz), aber 32-Bit-Anwendungen müssen vorsichtig sein.

SIDEBAR: Einige Erläuterungen zum virtuellen Adressraum:

Darüber hinaus ist es ein wenig schwer zu erklären, und die meisten Leute interessiert es nicht, aber wenn Sie interessiert sind, ist dies eine schöne Zusammenfassung: https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces

Wie auch immer, wenn wir wissen, was wir wissen, warum verbraucht es so viel und wie können wir das Problem beheben?

Spoiler-Alarm: Die sofortige Lösung bestand darin, Veteran die vom Notes-Client verwendete Java-Heap-Größe. Dies scheint nicht intuitiv zu sein – normalerweise möchten Sie den Speicher erhöhen, wenn Sie einen Speichermangel haben – aber lesen Sie weiter.

Die Größe des Java-Heapspeichers für den Client wird durch einen Parameter in der Datei jvm.properties gesteuert Notes/framework/rcp/deploy-Verzeichnis. Es hat einen Eintrag wie diesen:

vmarg.Xmx=-Xmx512m

Dies steuert die maximale Größe des Java-Heapspeichers, d. h. die Speichermenge, die Java (und in diesem Fall der Notes-Client) zum Ausführen von Code verwendet. Der Standardwert für Notes beträgt 512 MB, wie im obigen Parameter gezeigt. Viele Kunden erhöhen diese jedoch gerne, wenn sie speicherintensive Aufgaben mit ihren Notes-Clients ausführen, insbesondere wenn sie Domino Designer verwenden.

Dies ist ein ziemlich üblicher Parameter, der angepasst werden muss, und es gibt sogar einen Hinweis darauf, ihn zu ändern hier.

Bei unseren Kunden, die aufgrund von Speicherfehlern aufgetreten sind, wurde dieser Parameter auf 1024 MB gesetzt. Mit Notes 9 war dies nie ein Problem, aber mit Notes 11 war es plötzlich zu viel Speicher, um dem Heap zuzuweisen.

Durch die Reduzierung auf Xmx512m wurden die Fehler wegen unzureichendem Speicher beseitigt.

Wir konnten auch im Performance Monitor bestätigen, dass die Verwendung eines 512 MB Heaps den virtuellen Adressraum auf etwa 1.5 GB reduzierte, was dem Client viel mehr Luft zum Atmen verschaffte, wenn er zusätzliche Speicherplatz reservieren musste.

Die nächste offensichtliche Frage ist: Warum hatten die Kunden dieses Problem nicht mit dem Notes 9-Client?

Wenn Sie eine 32-Bit-Anwendung kompilieren, können Sie ein Flag namens /LARGEADDRESSAWARE setzen. Dadurch kann der Prozess der Anwendung auf einem 4-Bit-Betriebssystem volle 64 GB virtuellen Adressraum verwenden, anstatt der oben gezeigten 2 GB.

Es stellt sich heraus, dass die java.exe und notes2.exe Dateien auf dem Notes 9-Client wurden mit den /LARGEADDRESSAWARE-Flags kompiliert, die Dateien java.exe und notes2.exe auf dem Notes 11-Client jedoch nicht.

Notes 9 verwendet die IBM-Version der Java JVM, aber Notes 11 verwendet die OpenJDK OpenJ9-Version. Die OpenJ9 32-Bit-Distribution wurde bis vor kurzem nicht mit /LARGEADDRESSAWARE kompiliert (Version 8u262, ab Juni 2020), sodass der Notes 11-Client auch nicht mit diesem Flag kompiliert wurde.

Mit anderen Worten, Notes 9 hatte einen vollen virtuellen Adressraum von 4 GB, während Notes 11 nur 2 GB hat.

Wir haben darüber mit HCL gesprochen, und sie sind sich des Problems bewusst und planen eine Lösung. Ram Krishnamurthy, Chefarchitekt des HCL Notes Kunde, gab uns diese Anleitung:

„Dies ist ein bekannter OpenJDK-Fehler nur für die Version 1.8 unter Windows. Eine Lösung für dieses Problem wurde vom OpenJDK-Team gefunden und wird Folgendes tun: release des Fixes in Kürze. Es ist derzeit geplant, diesen Fix in ein kommendes 1101 Fixpack aufzunehmen. Dies betrifft nur v11-basierte Versionen, da es das OpenJDK bündelt. Bis dahin kann der in diesem Artikel dokumentierte Workaround verwendet werden.“

Sobald der Notes-Client eine neuere Version von OpenJ9 verwendet und HCL in der Lage ist, das Compiler-Flag erneut hinzuzufügen, wird dieses Problem behoben.