кластер из 3нод елк. По параметрами 64Гб ОЗУ, 18 ядер. На каждую ноду по 400 шардов. Последнюю неделю на одной из нод в логах стали валиться ошибки:
[2023-08-28T12:39:30,774][WARN ][o.e.m.j.JvmGcMonitorService] [elasticsearch] [gc][young][4390][536] duration [1s], collections [1]/[2s], total [1s]/[1.9m], memory [15.3gb]->[9.5gb]/[30gb], all_pools {[young] [5.9gb]->[64mb]/[0b]}{[old] [8.8gb]->[8.9gb]/[30gb]}{[survivor] [603.4mb]->[526.7mb]/[0b]}
[2023-08-28T12:39:30,774][WARN ][o.e.m.j.JvmGcMonitorService] [elasticsearch] [gc][4390] overhead, spent [1s] collecting in the last [2s]
Эта же нода висит в 100 загрузке CPU. Куда копать, что смотреть ?
Очевидно, что проблема в сборщике мусора gc, но не до конца понимаю куда смотреть, чтобы найти причину такого поведения. Может кто сталкивался с чем то похожим
Вы настройки GC как-нибудь меняли? Шесть гб многовато для янга выглядит
ELK достался по наследству. Точно сказать не могу, но вот текущие настройки в jvm.options # Xms represents the initial size of total heap space # Xmx represents the maximum size of total heap space -Xms30g -Xmx30g ## GC configuration 8-13:-XX:+UseConcMarkSweepGC 8-13:-XX:CMSInitiatingOccupancyFraction=75 8-13:-XX:+UseCMSInitiatingOccupancyOnly ## optimizations # disable calls to System#gc -XX:+DisableExplicitGC # pre-touch memory pages used by the JVM during initialization -XX:+AlwaysPreTouch ## basic -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 -Dio.netty.recycler.maxCapacityPerThread=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Dlog4j.skipJansi=true -XX:+HeapDumpOnOutOfMemoryError
Попробуйте использовать jdk более новый и +ParallelGC вместо +UseConcMarkSweepGC
Обсуждают сегодня