On Tue, Feb 12, 2019 at 06:09:36AM CST, Howard Chu wrote:
Zev Weiss wrote:
Couldn't one s/running with larger limits/consuming more resources/ and
s/system administration/software development/ and produce an equally valid
argument
though? (If anything, larger-than-necessary limits seem the more justifiable
of the two to me -- it allows for future growth, which can be hard to predict.)
slapd is using the resources that the system says it is able to use.
More to the crux of the matter: why does slapd need to preallocate all OPEN_MAX
possible connection info records at once instead of dynamically as connections
are actually created?
Already answered.
http://www.openldap.org/lists/openldap-technical/201902/msg00011.html
I've actually been bitten by the inverse problem when slapd ran up against my
distro's default FD limit (causing no small amount of grief to the various
client
systems on my network). I of course remedied this by cranking up said limit a
fair amount, but the number I chose was basically just a hand-wavy,
seat-of-the-pants guess at something that would last a while before I had to
tweak it again, and thus means that slapd's going to be sitting on significantly
more memory than it really needs.
So as an administrator I'm left with the question of how to balance slapd's
file descriptor requirements against my desire to not have it tying up a bunch
of
memory it's never actually going to use. It seems like that balancing act
would be a lot easier if slapd could dynamically allocate memory for
connections.
It's not tying up a bunch of memory. It's using up some address space, but if
it is indeed
unused, the OS will not dedicate any actual RAM to that address space.
Andreas's initial message showed a pretty large difference in top's RES
column -- wouldn't that indicate that that virtual address space is in
fact backed by actual allocated physical pages?
Zev
