mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
63 lines
3.4 KiB
Plaintext
63 lines
3.4 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * scalability_and_performance/using-node-tuning-operator.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="defer-application-of-tuning-changes_{context}"]
|
|
= Deferring application of tuning changes
|
|
|
|
As an administrator, use the Node Tuning Operator (NTO) to update custom resources (CRs) on a running system and make tuning changes. For example, they can update or add a sysctl parameter to the [sysctl] section of the tuned object. When administrators apply a tuning change, the NTO prompts TuneD to reprocess all configurations, causing the tuned process to roll back all tuning and then reapply it.
|
|
|
|
Latency-sensitive applications may not tolerate the removal and reapplication of the tuned profile, as it can briefly disrupt performance. This is particularly critical for configurations that partition CPUs and manage process or interrupt affinity using the performance profile. To avoid this issue, {product-title} introduced new methods for applying tuning changes. Before {product-title} 4.17, the only available method, immediate, applied changes instantly, often triggering a tuned restart.
|
|
|
|
The following additional methods are supported:
|
|
|
|
* `always`: Every change is applied at the next node restart.
|
|
* `update`: When a tuning change modifies a tuned profile, it is applied immediately by default and takes effect as soon as possible. When a tuning change does not cause a tuned profile to change and its values are modified in place, it is treated as always.
|
|
|
|
Enable this feature by adding the annotation `tuned.openshift.io/deferred`. The following table summarizes the possible values for the annotation:
|
|
|
|
[cols="3,3",options="header"]
|
|
|===
|
|
|Annotation value | Description
|
|
|missing | The change is applied immediately.
|
|
|always | The change is applied at the next node restart.
|
|
|update | The change is applied immediately if it causes a profile change, otherwise at the next node restart.
|
|
|===
|
|
|
|
The following example demonstrates how to apply a change to the `kernel.shmmni` sysctl parameter by using the `always` method:
|
|
|
|
.Example
|
|
[source,yaml]
|
|
----
|
|
apiVersion: tuned.openshift.io/v1
|
|
kind: Tuned
|
|
metadata:
|
|
name: performance-patch
|
|
namespace: openshift-cluster-node-tuning-operator
|
|
annotations:
|
|
tuned.openshift.io/deferred: "always"
|
|
spec:
|
|
profile:
|
|
- name: performance-patch
|
|
data: |
|
|
[main]
|
|
summary=Configuration changes profile inherited from performance created tuned
|
|
include=openshift-node-performance-performance <1>
|
|
[sysctl]
|
|
kernel.shmmni=8192 <2>
|
|
recommend:
|
|
- machineConfigLabels:
|
|
machineconfiguration.openshift.io/role: worker-cnf <3>
|
|
priority: 19
|
|
profile: performance-patch
|
|
----
|
|
|
|
<1> The `include` directive is used to inherit the `openshift-node-performance-performance` profile. This is a best practice to ensure that the profile is not missing any required settings.
|
|
<2> The `kernel.shmmni` sysctl parameter is being changed to `8192`.
|
|
<3> The `machineConfigLabels` field is used to target the `worker-cnf` role. Configure a `MachineConfigPool` resource to ensure the profile is applied only to the correct nodes.
|
|
|
|
[NOTE]
|
|
====
|
|
You can use {cgu-operator-full} to perform a controlled reboot across a fleet of spoke clusters to apply a deferred tuning change. For more information about coordinated reboots, see "Coordinating reboots for configuration changes".
|
|
==== |