Revert max-worker-connections default value

[aledbf]

What this PR does / why we need it:

Avoid increase of the RAM utilization on idle.

• Add an option to automatically set worker_connections based on worker_rlimit_nofile #3604 (comment)
• Add an option to automatically set worker_connections based on worker_rlimit_nofile #3604 (comment)

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aledbf

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [aledbf]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ramnes]

I'd be in favor of defining the same default value for max-worker-open-files. I don't think that it makes sense to have a max-worker-open-files depending on the system configuration with a hard coded max-worker-connections at the same time.

Also, the default limit of opened files is 1024 on most systems, so we should avoid using a higher value without checking the limit first, or the user might experience nasty things in production when scaling up.

[ramnes]

Suggested change

	|[map-hash-bucket-size](#max-hash-bucket-szie)|int|64|
	|[map-hash-bucket-size](#max-hash-bucket-size)|int|64|

[ramnes]

How do we define what is an acceptable or non-acceptable default RAM usage? It doesn't seems bad to me that if the server is configured to have a huge maximum of opened files, Nginx leverages that; then if some users want less RAM usage on idle, we could just advise them to reduce max-worker-open-files at the cost of a concurrency penalty.

If we want to base all the default settings on the available RAM, I feel that it really gets much more difficult. Doing this properly would require a available-ram-usage-ratio option or something like, which would calculate a good value for worker_connections and worker_rlimit_nofile based on the memory size of one event, on the total available RAM, and on the system's maximum number of opened files.

[aledbf]

How do we define what is an acceptable or non-acceptable default RAM usage?

Right now, any considerable deviation from what is provided now is not acceptable. Keep in mind many users have CPU/RAM limit in place. A change like this one could break existing deployments

Edit: the first part sounds a bit extreme 😄

[ramnes]

Makes sense. What would you think of 1/ putting that default value on max-worker-open-files but keeping 0 on max-worker-connections, and 2/ adding a check on top of this diff to verify that the value is not superior to the system maximum number of opened files, and if it is, to use that maximum? That would answer my concerns from my first comment here.

[aledbf]

@ramnes right now we need to release 0.22. After that, we can try to improve the defaults but only max-worker-connections affects memory usage.

[ramnes]

If you put 16384 as default for max-worker-open-files and keep max-worker-connections to 0, it will have the desired effect on RAM usage since max-worker-connections will take max-worker-open-files value.

[aledbf]

If you put 16384 as default for max-worker-open-files and keep max-worker-connections to 0, it will have the desired effect on RAM usage since max-worker-connections will take max-worker-open-files value.

As I said, we can review this after the release. Right now I need at least two days in production before releasing a new version. I prefer to revert one default value than changing two. We already know how it behaves with the change in this PR.

[ramnes]

I'd suggest keeping an explanation on what 0 means, even if it's not the default anymore:

Suggested change

	_**default:**_ 16384
	0 will use the value of [max-worker-open-files](#max-worker-open-files).
	_**default:**_ 16384

[aledbf]

Good idea. done