Can you tell me a little bit about this file, or give me a link I can chew on to understand where it should be installed? :)

Also, if it goes into a "docker.service.d" directory (like it appears to), wouldn't it make more sense to name it "limits.conf" ?

sorry .. haven't tested this yet, sent it out too soon :\

Good to know :)

@tianon so latest version works

Max processes 1048576 1048576 processes
Max open files 1048576 1048576 files

So how about some information about where and how to use this? :) Is there somewhere in /usr/lib/systemd this can be installed by packagers, or is this meant for users to put into /etc/systemd?

whoops sorry ..(speaking with fedora as reference) there's /usr/lib/systemd/system/docker.service installed via rpm. This new addition would also be in the same dir as docker.service (so /usr/lib/systemd/system/docker.service.d/limits.conf)

to see the difference, just add this and then do

systemctl daemon-reload
systemctl restart docker
cat /proc/`pidof docker`/limits

Perfect, thanks. That's exactly the information I was hoping for. 👍

Also, for posterity: http://www.freedesktop.org/software/systemd/man/systemd.exec.html#LimitCPU=

So, why not just use "infinity", if we're going insanely high anyways? :)

/devilsadvocate

umm, container bombs? ;)

Fair enough, but won't those take out the host anyways? Especially with such a high limit?

i was given that number by a perf eng guy, so I'd say that's a tested limit, but if you'd prefer to wait until further info/confirmation

Hi folks, I'm the perf eng guy.

According to http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Unit%20Load%20Path

We should drop the override here:
/etc/systemd/system/docker.service.d/limits.conf

Hi @tianon there's nothing special about 1048576. In fact it's higher than is actually necessary (at the moment). It is however what we've tested with, and as @lsm5 mentioned, we haven't hit any issues with these 2 particular limit changes.

Regarding other LimitXYZ knobs for systemd like LimitCPU: right now we are trying to identify the smallest set of changes that are needed for scaling vertically. No shotgun approach, just the minimum, technically verified set.

We'll send RFC mail or patches if we need/recommend other knobs, as we did for this:
https://groups.google.com/forum/#!msg/docker-user/k5hqpNg8gwQ/-00mvrB2nIkJ

aah my bad on the override install location, sorry about that

Ah, so this is something that shouldn't be installed by the package, but should be installed by users if they want it?

@lsm5 can correct me if I'm wrong about the implementation, but AIUI, the intent is to have this systemd unit file override exist in the upstream repo (for anyone's use), then our packaging will take care of actually enabling it in the distribution.

In that case it sounds like it ought to be added to "docker.service" directly, and then overridden by users in "/etc/systemd/system/docker.service.d/limits.conf", like the other bits of "docker.service", but I could certainly be wrong.

As an example, "radvd.service" from Gentoo: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/radvd/files/radvd.service (which sets "LimitNOFSIZE" and "CPUSchedulingPolicy").

@jeremyeder yup that was the intent

@tianon yup this works ... i'll update this PR

lgtm

@tianon welcome ;)

Thanks @lsm5, LGTM

Thanks for looking it over too, @philips :D

Now we've got to figure out how to add the same limit in the other init files in a clean way that's just as easy for users to override, but that's a completely orthogonal issue. :)

This is still an issue for the sysvinit script.