HTML5サーバーメモリ使用量
Terminal Service Plus HTML5サーバーはJAVAで動作します。JAVAがメモリをどのように扱うかを理解することで、Terminal Service Plus HTML5サーバーのメモリ使用量を理解するのに役立ちます。
割り当てられたメモリ
Javaが実行されると、コンピュータの物理メモリの25%を割り当てようとします。このメモリは「割り当てられています」が、直接使用されるわけではありません - これはWindowsタスクマネージャーで見ることができる実際のメモリ使用量ではありません。
JAVAプラットフォーム: 32ビット vs 64ビット
これら二つのプラットフォームの間には大きな違いがあります。
- JAVA 32ビットは定義上4GB以上のRAMを扱うことができません。利用可能なメモリの25%を割り当てるため、物理メモリが4GBあると仮定すると、最大で1GBを割り当てます。物理メモリが2GBしかない場合は、500MBのみを割り当てます。
- JAVA 64ビットは4GB以上の容量を理論的には最大16GBまで扱うことができます。 exa バイト) したがって、割り当てられたメモリは物理メモリのみに依存します。
JAVAメモリ管理
JAVAは「仮想マシン」です。これはJAVAが自分でメモリ管理を行うことを意味します。一度JAVAがメモリを割り当てると、もう必要なくなっても自動的にシステムに返すことはありません。これはパフォーマンスの理由からであり、メモリの割り当てと解放はCPUに負担をかける作業です。
JAVAは通常、システムに返す前に未使用のメモリの大きな塊ができるまで待機します。この大きな塊のサイズは、コンピュータの物理メモリのサイズに直接依存します。コンピュータの物理メモリが多いほど、JAVAによって割り当てられるメモリも多くなります。
Terminal Service Plus HTML5 サーバー メモリ使用量
これらの技術的な詳細が、Windowsタスクマネージャーを開いて、Terminal Service Plus HTML5 Serverが多くのメモリを使用していると思ったり、JAVA 32ビットがJAVA 64ビットよりも少ないメモリを使用していると思ったりする理由です。
実際、Terminal Service Plus HTML5 Serverによって実際に使用されるメモリは、開かれたHTML5セッションの数に直接関連しています。コンピュータの利用可能なメモリが多いほど、より多くのHTML5セッションを開くことができます。
HTML5セッションメモリ使用量
HTML5セッションで使用されるメモリは、ユーザーの活動(使用されるアプリケーションやプログラム、Word/Excelと描画集中的なプログラムの違い)およびTerminal Service Plus HTML5サーバーとクライアントコンピュータ間に確立された接続方法に依存します。
一般的な使用ケースでは、HTML5セッションは30 MBのメモリを使用します(標準使用、バイナリウェブソケット接続)。最悪の場合、セッションは最大100 MBのメモリを使用します(集中的な使用、古いブラウザ用の「XHR」フォールバック接続)。
HTTPおよびHTTPSサーバーのリスニングの喪失
各Javaエラーログは、操作に十分なネイティブメモリを示しています。
問題は実際には非常に簡単です。
HTML5セッションが開始されると、報告された値に応じて十分なメモリがあります。
その後、RDPセッション内で、未知のプログラムを起動し、すべてのネイティブメモリを自分のものとして盗みます。
Javaが再度要求すると、それは突然利用できなくなり、この不十分なメモリエラーが発生します。
- Javaランタイム環境が続行するためのメモリが不足しています。
- ネイティブメモリ割り当て(mmap)が234881024バイトをマップできませんでした。エラーの詳細:仮想空間G1# 可能な理由:
- システムは物理RAMまたはスワップスペースが不足しています# このプロセスは圧縮Oopsが有効になっており、Javaヒープがネイティブヒープの成長を妨げている可能性があります
可能な解決策:
- システムのメモリ負荷を軽減する
- 物理メモリまたはスワップ領域を増やす# スワップサポートストレージが満杯かどうかを確認する
- Javaヒープサイズを減少させる (-Xmx/-Xms)
- Javaスレッドの数を減らす # Javaスレッドスタックサイズを減らす (-Xss)
- -XX:ReservedCodeCacheSize=の大きなコードキャッシュを設定します
JVMはゼロベース圧縮Oopsモードで実行されており、このモードではJavaヒープが最初の32GBのアドレス空間に配置されます。Javaヒープのベースアドレスは、ネイティブヒープの成長の最大限界です。
使用してください
-XX:HeapBaseMinAddress
潜在的には、最初からJavaにより多くのネイティブメモリを割り当て、システムにメモリを返さないように強制し、したがって自分自身に割り当てることができます。
しかし、この場合、次の問題に直面することになります:RDPセッションで実行されているプログラムがメモリ不足になる可能性があり、システム全体がクラッシュする可能性があります。
しかし、まだ試すことができます。
-
以下のファイルをNotepadで開いて編集してください: *\Clients\webserver\runwebserver.ini
-
そこでは、次のコマンドライン設定が見つかります。このように:
-Djdk.tls.ephemeralDHKeySize=matched -Djdk.tls.rejectClientInitiatedRenegotiation=true -Dorg.jboss.netty.epollBugWorkaround=true -XX:+UseG1GC -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=10 ************and so on
- runwebserver.iniの全行を削除し、その代わりに以下を追加してください:
-server -javaagent:"%~dp0httpwebs.jar" -Djdk.tls.ephemeralDHKeySize=matched -Djdk.tls.rejectClientInitiatedRenegotiation=true -Dorg.jboss.netty.epollBugContourn=true --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.base/java.lang.reflect=ALL-UNNAMED --add-opens java.base/sun.security.ssl=ALL-UNNAMED --add-opens java.base/java.nio=ALL-UNNAMED --add-opens java.base/jdk.internal.ref=ALL-UNNAMED --add-exports java.prefs/java.util.prefs=ALL-UNNAMED ---add-exports java.base/java.lang.reflect=ALL-UNNAMED --add-exports java.base/sun.security.ssl=ALL-UNNAMED --add-exports java.base/jdk.internal.ref=ALL-UNNAMED --add-exports java.base/java.nio=ALL-UNNAMED
-
AdminTool GUIを介してHTML5サーバーを再起動して変更を適用します。
しかし、その前に、web server\runwebserver.batファイルのプロパティに読み取り専用属性が設定されていないことを確認してください。そうでないと、AdminTool GUIは再起動後にrunwebserver.batを適応できません。
ほとんどの場合、これで十分です。Javaがメモリを使用すると、それをシステムに戻すのではなく、他の用途に割り当てます。したがって、html5service.exeのメモリ使用量は、システムの利用可能なメモリの70%に達する可能性があります。この場合、Javaはクラッシュを停止する可能性があります。しかし、別のプログラムが大量のメモリを消費している場合、代わりにクラッシュする可能性があります。その場合、私たちは無力です。Java HTMLサーバーや他のプログラムを実行するのに十分なメモリがあることを確認する必要があります。
Javaには、Java仮想マシン自体のメモリ割り当てを改善できる-XX:+AggressiveHeapというオプションがあり、そのため*\webserver\runwebserver.iniの最終的な内容が改善される可能性があります。
それはこのように見えるかもしれません:
-XX:+AggressiveHeap -server -javaagent:"%~dp0httpwebs.jar" -Djdk.tls.ephemeralDHKeySize=matched -Djdk.tls.rejectClientInitiatedRenegotiation=true -Dorg.jboss.netty.epollBugWorkaround=true --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.base/java.lang.reflect=ALL-UNNAMED --add-opens java.base/sun.security.ssl=ALL-UNNAMED --add-opens java.base/java.nio=ALL-UNNAMED --add-opens java.base/jdk.internal.ref=ALL-UNNAMED --add-exports java.prefs/ java.util.prefs=ALL-UNNAMED --add-exports java.base/java.lang.reflect=ALL-UNNAMED --add