Apply specific kernel network tuning parameters to the OpenShift profile
(/profiles/openshift/tuned.conf) to support high bandwidth-delay product links.
The following TCP settings are added:
net.ipv4.tcp_notsent_lowat=131072: Sets tcp_notsent_lowat to a value intended to balance throughput and latency while limiting total socket memory usage.
net.ipv4.tcp_slow_start_after_idle=0: Disables slow start after a connection has been idle, allowing immediate maximum throughput upon resuming data transfer.
net.ipv4.tcp_rmem="4096 131072 16777216": Increases the maximum TCP receive buffer size to improve performance on high-bandwidth-delay product connections.
net.ipv4.tcp_wmem="4096 16384 16777216": Increases the maximum TCP send buffer size for similar reasons.
These changes are based on work done by Cloudflare for improving TCP
performance on high bandwidth-delay product links but are more conservative in adjusting rmem and wmem
Reference: https://blog.cloudflare.com/optimizing-tcp-for-high-throughput-and-low-latency/
Signed-off-by: Graham Heffern <gheffern@gmail.com>
With openshift/machine-config-operator#3676 we
removed globally setting ip forwarding in MCO. We should not be setting
it in the default profile for OpenShift. We now set it on a per
interface basis as needed. However, by setting proc/sys/net/ipv4/forward
rather than (forwarding) it will reset all the values:
"This variable is special, its change resets all configuration
parameters to their default state (RFC1122 for hosts, RFC1812
for routers)"
We suspect this causes upgrade to fail. NTO sets this to 1, which then
resets all the per interface config that OVNK wrote. Then during upgrade
when there is a tuned profile change, the config change is rolled back
so forward is 0, and now there is no connectivity to kapi and upgrade
fails.
Signed-off-by: Tim Rozet <trozet@redhat.com>
The kernel tunable fs.aio-max-nr specifies the maximum number of events
specified on the io_setup() call for all currently active aio contexts.
On large systems this causes issues with the io_setup() call failing
with EAGAIN. Libvirt already increases this setting to 1048576:
96e99e4948/src/remote/libvirtd.sysctl
The only potential drawback of a larger limit is that a malicious users
could issue parallel io_setup() requests to cause the kernel to set
aside memory.
Signed-off-by: Jiri Mencak <jmencak@users.noreply.github.com>
AWS Nitro instances need special tuning for NVMe devices:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/nvme-ebs-volumes.html#timeout-nvme-ebs-volumes
[sysfs]
/sys/module/nvme_core/parameters/io_timeout=4294967295
/sys/module/nvme_core/parameters/max_retries=10
This tuning should probably be moved to Cloud Provider-specific profiles
once the functionality is implemented.
Signed-off-by: Jiri Mencak <jmencak@users.noreply.github.com>
The [scheduler] plug-in can be very CPU intensive, especially on the
OpenShift platform. The bug for this issue is tracked by rhbz#1921738.
Until this is fixed, work around this problem in the openshift
parent profile by adding "runtime=0" [scheduler] plug-in option.
Signed-off-by: Jiri Mencak <jmencak@users.noreply.github.com>
