$ oc label node <node_name> node-role.kubernetes.io/worker-cnf="" (1)
通过使用集群性能配置文件来调整节点以实现低延迟。您可以限制基础设施和应用程序容器的 CPU,配置巨页、超线程以及为延迟敏感进程配置 CPU 分区。
您可以使用性能配置文件创建器 (PPC) 工具创建集群性能配置文件。PPC 是节点调整运算符的一个功能。
PPC 将有关集群的信息与用户提供的配置相结合,以生成适合您的硬件、拓扑结构和用例的性能配置文件。
性能配置文件仅适用于集群可以直接访问底层硬件资源的裸机环境。您可以为单节点 OpenShift 集群和多节点集群配置性能配置文件。 |
以下是您在集群中创建和应用性能配置文件的高级工作流程
为要使用性能配置作为目标的节点创建机器配置池 (MCP)。在单节点 OpenShift 集群中,您必须使用master
MCP,因为集群中只有一个节点。
使用must-gather
命令收集有关集群的信息。
使用 PPC 工具通过以下任一方法创建性能配置文件
使用 Podman 运行 PPC 工具。
使用包装器脚本运行 PPC 工具。
为您的用例配置性能配置文件并将性能配置文件应用于您的集群。
性能配置文件创建器 (PPC) 是一个命令行工具,随节点调整运算符一起提供,可帮助您为集群创建性能配置文件。
最初,您可以使用 PPC 工具处理must-gather
数据以显示集群的关键性能配置,包括以下信息
使用已分配的 CPU ID 进行 NUMA 单元分区
超线程节点配置
您可以使用此信息来帮助您配置性能配置文件。
向 PPC 工具指定性能配置参数以生成适合您的硬件、拓扑结构和用例的建议性能配置文件。
您可以使用以下任一方法运行 PPC
使用 Podman 运行 PPC
使用包装器脚本运行 PPC
使用包装器脚本将一些更细粒度的 Podman 任务抽象到可执行脚本中。例如,包装器脚本处理诸如拉取和运行所需的容器映像、将目录安装到容器以及通过 Podman 直接向容器提供参数等任务。两种方法都能达到相同的结果。 |
对于多节点集群,您可以定义一个机器配置池 (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
资源
创建一个 YAML 文件,定义MachineConfigPool
资源
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)
1 | 指定MachineConfigPool 资源的名称。 |
2 | 为机器配置池指定一个唯一的标签。 |
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
性能配置文件创建器 (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 数据文件夹的名称。 |
如果您运行性能配置文件创建器包装器脚本,则需要压缩输出。 |
有关must-gather
工具的更多信息,请参阅收集有关集群的数据。
作为集群管理员,您可以将 Podman 与性能配置文件创建器 (PPC) 一起使用来创建性能配置文件。
有关 PPC 参数的更多信息,请参阅“性能配置文件创建器参数”部分。
PPC 使用来自您集群的 |
以具有cluster-admin
角色的用户身份访问集群。
安装在裸机硬件上的集群。
您已安装podman
和 OpenShift CLI (oc
)。
访问节点调整操作符镜像。
您已标识包含目标配置节点的机器配置池。
您可以访问集群的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.17 -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.17 --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.17 --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。
此示例中的 |
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
包装器脚本简化了使用性能配置文件创建器 (PPC) 工具创建性能配置文件的过程。该脚本处理诸如提取和运行所需容器镜像、将目录挂载到容器以及通过 Podman 直接向容器提供参数等任务。
有关性能配置文件创建器参数的更多信息,请参阅“性能配置文件创建器参数”部分。
PPC 使用来自您集群的 |
以具有cluster-admin
角色的用户身份访问集群。
安装在裸机硬件上的集群。
您已安装podman
和 OpenShift CLI (oc
)。
访问节点调整操作符镜像。
您已标识包含目标配置节点的机器配置池。
访问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.17"
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
您可以使用 |
要显示有关集群的信息,请使用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 的目录的路径。这是包装器脚本的必需参数。
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。
此示例中的 |
通过运行以下命令查看已创建的 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
参数 | 描述 |
---|---|
|
MCP 的名称;例如,对应于目标机器的 |
|
must-gather 目录的路径。 仅当您使用 Podman 运行 PPC 工具时,才需要此参数。如果您使用包装器脚本使用 PPC,请勿使用此参数。而是使用包装器脚本的 |
|
保留的 CPU 数量。使用大于零的自然数。 |
|
启用实时内核。 可能的值: |
参数 | 描述 | ||
---|---|---|---|
|
禁用超线程。 可能的值: 默认值:
|
||
enable-hardware-tuning |
启用最大 CPU 频率设置。 要启用此功能,请为在隔离和保留 CPU 上运行的应用程序设置以下两个字段的最大频率
这是一个高级功能。如果配置了硬件调整,则生成的 |
||
|
这会捕获集群信息。此参数还需要 可能的值
默认值: |
||
|
已下线的 CPU 数量。
|
||
|
功耗模式。 可能的值
默认值: |
||
|
启用每个 Pod 的电源管理。如果将 可能的值: 默认值: |
||
|
要创建的性能配置文件的名称。 默认值: |
||
|
将保留的 CPU 分散到 NUMA 节点上。 可能的值: 默认值: |
||
|
要创建的性能配置文件的 Kubelet Topology Manager 策略。 可能的值
默认值: |
||
|
启用用户级网络 (DPDK) 后运行。 可能的值: 默认值: |
使用以下参考性能配置文件作为开发您自己的自定义配置文件的基础。
为了最大限度地提高在 Red Hat OpenStack Platform (RHOSP) 上使用数据平面开发套件 (OVS-DPDK) 的 Open vSwitch 的集群中的机器性能,您可以使用性能配置文件。
您可以使用以下性能配置文件模板为您的部署创建配置文件。
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
键插入适合您配置的值。
以下性能配置文件配置商品硬件上 OpenShift Container Platform 集群的节点级性能设置,以承载电信 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
以下性能配置文件配置商品硬件上 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
节点调整操作符支持性能配置文件apiVersion
字段的v2
、v1
和v1alpha1
。v1 和 v1alpha1 API 是相同的。v2 API 包含一个可选的布尔字段globallyDisableIrqLoadBalancing
,其默认值为false
。
当您将节点调整操作符性能配置文件自定义资源定义 (CRD) 从 v1 或 v1alpha1 升级到 v2 时,globallyDisableIrqLoadBalancing
在现有配置文件中设置为true
。
|
将节点调整操作符 API 版本从 v1alpha1 升级到 v1 时,v1alpha1 性能配置文件将使用“无”转换策略动态转换,并以 API 版本 v1 提供给节点调整操作符。
从较旧的节点调整操作符 API 版本升级时,现有 v1 和 v1alpha1 性能配置文件将使用注入值为true
的globallyDisableIrqLoadBalancing
字段的转换 Webhook 进行转换。
使用性能配置文件创建器 (PPC) 工具创建适合环境硬件和拓扑结构的PerformanceProfile
。下表描述了为与 PPC 工具关联的power-consumption-mode
标志设置的可能值以及应用的工作负载提示。
性能配置文件创建器设置 | 提示 | 环境 | 描述 |
---|---|---|---|
默认 |
|
无需延迟要求的高吞吐量集群 |
仅通过 CPU 分区实现的性能。 |
低延迟 |
|
区域数据中心 |
既需要节能又需要低延迟:在电源管理、延迟和吞吐量之间进行折衷。 |
超低延迟 |
|
远端边缘集群,延迟关键型工作负载 |
针对绝对最小的延迟和最大的确定性进行了优化,但会增加功耗。 |
每个 Pod 的电源管理 |
|
关键和非关键工作负载 |
允许每个 Pod 进行电源管理。 |
以下配置通常用于电信 RAN DU 部署中。
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
name: workload-hints
spec:
...
workloadHints:
realTime: true
highPowerConsumption: false
perPodPowerManagement: false (1)
1 | 禁用一些可能会影响系统延迟的调试和监控功能。 |
当在性能配置文件中将 |
有关功耗和实时设置组合如何影响延迟的更多信息,请参见了解工作负载提示。
您可以为具有与高优先级工作负载协同定位的低优先级工作负载的节点启用节能,而不会影响高优先级工作负载的延迟或吞吐量。无需修改工作负载本身即可实现节能。
此功能在英特尔 Ice Lake 和更高版本的英特尔 CPU 上受支持。处理器的功能可能会影响高优先级工作负载的延迟和吞吐量。 |
您已在 BIOS 中启用 C 状态和操作系统控制的 P 状态
使用设置为true
的per-pod-power-management
参数生成PerformanceProfile
$ podman run --entrypoint performance-profile-creator -v \
/must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.17 \
--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 调节器。 |
在TunedPerformancePatch
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 中检查最大支持频率。作为起点,您可以使用一个百分比,将所有 CPU 的频率限制在“所有核心 Turbo”频率。 “所有核心 Turbo”频率是指所有核心完全占用时所有核心运行的频率。 |
通用的维护和工作负载任务使用 CPU 的方式可能会影响对延迟敏感的进程。默认情况下,容器运行时使用所有在线 CPU 来同时运行所有容器,这可能会导致上下文切换和延迟峰值。通过将这些进程彼此分离,CPU 分区可以防止有干扰的进程干扰对延迟敏感的进程。
进程类型 | 详情 |
---|---|
|
运行在除低延迟工作负载运行的 CPU 之外的任何 CPU 上。 |
基础设施 Pod |
运行在除低延迟工作负载运行的 CPU 之外的任何 CPU 上。 |
中断 |
重定向到保留的 CPU(在 OpenShift Container Platform 4.7 及更高版本中可选)。 |
内核进程 |
固定到保留的 CPU。 |
对延迟敏感的工作负载 Pod |
固定到隔离池中的一组特定的专用 CPU。 |
OS 进程/systemd 服务 |
固定到保留的 CPU。 |
节点上所有 QoS 进程类型(Burstable
、BestEffort
或 Guaranteed
)的 Pod 的可分配核心容量等于隔离池的容量。保留池的容量从节点的总核心容量中移除,供集群和操作系统维护任务使用。
一个节点的容量为 100 个核心。使用性能配置文件,集群管理员将 50 个核心分配给隔离池,50 个核心分配给保留池。集群管理员将 25 个核心分配给 QoS Guaranteed
Pod,25 个核心分配给 BestEffort
或 Burstable
Pod。这与隔离池的容量相匹配。
一个节点的容量为 100 个核心。使用性能配置文件,集群管理员将 50 个核心分配给隔离池,50 个核心分配给保留池。集群管理员将 50 个核心分配给 QoS Guaranteed
Pod,一个核心分配给 BestEffort
或 Burstable
Pod。这比隔离池的容量多了一个核心。由于 CPU 容量不足,Pod 调度失败。
要使用的确切分区模式取决于许多因素,例如硬件、工作负载特性和预期的系统负载。以下是一些示例用例:
如果对延迟敏感的工作负载使用特定的硬件,例如网络接口控制器 (NIC),请确保隔离池中的 CPU 尽可能靠近此硬件。至少,您应该将工作负载放在同一个非一致性内存访问 (NUMA) 节点中。
保留池用于处理所有中断。当依赖系统网络时,请分配一个足够大的保留池来处理所有传入的数据包中断。在 4.17 和更高版本中,工作负载可以选择性地标记为敏感。
关于哪些特定的 CPU 应该用于保留和隔离分区,需要进行详细的分析和测量。设备和内存的 NUMA 亲和性等因素起着作用。选择还取决于工作负载架构和具体的用例。
保留和隔离的 CPU 池不能重叠,并且必须共同涵盖工作节点中的所有可用核心。 |
为了确保维护任务和工作负载不会相互干扰,请在性能配置文件的spec
部分中指定两组 CPU。
isolated
- 指定应用程序容器工作负载的 CPU。这些 CPU 的延迟最低。此组中的进程没有中断,例如,可以达到更高的 DPDK 零丢包带宽。
reserved
- 指定集群和操作系统维护任务的 CPU。reserved
组中的线程通常很繁忙。不要在reserved
组中运行对延迟敏感的应用程序。对延迟敏感的应用程序应在isolated
组中运行。
创建适合环境硬件和拓扑结构的性能配置文件。
添加reserved
和isolated
参数,以及您希望为基础设施和应用程序容器保留和隔离的 CPU。
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: ""
1 | 指定哪些 CPU 用于基础设施容器执行集群和操作系统维护任务。 |
2 | 指定哪些 CPU 用于应用程序容器运行工作负载。 |
3 | 可选:指定节点选择器以将性能配置文件应用于特定节点。 |
要为 OpenShift Container Platform 集群配置超线程,请在性能配置文件中将 CPU 线程设置为与为保留或隔离 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 在物理核心 0 上运行,CPU1 和 CPU5 在物理核心 1 上运行,依此类推。
或者,要查看为特定物理 CPU 核心(以下示例中的cpu0
)设置的线程,请打开 shell 提示符并运行以下命令:
$ 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 中的基础设施容器将使用保留的 CPU,而应用程序容器将使用隔离的 CPU。
...
cpu:
isolated: 0,4
reserved: 1-3,5-7
...
保留和隔离的 CPU 池不能重叠,并且必须共同涵盖工作节点中的所有可用核心。 |
大多数英特尔处理器默认启用超线程。如果启用超线程,则特定核心处理的所有线程都必须在同一核心上被隔离或处理。 启用超线程后,所有保证型 Pod 必须使用同步多线程 (SMT) 级别倍数,以避免可能导致 Pod 失败的“嘈杂邻居”情况。有关详细信息,请参阅静态策略选项。 |
为低延迟处理配置集群时,请考虑在部署集群之前是否要禁用超线程。要禁用超线程,请执行以下步骤:
创建一个适合您的硬件和拓扑结构的性能配置文件。
将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 中的基础设施容器将使用保留的 CPU,而应用程序容器将使用隔离的 CPU。 |
节点调优操作符 (Node Tuning Operator) 可以管理主机 CPU,将其划分为集群和操作系统维护任务(包括 Pod 基础设施容器)的保留 CPU 和应用程序容器运行工作负载的隔离 CPU。这允许您将 CPU 设置为低延迟工作负载的隔离 CPU。
设备中断在所有隔离的和保留的 CPU 之间进行负载均衡,以避免 CPU 过载,但运行保证型 Pod 的 CPU 除外。当为 Pod 设置相关的注释时,将阻止保证型 Pod CPU 处理设备中断。
在性能配置文件中,globallyDisableIrqLoadBalancing
用于管理是否处理设备中断。对于某些工作负载,保留的 CPU 并不总是足以处理设备中断,因此,不会全局禁用隔离 CPU 上的设备中断。默认情况下,节点调优操作符不会禁用隔离 CPU 上的设备中断。
某些 IRQ 控制器缺乏对 IRQ 亲缘性设置的支持,并将始终公开所有在线 CPU 作为 IRQ 掩码。这些 IRQ 控制器实际上在 CPU 0 上运行。
以下是 Red Hat 已知缺乏 IRQ 亲缘性设置支持的驱动程序和硬件示例。此列表并非详尽无遗。
某些 RAID 控制器驱动程序,例如 megaraid_sas
许多非易失性内存高速 (NVMe) 驱动程序
某些主板上的局域网 (LOM) 网络控制器
驱动程序使用 managed_irqs
它们不支持 IRQ 亲缘性设置的原因可能与处理器类型、IRQ 控制器或主板中的电路连接等因素有关。 |
如果任何 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,也无法更改其亲缘性。
配置集群节点以进行 IRQ 动态负载均衡,以控制哪些核心可以接收设备中断请求 (IRQ)。
对于核心隔离,所有服务器硬件组件都必须支持 IRQ 亲缘性。要检查服务器的硬件组件是否支持 IRQ 亲缘性,请查看服务器的硬件规格或联系您的硬件提供商。
以具有集群管理员权限的用户身份登录到 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 和隔离 CPU 后,操作系统进程、内核进程和 systemd 服务将在保留 CPU 上运行。基础设施 Pod 将在任何 CPU 上运行,低延迟工作负载运行的 CPU 除外。低延迟工作负载 Pod 将在隔离池中的专用 CPU 上运行。有关更多信息,请参见“限制基础设施和应用程序容器的 CPU”。 |
节点必须预分配在 OpenShift Container Platform 集群中使用的巨页。使用节点调优操作符在特定节点上分配巨页。
OpenShift Container Platform 提供了一种创建和分配巨页的方法。节点调优操作符提供了一种更简单的方法,可以使用性能配置文件来完成此操作。
例如,在性能配置文件的 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-###: ###
节点调优操作符有助于减少 NIC 队列以提高性能。调整是使用性能配置文件进行的,允许自定义不同网络设备的队列。
性能配置文件允许您调整每个网络设备的队列计数。
支持的网络设备
非虚拟网络设备
支持多个队列(通道)的网络设备
不支持的网络设备
纯软件网络接口
块设备
Intel DPDK 虚拟函数
以具有cluster-admin
角色的用户身份访问集群。
安装 OpenShift CLI (oc
)。
以具有 cluster-admin
权限的用户身份登录到运行节点调优操作符的 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
:以 16 位十六进制数表示的网络设备厂商 ID,带有 0x
前缀。
deviceID
:以 16 位十六进制数表示的网络设备 ID(型号),带有 0x
前缀。
如果指定了 如果指定了两个或多个设备,则网络队列计数将设置为与其中一个设备匹配的任何网络设备的计数。 |
使用此示例性能配置文件,将所有设备的队列计数设置为预留的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计数。
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: ""
使用此示例性能配置文件,将所有接口名称不是eno1
的设备的队列计数设置为预留的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: "!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
在本节中,一些示例说明了不同的性能配置文件以及如何验证更改是否已应用。
在此示例中,所有支持的设备的网络队列计数均设置为预留的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。这与性能配置文件中配置的内容相匹配。 |
在此示例中,所有支持的具有特定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。这与性能配置文件中配置的内容相匹配。 |
在此示例中,所有支持的与任何已定义设备标识符匹配的网络设备的网络队列计数均设置为预留的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。例如,如果另一个网络设备ens2 的vendorID=0x1af4 ,则其总网络队列数也设置为2。同样,interfaceName 等于eth0 的设备的总网络队列数也将设置为2。 |