ノート11のメモリ不足の謎

Notes 11にアップグレードした一部のお客様は、Notesクライアントでメモリ不足エラーが発生しました。

十分な空きメモリがないことを示すメッセージボックスである場合もあれば、トレースログのエラーでハングした場合もあります。 これは通常、クライアントをしばらく開いた後、インターネットから送信されたMIMEメールを開いたり、リンクをクリックして外部ブラウザを開いたりしたときに発生しました。 ユーザーがSametimeにログインしている場合は、発生する可能性が高くなります。

これについての奇妙なこと：

一体何が起こっていたのか、そしてそれを修正するために何ができるでしょうか？

最初の手がかりは、タスクマネージャーが表示するのは ワーキングセット アプリケーションのメモリ：基本的に使用中のメモリの量。 これは知っておくとよい数値であり、ほとんどの場合、これが重要な数値ですが、メモリが不足する可能性のある方法は他にもあります。 詳細を確認するために、Windowsパフォーマンスモニターを開きました。

Performance Monitorには、追跡可能な追加のメモリ測定値を含む[プロセス]セクションがあります。 具体的には、「プライベートバイト」（ コミットした アプリケーションが使用しているメモリ）と「仮想バイト」（ 仮想アドレス空間 アプリケーションは予約済みです）。 これは、Notesクライアントの実行中にパフォーマンスモニターとタスクマネージャーを並べたスクリーンショットです。

タスクマネージャーが215MBのメモリを使用していることを示しているのに対し、パフォーマンスモニターは使用中のメモリがあることを示していることがわかります。 ほぼ2GBの仮想アドレス空間が予約されています。 テストを行っていたところ、クライアントが仮想アドレス空間モニターの2GBマークに達した時点で、メモリ不足エラーが発生していることがわかりました。

Notesクライアントはまだ2ビットアプリケーションであるため、この32GBのマークは重要です。 これの副作用の2つは、4GBの仮想アドレス空間しか使用できないことです（実際には64GBですが、その半分はカーネルによって要求されます）。 32ビットアプリケーションには、はるかに大きな仮想アドレス空間があります（テラバイトの領域を予約する場合があります）が、XNUMXビットアプリケーションには注意が必要です。

サイドバー：仮想アドレス空間に関するいくつかの説明：

それを超えて説明するのは少し難しいです、そしてほとんどの人は気にしません、しかしあなたが興味を持っているならこれは素晴らしい要約です： https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces

とにかく、私たちが知っていることを知って、なぜそれがそれほど多くを使用しているのか、そしてどうすれば問題を解決できますか？

ネタバレ注意：当面の修正は 減らします Notesクライアントが使用するJavaヒープサイズ。 これは直感に反しているように見えます。通常、メモリ不足エラーが発生した場合は、メモリを増やしたいと考えていますが、読み続けてください。

クライアントのJavaヒープサイズは、jvm.propertiesファイルのパラメータによって制御されます。 Notes / framework / rcp / deployディレクトリ。 次のようなエントリがあります。

vmarg.Xmx = -Xmx512m

これは、Javaヒープの最大サイズを制御します。これは、Java（この場合はNotesクライアント）がコードの実行に使用するメモリの量です。 上記のパラメータに示されているように、Notesのデフォルト値は512MBです。 ただし、多くのお客様は、Notesクライアントでメモリを大量に消費することを行っている場合、特にDomino Designerを使用している場合は、これを増やしたいと考えています。

これは調整するのにかなり一般的なパラメータであり、それを変更することについての技術情報さえあります こちら.

メモリ不足エラーが発生していたお客様は、このパラメータを1024MBに設定していました。 これはNotes9では決して問題ではありませんでしたが、Notes 11では突然、ヒープに割り当てるにはメモリが多すぎました。

これをXmx512mに戻すことで、メモリ不足エラーがなくなりました。

また、パフォーマンスモニターで、512MBのヒープを使用すると、仮想アドレス空間が約1.5GBに減少したことを確認できました。これにより、余分な領域を予約する必要がある場合に、クライアントに余裕ができました。

次の明らかな質問は、なぜ顧客はNotes9クライアントでこの問題を抱えていなかったのかということです。

32ビットアプリケーションをコンパイルする場合、/ LARGEADDRESSAWAREと呼ばれる設定可能なフラグがあります。 これにより、アプリケーションのプロセスで、上記の4GBではなく、64ビットオペレーティングシステムで2GBの仮想アドレス空間全体を使用できるようになります。

それは java.exe & notes2.exe Notes9クライアントのファイルは/ LARGEADDRESSAWAREフラグを使用してコンパイルされましたが、Notes2クライアントのjava.exeファイルとnotes11.exeファイルはコンパイルされませんでした。

Notes9はIBMバージョンのJavaJVMを使用しましたが、Notes11はOpenJDKOpenJ9バージョンを使用します。 OpenJ9ビットディストリビューションは最近まで/ LARGEADDRESSAWAREでコンパイルされていなかったため（バージョン32u8、262年2020月から）、Notes11クライアントもそのフラグでコンパイルされませんでした。

つまり、Notes 9には完全な4GBの仮想アドレス空間がありましたが、Notes11には2GBしかありません。

これについてHCLと話し合っており、HCLは問題を認識しており、修正を計画しています。 のチーフアーキテクト、Ram Krishnamurthy HCL Notes クライアント、私たちにこのガイダンスを与えました：

「これは、Windowsのみの1.8バージョンの既知のOpenJDKの欠陥です。 この問題の修正はOpenJDKチームによって発見され、 release まもなく修正の。 この修正は現在、次の1101フィックスパックに含まれる予定です。 OpenJDKがバンドルされているため、これはv11ベースのバージョンにのみ影響します。 それまでは、この記事に記載されている回避策を使用できます。」

Notes クライアントが新しいバージョンの OpenJ9 を使用すると、 HCL コンパイラ フラグを再度追加することができれば、この問題はなくなります。