I discovered ElasticSearch few weeks ago and I use it for a new
project. It's a great tool !
On my laptop (Ubuntu), I have no problem with ES.
But when I try to start ES on a server (Debian), the server totally
freezes and I have to hard-reboot it.
I use the ES out of the box : http://github.com/downloads/elasticsearch/elasticsearch/elasticsearch-0.13.1.tar.gz
without configuration for the moment.
And I start it with bin/elasticsearch -f
(I also tried with the service package, same problem)
But when I try to start ES on a server (Debian), the server totally
freezes and I have to hard-reboot it.
What version of Java are you using? If it's not the official Sun Java,
you may run into problems (based on my experience with other Java
software, like Eclipse)
But when I try to start ES on a server (Debian), the server totally
freezes and I have to hard-reboot it.
What version of Java are you using? If it's not the official Sun Java,
you may run into problems (based on my experience with other Java
software, like Eclipse)
I use openjdk-6-jre
I just tried with sun-java6-jre and I've the same pb.
With bootstrap.mlockall set to false, ES starts !
I have this exception, but ES is usable :
Exception in thread "elasticsearch[Jubilee][tp]-pool-1-thread-1"
org.elasticsearch.discovery.zen.ping.ZenPingException: Failed to send
ping request over multicast
Why do ES crashes when bootstrap.mlockall is set to true ? It seems to
be dangerous... (It costs me 1 server, and I've lost lot of data)
But when I try to start ES on a server (Debian), the server totally
freezes and I have to hard-reboot it.
What version of Java are you using? If it's not the official Sun Java,
you may run into problems (based on my experience with other Java
software, like Eclipse)
I am not sure why it crashes to be honest, it just calls mlockall, it
shouldn't cause the OS to crash completely. In any case, let me turn this to
be off by default, and allow people to turn it on.
I use openjdk-6-jre
I just tried with sun-java6-jre and I've the same pb.
With bootstrap.mlockall set to false, ES starts !
I have this exception, but ES is usable :
Exception in thread "elasticsearch[Jubilee][tp]-pool-1-thread-1"
org.elasticsearch.discovery.zen.ping.ZenPingException: Failed to send
ping request over multicast
Why do ES crashes when bootstrap.mlockall is set to true ? It seems to
be dangerous... (It costs me 1 server, and I've lost lot of data)
But when I try to start ES on a server (Debian), the server totally
freezes and I have to hard-reboot it.
What version of Java are you using? If it's not the official Sun Java,
you may run into problems (based on my experience with other Java
software, like Eclipse)
My two cents... This feature makes ES performance very reliable and
fixed some performance spikes that we encountered. I think it should
be defaulted to on.
It seems to me that the setting only causes problems when misused.
Along these same lines, what happens without this setting and someone
tries to allocate more mem than their system has and their JVM heap
reaches that point? I'd assume massive swapping leading to performance
degradation, which would only happen after hours or days of up time.
This seems like a ticking time bomb that would be much worse than fail
to start up.
Best case would be to check system memory before the mlockall call and
then gracefully exit with a descriptive error that you don't have
enough mem on your system.
Btw, this should probably be listed as a breaking change in the 0.14
release notes.
The problem with having this setting set to true is the fact that people
have reported that it got to a stage where the OS crashed completely. Not
sure why it happened, but ES should not cause that with an out of the box
setting. Checking if there is enough memory is a good start, there is no API
for that in Java, but can try and use native code, I can play around with it
and see how it goes.
My two cents... This feature makes ES performance very reliable and
fixed some performance spikes that we encountered. I think it should
be defaulted to on.
It seems to me that the setting only causes problems when misused.
Along these same lines, what happens without this setting and someone
tries to allocate more mem than their system has and their JVM heap
reaches that point? I'd assume massive swapping leading to performance
degradation, which would only happen after hours or days of up time.
This seems like a ticking time bomb that would be much worse than fail
to start up.
Best case would be to check system memory before the mlockall call and
then gracefully exit with a descriptive error that you don't have
enough mem on your system.
Btw, this should probably be listed as a breaking change in the 0.14
release notes.
The problem with having this setting set to true is the fact that people
have reported that it got to a stage where the OS crashed completely. Not
sure why it happened, but ES should not cause that with an out of the box
setting. Checking if there is enough memory is a good start, there is no API
for that in Java, but can try and use native code, I can play around with it
and see how it goes.
My two cents... This feature makes ES performance very reliable and
fixed some performance spikes that we encountered. I think it should
be defaulted to on.
It seems to me that the setting only causes problems when misused.
Along these same lines, what happens without this setting and someone
tries to allocate more mem than their system has and their JVM heap
reaches that point? I'd assume massive swapping leading to performance
degradation, which would only happen after hours or days of up time.
This seems like a ticking time bomb that would be much worse than fail
to start up.
Best case would be to check system memory before the mlockall call and
then gracefully exit with a descriptive error that you don't have
enough mem on your system.
Btw, this should probably be listed as a breaking change in the 0.14
release notes.
Agreed, thats what I meant when I said going native (ES already uses Sigar)
:). Though, total mem might not be enough, but available mem should be
checked.
The problem with having this setting set to true is the fact that people
have reported that it got to a stage where the OS crashed completely. Not
sure why it happened, but ES should not cause that with an out of the box
setting. Checking if there is enough memory is a good start, there is no
API
for that in Java, but can try and use native code, I can play around with
it
and see how it goes.
My two cents... This feature makes ES performance very reliable and
fixed some performance spikes that we encountered. I think it should
be defaulted to on.
It seems to me that the setting only causes problems when misused.
Along these same lines, what happens without this setting and someone
tries to allocate more mem than their system has and their JVM heap
reaches that point? I'd assume massive swapping leading to performance
degradation, which would only happen after hours or days of up time.
This seems like a ticking time bomb that would be much worse than fail
to start up.
Best case would be to check system memory before the mlockall call and
then gracefully exit with a descriptive error that you don't have
enough mem on your system.
Btw, this should probably be listed as a breaking change in the 0.14
release notes.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.