I'm getting an error while starting elasticsearch via docker

max file descriptors [40960] for elasticsearch process is too low, increase to at least [65536]
max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

What's the right way to tweak those params? I've looked around but didn't find a definitive answer.

 

Should I just add this to /boot/config/go?

ulimit -n 65536
sysctl -w vm.max_map_count=262144

 

unRAID v6.3.2

Not sure but you may have to run those commands within the docker container environment.  There a way to exec a shell within it, possibly in the Docker FAQ.  But probably better built into the container startup somewhere.  Try asking the elasticsearch container author to add it.

Yeah, I checked that -> ELK Stack Prerequisites These settings need to be made at the host level.

 

Do you know if that go script is the right place for setting kernel parameters like these?  

Any word on this?

@Jclendineng

I just added the commands to a user script per BRiT

What commands are you using? I can't seem to get it to stick.  Thanks in advance!

You need to install the 'CA User Scripts' plugin and create a script that will run on array startup. The plugin has a nice help section that will walk you thru it.

For everyone else, he meant to say:

 

Add a script named vm.max_map_count, and the contents being "vm.max_map_count=262144" and set to start on array start.

 

I added some help on the other thread concerning running the ELK stack.

Thank you for this.

 

Yet doing 'ulimit -n 65536' on the host, I still get the error:

max file descriptors [40960] for elasticsearch process is too low, increase to at least [65536]

My guess now is that I have to do that command in the elasticsearch container, how can I pass it in the edit section of the docker container?


EDIT: Add '--ulimit nofile=65536:65536' in the Extra Parameters field when you edit the docker container.

Edited November 14, 20187 yr by JohanSF

A few things to bear in mind here guys:

 

1) Setting a resource limit via the ulimit command will only make that new limit available to subsequent commands executed in that same shell - i.e. ulimit *only* affects the shell session as it's actually a built-in shell command. Little hint try running finding a ulimit binary and you'll see it doesn't exist (which ulimit) - this normally hints to shell related commands, command aliases or shell functions.

 

2) As noted by @JohanSF the correct way to adjust resource limits for containers is as per his note stating you should add the --ulimit ... to the Extra Parameters (see his post for details, I am paraphrasing).

 

3) As UNRAID uses slackware as it's base distro/upstream, then unless there is something very customized for the environment like the filesystem or loading the boot disk into RAM and /boot/config etc, that actually Slackware's manuals/wikis are relevant, although you will need to test out what gets persisted across boots if you do not already know, and that given that it's Slack the normal way to apply ulimit is via the /etc/initscript file. This is the script that is used by init to then run all of the startup scripts etc. https://slackwiki.com/Resource_Limits

 

4) Usual warnings apply - make sure you backup the file first, and then execute it with something like bash again as the fourth parameter to the file so you can then run ulimit again to a) make sure you haven't broken the file, and b) make sure you are getting the values you expect  

 

Caveat emptor...

 

 

 

Sorry to bring this thread back up, but I still cant figure this out. Which way is the proper way?