استخدام ذاكرة خادم HTML5

يعمل خادم Terminal Service Plus HTML5 على JAVA. يساعد فهم كيفية تعامل JAVA مع الذاكرة في فهم استخدام الذاكرة لخادم Terminal Service Plus HTML5.

الذاكرة المعينة

عندما يعمل Java، فإنه يحاول تخصيص 25% من الذاكرة الفيزيائية للكمبيوتر. هذه الذاكرة "مخصصة" ولكنها لا تستخدم مباشرة - فهي ليست الاستخدام الحقيقي للذاكرة الذي يمكن رؤيته في إدارة المهام في Windows.

منصة JAVA: 32 بت مقابل 64 بت

هناك فرق كبير واحد بين هاتين المنصتين:

JAVA 32 بت لا يمكنه التعامل مع أكثر من 4 جيجابايت من الذاكرة العشوائية حسب التعريف. نظرًا لأنه سيخصص 25% من إجمالي الذاكرة المتاحة، فسوف يخصص في أقصى حد 1 جيجابايت، على افتراض وجود 4 جيجابايت من الذاكرة الفعلية. إذا كانت الذاكرة الفعلية 2 جيجابايت فقط، فسوف يخصص فقط 500 ميجابايت، وهكذا.
JAVA 64-bit يمكنه التعامل مع أكثر من 4 جيجابايت (نظريًا حتى 16 إكساء بايت)، لذا ستعتمد الذاكرة المخصصة فقط على الذاكرة الفعلية.

إدارة ذاكرة JAVA

JAVA هي "آلة افتراضية". يعني أن JAVA تدير إدارة الذاكرة بمفردها. بمجرد أن تخصص JAVA بعض الذاكرة، حتى عندما لا تحتاج إليها بعد الآن، فلن تعيدها تلقائيًا إلى النظام. هذا لأسباب تتعلق بالأداء، حيث إن تخصيص الذاكرة وإلغاء تخصيصها هما مهام تتطلب موارد المعالج.

عادةً ما تنتظر JAVA حتى يكون لديها كمية كبيرة من الذاكرة غير المستخدمة قبل إعادتها إلى النظام. يعتمد حجم هذه الكمية الكبيرة مباشرةً على حجم الذاكرة الفيزيائية للكمبيوتر. كلما زادت الذاكرة الفيزيائية على الكمبيوتر، زادت الذاكرة المخصصة بواسطة JAVA.

استخدام ذاكرة خادم HTML5 لـ Terminal Service Plus

كل هذه التفاصيل الفنية هي السبب في أنه يمكن للمرء فتح إدارة مهام ويندوز والتفكير في أن 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 ميغابايت من الذاكرة (استخدام قياسي، اتصال websockets ثنائي). في أسوأ الحالات، ستستخدم الجلسة ما يصل إلى 100 ميغابايت من الذاكرة (استخدام مكثف، اتصال "XHR" كخيار احتياطي للمتصفحات القديمة).

فقدان استماع خادم HTTP و HTTPS

تشير كل سجلات أخطاء Java إلى وجود ذاكرة أصلية كافية للتشغيل.

المشكلة في الواقع بسيطة جدًا.
عندما تبدأ جلسة HTML5، يكون هناك ذاكرة كافية وفقًا للقيم المبلغ عنها.
ثم، داخل جلسة RDP، يبدأ برنامجًا غير معروف ويسرق كل الذاكرة الأصلية لنفسه.

عندما تطلب Java ذلك مرة أخرى، لم يعد متاحًا فجأة، مما يتسبب في حدوث خطأ في الذاكرة غير الكافية.

لا توجد ذاكرة كافية لاستمرار بيئة تشغيل Java.
فشل تخصيص الذاكرة الأصلية (mmap) في تعيين 234881024 بايت. تفاصيل الخطأ: المساحة الافتراضية G1# الأسباب المحتملة:
نفد النظام من ذاكرة الوصول العشوائي الفعلية أو مساحة التبادل# هذه العملية تعمل مع تمكين Compressed Oops، وقد يكون كومة Java تعيق نمو الكومة الأصلية

الحلول الممكنة:

قلل من حمل الذاكرة على النظام
زيادة الذاكرة الفعلية أو مساحة التبادل# تحقق مما إذا كانت مساحة التخزين لدعم التبادل ممتلئة
تقليل حجم كومة جافا (-Xmx/-Xms)
تقليل عدد خيوط Java # تقليل حجم مكدس خيوط Java (-Xss)
قم بتعيين ذاكرة تخزين مؤقتة أكبر للشيفرة باستخدام -XX:ReservedCodeCacheSize=

يعمل JVM في وضع Oops المضغوط القائم على الصفر، حيث يتم وضع كومة Java في أول 32 جيجابايت من مساحة العناوين. العنوان الأساسي لكومة Java هو الحد الأقصى لنمو الكومة الأصلية.
يرجى الاستخدام -XX:HeapBaseMinAddress

من المحتمل أن تتمكن من تخصيص المزيد من الذاكرة الأصلية لجافا من البداية وإجبارها على التوقف عن إعادة الذاكرة إلى النظام، وبالتالي تخصيصها لنفسها.
ومع ذلك، في هذه الحالة، ستواجه المشكلة التالية: قد تنفد الذاكرة من البرامج التي تعمل في جلسة RDP، وقد يتعطل النظام بالكامل.

لكن يمكنك المحاولة.

افتح وعدل الملف التالي باستخدام المفكرة: *\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

أعد تشغيل خادم HTML5 عبر واجهة AdminTool لتطبيق التغييرات.
(لكن قبل القيام بذلك، تأكد من أن ملف web server\runwebserver.bat ليس لديه خاصية القراءة فقط محددة في خصائصه. خلاف ذلك، لن يتمكن واجهة AdminTool من تعديل runwebserver.bat بعد إعادة التشغيل.)

في معظم الحالات، يجب أن يكون هذا كافيًا. بمجرد أن يستخدم Java الذاكرة، سيخصصها لاستخدامات أخرى بدلاً من إعادتها إلى النظام. لذلك، قد يصل استخدام الذاكرة لـ html5service.exe إلى 70% من الذاكرة المتاحة للنظام. في هذه الحالة، يجب أن يتوقف Java عن التعطل. ومع ذلك، إذا كان برنامج آخر يستهلك كمية كبيرة من الذاكرة، فقد يتعطل بدلاً من ذلك. في هذه الحالة، نحن بلا حول ولا قوة؛ يجب عليك التأكد من وجود ما يكفي من الذاكرة لتشغيل خادم Java HTML بالإضافة إلى برامج أخرى.

هناك خيار في Java يسمى -XX:+AggressiveHeap يمكن أن يحسن تخصيص الذاكرة لآلة Java الافتراضية نفسها، وبالتالي المحتوى النهائي ل *\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