I'm not sure we should do this, because it also impacts kernel memory utilization (all the issues listed in the documentation). If we are going to change this, we should indicate (as a comment) how much memory this will require.

@jawnsy @mterhar From the Slack conversation provided in the PR description, it sounds like we shouldn't recommend the max? Could we up this number without getting into the billions (if so, what's a good number? 2.5 million-ish as Kyle suggested?) , plus add the following information?

Each "watch" costs roughly 90 bytes on a 32bit kernel, and roughly 160 bytes on a 64bit one.

Maybe the solution is to make it an env var, add a comment with a calculation of memory usage, and use a larger default. 2 or 4 million does seem more tractable

I think 2 mil is a good place, but is there a reason to use an env var in this instance? Pardon my ignorance, but when I was looking at how to set one up for a container, it seemed to be adding complexity in this case.

Also, which memory allocation should be bumped, the requests or the limits?

The memory is kernel memory, and not accounted for in the memory control group, hence it isn't reflected in the request/limit settings. This means that large values can allow a user to consume all memory on the system. I've updated the example to default to 10 million watches, which is a large number and still a reasonable default.

I think 2 mil is a good place, but is there a reason to use an env var in this instance? Pardon my ignorance, but when I was looking at how to set one up for a container, it seemed to be adding complexity in this case.

Also, which memory allocation should be bumped, the requests or the limits?