Объясните и управляйте упругими поисковыми компонентами памяти - PullRequest
Новая
       24

Объясните и управляйте упругими поисковыми компонентами памяти

0 голосов
/ 30 августа 2018

Я настроил кучу 16 ГБ в моем узле упругого поиска, и узел имеет 36 ГБ в нем упругий поиск Java-процесс потребляет 95% от него. Если мы соберем кучу и не кучу памяти, вместе они не 95%. Я хочу контролировать использование памяти и не хочу, чтобы использование системной памяти превышало 90%.

Ниже приведены результаты ps aux | grepasticsearch 

103       3242 55.0 95.4 208321876 36468416 ?  Sl   00:16 778:35 /usr/bin/java -Xms16g -Xmx16g -XX:MaxDirectMemorySize=16g -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -server -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -Djdk.io.permissionsUseCanonicalPath=true -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Dlog4j.skipJansi=true -XX:+HeapDumpOnOutOfMemoryError -Des.path.home=/usr/share/elasticsearch -cp /usr/share/elasticsearch/lib/elasticsearch-5.1.1.jar:/usr/share/elasticsearch/lib/* org.elasticsearch.bootstrap.Elasticsearch -d -p /var/run/elasticsearch/elasticsearch.pid -Edefault.path.logs=/var/log/elasticsearch -Edefault.path.data=/var/lib/elasticsearch -Edefault.path.conf=/etc/elasticsearch

Ниже приведены результаты jmap -heap 

root@ice-bsd-none-551475:~# jmap -heap 3242
Attaching to process ID 3242, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.5-b02

using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC

Heap Configuration:
   MinHeapFreeRatio         = 40
   MaxHeapFreeRatio         = 70
   MaxHeapSize              = 17179869184 (16384.0MB)
   NewSize                  = 959643648 (915.1875MB)
   MaxNewSize               = 959643648 (915.1875MB)
   OldSize                  = 16220225536 (15468.8125MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):
   capacity = 863698944 (823.6875MB)
   used     = 89336768 (85.19818115234375MB)
   free     = 774362176 (738.4893188476562MB)
   10.343507841547158% used
Eden Space:
   capacity = 767754240 (732.1875MB)
   used     = 82442520 (78.6233139038086MB)
   free     = 685311720 (653.5641860961914MB)
   10.738139329585467% used
From Space:
   capacity = 95944704 (91.5MB)
   used     = 6894248 (6.574867248535156MB)
   free     = 89050456 (84.92513275146484MB)
   7.18564726615864% used
To Space:
   capacity = 95944704 (91.5MB)
   used     = 0 (0.0MB)
   free     = 95944704 (91.5MB)
   0.0% used
concurrent mark-sweep generation:
   capacity = 16220225536 (15468.8125MB)
   used     = 2346399531588267400 (2.237700969303386E12MB)
   free     = 15354485090581 MB
   1.4465887212113964E10% used

31656 interned Strings occupying 4070216 bytes.

Несмотря на то, что общий объем памяти из jmap-heap меньше 20 ГБ, общее использование памяти процессом java составляет 95,4% от результатов команды top.

Я проверил используемую прямую память и использованную карту памяти из jconsole 

Direct memory used = 10798837846(10GB)
Mapped Memory used = 166282997194(166GB)

Я хочу уменьшить общее использование памяти на машине и контролировать общую память этого процесса упругого поиска.

...