22.7. vDU 애플리케이션 워크로드에 대한 단일 노드 OpenShift 클러스터 튜닝 검증
vDU(가상 분산 장치) 애플리케이션을 배포하기 전에 클러스터 호스트 펌웨어 및 기타 다양한 클러스터 구성 설정을 튜닝하고 구성해야 합니다. 다음 정보를 사용하여 vDU 워크로드를 지원하는 클러스터 구성의 유효성을 검증합니다.
추가 리소스
- vDU 애플리케이션 배포를 위해 조정된 단일 노드 OpenShift 클러스터에 대한 자세한 내용은 단일 노드 OpenShift에 vDU 배포를 위한 참조 구성 을 참조하십시오.
22.7.1. vDU 클러스터 호스트에 권장되는 펌웨어 구성
다음 표를 기준으로 사용하여 OpenShift Container Platform 4.11에서 실행되는 vDU 애플리케이션의 클러스터 호스트 펌웨어를 구성합니다.
다음 표는 vDU 클러스터 호스트 펌웨어 구성에 대한 일반적인 권장 사항입니다. 정확한 펌웨어 설정은 요구 사항 및 특정 하드웨어 플랫폼에 따라 다릅니다. 펌웨어 자동 설정은 제로 툴 프로비저닝 파이프라인에 의해 처리되지 않습니다.
펌웨어 설정 | 설정 | 설명 |
---|---|---|
HyperTransport (HT) | 활성화됨 | HyperTransport (HT) 버스는 AMD에서 개발한 버스 기술입니다. HT는 호스트 메모리의 구성 요소와 다른 시스템 주변 장치 간의 고속 링크를 제공합니다. |
UEFI | 활성화됨 | vDU 호스트의 UEFI에서 부팅을 활성화합니다. |
CPU 전원 및 성능 정책 | 성능 | CPU 전원 및 성능 정책을 설정하여 전력 효율성보다 성능을 최적화합니다. |
코어 빈도 스케일링 | 비활성화됨 | CPU가 아닌 부분의 가중 및 빈도가 독립적으로 설정되지 않도록 Uncore Frequency 스케일링을 비활성화합니다. |
Uncore Frequency | 최대 | 캐시 및 메모리 컨트롤러와 같은 CPU의 코어가 아닌 부분을 최대 작업 빈도로 설정합니다. |
성능 P-limit | 비활성화됨 | 프로세서의 Uncore 빈도 조정되지 않도록 성능 P-limit를 비활성화합니다. |
향상된 Intel® SpeedStep Tech | 활성화됨 | 강화된 Intel SpeedStep을 사용하면 시스템이 호스트의 전력 소비와 heat 프로덕션을 줄이는 프로세서의 부족과 코어 빈도를 동적으로 조정할 수 있습니다. |
Intel® Turbo Boost Technology | 활성화됨 | 활성화된 Intel 기반 CPU용 FeatureGate Boost Technology를 사용하면 프로세서 코어가 전력, 현재 및 온도 사양 제한 미만의 작동 빈도보다 프로세서 코어를 자동으로 실행할 수 있습니다. |
Intel Configurable TDP | 활성화됨 | CPU에 대해 TDP(rmal Design Power)를 활성화합니다. |
구성 가능한 TDP 수준 | 수준 2 | TDP 수준은 특정 성능 등급에 필요한 CPU 전력 사용량을 설정합니다. TDP 레벨 2는 전력 소비에 따라 CPU를 가장 안정적인 성능 수준으로 설정합니다. |
energy Efficient 터 | 비활성화됨 | VMC Efficient FeatureGate를 비활성화하여 프로세서가 전력 효율성 기반 정책을 사용하지 못하도록 합니다. |
하드웨어 P-States | 비활성화됨 |
|
패키지 C-State | C0/C1 상태 | C0 또는 C1 상태를 사용하여 프로세서를 완전히 활성 상태(C0)로 설정하거나 소프트웨어 (C1)에서 실행되는 CPU 내부 클럭을 중지합니다. |
C1E | 비활성화됨 | CPU Enhanced Halt (C1E)는 Intel 칩의 전력 절약 기능입니다. C1E를 비활성화하면 운영 체제가 비활성화될 때 CPU에 stop 명령을 보내지 않습니다. |
프로세서 C6 | 비활성화됨 | C6 절전은 유휴 CPU 코어 및 캐시를 자동으로 비활성화하는 CPU 기능입니다. C6을 비활성화하면 시스템 성능이 향상됩니다. |
하위 NUMA 클러스터링 | 비활성화됨 | 하위 NUMA 클러스터링은 프로세서 코어, 캐시 및 메모리를 여러 NUMA 도메인으로 나눕니다. 이 옵션을 비활성화하면 대기 시간에 민감한 워크로드의 성능이 향상될 수 있습니다. |
호스트의 펌웨어에서 글로벌 SR-IOV 및 VT-d 설정을 활성화합니다. 이러한 설정은 베어 메탈 환경과 관련이 있습니다.
22.7.2. vDU 애플리케이션을 실행하기 위한 권장 클러스터 구성
가상화된 DCN(Distributed Unit) 애플리케이션을 실행하는 클러스터에는 고도로 조정되고 최적화된 구성이 필요합니다. 다음 정보는 OpenShift Container Platform 4.11 클러스터에서 vDU 워크로드를 지원하는 데 필요한 다양한 요소를 설명합니다.
22.7.2.1. 권장되는 클러스터 MachineConfig CR
ztp-site-generate
컨테이너에서 추출한 MachineConfig
사용자 정의 리소스(CR)가 클러스터에 적용되었는지 확인합니다. CR은 추출된 out/source-crs/extra-manifest/
폴더에 있습니다.
ztp-site-generate
컨테이너의 다음 MachineConfig
CR은 클러스터 호스트를 구성합니다.
CR filename | 설명 |
---|---|
|
클러스터의 워크로드 파티셔닝을 구성합니다. 클러스터를 설치할 때 이 |
|
SCTP 커널 모듈을 로드합니다. 이러한 |
| 컨테이너 마운트 네임스페이스 및 Kubelet 구성을 구성합니다. |
| 클러스터의 빠른 시작을 구성합니다. |
|
클러스터에 대한 |
22.7.2.2. 권장되는 클러스터 Operator
다음 Operator는 가상화된 분산 장치(vDU) 애플리케이션을 실행하는 클러스터에 필요하며 기준 참조 구성의 일부입니다.
- Node Tuning Operator(NTO). NTO 패키지 기능은 이제 NTO의 일부인 Performance Addon Operator와 함께 제공되었습니다.
- PTP Operator
- SR-IOV 네트워크 Operator
- Red Hat OpenShift Logging Operator
- Local Storage Operator
22.7.2.3. 권장되는 클러스터 커널 구성
클러스터에서 항상 지원되는 최신 실시간 커널 버전을 사용하십시오. 클러스터에서 다음 구성을 적용해야 합니다.
클러스터 성능 프로필에 다음
additionalKernelArgs
가 설정되어 있는지 확인합니다.spec: additionalKernelArgs: - "rcupdate.rcu_normal_after_boot=0" - "efi=runtime"
Tuned
CR의performance-patch
프로필이 관련PerformanceProfile
CR에서 설정된 분리된 CPU와 일치하는 올바른 CPU격리
세트를 구성합니다. 예를 들면 다음과 같습니다.spec: profile: - name: performance-patch # The 'include' line must match the associated PerformanceProfile name # And the cmdline_crash CPU set must match the 'isolated' set in the associated PerformanceProfile data: | [main] summary=Configuration changes profile inherited from performance created tuned include=openshift-node-performance-openshift-node-performance-profile [bootloader] cmdline_crash=nohz_full=2-51,54-103 1 [sysctl] kernel.timer_migration=1 [scheduler] group.ice-ptp=0:f:10:*:ice-ptp.* [service] service.stalld=start,enable service.chronyd=stop,disable
- 1
- 나열된 CPU는 호스트 하드웨어 구성, 특히 시스템 및 CPU 토폴로지에서 사용 가능한 CPU 수에 따라 다릅니다.
22.7.2.4. 실시간 커널 버전 확인
OpenShift Container Platform 클러스터에서 항상 최신 버전의 realtime 커널을 사용하십시오. 클러스터에서 사용 중인 커널 버전에 대해 확실하지 않은 경우 현재 실시간 커널 버전을 릴리스 버전과 다음 절차와 비교할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 로그인되어 있습니다. -
podman
이 설치되어 있어야 합니다.
절차
다음 명령을 실행하여 클러스터 버전을 가져옵니다.
$ OCP_VERSION=$(oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}')
릴리스 이미지 SHA 번호를 가져옵니다.
$ DTK_IMAGE=$(oc adm release info --image-for=driver-toolkit quay.io/openshift-release-dev/ocp-release:$OCP_VERSION-x86_64)
릴리스 이미지 컨테이너를 실행하고 클러스터의 현재 릴리스와 함께 패키지로 제공되는 커널 버전을 추출합니다.
$ podman run --rm $DTK_IMAGE rpm -qa | grep 'kernel-rt-core-' | sed 's#kernel-rt-core-##'
출력 예
4.18.0-305.49.1.rt7.121.el8_4.x86_64
이는 릴리스와 함께 제공되는 기본 실시간 커널 버전입니다.
참고realtime 커널은 커널 버전의
.rt
문자열로 표시됩니다.
검증
클러스터의 현재 릴리스에 대해 나열된 커널 버전이 클러스터에서 실행 중인 실제 실시간 커널과 일치하는지 확인합니다. 다음 명령을 실행하여 실행 중인 실시간 커널 버전을 확인합니다.
클러스터 노드에 대한 원격 쉘 연결을 엽니다.
$ oc debug node/<node_name>
실시간 커널 버전을 확인합니다.
sh-4.4# uname -r
출력 예
4.18.0-305.49.1.rt7.121.el8_4.x86_64
22.7.3. 권장 클러스터 구성 적용
클러스터가 올바른 구성을 실행 중인지 확인할 수 있습니다. 다음 절차에서는 OpenShift Container Platform 4.11 클러스터에서 DU 애플리케이션을 배포하는 데 필요한 다양한 구성을 확인하는 방법을 설명합니다.
사전 요구 사항
- 클러스터를 배포하고 vDU 워크로드에 맞게 조정했습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 로그인했습니다.
절차
기본 OperatorHub 소스가 비활성화되어 있는지 확인합니다. 다음 명령을 실행합니다.
$ oc get operatorhub cluster -o yaml
출력 예
spec: disableAllDefaultSources: true
다음 명령을 실행하여 워크로드 분할(
PreferredDuringScheduling
)에 필요한 모든CatalogSource
리소스에 주석이 추가되었는지 확인합니다.$ oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'
출력 예
certified-operators -- {"effect": "PreferredDuringScheduling"} community-operators -- {"effect": "PreferredDuringScheduling"} ran-operators 1 redhat-marketplace -- {"effect": "PreferredDuringScheduling"} redhat-operators -- {"effect": "PreferredDuringScheduling"}
- 1
- 주석이 없는
CatalogSource
리소스도 반환됩니다. 이 예에서는ran-operators
CatalogSource
리소스에 주석이 추가되지 않으며PreferredDuringScheduling
주석이 없습니다.
참고올바르게 구성된 vDU 클러스터에는 주석이 있는 단일 카탈로그 소스만 나열됩니다.
적용 가능한 모든 OpenShift Container Platform Operator 네임 스페이스가 워크로드 파티셔닝을 위해 주석이 추가되었는지 확인합니다. 여기에는 핵심 OpenShift Container Platform과 참조 DU 튜닝 구성에 포함된 추가 Operator 세트를 사용하여 설치된 모든 Operator가 포함됩니다. 다음 명령을 실행합니다.
$ oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'
출력 예
default -- openshift-apiserver -- management openshift-apiserver-operator -- management openshift-authentication -- management openshift-authentication-operator -- management
중요워크로드 파티셔닝을 위해 추가 Operator에 주석을 달 수 없습니다. 이전 명령의 출력에서
--
separator의 오른쪽에 있는 값 없이 추가 Operator를 나열해야 합니다.ClusterLogging
구성이 올바른지 확인합니다. 다음 명령을 실행합니다.적절한 입력 및 출력 로그가 구성되어 있는지 확인합니다.
$ oc get -n openshift-logging ClusterLogForwarder instance -o yaml
출력 예
apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: creationTimestamp: "2022-07-19T21:51:41Z" generation: 1 name: instance namespace: openshift-logging resourceVersion: "1030342" uid: 8c1a842d-80c5-447a-9150-40350bdf40f0 spec: inputs: - infrastructure: {} name: infra-logs outputs: - name: kafka-open type: kafka url: tcp://10.46.55.190:9092/test pipelines: - inputRefs: - audit name: audit-logs outputRefs: - kafka-open - inputRefs: - infrastructure name: infrastructure-logs outputRefs: - kafka-open ...
큐레이션 일정이 애플리케이션에 적합한지 확인합니다.
$ oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yaml
출력 예
apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: creationTimestamp: "2022-07-07T18:22:56Z" generation: 1 name: instance namespace: openshift-logging resourceVersion: "235796" uid: ef67b9b8-0e65-4a10-88ff-ec06922ea796 spec: collection: logs: fluentd: {} type: fluentd curation: curator: schedule: 30 3 * * * type: curator managementState: Managed ...
다음 명령을 실행하여 웹 콘솔이 비활성화(
managementState: Removed
)인지 확인합니다.$ oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"
출력 예
Removed
다음 명령을 실행하여 클러스터 노드에서
chronyd
가 비활성화되어 있는지 확인합니다.$ oc debug node/<node_name>
노드에서
chronyd
의 상태를 확인합니다.sh-4.4# chroot /host
sh-4.4# systemctl status chronyd
출력 예
● chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:chronyd(8) man:chrony.conf(5)
PTP 인터페이스가
linuxptp-daemon
컨테이너 및 PTP 관리 클라이언트(pmc
) 도구에 원격 쉘 연결을 사용하여 기본 시계와 성공적으로 동기화되었는지 확인합니다.다음 명령을 실행하여
linuxptp-daemon
Pod의 이름으로$PTP_POD_NAME
변수를 설정합니다.$ PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)
다음 명령을 실행하여 PTP 장치의 동기화 상태를 확인합니다.
$ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'
출력 예
sending: GET PORT_DATA_SET 3cecef.fffe.7a7020-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET portIdentity 3cecef.fffe.7a7020-1 portState SLAVE logMinDelayReqInterval -4 peerMeanPathDelay 0 logAnnounceInterval 1 announceReceiptTimeout 3 logSyncInterval 0 delayMechanism 1 logMinPdelayReqInterval 0 versionNumber 2 3cecef.fffe.7a7020-2 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET portIdentity 3cecef.fffe.7a7020-2 portState LISTENING logMinDelayReqInterval 0 peerMeanPathDelay 0 logAnnounceInterval 1 announceReceiptTimeout 3 logSyncInterval 0 delayMechanism 1 logMinPdelayReqInterval 0 versionNumber 2
다음
pmc
명령을 실행하여 PTP 클럭 상태를 확인합니다.$ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET TIME_STATUS_NP'
출력 예
sending: GET TIME_STATUS_NP 3cecef.fffe.7a7020-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP master_offset 10 1 ingress_time 1657275432697400530 cumulativeScaledRateOffset +0.000000000 scaledLastGmPhaseChange 0 gmTimeBaseIndicator 0 lastGmPhaseChange 0x0000'0000000000000000.0000 gmPresent true 2 gmIdentity 3c2c30.ffff.670e00
/var/run/ptp4l.0.config
의 값에 해당하는 예상마스터 오프셋
값이linuxptp-daemon-container
로그에 있는지 확인합니다.$ oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-container
출력 예
phc2sys[56020.341]: [ptp4l.1.config] CLOCK_REALTIME phc offset -1731092 s2 freq -1546242 delay 497 ptp4l[56020.390]: [ptp4l.1.config] master offset -2 s2 freq -5863 path delay 541 ptp4l[56020.390]: [ptp4l.0.config] master offset -8 s2 freq -10699 path delay 533
다음 명령을 실행하여 SR-IOV 구성이 올바른지 확인합니다.
SriovOperatorConfig
리소스의disableDrain
값이true
로 설정되어 있는지 확인합니다.$ oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"
출력 예
true
다음 명령을 실행하여
SriovNetworkNodeState
동기화 상태가Succeeded
상태인지 확인합니다.$ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"
출력 예
Succeeded
SR-IOV용으로 구성된 각 인터페이스에서
Vfs
(가상 기능)의 예상 수 및 구성이 있는지 확인하고.status.interfaces
필드에 올바른지 확인합니다. 예를 들어 다음과 같습니다.$ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yaml
출력 예
apiVersion: v1 items: - apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodeState ... status: interfaces: ... - Vfs: - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.0 vendor: "8086" vfID: 0 - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.1 vendor: "8086" vfID: 1 - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.2 vendor: "8086" vfID: 2 - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.3 vendor: "8086" vfID: 3 - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.4 vendor: "8086" vfID: 4 - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.5 vendor: "8086" vfID: 5 - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.6 vendor: "8086" vfID: 6 - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.7 vendor: "8086" vfID: 7
클러스터 성능 프로필이 올바른지 확인합니다.
cpu
및hugepages
섹션은 하드웨어 구성에 따라 다릅니다. 다음 명령을 실행합니다.$ oc get PerformanceProfile openshift-node-performance-profile -o yaml
출력 예
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: creationTimestamp: "2022-07-19T21:51:31Z" finalizers: - foreground-deletion generation: 1 name: openshift-node-performance-profile resourceVersion: "33558" uid: 217958c0-9122-4c62-9d4d-fdc27c31118c spec: additionalKernelArgs: - idle=poll - rcupdate.rcu_normal_after_boot=0 - efi=runtime cpu: isolated: 2-51,54-103 reserved: 0-1,52-53 hugepages: defaultHugepagesSize: 1G pages: - count: 32 size: 1G machineConfigPoolSelector: pools.operator.machineconfiguration.openshift.io/master: "" net: userLevelNetworking: true nodeSelector: node-role.kubernetes.io/master: "" numa: topologyPolicy: restricted realTimeKernel: enabled: true status: conditions: - lastHeartbeatTime: "2022-07-19T21:51:31Z" lastTransitionTime: "2022-07-19T21:51:31Z" status: "True" type: Available - lastHeartbeatTime: "2022-07-19T21:51:31Z" lastTransitionTime: "2022-07-19T21:51:31Z" status: "True" type: Upgradeable - lastHeartbeatTime: "2022-07-19T21:51:31Z" lastTransitionTime: "2022-07-19T21:51:31Z" status: "False" type: Progressing - lastHeartbeatTime: "2022-07-19T21:51:31Z" lastTransitionTime: "2022-07-19T21:51:31Z" status: "False" type: Degraded runtimeClass: performance-openshift-node-performance-profile tuned: openshift-cluster-node-tuning-operator/openshift-node-performance-openshift-node-performance-profile
참고CPU 설정은 서버에서 사용 가능한 코어 수에 따라 다르며 워크로드 파티션 설정에 맞게 조정해야 합니다.
hugepages
구성은 서버 및 애플리케이션에 따라 다릅니다.다음 명령을 실행하여
PerformanceProfile
이 클러스터에 적용되었는지 확인합니다.$ oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"
출력 예
Available -- True Upgradeable -- True Progressing -- False Degraded -- False
다음 명령을 실행하여
Tuned
성능 패치 설정을 확인합니다.$ oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yaml
출력 예
apiVersion: tuned.openshift.io/v1 kind: Tuned metadata: creationTimestamp: "2022-07-18T10:33:52Z" generation: 1 name: performance-patch namespace: openshift-cluster-node-tuning-operator resourceVersion: "34024" uid: f9799811-f744-4179-bf00-32d4436c08fd spec: profile: - data: | [main] summary=Configuration changes profile inherited from performance created tuned include=openshift-node-performance-openshift-node-performance-profile [bootloader] cmdline_crash=nohz_full=2-23,26-47 1 [sysctl] kernel.timer_migration=1 [scheduler] group.ice-ptp=0:f:10:*:ice-ptp.* [service] service.stalld=start,enable service.chronyd=stop,disable name: performance-patch recommend: - machineConfigLabels: machineconfiguration.openshift.io/role: master priority: 19 profile: performance-patch
- 1
cmdline=nohz_full=
의 cpu 목록은 하드웨어 구성에 따라 달라집니다.
다음 명령을 실행하여 클러스터 네트워킹 진단이 비활성화되어 있는지 확인합니다.
$ oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'
출력 예
true
Kubelet
하우스키핑 간격이 느린 속도로 조정되었는지 확인합니다. 이는containerMountNS
머신 구성에 설정되어 있습니다. 다음 명령을 실행합니다.$ oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION
출력 예
Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"
다음 명령을 실행하여 Grafana 및
alertManagerMain
이 비활성화되어 있으며 Prometheus 보존 기간이 24h로 설정되어 있는지 확인합니다.$ oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"
출력 예
grafana: enabled: false alertmanagerMain: enabled: false prometheusK8s: retention: 24h
다음 명령을 사용하여 Grafana 및
alertManagerMain
경로가 클러스터에 없는 것을 확인합니다.$ oc get route -n openshift-monitoring alertmanager-main
$ oc get route -n openshift-monitoring grafana
두 쿼리 모두
서버(NotFound) 메시지에서 Error
를 반환해야 합니다.
다음 명령을 실행하여
PerformanceProfile
,Tuned
performance-patch, workload partitioning 및 kernel 명령줄 인수 각각에 대해예약된
최소 4개의 CPU가 있는지 확인합니다.$ oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"
출력 예
0-3
참고워크로드 요구 사항에 따라 예약된 CPU를 추가로 할당해야 할 수 있습니다.