13.2. 성능 프로필을 사용하여 짧은 대기 시간을 실현하도록 노드 튜닝


클러스터 성능 프로필을 사용하여 짧은 대기 시간을 위해 노드를 조정합니다. 인프라 및 애플리케이션 컨테이너의 CPU를 제한하고, 대규모 페이지, 하이퍼 스레딩을 구성하고, 대기 시간에 민감한 프로세스를 위해 CPU 파티션을 구성할 수 있습니다.

13.2.1. 성능 프로파일 작성

PPC(Performance Profile Creator) 툴을 사용하여 클러스터 성능 프로필을 생성할 수 있습니다. PPC는 Node Tuning Operator의 기능입니다.

PPC는 사용자 제공 구성과 클러스터에 대한 정보를 결합하여 하드웨어, 토폴로지 및 사용 사례에 적합한 성능 프로필을 생성합니다.

참고

성능 프로필은 클러스터가 기본 하드웨어 리소스에 직접 액세스할 수 있는 베어 메탈 환경에만 적용됩니다. 단일 노드 OpenShift 및 다중 노드 클러스터 모두에 대해 성능 프로필을 구성할 수 있습니다.

다음은 클러스터에서 성능 프로필을 생성하고 적용하기 위한 고급 워크플로입니다.

  • 성능 구성으로 대상으로 지정할 노드의 MCP(머신 구성 풀)를 생성합니다. 단일 노드 OpenShift 클러스터에서는 클러스터에 노드가 하나뿐이므로 마스터 MCP를 사용해야 합니다.
  • must-gather 명령을 사용하여 클러스터에 대한 정보를 수집합니다.
  • PPC 툴을 사용하여 다음 방법 중 하나를 사용하여 성능 프로필을 생성합니다.

    • Podman을 사용하여 PPC 툴을 실행합니다.
    • 래퍼 스크립트를 사용하여 PPC 툴을 실행합니다.
  • 사용 사례에 대한 성능 프로필을 구성하고 클러스터에 성능 프로필을 적용합니다.

13.2.1.1. 성능 프로파일 작성툴 정보

PPC(Performance Profile Creator)는 Node Tuning Operator와 함께 제공되는 명령줄 툴로, 클러스터에 대한 성능 프로필을 생성하는 데 도움이 될 수 있습니다.

처음에 PPC 툴을 사용하여 must-gather 데이터를 처리하여 다음 정보를 포함하여 클러스터의 주요 성능 구성을 표시할 수 있습니다.

  • 할당된 CPU ID로 NUMA 셀 파티셔닝
  • 하이퍼 스레딩 노드 구성

이 정보를 사용하여 성능 프로필을 구성할 수 있습니다.

PPC 실행

PPC 툴에 대한 성능 구성 인수를 지정하여 하드웨어, 토폴로지 및 사용 사례에 적합한 제안된 성능 프로필을 생성합니다.

다음 방법 중 하나를 사용하여 PPC를 실행할 수 있습니다.

  • Podman을 사용하여 PPC 실행
  • 래퍼 스크립트를 사용하여 PPC 실행
참고

래퍼 스크립트를 사용하면 일부 작업은 더 세분화된 Podman 작업을 실행 가능한 스크립트로 추상화합니다. 예를 들어 래퍼 스크립트는 필요한 컨테이너 이미지 가져오기 및 실행, 디렉터리를 컨테이너에 마운트하고 Podman을 통해 컨테이너에 직접 매개 변수를 제공하는 등의 작업을 처리합니다. 두 방법 모두 동일한 결과를 얻을 수 있습니다.

13.2.1.2. 성능 튜닝을 위해 노드를 대상으로 하는 머신 구성 풀 생성

다중 노드 클러스터의 경우 MCP(Machine config pool)를 정의하여 성능 프로필로 구성할 대상 노드를 식별할 수 있습니다.

단일 노드 OpenShift 클러스터에서는 클러스터에 노드가 하나뿐이므로 마스터 MCP를 사용해야 합니다. 단일 노드 OpenShift 클러스터에 대해 별도의 MCP를 생성할 필요가 없습니다.

사전 요구 사항

  • cluster-admin 역할 액세스 권한이 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. 다음 명령을 실행하여 구성의 대상 노드에 레이블을 지정합니다.

    $ oc label node <node_name> node-role.kubernetes.io/worker-cnf="" 1
    1
    & lt;node_name >을 노드 이름으로 바꿉니다. 이 예제에서는 worker-cnf 레이블을 적용합니다.
  2. 대상 노드가 포함된 MachineConfigPool 리소스를 생성합니다.

    1. 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

      1
      MachineConfigPool 리소스의 이름을 지정합니다.
      2
      머신 구성 풀의 고유한 라벨을 지정합니다.
      3
      사용자가 정의한 대상 레이블이 있는 노드를 지정합니다.
    2. 다음 명령을 실행하여 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

13.2.1.3. PPC용 클러스터에 대한 데이터 수집

PPC(Performance Profile creator) 툴에는 must-gather 데이터가 필요합니다. 클러스터 관리자는 must-gather 명령을 실행하여 클러스터에 대한 정보를 캡처합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 성능 프로필을 사용하여 구성할 대상 MCP를 확인했습니다.

프로세스

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.
  2. 다음 명령을 실행하여 클러스터 정보를 수집합니다.

    $ oc adm must-gather

    이 명령은 must-gather.local.1971646453781853027 과 유사한 이름 형식을 사용하여 must-gather 데이터를 사용하여 must-gather 데이터를 사용하여 폴더를 생성합니다.

  3. 선택 사항: must-gather 디렉터리에서 압축 파일을 생성합니다.

    $ tar cvaf must-gather.tar.gz <must_gather_folder> 1
    1
    must-gather 데이터 폴더의 이름으로 바꿉니다.
    참고

    Performance Profile Creator 래퍼 스크립트를 실행하는 경우 압축 출력이 필요합니다.

추가 리소스

13.2.1.4. Podman을 사용하여 Performance Profile Creator 실행

클러스터 관리자는 PPC(Performance Profile Creator)와 함께 Podman을 사용하여 성능 프로필을 생성할 수 있습니다.

PPC 인수에 대한 자세한 내용은 "Performance Profile Creator arguments" 섹션을 참조하십시오.

중요

PPC는 클러스터의 must-gather 데이터를 사용하여 성능 프로필을 생성합니다. 성능 구성을 대상으로 하는 노드 레이블을 다시 지정하는 등 클러스터를 변경하는 경우 PPC를 다시 실행하기 전에 must-gather 데이터를 다시 생성해야 합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
  • podman 및 OpenShift CLI(oc)를 설치했습니다.
  • Node Tuning Operator 이미지에 액세스할 수 있습니다.
  • 구성을 위한 대상 노드가 포함된 머신 구성 풀을 확인했습니다.
  • 클러스터의 must-gather 데이터에 액세스할 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 머신 구성 풀을 확인합니다.

    $ 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

  2. 다음 명령을 실행하여 registry.redhat.io 에 인증하려면 Podman을 사용합니다.

    $ podman login registry.redhat.io
    Username: <user_name>
    Password: <password>
  3. 선택 사항: 다음 명령을 실행하여 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

  4. 클러스터에 대한 정보를 표시하려면 다음 명령을 실행하여 로그 인수와 함께 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-creatorpodman 의 새 진입점으로 성능 프로파일 작성기를 정의합니다.
    • -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=---

  5. 다음 명령을 실행하여 성능 프로필을 생성합니다. 예에서는 샘플 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-cnfworker-=cnf 머신 구성 풀을 지정합니다.
    • --reserved-cpu-count=1 은 예약된 CPU 1개를 지정합니다.
    • --RT-kernel=true 는 실시간 커널을 활성화합니다.
    • --split-reserved-cpus-across-numa=false 는 NUMA 노드 간에 예약된 CPU 분할을 비활성화합니다.
    • --power-consumption-mode=ultra-low-latency 는 전력 소비 증가 시 대기 시간을 최소화합니다.
    • --offlined-cpu-count=1 은 오프라인 CPU 1개를 지정합니다.

      참고

      이 예제의 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: []"

  6. 다음 명령을 실행하여 생성된 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

  7. 생성된 프로필을 적용합니다.

    $ oc apply -f my-performance-profile.yaml

    출력 예

    performanceprofile.performance.openshift.io/performance created

13.2.1.5. Performance Profile Creator 래퍼 스크립트 실행

래퍼 스크립트는 PPC(Performance Profile Creator) 툴을 사용하여 성능 프로필을 생성하는 프로세스를 간소화합니다. 이 스크립트는 필요한 컨테이너 이미지 가져오기 및 실행, 디렉터리를 컨테이너에 마운트하고 Podman을 통해 컨테이너에 직접 매개변수를 제공하는 등의 작업을 처리합니다.

Performance Profile Creator 인수에 대한 자세한 내용은 "Performance Profile Creator arguments" 섹션을 참조하십시오.

중요

PPC는 클러스터의 must-gather 데이터를 사용하여 성능 프로필을 생성합니다. 성능 구성을 대상으로 하는 노드 레이블을 다시 지정하는 등 클러스터를 변경하는 경우 PPC를 다시 실행하기 전에 must-gather 데이터를 다시 생성해야 합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
  • podman 및 OpenShift CLI(oc)를 설치했습니다.
  • Node Tuning Operator 이미지에 액세스할 수 있습니다.
  • 구성을 위한 대상 노드가 포함된 머신 구성 풀을 확인했습니다.
  • must-gather tarball에 액세스합니다.

프로세스

  1. 예를 들어 다음과 같이 run-perf-profile-creator.sh라는 이름의 파일을 로컬 시스템에 생성합니다

    $ vi run-perf-profile-creator.sh
  2. 다음 코드를 파일에 붙여넣습니다.

    #!/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 "$@"
  3. 이 스크립트에 모든 사용자에 대한 실행 권한을 추가합니다.

    $ chmod a+x run-perf-profile-creator.sh
  4. 다음 명령을 실행하여 registry.redhat.io 에 인증하려면 Podman을 사용합니다.

    $ podman login registry.redhat.io
    Username: <user_name>
    Password: <password>
  5. 선택 사항: 다음 명령을 실행하여 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 이미지의 경로를 설정할 수 있습니다. 경로를 설정하지 않으면 래퍼 스크립트는 기본 이미지 registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.17 을 사용합니다.

  6. 클러스터에 대한 정보를 표시하려면 다음 명령을 실행하여 로그 인수와 함께 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=---

  7. 다음 명령을 실행하여 성능 프로필을 생성합니다.

    $ ./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-cnfworker-=cnf 머신 구성 풀을 지정합니다.
    • --reserved-cpu-count=1 은 예약된 CPU 1개를 지정합니다.
    • --RT-kernel=true 는 실시간 커널을 활성화합니다.
    • --split-reserved-cpus-across-numa=false 는 NUMA 노드 간에 예약된 CPU 분할을 비활성화합니다.
    • --power-consumption-mode=ultra-low-latency 는 전력 소비 증가 시 대기 시간을 최소화합니다.
    • --offlined-cpu-count=1 은 오프라인 CPU 1개를 지정합니다.

      참고

      이 예제의 mcp-name 인수는 oc get mcp 명령의 출력에 따라 worker-cnf로 설정됩니다. 단일 노드 OpenShift의 경우 --mcp-name=master 를 사용합니다.

  8. 다음 명령을 실행하여 생성된 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

  9. 생성된 프로필을 적용합니다.

    $ oc apply -f my-performance-profile.yaml

    출력 예

    performanceprofile.performance.openshift.io/performance created

13.2.1.6. Performance Profile Creator 인수

표 13.1. 필요한 Performance Profile Creator 인수
인수설명

mcp-name

MCP의 이름(예: 대상 머신에 해당하는 worker-cnf )입니다.

must-gather-dir-path

의 경로는 디렉터리를 수집해야 합니다.

이 인수는 Podman을 사용하여 PPC 툴을 실행하는 경우에만 필요합니다. 래퍼 스크립트와 함께 PPC를 사용하는 경우 이 인수를 사용하지 마십시오. 대신 래퍼 스크립트에 -t 옵션을 사용하여 must-gather tarball의 디렉터리 경로를 지정합니다.

reserved-cpu-count

예약된 CPU 수입니다. 0보다 큰 자연수를 사용합니다.

rt-kernel

실시간 커널을 활성화합니다.

가능한 값: true 또는 false.

표 13.2. 선택적 Performance Profile Creator 인수
인수설명

disable-ht

하이퍼 스레딩을 비활성화합니다.

가능한 값: true 또는 false.

기본값: false

주의

이 인수가 true 로 설정된 경우 BIOS에서 Hyper-Threading을 비활성화해서는 안 됩니다. 하이퍼 스레딩 비활성화는 커널 명령줄 인수를 사용하여 수행됩니다.

enable-hardware-tuning

최대 CPU 빈도 설정을 활성화합니다.

이 기능을 활성화하려면 다음 두 필드에 대해 분리된 CPU 및 예약된 CPU에서 실행되는 애플리케이션의 최대 빈도를 설정합니다.

  • spec.hardwareTuning.isolatedCpuFreq
  • spec.hardwareTuning.reservedCpuFreq

이는 고급 기능입니다. 하드웨어 튜닝을 구성하는 경우 생성된 PerformanceProfile 에는 빈도 설정을 설정하는 방법에 대한 경고 및 지침이 포함됩니다.

info

이는 클러스터 정보를 캡처합니다. 이 인수에는 must-gather-dir-path 인수도 필요합니다. 다른 인수가 설정되면 무시됩니다.

가능한 값은 다음과 같습니다.

  • log
  • JSON

기본값: log.

offlined-cpu-count

오프라인 CPU 수입니다.

참고

0보다 큰 자연수를 사용합니다. 논리 프로세서가 충분하지 않으면 오류 메시지가 기록됩니다. 메시지는 다음과 같습니다.

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]

power-consumption-mode

전력 소비 모드입니다.

가능한 값은 다음과 같습니다.

  • Default: CPU 파티셔닝을 통해서만 수행되었습니다.
  • low-latency: 대기 시간을 개선하기 위한 향상된 조치
  • Ultra-Low-latency: 전원 관리를 통해 최적의 대기 시간에 제공되는 우선 순위입니다.

기본값: default.

per-pod-power-management

Pod 전원 관리당 활성화. Ultra-Low-latency를 전력 소비 모드로 구성한 경우에는 이 인수를 사용할 수 없습니다.

가능한 값: true 또는 false.

기본값: false

profile-name

생성할 성능 프로파일의 이름입니다.

기본값: performance.

split-reserved-cpus-across-numa

NUMA 노드에서 예약된 CPU를 분할합니다.

가능한 값: true 또는 false.

기본값: false

topology-manager-policy

생성할 성능 프로필의 Kubelet Topology Manager 정책입니다.

가능한 값은 다음과 같습니다.

  • single-numa-node
  • best-effort
  • restricted

기본값: restricted.

user-level-networking

DPDK(사용자 수준 네트워킹)가 활성화된 상태에서 실행합니다.

가능한 값: true 또는 false.

기본값: false

13.2.1.7. 성능 프로필 참조

다음 참조 성능 프로필을 기반으로 사용하여 고유한 사용자 지정 프로필을 개발할 수 있습니다.

13.2.1.7.1. OpenStack에서 OVS-DPDK를 사용하는 클러스터의 성능 프로필 템플릿

RHOSP(Red Hat OpenStack Platform)에서 OVS-DPDK(Data Plane Development Kit)를 사용하여 Open vSwitch를 사용하는 클러스터의 머신 성능을 최대화하려면 성능 프로필을 사용할 수 있습니다.

다음 성능 프로필 템플릿을 사용하여 배포에 대한 프로필을 생성할 수 있습니다.

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_RESERVEDHUGEPAGES_COUNT 키에 대한 구성에 적합한 값을 삽입합니다.

13.2.1.7.2. Telco RAN DU 참조 성능 프로파일

다음 성능 프로필은 상용 하드웨어에서 OpenShift Container Platform 클러스터에 대한 노드 수준 성능 설정을 구성하여 Telco 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

13.2.1.7.3. Telco 코어 참조 성능 프로파일

다음 성능 프로필은 상용 하드웨어에서 OpenShift Container Platform 클러스터에 대한 노드 수준 성능 설정을 구성하여 통신 핵심 워크로드를 호스팅합니다.

Telco 코어 참조 성능 프로파일

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

13.2.2. 지원되는 성능 프로필 API 버전

Node Tuning Operator는 성능 프로필 apiVersion 필드에 대해 v2,v1, v1alpha1 을 지원합니다. v1 및 v1alpha1 API는 동일합니다. v2 API에는 기본값인 false 값을 사용하여 선택적 부울 필드 loballyDisableIrqLoadBalancing이 포함됩니다.

장치 인터럽트 처리를 사용하기 위해 성능 프로파일을 업그레이드

Node Tuning Operator 성능 프로파일 CRD(사용자 정의 리소스 정의)를 v1 또는 v1alpha1에서 v2로 업그레이드하는 경우 기존 프로필에서 globallyDisableIrqLoadBalancingtrue 로 설정됩니다.

참고

globallyDisableIrqLoadBalancing 은 Isolated CPU 세트에 대해 IRQ 로드 밸런싱이 비활성화됩니다. 옵션이 true 로 설정되면 Isolated CPU 세트에 대한 IRQ 로드 밸런싱이 비활성화됩니다. 옵션을 false 로 설정하면 모든 CPU에서 IRQ를 분산할 수 있습니다.

Node Tuning Operator API를 v1alpha1에서 v1로 업그레이드

Node Tuning Operator API 버전을 v1alpha1에서 v1로 업그레이드할 때 "None" 변환 전략을 사용하여 v1alpha1 성능 프로파일이 즉시 변환되고 API 버전 v1을 사용하여 Node Tuning Operator에 제공됩니다.

Node Tuning Operator API를 v1alpha1 또는 v1에서 v2로 업그레이드

이전 Node Tuning Operator API 버전에서 업그레이드할 때 기존 v1 및 v1alpha1 성능 프로파일은 true 값이 truegloballyDisableIrqLoadBalancing 필드를 삽입하는 변환 Webhook를 사용하여 변환됩니다.

13.2.3. 워크로드 힌트를 사용하여 노드 전력 소비 및 실시간 처리 구성

프로세스

  • PPC( Performance Profile Creator) 툴을 사용하여 환경 하드웨어 및 토폴로지에 적합한 PerformanceProfile을 생성합니다. 다음 표에서는 PPC 툴과 관련된 power-consumption-mode 플래그 및 적용된 워크로드 팁에 대해 설정된 가능한 값을 설명합니다.
표 13.3. 대기 시간에 전력 소비 및 실시간 설정 조합의 영향
Performance Profile creator 설정환경설명

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당 전원 관리를 허용합니다.

예제

다음 구성은 일반적으로 telco RAN DU 배포에서 사용됩니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: workload-hints
    spec:
      ...
      workloadHints:
        realTime: true
        highPowerConsumption: false
        perPodPowerManagement: false 1
1
시스템 대기 시간에 영향을 줄 수 있는 일부 디버깅 및 모니터링 기능을 비활성화합니다.
참고

성능 프로파일에서 realTime 워크로드 힌트 플래그가 true 로 설정된 경우 고정 CPU가 있는 보장된 모든 Pod에 cpu-quota.crio.io: disable 주석을 추가합니다. 이 주석은 Pod 내에서 프로세스 성능이 저하되지 않도록 하는 데 필요합니다. realTime 워크로드 힌트가 명시적으로 설정되지 않은 경우 기본값은 true 입니다.

전력 소비와 실시간 설정의 조합이 대기 시간에 미치는 영향에 대한 자세한 내용은 워크로드 팁 이해를 참조하십시오.

13.2.4. 공동 배치된 높은 우선 순위 워크로드 및 낮은 우선 순위 워크로드를 실행하는 노드에 대한 전원 저장 구성

우선 순위가 높은 워크로드가 높은 노드의 대기 시간 또는 처리량에 영향을 미치지 않고 우선 순위가 높은 워크로드가 낮은 노드에 대한 전원을 절약할 수 있습니다. 워크로드 자체를 수정하지 않고도 전력 절감이 가능합니다.

중요

이 기능은 Intel Ice Lake 이상 세대의 Intel CPU에서 지원됩니다. 프로세서의 기능은 높은 우선 순위 워크로드의 대기 시간 및 처리량에 영향을 미칠 수 있습니다.

사전 요구 사항

  • BIOS에서 C-states 및 운영 체제를 활성화했습니다.

프로세스

  1. 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.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

  2. PerformanceProfile CR(사용자 정의 리소스)에서 기본 cpufreq governor를 추가 커널 인수로 설정합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
         name: performance
    spec:
        ...
        additionalKernelArgs:
        - cpufreq.default_governor=schedutil 1
    1
    그러나 schedutil governor를 사용하는 것이 좋습니다. 그러나 온디맨드 또는 전원 세이저와 같은 다른 governor를 사용할 수 있습니다.
  3. TunedPerformancePatch CR에서 최대 CPU 빈도를 설정합니다.

    spec:
      profile:
      - data: |
          [sysfs]
          /sys/devices/system/cpu/intel_pstate/max_perf_pct = <x> 1
    1
    max_perf_pctcpufreq 드라이버가 지원되는 최대 cpu 빈도의 백분율로 설정할 수 있는 최대 빈도를 제어합니다. 이 값은 모든 CPU에 적용됩니다. /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 에서 지원되는 최대 빈도를 확인할 수 있습니다. 시작점으로 모든 CPU를 모든 코어 frequency로 제한하는 백분율로 사용할 수 있습니다. 모든 코어의 frequency는 코어가 완전히 비어 있을 때 모든 코어가 실행되는 빈도입니다.

13.2.5. 인프라 및 애플리케이션 컨테이너의 CPU 제한

일반 하우스키핑 및 워크로드 작업에서는 대기 시간에 민감한 프로세스에 영향을 줄 수 있는 방식으로 CPU를 사용합니다. 기본적으로 컨테이너 런타임은 모든 온라인 CPU를 사용하여 모든 컨테이너를 함께 실행하여 컨텍스트 스위치와 대기 시간이 급증할 수 있습니다. CPU를 파티셔닝하면 noisy 프로세스에서 서로 분리하여 대기 시간에 민감한 프로세스를 방해하지 않습니다. 다음 표에서는 Node Tuning Operator를 사용하여 노드를 조정한 후 CPU에서 프로세스가 실행되는 방법을 설명합니다.

표 13.4. 프로세스의 CPU 할당
프로세스 유형세부 정보

BurstableBestEffort Pod

대기 시간이 짧은 워크로드가 실행 중인 경우를 제외하고 모든 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 보장된 Pod에 25개의 코어를 할당하고 BestEffort 또는 Burstable Pod의 경우 25개의 코어를 할당합니다. 이는 격리된 풀의 용량과 일치합니다.

예시 2

노드에는 100개의 코어 용량이 있습니다. 클러스터 관리자는 성능 프로필을 사용하여 분리된 풀에 50개의 코어와 예약된 풀에 50개의 코어를 할당합니다. 클러스터 관리자는 QoS 보장된 Pod에 50개의 코어를 할당하고 BestEffort 또는 Burstable Pod의 코어 1개를 할당합니다. 이렇게 하면 격리된 풀의 용량을 하나의 코어로 초과합니다. CPU 용량이 부족하여 Pod 예약이 실패합니다.

사용할 정확한 파티셔닝 패턴은 하드웨어, 워크로드 특성 및 예상되는 시스템 로드와 같은 여러 요인에 따라 다릅니다. 일부 샘플 사용 사례는 다음과 같습니다.

  • 대기 시간에 민감한 워크로드가 NIC(네트워크 인터페이스 컨트롤러)와 같은 특정 하드웨어를 사용하는 경우 격리된 풀의 CPU가 이 하드웨어에 최대한 가까운지 확인합니다. 최소한 동일한 NUMA(Non-Uniform Memory Access) 노드에 워크로드를 배치해야 합니다.
  • 예약된 풀은 모든 인터럽트를 처리하는 데 사용됩니다. 시스템 네트워킹에 따라 들어오는 모든 패킷 인터럽트를 처리하기 위해 충분히 크기의 예비 풀을 할당합니다. 4.17 이상 버전에서 워크로드는 선택적으로 민감한 것으로 레이블을 지정할 수 있습니다.

예약 및 격리된 파티션에 사용해야 하는 특정 CPU에 대한 결정에는 자세한 분석과 측정이 필요합니다. 장치 및 메모리의 NUMA 선호도와 같은 요소가 역할을 합니다. 선택 사항은 워크로드 아키텍처 및 특정 사용 사례에 따라 다릅니다.

중요

예약 및 격리된 CPU 풀은 겹치지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.

하우스키핑 작업과 워크로드가 서로 방해하지 않도록 하려면 성능 프로필의 spec 섹션에 두 개의 CPU 그룹을 지정합니다.

  • isolated - 애플리케이션 컨테이너 워크로드에 대한 CPU를 지정합니다. 이러한 CPU는 대기 시간이 가장 짧습니다. 이 그룹의 프로세스에는 중단이 발생하지 않으므로 예를 들어 프로세스가 훨씬 더 높은 DPDK 제로 패킷 손실 대역폭에 도달할 수 있습니다.
  • reserved - 클러스터 및 운영 체제 하우스키핑 작업의 CPU를 지정합니다. 예약된 그룹의 스레드는 종종 사용 중입니다. 예약된 그룹에서 대기 시간에 민감한 애플리케이션을 실행하지 마십시오. 대기 시간에 민감한 애플리케이션은 격리된 그룹에서 실행됩니다.

프로세스

  1. 환경의 하드웨어 및 토폴로지에 적합한 성능 프로필을 만듭니다.
  2. 인프라 및 애플리케이션 컨테이너에 대해 reservedisolated하려는 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
    선택 사항: 노드 선택기를 지정하여 특정 노드에 성능 프로파일을 적용합니다.

13.2.6. 클러스터의 하이퍼 스레딩 구성

OpenShift Container Platform 클러스터에 대한 Hyper-Threading을 구성하려면 성능 프로필의 CPU 스레드를 예약 또는 분리된 CPU 풀에 대해 구성된 동일한 코어로 설정합니다.

참고

성능 프로필을 구성하고 호스트의 Hyper-Threading 구성을 변경하는 경우 PerformanceProfile YAML에서 CPU isolatedreserved 필드를 새 구성과 일치하도록 업데이트해야 합니다.

주의

이전에 활성화된 호스트 Hyper-Threading 구성을 비활성화하면 PerformanceProfile YAML에 나열된 CPU 코어 ID가 올바르지 않을 수 있습니다. 이렇게 잘못된 구성으로 인해 나열된 CPU를 더 이상 찾을 수 없으므로 노드를 사용할 수 없게 될 가능성이 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. 구성할 호스트의 모든 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

    이 예에서는 4개의 물리적 CPU 코어에서 실행 중인 논리 CPU 코어가 8개 있습니다. CPU0 및 CPU4는 물리적 Core0에서 실행되고 CPU1 및 CPU5는 물리적 Core 1에서 실행되고 있습니다.

    또는 특정 물리적 CPU 코어(아래 예제에서cpu0) 에 설정된 스레드를 보려면 쉘 프롬프트를 열고 다음을 실행합니다.

    $ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

    출력 예

    0-4

  2. PerformanceProfile YAML에서 분리 및 예약된 CPU를 적용합니다. 예를 들어 논리 코어 CPU0 및 CPU4를 isolated 로, 논리 코어 CPU1을 CPU3으로, CPU5를 예약된 CPU7으로 설정할 수 있습니다. 예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.

    ...
      cpu:
        isolated: 0,4
        reserved: 1-3,5-7
    ...
    참고

    예약 및 격리된 CPU 풀은 겹치지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.

중요

Hyper-Threading은 대부분의 Intel 프로세서에서 기본적으로 활성화되어 있습니다. Hyper-Threading을 활성화하면 특정 코어에서 처리되는 모든 스레드를 동일한 코어에서 분리하거나 처리해야 합니다.

하이퍼 스레딩을 활성화하면 모든 보장된 Pod에서 동시 멀티 스레딩(SMT) 수준의 여러 개를 사용하여 Pod가 실패할 수 있는 "noisy neighbor" 상황을 방지해야 합니다. 자세한 내용은 정적 정책 옵션을 참조하십시오.

13.2.6.1. 짧은 대기 시간 애플리케이션의 하이퍼 스레딩 비활성화

대기 시간이 짧은 처리를 위해 클러스터를 구성할 때 클러스터를 배포하기 전에 Hyper-Threading을 비활성화할지 여부를 고려하십시오. 하이퍼 스레딩을 비활성화하려면 다음 단계를 수행합니다.

  1. 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.
  2. 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를 사용합니다.

13.2.7. 보장된 pod 분리 CPU의 장치 중단 처리 관리

Node Tuning Operator는 호스트 CPU를 Pod 인프라 컨테이너를 포함하여 클러스터 및 운영 체제 하우스키핑 작업을 위해 예약된 CPU와 워크로드를 실행하기 위해 애플리케이션 컨테이너의 분리된 CPU로 나누어 호스트 CPU를 관리할 수 있습니다. 이를 통해 대기 시간이 짧은 워크로드의 CPU를 분리된 상태로 설정할 수 있습니다.

장치 중단은 보장된 pod가 실행 중인 CPU를 제외하고 CPU의 과부하를 방지하기 위해 모든 분리된 CPU와 예약된 CPU 간에 균형을 유지합니다. pod에 관련 주석이 설정되어 있으면 보장된 Pod CPU가 장치 인터럽트를 처리하지 못합니다.

새로운 성능 프로파일 필드 globallyDisableIrqLoadBalancing은 장치 중단을 처리할지 여부를 관리하는 데 사용할 수 있습니다. 특정 워크로드의 경우 예약된 CPU가 장치 인터럽트를 처리하기에 충분하지 않으며, 이러한 이유로 장치 인터럽트는 분리된 CPU에서 전역적으로 비활성화되지 않습니다. 기본적으로 Node Tuning Operator는 분리된 CPU에서 장치 인터럽트를 비활성화하지 않습니다.

13.2.7.1. 노드의 유효한 IRQ 선호도 설정 찾기

일부 IRQ 컨트롤러는 IRQ 선호도 설정을 지원하지 않으며 항상 모든 온라인 CPU를 IRQ 마스크로 노출합니다. 이러한 IRQ 컨트롤러는 CPU 0에서 효과적으로 실행됩니다.

다음은 IRQ 선호도 설정에 대한 지원이 부족한 드라이버 및 하드웨어의 예입니다. 목록은 전혀 완전하지 않습니다.

  • megaraid_sas와 같은 일부 RAID 컨트롤러 드라이버
  • 많은 비휘발성 메모리 표현(NVMe) 드라이버
  • 마더보드(LOM) 네트워크 컨트롤러의 일부 LAN
  • 드라이버는 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를 대상으로 하는 경우에도 관리 인터럽트의 유사성을 변경할 수 없습니다.

13.2.7.2. 노드 인터럽트 유사성 구성

IRQ(장치 인터럽트 요청)를 수신할 수 있는 코어를 제어하도록 IRQ 동적 로드 밸런싱 클러스터 노드를 구성합니다.

사전 요구 사항

  • 코어 격리의 경우 모든 서버 하드웨어 구성 요소에서 IRQ 선호도를 지원해야 합니다. 서버의 하드웨어 구성 요소가 IRQ 선호도를 지원하는지 확인하려면 서버의 하드웨어 사양을 보거나 하드웨어 공급자에게 문의하십시오.

프로세스

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.
  2. performance.openshift.io/v2를 사용하도록 성능 프로파일의 apiVersion을 설정합니다.
  3. globallyDisableIrqLoadBalancing 필드를 삭제제거하거나 false로 설정합니다.
  4. 적절한 분리 및 예약된 CPU를 설정합니다. 다음 스니펫에서는 두 개의 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에서 실행됩니다. 자세한 내용은 "인프라 및 애플리케이션 컨테이너용 CPU 제한"을 참조하십시오.

13.2.8. 대규모 페이지 구성

노드는 OpenShift Container Platform 클러스터에서 사용되는 대규모 페이지를 사전 할당해야 합니다. Node Tuning Operator를 사용하여 특정 노드에 대규모 페이지를 할당합니다.

OpenShift Container Platform에서는 대규모 페이지를 생성하고 할당하는 방법을 제공합니다. Node Tuning Operator는 성능 프로필을 사용하여 이 작업을 더 쉽게 수행할 수 있는 방법을 제공합니다.

예를 들어 성능 프로필의 hugepages pages 섹션에서 size, countnode(선택사항)로 된 여러 블록을 지정할 수 있습니다.

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-###:  ###

13.2.8.1. 여러 대규모 페이지 크기 할당

동일한 컨테이너에서 다양한 크기의 대규모 페이지를 요청할 수 있습니다. 이 경우 다양한 대규모 페이지 크기 요구사항이 있는 컨테이너로 구성된 더 복잡한 Pod를 정의할 수 있습니다.

예를 들어 1G2M 크기를 정의할 수 있으며 Node Tuning Operator는 다음과 같이 노드에서 크기를 둘 다 구성합니다.

spec:
  hugepages:
    defaultHugepagesSize: 1G
    pages:
    - count: 1024
      node: 0
      size: 2M
    - count: 4
      node: 1
      size: 1G

13.2.9. Node Tuning Operator를 사용하여 NIC 대기열 감소

Node Tuning Operator를 사용하면 성능 향상을 위해 NIC 대기열을 줄일 수 있습니다. 성능 프로필을 사용하여 조정되므로 다양한 네트워크 장치에 대한 대기열을 사용자 지정할 수 있습니다.

13.2.9.1. 성능 프로파일을 사용하여 NIC 큐 조정

성능 프로파일을 사용하면 각 네트워크 장치의 대기열 수를 조정할 수 있습니다.

지원되는 네트워크 장치는 다음과 같습니다.

  • 비가상 네트워크 장치
  • 멀티 큐(채널)를 지원하는 네트워크 장치

지원되지 않는 네트워크 장치는 다음과 같습니다.

  • Pure Software 네트워크 인터페이스
  • 블록 장치
  • Intel DPDK 가상 기능

사전 요구 사항

  • cluster-admin 역할을 가진 사용자로 클러스터에 액세스합니다.
  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. cluster-admin 권한이 있는 사용자로 Node Tuning Operator를 실행하는 OpenShift Container Platform 클러스터에 로그인합니다.
  2. 하드웨어 및 토폴로지에 적합한 성능 프로파일을 만들고 적용합니다. 프로파일 생성에 대한 지침은 "성능 프로파일 생성" 섹션을 참조하십시오.
  3. 생성된 성능 프로파일을 편집합니다.

    $ oc edit -f <your_profile_name>.yaml
  4. spec 필드를 net 오브젝트로 채웁니다. 오브젝트 목록에는 다음 두 개의 필드가 포함될 수 있습니다.

    • userLevelNetworking은 부울 플래그로 지정된 필수 필드입니다. userLevelNetworkingtrue인 경우 지원되는 모든 장치에 대해 대기열 수가 예약된 CPU 수로 설정됩니다. 기본값은 false입니다.
    • devices는 예약된 CPU 수로 큐를 설정할 장치 목록을 지정하는 선택적 필드입니다. 장치 목록이 비어 있으면 구성이 모든 네트워크 장치에 적용됩니다. 구성은 다음과 같습니다.

      • interfacename: 이 필드는 인터페이스 이름을 지정하고, 양수 또는 음수일 수 있는 쉘 스타일 와일드카드를 지원합니다.

        • 와일드카드 구문의 예는 다음과 같습니다. <string> .*
        • 음수 규칙 앞에는 느낌표가 붙습니다. 제외된 목록이 아닌 모든 장치에 넷 큐 변경 사항을 적용하려면 !<device>를 사용합니다(예: !eno1).
      • vendorID: 접두사가 0x인 16비트 16진수로 표시되는 네트워크 장치 공급업체 ID입니다.
      • deviceID: 0x 접두사가 있는 16비트 16진수로 표시되는 네트워크 장치 ID(모델)입니다.

        참고

        deviceID가 지정되어 있는 경우 vendorID도 정의해야 합니다. 장치 항목 interfaceName, vendorID, vendorIDdeviceID의 쌍에 지정된 모든 장치 식별자와 일치하는 장치는 네트워크 장치로 간주됩니다. 그러면 이 네트워크 장치의 네트워크 대기열 수가 예약된 CPU 수로 설정됩니다.

        두 개 이상의 장치가 지정되면 네트워크 대기열 수가 해당 장치 중 하나와 일치하는 모든 네트워크 장치로 설정됩니다.

  5. 다음 예제 성능 프로필을 사용하여 대기열 수를 모든 장치에 예약된 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: ""
  6. 다음 예제 성능 프로필을 사용하여 정의된 장치 식별자와 일치하는 모든 장치에 대해 대기열 수를 예약된 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: ""
  7. 다음 예제 성능 프로필을 사용하여 인터페이스 이름 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: ""
  8. 이 예제 성능 프로필을 사용하여 이름이 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: ""
  9. 인터페이스 이름 eth0, 0x1af4vendorID0x1000deviceID는 모든 장치에 대해 대기열 수를 예약된 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: ""
  10. 업데이트된 성능 프로필을 적용합니다.

    $ oc apply -f <your_profile_name>.yaml

추가 리소스

13.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입니다. 예를 들어 vendorID=0x1af4가 있는 다른 네트워크 장치 ens2가 별도로 존재하는 경우 총 네트워크 대기열 수는 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
...
  • interfaceNameeth0인 장치 및 다음 성능 프로필이 있는 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로 설정됩니다. 마찬가지로 interfaceNameeth0인 장치에는 총 네트워크 대기열이 2로 설정됩니다.

13.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
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.