14.2. 使用性能配置集调整节点以实现低延迟
使用集群性能配置集调整节点以实现低延迟。您可以限制 infra 和应用程序容器的 CPU,配置巨页、Hyper-Threading,并为对延迟敏感的进程配置 CPU 分区。
14.2.1. 创建性能配置集
您可以使用 Performance Profile Creator (PPC) 工具创建集群性能配置集。PPC 是 Node Tuning Operator 的功能。
PPC 将有关集群的信息与用户提供的配置相结合,以生成适合您的硬件、拓扑和用例的性能配置集。
性能配置集只适用于集群直接访问底层硬件资源的裸机环境。您可以为单节点 OpenShift 和多节点集群配置性能配置集。
以下是在集群中创建和应用性能配置集的高级工作流:
-
为您要使用性能配置为目标的节点创建机器配置池 (MCP)。在单节点 OpenShift 集群中,您必须使用
master
MCP,因为集群中只有一个节点。 -
使用
must-gather
命令收集有关集群的信息。 使用 PPC 工具使用以下方法之一创建性能配置集:
- 使用 Podman 运行 PPC 工具。
- 使用 wrapper 脚本运行 PPC 工具。
- 为您的用例配置性能配置集,并将性能配置集应用到集群。
14.2.1.1. 关于性能配置集创建器
Performance Profile Creator (PPC) 是一个命令行工具,由 Node Tuning Operator 提供,它可帮助您为集群创建性能配置集。
最初,您可以使用 PPC 工具处理 must-gather
数据来显示集群的关键性能配置,包括以下信息:
- 使用分配的 CPU ID 进行 NUMA 单元分区
- 超线程节点配置
您可以使用这些信息来帮助配置性能配置集。
运行 PPC
为 PPC 工具指定性能配置参数,以生成适合您的硬件、拓扑和用例的推荐性能配置集。
您可以使用以下方法之一运行 PPC:
- 使用 Podman 运行 PPC
- 使用 wrapper 脚本运行 PPC
使用 wrapper 脚本将一些更精细的 Podman 任务抽象到可执行脚本中。例如,wrapper 脚本处理诸如拉取和运行所需容器镜像、将目录挂载到容器等任务,并通过 Podman 直接向容器提供参数。两种方法都获得相同的结果。
14.2.1.2. 为性能调整创建机器配置池到目标节点
对于多节点集群,您可以定义机器配置池 (MCP) 来识别您要使用性能配置集配置的目标节点。
在单节点 OpenShift 集群中,您必须使用 master
MCP,因为集群中只有一个节点。您不需要为单节点 OpenShift 集群创建单独的 MCP。
先决条件
-
有
cluster-admin
角色访问权限。 -
已安装 OpenShift CLI(
oc
)。
流程
运行以下命令为配置标记目标节点:
$ oc label node <node_name> node-role.kubernetes.io/worker-cnf="" 1
- 1
- 将
<node_name>
替换为节点的名称。本例应用worker-cnf
标签。
创建包含目标节点的
MachineConfigPool
资源:创建定义
MachineConfigPool
资源的 YAML 文件:mcp-worker-cnf.yaml
文件示例apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: worker-cnf 1 labels: machineconfiguration.openshift.io/role: worker-cnf 2 spec: machineConfigSelector: matchExpressions: - { key: machineconfiguration.openshift.io/role, operator: In, values: [worker, worker-cnf], } paused: false nodeSelector: matchLabels: node-role.kubernetes.io/worker-cnf: "" 3
运行以下命令来应用
MachineConfigPool
资源:$ oc apply -f mcp-worker-cnf.yaml
输出示例
machineconfigpool.machineconfiguration.openshift.io/worker-cnf created
验证
运行以下命令,检查集群中的机器配置池:
$ oc get mcp
输出示例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-58433c7c3c1b4ed5ffef95234d451490 True False False 3 3 3 0 6h46m worker rendered-worker-168f52b168f151e4f853259729b6azc4 True False False 2 2 2 0 6h46m worker-cnf rendered-worker-cnf-168f52b168f151e4f853259729b6azc4 True False False 1 1 1 0 73s
14.2.1.3. 为 PPC 收集集群数据
Performance Profile Creator(PPC)工具需要 must-gather
数据。作为集群管理员,运行 must-gather
命令来捕获集群的信息。
先决条件
-
使用具有
cluster-admin
角色的用户访问集群。 -
已安装 OpenShift CLI(
oc
)。 - 您识别要使用性能配置集配置的目标 MCP。
流程
-
进入存储
must-gather
数据的目录。 运行以下命令来收集集群信息:
$ oc adm must-gather
该命令在本地目录中创建带有
must-gather
数据的文件夹,其命名格式类似如下:must-gather.local.1971646453781853027
。可选:从
must-gather
目录创建一个压缩文件:$ tar cvaf must-gather.tar.gz <must_gather_folder> 1
- 1
- 使用
must-gather
数据文件夹的名称替换。
注意如果您正在运行性能配置集 Creator wrapper 脚本,则需要压缩输出。
其他资源
-
有关
must-gather
工具的更多信息,请参阅收集集群的相关数据。
14.2.1.4. 使用 Podman 运行 Performance Profile Creator
作为集群管理员,您可以使用带有 Performance Profile Creator (PPC) 的 Podman 来创建性能配置集。
有关 PPC 参数的更多信息,请参阅 "Performance Profile Creator 参数" 部分。
PPC 使用集群中的 must-gather
数据来创建性能配置集。如果您对集群进行任何更改,如重新标记针对性能配置的节点,则必须在再次运行 PPC 前重新创建 must-gather
数据。
先决条件
-
使用具有
cluster-admin
角色的用户访问集群。 - 在裸机硬件上安装的集群。
-
已安装
podman
和 OpenShift CLI (oc
)。 - 访问 Node Tuning Operator 镜像。
- 您识别包含用于配置的目标节点的机器配置池。
-
您可以访问集群的
must-gather
数据。
流程
运行以下命令检查机器配置池:
$ oc get mcp
输出示例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-58433c8c3c0b4ed5feef95434d455490 True False False 3 3 3 0 8h worker rendered-worker-668f56a164f151e4a853229729b6adc4 True False False 2 2 2 0 8h worker-cnf rendered-worker-cnf-668f56a164f151e4a853229729b6adc4 True False False 1 1 1 0 79m
运行以下命令,使用 Podman 向
registry.redhat.io
进行身份验证:$ podman login registry.redhat.io
Username: <user_name> Password: <password>
可选:运行以下命令来显示 PPC 工具的帮助信息:
$ podman run --rm --entrypoint performance-profile-creator registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.16 -h
输出示例
A tool that automates creation of Performance Profiles Usage: performance-profile-creator [flags] Flags: --disable-ht Disable Hyperthreading -h, --help help for performance-profile-creator --info string Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log") --mcp-name string MCP name corresponding to the target machines (required) --must-gather-dir-path string Must gather directory path (default "must-gather") --offlined-cpu-count int Number of offlined CPUs --per-pod-power-management Enable Per Pod Power Management --power-consumption-mode string The power consumption mode. [Valid values: default, low-latency, ultra-low-latency] (default "default") --profile-name string Name of the performance profile to be created (default "performance") --reserved-cpu-count int Number of reserved CPUs (required) --rt-kernel Enable Real Time Kernel (required) --split-reserved-cpus-across-numa Split the Reserved CPUs across NUMA nodes --topology-manager-policy string Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted") --user-level-networking Run with User level Networking(DPDK) enabled
要显示集群的信息,请运行以下命令使用
log
参数运行 PPC 工具:$ podman run --entrypoint performance-profile-creator -v <path_to_must_gather>:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.16 --info log --must-gather-dir-path /must-gather
-
--entrypoint performance-profile-creator
将性能配置集创建者定义为podman
的新入口点。 -v <path_to_must_gather>
指定到以下组件之一的路径:-
包含
must-gather
数据的目录。 -
包含
must-gather
解压缩的 .tar 文件的现有目录。
-
包含
--info log
指定输出格式的值。输出示例
level=info msg="Cluster info:" level=info msg="MCP 'master' nodes:" level=info msg=--- level=info msg="MCP 'worker' nodes:" level=info msg="Node: host.example.com (NUMA cells: 1, HT: true)" level=info msg="NUMA cell 0 : [0 1 2 3]" level=info msg="CPU(s): 4" level=info msg="Node: host1.example.com (NUMA cells: 1, HT: true)" level=info msg="NUMA cell 0 : [0 1 2 3]" level=info msg="CPU(s): 4" level=info msg=--- level=info msg="MCP 'worker-cnf' nodes:" level=info msg="Node: host2.example.com (NUMA cells: 1, HT: true)" level=info msg="NUMA cell 0 : [0 1 2 3]" level=info msg="CPU(s): 4" level=info msg=---
-
运行以下命令来创建性能配置集。这个示例使用示例 PPC 参数和值:
$ podman run --entrypoint performance-profile-creator -v <path_to_must_gather>:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.16 --mcp-name=worker-cnf --reserved-cpu-count=1 --rt-kernel=true --split-reserved-cpus-across-numa=false --must-gather-dir-path /must-gather --power-consumption-mode=ultra-low-latency --offlined-cpu-count=1 > my-performance-profile.yaml
-v <path_to_must_gather>
指定到以下组件之一的路径:-
包含
must-gather
数据的目录。 -
包含
must-gather
解压缩的 .tar 文件的目录。
-
包含
-
--mcp-name=worker-cnf
指定worker-=cnf
机器配置池。 -
--reserved-cpu-count=1
指定一个保留 CPU。 -
--rt-kernel=true
启用实时内核。 -
--split-reserved-cpus-across-numa=false
禁用跨 NUMA 节点的保留 CPU 分割。 -
--power-consumption-mode=ultra-low-latency
指定最大延迟,这会增加功耗。 --offlined-cpu-count=1
指定一个离线 CPU。注意本例中的
mcp-name
参数根据oc get mcp
命令的输出设置为worker-cnf
。对于单节点 OpenShift,请使用--mcp-name=master
。输出示例
level=info msg="Nodes targeted by worker-cnf MCP are: [worker-2]" level=info msg="NUMA cell(s): 1" level=info msg="NUMA cell 0 : [0 1 2 3]" level=info msg="CPU(s): 4" level=info msg="1 reserved CPUs allocated: 0 " level=info msg="2 isolated CPUs allocated: 2-3" level=info msg="Additional Kernel Args based on configuration: []"
运行以下命令,查看创建的 YAML 文件:
$ cat my-performance-profile.yaml
输出示例
--- apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: cpu: isolated: 2-3 offlined: "1" reserved: "0" machineConfigPoolSelector: machineconfiguration.openshift.io/role: worker-cnf nodeSelector: node-role.kubernetes.io/worker-cnf: "" numa: topologyPolicy: restricted realTimeKernel: enabled: true workloadHints: highPowerConsumption: true perPodPowerManagement: false realTime: true
应用生成的配置集:
$ oc apply -f my-performance-profile.yaml
输出示例
performanceprofile.performance.openshift.io/performance created
14.2.1.5. 运行性能配置集 Creator wrapper 脚本
wrapper 脚本简化了使用 Performance Profile Creator (PPC) 工具创建性能配置集的过程。脚本处理诸如拉取和运行所需容器镜像、将目录挂载到容器等任务,并通过 Podman 直接向容器提供参数。
有关 Performance Profile Creator 参数的更多信息,请参阅 "Performance Profile Creator 参数" 部分。
PPC 使用集群中的 must-gather
数据来创建性能配置集。如果您对集群进行任何更改,如重新标记针对性能配置的节点,则必须在再次运行 PPC 前重新创建 must-gather
数据。
先决条件
-
使用具有
cluster-admin
角色的用户访问集群。 - 在裸机硬件上安装的集群。
-
已安装
podman
和 OpenShift CLI (oc
)。 - 访问 Node Tuning Operator 镜像。
- 您识别包含用于配置的目标节点的机器配置池。
-
访问
must-gather
tarball。
流程
在本地机器上创建一个文件,例如
run-perf-profile-creator.sh
:$ vi run-perf-profile-creator.sh
将以下代码粘贴到文件中:
#!/bin/bash readonly CONTAINER_RUNTIME=${CONTAINER_RUNTIME:-podman} readonly CURRENT_SCRIPT=$(basename "$0") readonly CMD="${CONTAINER_RUNTIME} run --entrypoint performance-profile-creator" readonly IMG_EXISTS_CMD="${CONTAINER_RUNTIME} image exists" readonly IMG_PULL_CMD="${CONTAINER_RUNTIME} image pull" readonly MUST_GATHER_VOL="/must-gather" NTO_IMG="registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.16" MG_TARBALL="" DATA_DIR="" usage() { print "Wrapper usage:" print " ${CURRENT_SCRIPT} [-h] [-p image][-t path] -- [performance-profile-creator flags]" print "" print "Options:" print " -h help for ${CURRENT_SCRIPT}" print " -p Node Tuning Operator image" print " -t path to a must-gather tarball" ${IMG_EXISTS_CMD} "${NTO_IMG}" && ${CMD} "${NTO_IMG}" -h } function cleanup { [ -d "${DATA_DIR}" ] && rm -rf "${DATA_DIR}" } trap cleanup EXIT exit_error() { print "error: $*" usage exit 1 } print() { echo "$*" >&2 } check_requirements() { ${IMG_EXISTS_CMD} "${NTO_IMG}" || ${IMG_PULL_CMD} "${NTO_IMG}" || \ exit_error "Node Tuning Operator image not found" [ -n "${MG_TARBALL}" ] || exit_error "Must-gather tarball file path is mandatory" [ -f "${MG_TARBALL}" ] || exit_error "Must-gather tarball file not found" DATA_DIR=$(mktemp -d -t "${CURRENT_SCRIPT}XXXX") || exit_error "Cannot create the data directory" tar -zxf "${MG_TARBALL}" --directory "${DATA_DIR}" || exit_error "Cannot decompress the must-gather tarball" chmod a+rx "${DATA_DIR}" return 0 } main() { while getopts ':hp:t:' OPT; do case "${OPT}" in h) usage exit 0 ;; p) NTO_IMG="${OPTARG}" ;; t) MG_TARBALL="${OPTARG}" ;; ?) exit_error "invalid argument: ${OPTARG}" ;; esac done shift $((OPTIND - 1)) check_requirements || exit 1 ${CMD} -v "${DATA_DIR}:${MUST_GATHER_VOL}:z" "${NTO_IMG}" "$@" --must-gather-dir-path "${MUST_GATHER_VOL}" echo "" 1>&2 } main "$@"
为这个脚本中的每个人添加执行权限:
$ chmod a+x run-perf-profile-creator.sh
运行以下命令,使用 Podman 向
registry.redhat.io
进行身份验证:$ podman login registry.redhat.io
Username: <user_name> Password: <password>
可选:运行以下命令来显示 PPC 工具的帮助信息:
$ ./run-perf-profile-creator.sh -h
输出示例
Wrapper usage: run-perf-profile-creator.sh [-h] [-p image][-t path] -- [performance-profile-creator flags] Options: -h help for run-perf-profile-creator.sh -p Node Tuning Operator image -t path to a must-gather tarball A tool that automates creation of Performance Profiles Usage: performance-profile-creator [flags] Flags: --disable-ht Disable Hyperthreading -h, --help help for performance-profile-creator --info string Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log") --mcp-name string MCP name corresponding to the target machines (required) --must-gather-dir-path string Must gather directory path (default "must-gather") --offlined-cpu-count int Number of offlined CPUs --per-pod-power-management Enable Per Pod Power Management --power-consumption-mode string The power consumption mode. [Valid values: default, low-latency, ultra-low-latency] (default "default") --profile-name string Name of the performance profile to be created (default "performance") --reserved-cpu-count int Number of reserved CPUs (required) --rt-kernel Enable Real Time Kernel (required) --split-reserved-cpus-across-numa Split the Reserved CPUs across NUMA nodes --topology-manager-policy string Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted") --user-level-networking Run with User level Networking(DPDK) enabled --enable-hardware-tuning Enable setting maximum CPU frequencies
注意您可以选择使用
-p
选项为 Node Tuning Operator 镜像设置路径。如果您没有设置路径,wrapper 脚本使用默认镜像:registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.16
。要显示集群的信息,请运行以下命令使用
log
参数运行 PPC 工具:$ ./run-perf-profile-creator.sh -t /<path_to_must_gather_dir>/must-gather.tar.gz -- --info=log
-t /<path_to_must_gather_dir>/must-gather.tar.gz
指定包含 must-gather tarball 的目录的路径。这是 wrapper 脚本的必要参数。输出示例
level=info msg="Cluster info:" level=info msg="MCP 'master' nodes:" level=info msg=--- level=info msg="MCP 'worker' nodes:" level=info msg="Node: host.example.com (NUMA cells: 1, HT: true)" level=info msg="NUMA cell 0 : [0 1 2 3]" level=info msg="CPU(s): 4" level=info msg="Node: host1.example.com (NUMA cells: 1, HT: true)" level=info msg="NUMA cell 0 : [0 1 2 3]" level=info msg="CPU(s): 4" level=info msg=--- level=info msg="MCP 'worker-cnf' nodes:" level=info msg="Node: host2.example.com (NUMA cells: 1, HT: true)" level=info msg="NUMA cell 0 : [0 1 2 3]" level=info msg="CPU(s): 4" level=info msg=---
运行以下命令来创建性能配置集。
$ ./run-perf-profile-creator.sh -t /path-to-must-gather/must-gather.tar.gz -- --mcp-name=worker-cnf --reserved-cpu-count=1 --rt-kernel=true --split-reserved-cpus-across-numa=false --power-consumption-mode=ultra-low-latency --offlined-cpu-count=1 > my-performance-profile.yaml
本例使用示例 PPC 参数和值。
-
--mcp-name=worker-cnf
指定worker-=cnf
机器配置池。 -
--reserved-cpu-count=1
指定一个保留 CPU。 -
--rt-kernel=true
启用实时内核。 -
--split-reserved-cpus-across-numa=false
禁用跨 NUMA 节点的保留 CPU 分割。 -
--power-consumption-mode=ultra-low-latency
指定最大延迟,这会增加功耗。 --offlined-cpu-count=1
指定一个离线 CPU。注意本例中的
mcp-name
参数根据oc get mcp
命令的输出设置为worker-cnf
。对于单节点 OpenShift,请使用--mcp-name=master
。
-
运行以下命令,查看创建的 YAML 文件:
$ cat my-performance-profile.yaml
输出示例
--- apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: cpu: isolated: 2-3 offlined: "1" reserved: "0" machineConfigPoolSelector: machineconfiguration.openshift.io/role: worker-cnf nodeSelector: node-role.kubernetes.io/worker-cnf: "" numa: topologyPolicy: restricted realTimeKernel: enabled: true workloadHints: highPowerConsumption: true perPodPowerManagement: false realTime: true
应用生成的配置集:
$ oc apply -f my-performance-profile.yaml
输出示例
performanceprofile.performance.openshift.io/performance created
14.2.1.6. Performance Profile Creator 参数
参数 | 描述 |
---|---|
|
MCP 的名称;例如,与目标机器对应的 |
| must gather 目录的路径。
只有在使用 Podman 运行 PPC 工具时才需要此参数。如果您将 PPC 与 wrapper 脚本搭配使用,请不要使用此参数。反之,使用 wrapper 脚本的 |
| 保留 CPU 的数量。使用大于零的一个自然数字。 |
| 启用实时内核。
可能的值: |
参数 | 描述 |
---|---|
| 禁用超线程。
可能的值:
默认值: 警告
如果此参数设为 |
enable-hardware-tuning | 启用最大 CPU 频率的设置。 要启用此功能,请在以下两个字段中为隔离和保留 CPU 上运行的应用程序设置最大频率:
这是一个高级功能。如果您配置硬件性能优化,则生成的 |
|
这会捕获集群信息。这个参数还需要 可能的值:
默认: |
| 离线 CPU 数量。 注意 使用大于零的一个自然数字。如果没有足够的逻辑处理器离线,则会记录错误消息。信息是: Error: failed to compute the reserved and isolated CPUs: please ensure that reserved-cpu-count plus offlined-cpu-count should be in the range [0,1] Error: failed to compute the reserved and isolated CPUs: please specify the offlined CPU count in the range [0,1] |
| 电源功耗模式。 可能的值:
默认: |
|
为每个 pod 电源管理启用。如果您将
可能的值:
默认值: |
| 要创建的性能配置集的名称。
默认: |
| 将保留的 CPU 划分到 NUMA 节点。
可能的值:
默认值: |
| 要创建的性能配置集的 kubelet Topology Manager 策略。 可能的值:
默认: |
| 在启用了用户级别网络(DPDK)的情况下运行。
可能的值:
默认值: |
14.2.1.7. 参考性能配置集
使用以下引用性能配置集作为开发您自己的自定义配置集的基础。
14.2.1.7.1. 在 OpenStack 上使用 OVS-DPDK 的集群的性能配置集模板
要最大化使用 Open vSwitch 和 Red Hat OpenStack Platform(RHOSP)上的 Data Plane Development Kit(OVS-DPDK)的机器性能,您可以使用性能配置集。
您可以使用以下性能配置集模板为您的部署创建配置集。
使用 OVS-DPDK 的集群的性能配置集模板
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: cnf-performanceprofile spec: additionalKernelArgs: - nmi_watchdog=0 - audit=0 - mce=off - processor.max_cstate=1 - idle=poll - intel_idle.max_cstate=0 - default_hugepagesz=1GB - hugepagesz=1G - intel_iommu=on cpu: isolated: <CPU_ISOLATED> reserved: <CPU_RESERVED> hugepages: defaultHugepagesSize: 1G pages: - count: <HUGEPAGES_COUNT> node: 0 size: 1G nodeSelector: node-role.kubernetes.io/worker: '' realTimeKernel: enabled: false globallyDisableIrqLoadBalancing: true
插入适用于 CPU_ISOLATED
、CPU_RESERVED
和 HUGEPAGES_COUNT
密钥的配置的值。
14.2.1.7.2. Telco RAN DU 参考设计性能配置集
以下性能配置集在商业硬件上配置 OpenShift Container Platform 集群的节点级性能设置,以托管电信 RAN DU 工作负载。
Telco RAN DU 参考设计性能配置集
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name} # Also in file 'validatorCRs/informDuValidator.yaml': # name: 50-performance-${PerformanceProfile.metadata.name} name: openshift-node-performance-profile annotations: ran.openshift.io/reference-configuration: "ran-du.redhat.com" spec: additionalKernelArgs: - "rcupdate.rcu_normal_after_boot=0" - "efi=runtime" - "vfio_pci.enable_sriov=1" - "vfio_pci.disable_idle_d3=1" - "module_blacklist=irdma" cpu: isolated: $isolated reserved: $reserved hugepages: defaultHugepagesSize: $defaultHugepagesSize pages: - size: $size count: $count node: $node machineConfigPoolSelector: pools.operator.machineconfiguration.openshift.io/$mcp: "" nodeSelector: node-role.kubernetes.io/$mcp: '' numa: topologyPolicy: "restricted" # To use the standard (non-realtime) kernel, set enabled to false realTimeKernel: enabled: true workloadHints: # WorkloadHints defines the set of upper level flags for different type of workloads. # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints # for detailed descriptions of each item. # The configuration below is set for a low latency, performance mode. realTime: true highPowerConsumption: false perPodPowerManagement: false
14.2.1.7.3. 电信核心参考设计性能配置集
以下性能配置集在商业硬件上为 OpenShift Container Platform 集群配置节点级别的性能设置,以托管电信核心工作负载。
电信核心参考设计性能配置集
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name} # Also in file 'validatorCRs/informDuValidator.yaml': # name: 50-performance-${PerformanceProfile.metadata.name} name: openshift-node-performance-profile annotations: ran.openshift.io/reference-configuration: "ran-du.redhat.com" spec: additionalKernelArgs: - "rcupdate.rcu_normal_after_boot=0" - "efi=runtime" - "vfio_pci.enable_sriov=1" - "vfio_pci.disable_idle_d3=1" - "module_blacklist=irdma" cpu: isolated: $isolated reserved: $reserved hugepages: defaultHugepagesSize: $defaultHugepagesSize pages: - size: $size count: $count node: $node machineConfigPoolSelector: pools.operator.machineconfiguration.openshift.io/$mcp: "" nodeSelector: node-role.kubernetes.io/$mcp: '' numa: topologyPolicy: "restricted" # To use the standard (non-realtime) kernel, set enabled to false realTimeKernel: enabled: true workloadHints: # WorkloadHints defines the set of upper level flags for different type of workloads. # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints # for detailed descriptions of each item. # The configuration below is set for a low latency, performance mode. realTime: true highPowerConsumption: false perPodPowerManagement: false
14.2.2. 支持的性能配置集 API 版本
Node Tuning Operator 在性能配置集 apiVersion
字段中支持 v2
、v1
和 v1alpha1
。v1 和 v1alpha1 API 相同。v2 API 包括一个可选的布尔值项 globallyDisableIrqLoadBalancing
,默认值为 false
。
升级性能配置集以使用设备中断处理
当您将 Node Tuning Operator 性能配置集自定义资源定义(CRD)从 v1 或 v1alpha1 升级到 v2 时,现有配置集会将 globallyDisableIrqLoadBalancing
设置为 true
。
globallyDisableIrqLoadBalancing
切换用于 Isolated CPU 集是否禁用了 IRQ 负载均衡。当选项设置为 true
时,它会禁用 Isolated CPU 集的 IRQ 负载均衡。将选项设置为 false
允许在所有 CPU 之间平衡 IRQ。
将 Node Tuning Operator API 从 v1alpha1 升级到 v1
当将 Node Tuning Operator API 版本从 v1alpha1 升级到 v1 时,,v1alpha1 性能配置集会通过"None" Conversion 策略自行转换,并提供给带有 API 版本 v1 的 Performance Addon Operator。
将 Node Tuning Operator API 从 v1alpha1 或 v1 升级到 v2
当从旧的 Node Tuning Operator API 版本升级时,现有的 v1 和 v1alpha1 性能配置集将使用转换 Webhook 转换,它将注入 globallyDisableIrqLoadBalancing
字段,值为 true
。
14.2.3. 使用工作负载提示配置节点功耗和实时处理
流程
-
使用
Performance Profile
Creator (PPC) 工具创建适合环境的硬件和拓扑的 PerformanceProfile。下表描述了为与 PPC 工具关联的power-consumption-mode
标志设置的可能值,以及应用的工作负载提示。
性能配置集创建器设置 | 提示 | 环境 | 描述 |
---|---|---|---|
Default(默认) |
workloadHints: highPowerConsumption: false realTime: false | 没有延迟要求的高吞吐量集群 | 仅通过 CPU 分区实现的性能。 |
Low-latency |
workloadHints: highPowerConsumption: false realTime: true | 地区数据中心 | 节能和低延迟都需要考虑的:在电源管理、延迟和吞吐量之间进行妥当调节。 |
Ultra-low-latency |
workloadHints: highPowerConsumption: true realTime: true | 对于远边缘集群,对延迟非常敏感的工作负载 | 实现最小延迟和最大确定性会增加电源消耗的成本。 |
每个 pod 电源管理 |
workloadHints: realTime: true highPowerConsumption: false perPodPowerManagement: true | 关键和非关键工作负载 | 允许每个 pod 进行电源管理。 |
Example
以下配置通常在电信 RAN DU 部署中使用。
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
name: workload-hints
spec:
...
workloadHints:
realTime: true
highPowerConsumption: false
perPodPowerManagement: false 1
- 1
- 禁用一些可能会影响系统延迟的调试和监控功能。
当在性能配置集中将 realTime
工作负载 hint 标志设置为 true
时,将 cpu-quota.crio.io: disable
注解添加到带有固定 CPU 的每个保证 pod。此注解是防止 pod 中进程性能降级所必需的。如果没有明确设置 realTime
工作负载提示,则默认为 true
。
有关如何将功耗和实时设置组合会影响延迟的更多信息,请参阅了解工作负载提示。
14.2.4. 为运行 colocated 高和低优先级工作负载的节点配置节能
您可以为带有低优先级工作负载的节点实现节能,而不影响高优先级工作负载的延迟或吞吐量。无需修改工作负载本身即可进行节能。
Intel Ice Lake 及更新的 Intel CPU 支持该功能。处理器的功能可能会影响高优先级工作负载的延迟和吞吐量。
先决条件
- 您在 BIOS 中启用了 C-states 和操作系统控制的 P-states
流程
将
per-pod-power-management
参数设置为true
来生成PerformanceProfile
:$ podman run --entrypoint performance-profile-creator -v \ /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.16 \ --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true \ --split-reserved-cpus-across-numa=false --topology-manager-policy=single-numa-node \ --must-gather-dir-path /must-gather --power-consumption-mode=low-latency \ 1 --per-pod-power-management=true > my-performance-profile.yaml
- 1
- 当
per-pod-power-management
参数设置为true
时,power-consumption-mode
参数必须是default
或low-latency
。
带有
perPodPowerManagement
的PerformanceProfile
示例apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: [.....] workloadHints: realTime: true highPowerConsumption: false perPodPowerManagement: true
在
PerformanceProfile
自定义资源(CR) 中将默认cpufreq
调控器设置为附加内核参数:apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: ... additionalKernelArgs: - cpufreq.default_governor=schedutil 1
- 1
- 建议使用
schedutil
管理器,但您可以使用其他监管器,如ondemand
或powersave
governors。
在
Tuned PerformancePatch
CR 中设置最大 CPU 频率:spec: profile: - data: | [sysfs] /sys/devices/system/cpu/intel_pstate/max_perf_pct = <x> 1
- 1
max_perf_pct
控制cpufreq
驱动程序的最大频率,以最大百分比的形式设置支持的 cpu 频率。这个值适用于所有 CPU。您可以检查/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
中的最大支持频率。作为起点,您可以使用以All Cores Turbo
频率封装所有 CPU 的百分比。All Cores Turbo
频率是所有内核在运行的频率,当内核完全占用时。
14.2.5. 为 infra 和应用程序容器限制 CPU
通用内务处理和工作负载任务使用 CPU 的方式可能会影响对延迟敏感的进程。默认情况下,容器运行时使用所有在线 CPU 一起运行所有容器,这可能导致上下文切换和延迟激增。对 CPU 进行分区可防止无状态进程通过相互分离来干扰对延迟敏感的进程。下表描述了在使用 Node Tuning Operator 调整节点后在 CPU 上运行的进程:
进程类型 | 详情 |
---|---|
| 在除了运行低延迟工作负载外的任意 CPU 上运行 |
基础架构 pod | 在除了运行低延迟工作负载外的任意 CPU 上运行 |
中断 | 重定向到保留的 CPU(OpenShift Container Platform 4.7 及更新的版本中的可选) |
内核进程 | 固定保留的 CPU |
对延迟敏感的工作负载 pod | 固定到隔离池中的特定专用 CPU |
OS 进程/systemd 服务 | 固定保留的 CPU |
在一个节点上的对于所有 QoS 进程类型( Burstable
、BestEffort
或 Guaranteed
)的 pod 的可分配容量等于隔离池的容量。保留池的容量已从节点的总内核容量中删除,供集群和操作系统日常任务使用。
示例 1
节点具有 100 个内核的容量。通过使用性能配置集,集群管理员将 50 个内核分配给隔离池,将 50 个内核分配给保留池。集群管理员为 QoS 为 BestEffort
或 Burstable
的 pod 分配 25 个内核,为 Guaranteed
的 pod 分配 25 个内核。这与隔离池的容量匹配。
示例 2
节点具有 100 个内核的容量。通过使用性能配置集,集群管理员将 50 个内核分配给隔离池,将 50 个内核分配给保留池。集群管理员为 QoS 为 BestEffort
或 Burstable
的 pod 分配一个内核,为 Guaranteed
的 pod 分配 50 个内核。这超过了隔离池容量一个内核。Pod 调度因为 CPU 容量不足而失败。
使用的确切分区模式取决于许多因素,如硬件、工作负载特性和预期的系统负载。以下是一些用例示例:
- 如果对延迟敏感的工作负载使用特定的硬件,如网络接口控制器(NIC),请确保隔离池中的 CPU 尽可能地与这个硬件接近。至少,您应该将工作负载放在同一个非统一内存访问 (NUMA) 节点中。
- 保留的池用于处理所有中断。根据系统网络,分配一个足够大小的保留池来处理所有传入的数据包中断。在 4.16 及更高版本中,工作负载可以选择性地被标记为敏感版本。
在决定哪些特定 CPU 用于保留和隔离分区时,需要详细分析和测量。设备和内存的 NUMA 紧密度等因素扮演了角色。选择也取决于工作负载架构和具体的用例。
保留和隔离的 CPU 池不得重叠,并且必须一起跨越 worker 节点中的所有可用内核。
为确保内务处理任务和工作负载不会相互干扰,请在性能配置集的 spec
部分指定两组 CPU。
-
isolated
- 指定应用程序容器工作负载的 CPU。这些 CPU 的延迟最低。这个组中的进程没有中断,例如,可以达到更高的 DPDK 零数据包丢失带宽。 -
reserved
- 为集群和操作系统日常任务指定 CPU。reserved
组中的线程经常会比较繁忙。不要在reserved
组中运行对延迟敏感的应用程序。对延迟敏感的应用程序在isolated
组中运行。
流程
- 创建适合环境硬件和拓扑的性能配置集。
使用您想要为 infra 和应用程序容器保留和隔离的 CPU 添加
reserved
和isolated
参数:apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: infra-cpus spec: cpu: reserved: "0-4,9" 1 isolated: "5-8" 2 nodeSelector: 3 node-role.kubernetes.io/worker: ""
14.2.6. 为集群配置超线程
要为 OpenShift Container Platform 集群配置超线程,请将性能配置集中的 CPU 线程设置为为保留或隔离的 CPU 池配置的相同内核。
如果您配置了性能配置集,然后更改主机的超线程配置,请确保更新 PerformanceProfile
YAML 中的 CPU isolated
和 reserved
字段以匹配新配置。
禁用之前启用的主机超线程配置可能会导致 PerformanceProfile
YAML 中列出的 CPU 内核 ID 错误。此不正确的配置可能会导致节点不可用,因为无法找到列出的 CPU。
先决条件
-
使用具有
cluster-admin
角色的用户访问集群。 - 安装 OpenShift CLI(oc)。
流程
确定在您要配置的主机的 CPU 上运行哪些线程。
您可以通过登录到集群并运行以下命令来查看在主机 CPU 上运行哪些线程:
$ lscpu --all --extended
输出示例
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ 0 0 0 0 0:0:0:0 yes 4800.0000 400.0000 1 0 0 1 1:1:1:0 yes 4800.0000 400.0000 2 0 0 2 2:2:2:0 yes 4800.0000 400.0000 3 0 0 3 3:3:3:0 yes 4800.0000 400.0000 4 0 0 0 0:0:0:0 yes 4800.0000 400.0000 5 0 0 1 1:1:1:0 yes 4800.0000 400.0000 6 0 0 2 2:2:2:0 yes 4800.0000 400.0000 7 0 0 3 3:3:3:0 yes 4800.0000 400.0000
在这个示例中,在四个物理 CPU 内核中运行了八个逻辑 CPU 内核。CPU0 和 CPU4 在物理 Core0 中运行,CPU1 和 CPU5 在物理 Core 1 中运行,以此类推。
另外要查看为特定物理 CPU 内核设定的线程(以下示例中的
cpu0
),打开命令提示符并运行以下命令:$ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
输出示例
0-4
在
PerformanceProfile
YAML 中应用隔离和保留的 CPU。例如,您可以将逻辑内核 CPU0 和 CPU4 设置为isolated
;将逻辑内核 CPU1 到 CPU3 以及 CPU5 到 CPU7 设置为reserved
。当您配置保留的和隔离的 CPU 时,pod 中的 infra 容器将使用保留的 CPU,应用程序容器则使用隔离的 CPU。... cpu: isolated: 0,4 reserved: 1-3,5-7 ...
注意保留和隔离的 CPU 池不得重叠,并且必须一起跨越 worker 节点中的所有可用内核。
大多数 Intel 处理器上默认启用超线程。如果启用超线程,特定内核处理的所有线程都必须被隔离或者在同一个内核中处理。
启用超线程后,所有保证的 pod 都必须使用多个 SMT (simultaneous multi-threading)级别,以避免造成 "noisy neighbor" 的情况并导致 pod 失败。如需更多信息,请参阅静态策略选项。
14.2.6.1. 为低延迟应用程序禁用超线程
在为低延迟进程配置集群时,请考虑是否要在部署集群前禁用超线程。要禁用 Hyper-Threading,请执行以下步骤:
- 创建一个适合您的硬件和拓扑的性能配置集。
将
nosmt
设为附加内核参数。以下示例的性能配置集演示了此设置:apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: example-performanceprofile spec: additionalKernelArgs: - nmi_watchdog=0 - audit=0 - mce=off - processor.max_cstate=1 - idle=poll - intel_idle.max_cstate=0 - nosmt cpu: isolated: 2-3 reserved: 0-1 hugepages: defaultHugepagesSize: 1G pages: - count: 2 node: 0 size: 1G nodeSelector: node-role.kubernetes.io/performance: '' realTimeKernel: enabled: true
注意当您配置保留的和隔离的 CPU 时,pod 中的 infra 容器将使用保留的 CPU,应用程序容器则使用隔离的 CPU。
14.2.7. 管理设备中断处理保证 pod 隔离 CPU
Node Tuning Operator 可以通过将主机 CPU 划分为保留的 CPU 来管理主机 CPU,以进行集群和操作系统日常任务(包括 pod infra 容器),以及用于应用程序容器运行工作负载的隔离 CPU。这可让您将低延迟工作负载的 CPU 设置为隔离状态。
设备中断在所有隔离和保留 CPU 之间平衡负载,以避免出现 CPU 超载问题,但运行有保证 pod 的 CPU 除外。当为 pod 设置相关注解时,保证 pod CPU 无法处理设备中断。
在性能配置集中,globallyDisableIrqLoadBalancing
用于管理设备中断是否被处理。对于某些工作负载,保留 CPU 并不总是足以处理设备中断,因此不会在隔离的 CPU 上禁用设备中断。默认情况下,Node Tuning Operator 不会禁用隔离 CPU 上的设备中断。
14.2.7.1. 为节点查找有效的 IRQ 关联性设置
有些 IRQ 控制器缺少对 IRQ 关联性设置的支持,并将始终将所有在线 CPU 公开为 IRQ 掩码。这些 IRQ 控制器在 CPU 0 上运行。
以下是红帽了解对 IRQ 关联性设置的支持的驱动程序和硬件示例。以下是相关的列表(并没有包括所有):
-
一些 RAID 控制器驱动程序,如
megaraid_sas
- 许多非易失性内存表达 (NVMe) 驱动程序
- 主板 (LOM) 网络控制器上的一些 LAN
-
驱动程序使用
managed_irqs
不支持 IRQ 关联性设置的原因可能与主板中的处理器类型、IRI 控制器或断路器连接等因素相关。
如果任何 IRQ 的有效关联性被设置为一个隔离的 CPU,则可能代表一些硬件或驱动程序不支持 IRQ 关联性设置。要查找有效的关联性,请登录到主机并运行以下命令:
$ find /proc/irq -name effective_affinity -printf "%p: " -exec cat {} \;
输出示例
/proc/irq/0/effective_affinity: 1 /proc/irq/1/effective_affinity: 8 /proc/irq/2/effective_affinity: 0 /proc/irq/3/effective_affinity: 1 /proc/irq/4/effective_affinity: 2 /proc/irq/5/effective_affinity: 1 /proc/irq/6/effective_affinity: 1 /proc/irq/7/effective_affinity: 1 /proc/irq/8/effective_affinity: 1 /proc/irq/9/effective_affinity: 2 /proc/irq/10/effective_affinity: 1 /proc/irq/11/effective_affinity: 1 /proc/irq/12/effective_affinity: 4 /proc/irq/13/effective_affinity: 1 /proc/irq/14/effective_affinity: 1 /proc/irq/15/effective_affinity: 1 /proc/irq/24/effective_affinity: 2 /proc/irq/25/effective_affinity: 4 /proc/irq/26/effective_affinity: 2 /proc/irq/27/effective_affinity: 1 /proc/irq/28/effective_affinity: 8 /proc/irq/29/effective_affinity: 4 /proc/irq/30/effective_affinity: 4 /proc/irq/31/effective_affinity: 8 /proc/irq/32/effective_affinity: 8 /proc/irq/33/effective_affinity: 1 /proc/irq/34/effective_affinity: 2
有些驱动程序使用 managed_irqs
,其关联性由内核在内部管理,用户空间无法更改关联性。在某些情况下,这些 IRQ 可能会分配给隔离的 CPU。有关 managed_irqs
的更多信息,请参阅 无法更改受管中断的关联性,即使它们目标隔离 CPU。
14.2.7.2. 配置节点中断关联性
为 IRQ 动态负载平衡配置集群节点,以控制哪些内核可以接收设备中断请求 (IRQ)。
先决条件
- 对于内核隔离,所有服务器硬件组件都必须支持 IRQ 关联性。要检查服务器的硬件组件是否支持 IRQ 关联性,请查看服务器的硬件规格或联系您的硬件供应商。
流程
- 以具有 cluster-admin 权限的用户身份登录 OpenShift Container Platform 集群。
-
将性能配置集
apiVersion
设置为使用performance.openshift.io/v2
。 -
删除
globallyDisableIrqLoadBalancing
字段,或把它设置为false
。 设置适当的隔离 CPU 和保留的 CPU。以下片段演示了保留 2 个 CPU 的配置集。对于在
isolated
CPU 集中运行的 pod,启用 IRQ 负载均衡:apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: dynamic-irq-profile spec: cpu: isolated: 2-5 reserved: 0-1 ...
注意当您配置保留和隔离的 CPU、操作系统进程、内核进程和 systemd 服务在保留 CPU 上运行时。基础架构 pod 在任何 CPU 上运行,但运行低延迟工作负载除外。低延迟工作负载 pod 在隔离池中的专用 CPU 上运行。如需更多信息,请参阅"为 infra 和应用程序容器限制 CPU"。
14.2.8. 配置巨页
节点必须预先分配在 OpenShift Container Platform 集群中使用的巨页。使用 Node Tuning Operator 在特定节点中分配巨页。
OpenShift Container Platform 提供了创建和分配巨页的方法。Node Tuning Operator 提供了一种更易于使用性能配置集的方法。
例如,在性能配置集的 hugepages
pages
部分,您可以指定多个块的 size
、count
以及可选的 node
:
hugepages:
defaultHugepagesSize: "1G"
pages:
- size: "1G"
count: 4
node: 0 1
- 1
node
是分配巨页的 NUMA 节点。如果省略了node
,该页面将平均分布在所有 NUMA 节点中。
等待显示更新已完成的相关机器配置池状态。
这些是分配巨页的唯一配置步骤。
验证
要验证配置,请查看节点上的
/proc/meminfo
文件:$ oc debug node/ip-10-0-141-105.ec2.internal
# grep -i huge /proc/meminfo
输出示例
AnonHugePages: ###### ## ShmemHugePages: 0 kB HugePages_Total: 2 HugePages_Free: 2 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: #### ## Hugetlb: #### ##
使用
oc describe
报告新大小:$ oc describe node worker-0.ocp4poc.example.com | grep -i huge
输出示例
hugepages-1g=true hugepages-###: ### hugepages-###: ###
14.2.8.1. 分配多个巨页大小
您可以在同一容器下请求具有不同大小的巨页。这样,您可以定义由具有不同巨页大小的容器组成的更复杂的 pod。
例如,您可以把大小定义为 1G
和 2M
,Node Tuning Operator 会在节点上配置这两个大小,如下所示:
spec: hugepages: defaultHugepagesSize: 1G pages: - count: 1024 node: 0 size: 2M - count: 4 node: 1 size: 1G
14.2.9. 使用 Node Tuning Operator 减少 NIC 队列
Node Tuning Operator 有助于减少 NIC 队列以提高性能。使用性能配置集进行调整,允许为不同的网络设备自定义队列。
14.2.9.1. 使用性能配置集调整 NIC 队列
通过性能配置集,您可以调整每个网络设备的队列计数。
支持的网络设备:
- 非虚拟网络设备
- 支持多个队列的网络设备(通道)
不支持的网络设备:
- 纯软件网络接口
- 块设备
- Intel DPDK 虚拟功能
先决条件
-
使用具有
cluster-admin
角色的用户访问集群。 -
安装 OpenShift CLI(
oc
)。
流程
-
以具有
cluster-admin
权限的用户身份登录运行 Node Tuning Operator 的 OpenShift Container Platform 集群。 - 创建并应用适合您的硬件和拓扑的性能配置集。有关创建配置集的指南,请参阅"创建性能配置集"部分。
编辑这个创建的性能配置集:
$ oc edit -f <your_profile_name>.yaml
使用
net
对象填充spec
字段。对象列表可以包含两个字段:-
userLevelNetworking
是一个必需字段,指定为布尔值标记。如果userLevelNetworking
为true
,则队列数将设置为所有支持设备的保留 CPU 计数。默认值为false
。 devices
是一个可选字段,指定队列设置为保留 CPU 数的设备列表。如果设备列表为空,则配置适用于所有网络设备。配置如下:interfaceName
:此字段指定接口名称,并支持 shell 样式的通配符,可以是正数或负数。-
通配符语法示例如下:
<string> .*
-
负规则的前缀为感叹号。要将网络队列更改应用到排除列表以外的所有设备,请使用
!<device>
。例如!eno1
。
-
通配符语法示例如下:
-
vendorID
:网络设备供应商 ID,以带有0x
前缀的 16 位十六进制数字代表。 deviceID
:网络设备 ID(model),以带有0x
前缀的 16 位十六进制数字代表。注意当指定
deviceID
时,还必须定义vendorID
。与设备条目interfaceName
、vendorID
或vendorID
加deviceID
中指定的所有设备标识符相匹配的设备会被视为一个网络设备。然后,此网络设备的 net 队列数设置为保留的 CPU 计数。当指定了两个或多个设备时,网络队列数将设置为与其中一个设备匹配的任何网络设备。
-
使用此示例性能配置集将所有设备的队列数设置为保留的 CPU 计数:
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: manual spec: cpu: isolated: 3-51,55-103 reserved: 0-2,52-54 net: userLevelNetworking: true nodeSelector: node-role.kubernetes.io/worker-cnf: ""
使用这个示例性能配置集,将所有与任何定义的设备标识符匹配的保留 CPU 数设置为保留的 CPU 计数:
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: manual spec: cpu: isolated: 3-51,55-103 reserved: 0-2,52-54 net: userLevelNetworking: true devices: - interfaceName: "eth0" - interfaceName: "eth1" - vendorID: "0x1af4" deviceID: "0x1000" nodeSelector: node-role.kubernetes.io/worker-cnf: ""
使用这个示例性能配置集,将所有以接口名称
eth
开头的设备的队列数设置为保留的 CPU 计数:apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: manual spec: cpu: isolated: 3-51,55-103 reserved: 0-2,52-54 net: userLevelNetworking: true devices: - interfaceName: "eth*" nodeSelector: node-role.kubernetes.io/worker-cnf: ""
使用这个示例性能配置集。将所有设备的队列数设置为保留的 CPU 计数,该接口具有
eno1
以外的任何接口:apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: manual spec: cpu: isolated: 3-51,55-103 reserved: 0-2,52-54 net: userLevelNetworking: true devices: - interfaceName: "!eno1" nodeSelector: node-role.kubernetes.io/worker-cnf: ""
使用这个示例性能配置集,将所有具有接口名称
eth0
,vendorID
为0x1af4
、deviceID
为0x1000
的设备的队列数设置为保留 CPU 数:apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: manual spec: cpu: isolated: 3-51,55-103 reserved: 0-2,52-54 net: userLevelNetworking: true devices: - interfaceName: "eth0" - vendorID: "0x1af4" deviceID: "0x1000" nodeSelector: node-role.kubernetes.io/worker-cnf: ""
应用更新的性能配置集:
$ oc apply -f <your_profile_name>.yaml
其他资源
14.2.9.2. 验证队列状态
在这一部分中,一些示例演示了不同的性能配置集以及如何验证是否应用了更改。
示例 1
在本例中,网络队列数为所有支持的设备设置为保留 CPU 数(2)。
性能配置集中的相关部分是:
apiVersion: performance.openshift.io/v2 metadata: name: performance spec: kind: PerformanceProfile spec: cpu: reserved: 0-1 #total = 2 isolated: 2-8 net: userLevelNetworking: true # ...
使用以下命令显示与设备关联的队列状态:
注意在应用了性能配置集的节点中运行这个命令。
$ ethtool -l <device>
在应用配置集前验证队列状态:
$ ethtool -l ens4
输出示例
Channel parameters for ens4: Pre-set maximums: RX: 0 TX: 0 Other: 0 Combined: 4 Current hardware settings: RX: 0 TX: 0 Other: 0 Combined: 4
应用配置集后验证队列状态:
$ ethtool -l ens4
输出示例
Channel parameters for ens4: Pre-set maximums: RX: 0 TX: 0 Other: 0 Combined: 4 Current hardware settings: RX: 0 TX: 0 Other: 0 Combined: 2 1
- 1
- 该组合通道显示为所有支持的设备保留 CPU 的总数为 2。这与性能配置集中配置的内容匹配。
示例 2
在本例中,针对具有特定 vendorID
的所有受支持的网络设备,网络队列数设置为保留 CPU 数(2)。
性能配置集中的相关部分是:
apiVersion: performance.openshift.io/v2 metadata: name: performance spec: kind: PerformanceProfile spec: cpu: reserved: 0-1 #total = 2 isolated: 2-8 net: userLevelNetworking: true devices: - vendorID = 0x1af4 # ...
使用以下命令显示与设备关联的队列状态:
注意在应用了性能配置集的节点中运行这个命令。
$ ethtool -l <device>
应用配置集后验证队列状态:
$ ethtool -l ens4
输出示例
Channel parameters for ens4: Pre-set maximums: RX: 0 TX: 0 Other: 0 Combined: 4 Current hardware settings: RX: 0 TX: 0 Other: 0 Combined: 2 1
- 1
- 带有
vendorID=0x1af4
的所有支持设备的预留 CPU 总数为 2。例如,如果存在另一个网络设备ens2
,其vendorID=0x1af4
也具有总计的网络队列为 2。这与性能配置集中配置的内容匹配。
示例 3
在本例中,针对与任何定义的设备标识符匹配的所有受支持网络设备,网络队列数设置为保留 CPU 数(2)。
命令 udevadm info
提供了有关设备的详细报告。在这个示例中,设备是:
# udevadm info -p /sys/class/net/ens4 ... E: ID_MODEL_ID=0x1000 E: ID_VENDOR_ID=0x1af4 E: INTERFACE=ens4 ...
# udevadm info -p /sys/class/net/eth0 ... E: ID_MODEL_ID=0x1002 E: ID_VENDOR_ID=0x1001 E: INTERFACE=eth0 ...
对于
interfaceName
等于eth0
的设备,以及具有vendorID=0x1af4
的设备,并使用以下性能配置集,将网络队列设置为 2:apiVersion: performance.openshift.io/v2 metadata: name: performance spec: kind: PerformanceProfile spec: cpu: reserved: 0-1 #total = 2 isolated: 2-8 net: userLevelNetworking: true devices: - interfaceName = eth0 - vendorID = 0x1af4 ...
应用配置集后验证队列状态:
$ ethtool -l ens4
输出示例
Channel parameters for ens4: Pre-set maximums: RX: 0 TX: 0 Other: 0 Combined: 4 Current hardware settings: RX: 0 TX: 0 Other: 0 Combined: 2 1
- 1
- 带有
vendorID=0x1af4
的所有支持设备的预留 CPU 总数设置为 2。例如,如果存在另一个带有vendorID=0x1af4
的网络设备ens2
,则其总子网队列也将设置为 2。类似地,interfaceName
等于eth0
的设备会将总网络队列设置为 2。
14.2.9.3. 与调整 NIC 队列关联的日志记录
详细说明所分配设备的日志消息记录在相应的 Tuned 守护进程日志中。以下信息可能会记录到 /var/log/tuned/tuned.log
文件中:
记录了一个
INFO
信息,详细描述了成功分配的设备:INFO tuned.plugins.base: instance net_test (net): assigning devices ens1, ens2, ens3
如果无法分配任何设备,则会记录
WARNING
信息:WARNING tuned.plugins.base: instance net_test: no matching devices available