search

elastic / elasticsearch

Free and Open Source, Distributed, RESTful Search Engine
https://www.elastic.co/products/elasticsearch
Other
69.56k stars 24.62k forks source link

redhat init script does not export ES_MIN_MEM and ES_MAX_MEM #4917

Closed teancom closed 10 years ago

teancom commented 10 years ago

By not doing so, setting the variables in /etc/sysconfig/elasticsearch does not actually do what is necessary - override the Xms and Xmx values on startup.

spinscale commented 10 years ago

Hey,

adding this is easy. Wondering what made you opt for ES_MIN_MEM and ES_MAX_MEM instead of ES_HEAP_SIZE? Any specific use case you are covering?

teancom commented 10 years ago

Well, I hadn’t looked at the ES_HEAP_SIZE variable before I started - I’m used to tuning the Xms and Xmx values with other java projects I’m the sysad on. And then when I did the thing I was told (via comments/doc for the /etc/sysconfig/elasticsearch file) , it didn’t work. Knowing about ES_HEAP_SIZE, though, I’ll probably go back to my developers and ask if they’re okay with using that instead.

—
David Bishop

On Jan 28, 2014, 3:16:36 AM, Alexander Reelsen notifications@github.com wrote:

Hey,

adding this is easy. Wondering what made you opt for ES_MIN_MEM and ES_MAX_MEM instead of ES_HEAP_SIZE? Any specific use case you are covering?

— Reply to this email directly or view it on GitHub(https://github.com/elasticsearch/elasticsearch/issues/4917#issuecomment-33458573).

spinscale commented 10 years ago

I'll close this one. I think ES_HEAP_SIZE is sufficient to be exposed. More options often lead to more confusion and I dont consider it any gain, when those are exposed. Any objections on your side? Happy to get different feedback to discuss.

JPvRiel commented 9 years ago

Hi there. I suggest this be re-opened, or the issue be re-created. Essentially the export issue is in debian too. One of two things need to be done in my view:

Note, in my VM use case, I very much did want use ES_MIN_MEM and ES_MAX_MEM and thought it was useful (but it didn't work).

Setup documentation says the following

ES_HEAP_SIZE : The heap size to start with https://github.com/elasticsearch/elasticsearch/blob/master/docs/reference/setup/as-a-service.asciidoc

I've just seen my 1.1.1 cluster die because ES_HEAP_SIZE actually means the min and max heap size, not just the start size

And this

The ES_HEAP_SIZE environment variable allows to set the heap memory that will be allocated to elasticsearch java process. It will allocate the same value to both min and max values, though those can be set explicitly (not recommended) by setting ES_MIN_MEM (defaults to 256m), and ES_MAX_MEM (defaults to 1g). https://github.com/elasticsearch/elasticsearch/blob/master/docs/reference/setup/configuration.asciidoc

Apart from fixing the missing exports for ES_MIN_MEM and ES_MAX_MEM, nowhere does it explain that ES_HEAP_SIZE will supersede the ES_MIN_MEM and ES_MAX_MEM settings.

I've read that being greedy and setting ES_HEAP_SIZE to grab 50% of system RAM is advised for better performance. However, if like me, one hast to run elasticsearch in a shared VM environment (yes, not ideal, but that's what we've got available for now), then I certainly don't want to entertain this premature memory hog mentality of ES_HEAP_SIZE=50% and rather, I want ES_MIN_MEM and ES_MAX_MEM to work as advertised and supersede the ES_HEAP_SIZE setting.

I've looked at https://github.com/elasticsearch/elasticsearch/blob/master/bin/elasticsearch.in.sh and at the init script /etc/init.d/elasticsearch as well as /etc/default/elasticsearch shipped with .deb download for ES v1.1.1 and ES v1.4.0 Observations

I've patched all of this in my install such that ES_MIN_MEM and ES_MAX_MEM supersede ES_HEAP_SIZE and work with debian /etc/default and /etc/init.d. If ES_MIN_MEM and ES_MAX_MEM are still supposed to be supported options, then I'm happy to try submit and commit this patch, but I've not yet tested how having ES_MIN_MEM and ES_MAX_MEM set will mess with the option of MAX_LOCKED_MEMORY and bootstrap.mlockall: true in elasticsearch.yml.

clintongormley commented 9 years ago

Hi @JPvRiel

MIN/MAX are indeed deprecated options, and if you have nodes dieing because they try to allocate all the heap initially, then you'll just have them dieing later on when the JVM tries to allocate it's MAX memory setting later on.

I've not yet tested how having ES_MIN_MEM and ES_MAX_MEM set will mess with the option of MAX_LOCKED_MEMORY and bootstrap.mlockall: true in elasticsearch.yml.

It won't play well at all. mlockall needs to lock all the memory into RAM at startup.

i suggest that a better approach is just to set ES_HEAP_SIZE to the maximum amount that you can safely allocate on that box, otherwise you're letting yourself in for a world of pain later on. Also, remember that Elasticsearch and Lucene need generous amounts of file system cache for them to function with decent performance. It doesn't sound like you're leaving any space for file system cache, which means that you're going to have to hit disk all the time. Performance will not be good in this case.

JPvRiel commented 9 years ago

Hey @Clintongormley, appreciate the reply. Sounds like I should find the time to submit a configuration documention patch which updates and clarifies it a bit?

Suppose I'm flogging a dead horse here (given 'closed' issue). I totally buy the recommendations made for ES_HEAP_SIZE in a production and dedicated hardware context - no disagreement there.

That said, in testing and dev workspaces with virtualized/shared infrastructure, I'm sticking to my preference of wanting memory only allocated as needed, and should probably drop my use of bootstrap.mlockall, MAX_LOCKED_MEMORY and ES_HEAP_SIZE. Instead I can use JAVA_OPTS with -Xms and -Xmx to have my way.

Some more interesting notes after a bit of reading

Anyhow, plan to look into this more out of interest, but for now, think I've figured out what to do for my use case (shared VM environment).