Not able to start the elasticsearch

Hi Team,
I have started elasticsearch using this command
etc/init.d# ./elasticsearch start
[ ok ] Starting elasticsearch (via systemctl): elasticsearch.service.

but cant able to access the elasticsearch

facing this error

emory: 4k page, physical 8070856k(1262412k free), swap 4882428k(4856492k free)
CommandLine flags: -XX:+AlwaysPreTouch -XX:CMSInitiatingOccupancyFraction=75 -XX:ErrorFile=/var/log/elasticsearch/hs_err_pid%p.log -XX:GCLogFileSize=67108864 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/lib/elasticsearch -XX:InitialHeapSize=1073741824 -XX:MaxHeapSize=1073741824 -XX:MaxNewSize=174485504 -XX:MaxTenuringThreshold=6 -XX:NewSize=174485504 -XX:NumberOfGCLogFiles=32 -XX:OldPLABSize=16 -XX:OldSize=348971008 -XX:-OmitStackTraceInFastThrow -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:ThreadStackSize=1024 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseGCLogFileRotation -XX:+UseParNewGC
2018-11-22T12:28:42.549+0530: 0.342: Total time for which application threads were stopped: 0.0000738 seconds, Stopping threads took: 0.0000214 seconds
2018-11-22T12:28:42.566+0530: 0.359: Total time for which application threads were stopped: 0.0000730 seconds, Stopping threads took: 0.0000220 seconds
2018-11-22T12:28:42.593+0530: 0.387: Total time for which application threads were stopped: 0.0000653 seconds, Stopping threads took: 0.0000092 seconds
2018-11-22T12:28:42.645+0530: 0.438: Total time for which application threads were stopped: 0.0000833 seconds, Stopping threads took: 0.0000132 seconds
2018-11-22T12:28:42.837+0530: 0.630: Total time for which application threads were stopped: 0.0001258 seconds, Stopping threads took: 0.0000130 seconds
2018-11-22T12:28:42.838+0530: 0.631: Total time for which application threads were stopped: 0.0000765 seconds, Stopping threads took: 0.0000076 seconds
2018-11-22T12:28:42.846+0530: 0.639: Total time for which application threads were stopped: 0.0001171 seconds, Stopping threads took: 0.0000127 seconds
2018-11-22T12:28:42.852+0530: 0.645: Total time for which application threads were stopped: 0.0001227 seconds, Stopping threads took: 0.0000245 seconds
2018-11-22T12:28:42.861+0530: 0.654: Total time for which application threads were stopped: 0.0001108 seconds, Stopping threads took: 0.0000094 seconds
2018-11-22T12:28:42.913+0530: 0.706: Total time for which application threads were stopped: 0.0001370 seconds, Stopping threads took: 0.0000216 seconds
2018-11-22T12:28:43.180+0530: 0.973: Total time for which application threads were stopped: 0.0001072 seconds, Stopping threads took: 0.0000093 seconds
2018-11-22T12:28:43.343+0530: 1.136: Total time for which application threads were stopped: 0.0011267 seconds, Stopping threads took: 0.0009115 seconds
2018-11-22T12:28:43.374+0530: 1.167: Total time for which application threads were stopped: 0.0001877 seconds, Stopping threads took: 0.0000228 seconds
2018-11-22T12:28:43.386+0530: 1.179: Total time for which application threads were stopped: 0.0001922 seconds, Stopping threads took: 0.0000398 seconds
Heap
par new generation total 153344K, used 114606K [0x00000000c0000000, 0x00000000ca660000, 0x00000000ca660000)
eden space 136320K, 84% used [0x00000000c0000000, 0x00000000c6febbd0, 0x00000000c8520000)
from space 17024K, 0% used [0x00000000c8520000, 0x00000000c8520000, 0x00000000c95c0000)
to space 17024K, 0% used [0x00000000c95c0000, 0x00000000c95c0000, 0x00000000ca660000)
concurrent mark-sweep generation total 878208K, used 0K [0x00000000ca660000, 0x0000000100000000, 0x0000000100000000)
Metaspace used 17205K, capacity 17660K, committed 17920K, reserved 1064960K
class space used 2082K, capacity 2270K, committed 2304K, reserved 1048576K
~
~

can anyone help me to resolve this issue?

Please do not ping people not already involved in the thread. As this forum is manned by volunteers I would also ask you to be patient. If you have not received any reply to your thread after 2-3 business days, it is generally fine to bump the issue.

Okay @Christian_Dahlqvist

Can you please post the contents of your jvm.options file?

Hi @rjernst,

This is my jvm.options contents ,

JVM configuration

################################################################

IMPORTANT: JVM heap size

################################################################

You should always set the min and max JVM heap

size to the same value. For example, to set

the heap to 4 GB, set:

-Xms4g

-Xmx4g

See https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html

for more information

################################################################

Xms represents the initial size of total heap space

Xmx represents the maximum size of total heap space

-Xms1g
-Xmx1g

################################################################

Expert settings

################################################################

All settings below this section are considered

expert settings. Don't tamper with them unless

you understand what you are doing

################################################################

GC configuration

-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly

optimizations

pre-touch memory pages used by the JVM during initialization

-XX:+AlwaysPreTouch

basic

explicitly set the stack size

-Xss1m

set to headless, just in case

-Djava.awt.headless=true

ensure UTF-8 encoding by default (e.g. filenames)

-Dfile.encoding=UTF-8

use our provided JNA always versus the system one

-Djna.nosys=true

turn off a JDK optimization that throws away stack traces for common

exceptions because stack traces are important for debugging

-XX:-OmitStackTraceInFastThrow

flags to configure Netty

-Dio.netty.noUnsafe=true
-Dio.netty.noKeySetOptimization=true
-Dio.netty.recycler.maxCapacityPerThread=0

log4j 2

-Dlog4j.shutdownHookEnabled=false
-Dlog4j2.disable.jmx=true

-Djava.io.tmpdir=${ES_TMPDIR}

heap dumps

generate a heap dump when an allocation from the Java heap fails

heap dumps are created in the working directory of the JVM

-XX:+HeapDumpOnOutOfMemoryError

specify an alternative path for heap dumps; ensure the directory exists and

has sufficient space

-XX:HeapDumpPath=/var/lib/elasticsearch

specify an alternative path for JVM fatal error logs

-XX:ErrorFile=/var/log/elasticsearch/hs_err_pid%p.log

JDK 8 GC logging

8:-XX:+PrintGCDetails
8:-XX:+PrintGCDateStamps
8:-XX:+PrintTenuringDistribution
8:-XX:+PrintGCApplicationStoppedTime
8:-Xloggc:/var/log/elasticsearch/gc.log
8:-XX:+UseGCLogFileRotation
8:-XX:NumberOfGCLogFiles=32
8:-XX:GCLogFileSize=64m

JDK 9+ GC logging

9-:-Xlog:gc*,gc+age=trace,safepoint:file=/var/log/elasticsearch/gc.log:utctime,pid,tags:filecount=32,filesize=64m

due to internationalization enhancements in JDK 9 Elasticsearch need to set the provider to COMPAT otherwise

time/date parsing will break in an incompatible way for some date patterns and locals

9-:-Djava.locale.providers=COMPAT

temporary workaround for C2 bug with JDK 10 on hardware with AVX-512

10-:-XX:UseAVX=2

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.