Why is /proc/sys/net/ipv4/ip_local_port_range adjusted?

[pat-s]

Disclaimer: I know what /proc/sys/net/ipv4/ip_local_port_range is used for and assume that you want to increase the availability of ephemeral ports for high-load scenarios.

However, I think changing the host-wide default isn't a good take and too intrusive.
In my specific case (and that is more a general default than a specific one of mine), the FW allows ephemeral ports from 32768-65535.
autobase changes this to 10000-65535. This creates issues: the VM is now allowed to use a port like 10445 for an outgoing connection. Depending on the call, it also expects a reply on that port, which will now fail.

While it really depends on the call at hand, tracking this down and figuring out what is the actual issue can be super tricky. The autobase task in which this is adjusted is processing very fast in the log and I wasn't even thinking about autobase possibly changing this.
I think there's not "enough" rationale for autobase to make this adjustment by default (unless I am overlooking something).

In general, I think autobase should be less intrusive adjusting instance-wide settings to networking and rather put all of these options into "optional optimizations" (there might be more, I didn't check yet).
Otherwise there's a medium-high risk that deploying autobase on a node that also runs other services will break these (and not even in an easy way if its due to settings like this one).

[vitabaks]

Hi,

Thanks for the thoughtful feedback!

This kernel parameter is one of many tuned defaults (see "System" section) in Autobase aimed at supporting very high-throughput database clusters, handling hundreds of thousands — or even millions — of TPS on a single node, with large numbers of connections to load balancers and pooling layers.
All default values in Autobase have been battle-tested over years of running production PostgreSQL clusters under heavy load. That said, they are tuned for general-purpose performance, and we understand that they may not suit all environments. If you’re aware of your specific requirements, you’re free to override these defaults in your environment.

It’s also worth noting that Autobase positions itself as an open-source alternative to managed database services — where system-level tuning is part of the experience, requiring no prior system prep by the user. So it’s more than just installing a Patroni cluster — it’s intended to be a fully automated, production-grade deployment.

P.S. It is not recommended to combine database servers with other services, as this can lead to conflicts at various levels.

[pat-s]

While I understand your general motivation here, I think these modifications would be better suited behind an performance_optimizations flag or similar.

In its current state, you're forcing nodes to solely exist for Postgres (due to these intrusive modifications to important host settings). By this, a lot of a node's resources stay unused.
In my particular case, I have 3x 12x 64Gi nodes with 2 TB disk. I mainly need the disks but also don't wanna waste almost 200Gi of memory (until I really need it for PG of course but that won't be anytime soon).

Unless one really aims for a super-high-performance cluster, sharing a VMs resources across multiple services (incl. PG) is totally fine and won't result in any performance degradation.
If one aims for a super high-perf PG cluster, one won't do service sharing on nodes anyways.

However, in many/most cases, users also want a "good setup" for shared servers. And there, it is important not to change essential vars like ip_local_port_range or edit the nameserver configuration (and possibly more).

I am quite sure that I won't be the only one in the future falling about this and not liking the fact that this is enabled by default.
If autobase put this behind a feature flag like mentioned earlier and use it for its cloud deployments and other deployments needing/aiming for "maximum performance", nothing will be lost or restricted.
At the same time, autobase can provide a super robust baseline experience which doesn't make any heavy modifications to a server.
If you would put a "Warning" message beside this feature flag in the docs and state something like "when enabling this, autobase will make changes to your nodes networking configurations - we advise to not run other services alongside it", this would make users aware of where they are going.

And on top: if there would be these two "modes", you could even do some benchmarks and show users how much more performance the "take single nodes only for autobase" config options has compared to the "baseline" one.

[vitabaks]

To disable kernel parameter tuning, specify sysctl_set: false

[pat-s]

Thanks. But this is only one tiny bit in the big puzzle: Ideally there would be a global switch that prohibits all network/kernel related tweaks (by default) 🙂️