[wip] Ulimit documentation improvements#4057
Conversation
…mention the scope of ulimit
andf-mongodb
left a comment
There was a problem hiding this comment.
Hi! Thanks for this PR.
I think the key consideration is that ulimit values are already set in the appropriate init scripts if MDB is installed via a package manager (most common install method). Parsing the proc filesystem is for command line invocations (somewhat common), and edits to init scripts are for installations from the TGZ package where the user then additionally decides to write their own init script (least common).
I have been planning to rework this page significantly after the 4.4 GA, to restructure around these three install methods, rather than its present unordered list form.
There's some good stuff in your PR, but I wonder if we should wait on this until I've had a chance to do the restructure. I would be happy to loop you in to review the resulting changes, and I would definitely be using some of your work on the proc filesystem section in the rework: it's solid.
If you wanted to get this out the door before that for some reason, then I'd ask that you limit your changes to the proc filesystem section, and I'll merge that, then address the rest when I get to the rework.
Sound alright? Feel free to reach out directly to discuss further. Thanks again for your work on this!
| .. note:: | ||
|
|
||
| If :binary:`~bin.mongod` or :binary:`~bin.mongos` processes are launched | ||
| using a systemwide process manager such as Upstart or systemd, they may | ||
| be subject to different resource limits. |
There was a problem hiding this comment.
I think this note would be more helpful if it pointed out that ulimit considerations are already handled in MDB init scripts. See the init.d, service, upstart, suse files here:
https://github.com/mongodb/mongo/tree/master/debian
https://github.com/mongodb/mongo/tree/master/rpm
Even brew sets appropriate ulimit values here:
https://github.com/mongodb/homebrew-brew/blob/master/Formula/mongodb-community.rb
So instead of differentiating based on running shell vs system-started shell, I would differentiate via user action required (TGZ install) vs no action required (package manager install).
| following ``bash`` function to return the content of the ``limits`` | ||
| object for a process or processes with a given name: | ||
| The per-process limits in effect for a particular process can be obtained | ||
| via the ``proc`` file system by examining the file located at |
There was a problem hiding this comment.
Singular "file" makes me think that I am checking one config file for all processes. I would recommend something like:
" ... can be obtained via the proc filesystem. Each running process stores its current ulimit values in a limits file located at /proc/<pid>/limits, where ... "
| .. code-block:: sh | ||
|
|
||
| return-limits(){ | ||
| get-limits(){ |
| - If :binary:`~bin.mongod` or :binary:`~bin.mongos` are launched using | ||
| startup scripts, the ``ulimit`` invocation must generally be placed in those | ||
| startup scripts prior to :binary:`~bin.mongod` or :binary:`~bin.mongos` | ||
| invocations. |
There was a problem hiding this comment.
Unless users installed MDB via the TGZ, and are creating their own init scripts (init.d, systemd, upstart), the appropriate ulimit values are already present in init scripts provided with the RPM or DEB file they installed.
It's still valuable to discuss what to do for users with custom scripts (For example, the numactl tabs here https://docs.mongodb.com/manual/administration/production-notes/#configuring-numa-on-linux), but it is the least likely case for our users. I don't think we need anything more than a small mention. So the three options are:
- Run from command line: you must set ulimit via the methods provided on this page.
- Run from our init script: no action
- Installed via TGZ and made your own init script: you must edit your init script to set ulimit
| .. note:: | ||
|
|
||
| On Linux distributions using Upstart, systemd or a similar process | ||
| manager to start :binary:`~bin.mongod` or :binary:`~bin.mongos` processes, | ||
| the resource limits must be configured in the process manager | ||
| as described below. |
There was a problem hiding this comment.
Not necessary, see above.
| The per-process limits in effect for a particular process can be obtained | ||
| via the ``proc`` file system by examining the file located at | ||
| ``/proc/<pid>/limits``, where ``<pid>`` is the process's :term:`PID` or | ||
| process identifier. For example, if :binary:`~bin.mongod` is running as | ||
| PID 1234, the limits in effect for this process can be viewed as follows: | ||
|
|
||
| .. code-block:: sh | ||
|
|
||
| % cat /proc/1234/limits | ||
| Limit Soft Limit Hard Limit Units | ||
| Max cpu time unlimited unlimited seconds | ||
| Max file size unlimited unlimited bytes | ||
| Max data size unlimited unlimited bytes | ||
| Max stack size 8388608 unlimited bytes | ||
| Max core file size 0 unlimited bytes | ||
| Max resident set unlimited unlimited bytes | ||
| Max processes 62913 62913 processes | ||
| Max open files 20000 20000 files | ||
| Max locked memory 16777216 16777216 bytes | ||
| Max address space unlimited unlimited bytes | ||
| Max file locks unlimited unlimited locks | ||
| Max pending signals 62913 62913 signals | ||
| Max msgqueue size 819200 819200 bytes | ||
| Max nice priority 0 0 | ||
| Max realtime priority 0 0 | ||
| Max realtime timeout unlimited unlimited us |
There was a problem hiding this comment.
I think the bulk of this is adequately addressed below in the proc filesystem section, no? Let's link to that section from option 1 (run from command line) above. This method does not apply to method 2 or 3. I would use get-limits() for those two methods to verify limits.
If you like, the /proc/<PID>/limits output could go down there as well, but I think it largely duplicates this output earlier:
|
I can certainly leave this PR until the redesign, but I am having trouble understanding the following:
Whatever values may be set in the init scripts, they may need to be adjusted up (if they are set conservatively and the particular deployment has many resources) or down (if they are set greedily and the particular deployment wants to be constrained). Therefore I would think that simply saying that init scripts that come with MongoDB set the values "appropriately" is not particularly helpful for administrators who need to change those values to suit their environment. |
* DOCSP-24188 clarifying account fields * added commas * formatting
* DOCSP-24188 clarifying account fields * added commas * formatting
* DOCSP-24188 clarifying account fields * added commas * formatting
* DOCSP-24188 clarifying account fields * added commas * formatting
* DOCSP-24188 clarifying account fields * added commas * formatting
/proc/<pid>/limits