Proper way to set max file descriptors


ksd2kd

Recommended Posts

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

Link to comment

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.

Link to comment
  • 1 year later...
  • 2 months later...

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 by JohanSF
  • Like 1
Link to comment
  • 10 months later...

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...

 

 

 

Link to comment
  • 8 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.