시스템 상태 및 성능 모니터링 및 관리

Red Hat Enterprise Linux 9

시스템 처리량, 대기 시간 및 전력 소비 최적화

Red Hat Customer Content Services

초록

Red Hat Enterprise Linux 9의 다양한 시나리오에서 처리량, 대기 시간 및 전력 소비를 모니터링하고 최적화합니다.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Red Hat 문서에 관한 피드백 제공

문서에 대한 피드백에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.

Jira를 통해 피드백 제출 (등록 필요)

  1. Jira 웹 사이트에 로그인합니다.
  2. 상단 탐색 모음에서 생성 을 클릭합니다.
  3. Summary (요약) 필드에 설명 제목을 입력합니다.
  4. Description (설명) 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
  5. 대화 상자 하단에서 생성 을 클릭합니다.

1장. TuneD 시작하기

시스템 관리자는 TuneD 애플리케이션을 사용하여 다양한 사용 사례에 맞게 시스템의 성능 프로파일을 최적화할 수 있습니다.

1.1. TuneD의 목적

tuned 는 시스템을 모니터링하고 특정 워크로드에서 성능을 최적화하는 서비스입니다. TuneD 의 코어는 다른 사용 사례에 맞게 시스템을 조정하는 프로필 입니다.

tuned 는 다음과 같은 사용 사례에 대해 사전 정의된 여러 프로필과 함께 배포됩니다.

  • 높은 처리량
  • 짧은 대기 시간
  • 전원 저장

각 프로필에 정의된 규칙을 수정하고 특정 장치를 조정하는 방법을 사용자 지정할 수 있습니다. 다른 프로필로 전환하거나 TuneD 를 비활성화하면 이전 프로필의 시스템 설정에 대한 모든 변경 사항이 원래 상태로 되돌아갑니다.

또한 장치 사용 변경에 대응하고 활성 장치의 성능을 개선하고 비활성 장치의 전력 소비를 줄이기 위해 설정을 조정할 수도 있습니다.

1.2. tuned 프로필

시스템의 상세한 분석은 매우 오래 걸릴 수 있습니다. tuned 는 일반적인 사용 사례에 대해 사전 정의된 여러 프로필을 제공합니다. 프로필을 생성, 수정 및 삭제할 수도 있습니다.

TuneD 로 제공되는 프로필은 다음 범주로 나뉩니다.

  • 절전 프로필
  • performance-boosting 프로필

performance-boosting 프로필에는 다음과 같은 측면에 중점을 둔 프로필이 포함됩니다.

  • 스토리지 및 네트워크에 대한 짧은 대기 시간
  • 스토리지 및 네트워크의 높은 처리량
  • 가상 머신 성능
  • 가상화 호스트 성능

프로필 구성의 구문

tuned.conf 파일에는 하나의 [main] 섹션과 플러그인 인스턴스를 구성하기 위한 다른 섹션을 포함할 수 있습니다. 그러나 모든 섹션은 선택 사항입니다.

해시 기호(#)로 시작하는 행은 주석입니다.

추가 리소스

  • tuned.conf(5) man page.

1.3. 기본 TuneD 프로필

설치하는 동안 시스템에 가장 적합한 프로필이 자동으로 선택됩니다. 현재 기본 프로필은 다음과 같은 사용자 정의 규칙에 따라 선택됩니다.

환경기본 프로필목표

컴퓨팅 노드

throughput-performance

최대 처리량 성능

가상 머신

virtual-guest

최상의 성능. 최상의 성능에 관심이 없는 경우 균형 잡힌 또는 절전 프로필로 변경할 수 있습니다.

기타 사례

balanced

균형 있는 성능 및 전력 소비

추가 리소스

  • tuned.conf(5) man page.

1.4. 병합된 TuneD 프로필

실험적 기능으로는 한 번에 더 많은 프로필을 선택할 수 있습니다. tuned 는 로드 중에 병합하려고 합니다.

충돌이 발생하면 마지막으로 지정된 프로필의 설정이 우선합니다.

예 1.1. 가상 게스트의 전력 소비 감소

다음 예제에서는 가상 머신에서 실행하도록 시스템을 최적화하여 최상의 성능을 발휘하고 전력 소비가 낮고 전력 소비가 낮을 때 동시에 조정할 수 있습니다.

# tuned-adm profile virtual-guest powersave
주의

결과 매개변수 조합이 의미가 있는지 확인하지 않고 병합이 자동으로 수행됩니다. 결과적으로 이 기능은 일부 매개 변수를 반대로 튜닝할 수 있습니다. 예를 들어, counterproductive일 수 있습니다. 예를 들어 throughput-performance 프로필을 사용하여 높은 처리량에 대해 디스크를 설정하고, 디스크 회전을 spindown-disk 프로필을 통해 낮은 값으로 디스크를 설정할 수 있습니다.

추가 리소스

*tuned-adm man 페이지. * tuned.conf(5) man page.

1.5. TuneD 프로필의 위치

tuned 는 프로필을 다음 디렉터리에 저장합니다.

/usr/lib/tuned/
배포별 프로필은 디렉터리에 저장됩니다. 각 프로필에는 자체 디렉터리가 있습니다. 프로필은 tuned.conf 라는 기본 구성 파일과 선택적으로 기타 파일(예: 도우미 스크립트)으로 구성됩니다.
/etc/tuned/
프로필을 사용자 지정해야 하는 경우 사용자 지정 프로필에 사용되는 디렉터리에 프로필 디렉터리를 복사합니다. 동일한 이름의 프로필이 두 개 있는 경우 /etc/tuned/ 에 있는 사용자 지정 프로필이 사용됩니다.

추가 리소스

  • tuned.conf(5) man page.

1.6. RHEL을 사용하여 배포된 tuned 프로필

다음은 Red Hat Enterprise Linux에서 TuneD 와 함께 설치된 프로필 목록입니다.

참고

제품별 또는 타사 TuneD 프로필이 더 있을 수 있습니다. 이러한 프로필은 일반적으로 별도의 RPM 패키지로 제공됩니다.

balanced

기본 power- saving 프로필. 이는 성능과 전력 소비 간의 절충을 위한 것입니다. 가능한 경우 자동 확장 및 자동 튜닝을 사용합니다. 유일한 단점은 대기 시간이 증가하는 것입니다. 현재 TuneD 릴리스에서는 CPU, 디스크, 오디오 및 비디오 플러그인을 활성화하고 보존 CPU governor를 활성화합니다. radeon_powersave 옵션은 지원되는 경우 dpm-balanced 값을 사용합니다. 그러지 않으면 auto 로 설정됩니다.

energy_performance_preference 특성을 일반적인 에너지 설정으로 변경합니다. 또한 scaling_governor policy 속성을 보존 하거나 CPU governor로 변경합니다.

powersave

최대 성능 절약을 위한 프로필입니다. 실제 전력 소비를 최소화하기 위해 성능을 제한할 수 있습니다. 현재 TuneD 릴리스에서는 SATA 호스트 어댑터의 USB 자동 일시 중지, WiFi 전원 저장 및 Aggressive Link Power Management (ALPM) 전원 절약 기능을 사용할 수 있습니다. 또한 정전 비율이 낮은 시스템의 멀티 코어 전력 절감을 예약하고 온디맨드 governor를 활성화합니다. 이는 AC97 오디오 전력 절약을 가능하게 하거나, 시스템에 따라 10초의 시간 초과로HDA-Intel의 전력 절약을 가능하게 합니다. 시스템에 KMS가 활성화된 지원되는 Radeon 그래픽 카드가 포함된 경우 프로필은 자동 전원 저장으로 구성합니다. ASUS Eee PC에서는 동적 슈퍼 하이브리드 엔진을 사용할 수 있습니다.

energy_performance_preference 속성을 powersave 또는 power energy setting로 변경합니다. 또한 scaling_governor 정책 속성을 온 디맨드 또는 절전 CPU governor로 변경합니다.

참고

경우에 따라 balanced 프로파일은 powersave 프로필에 비해 더 효율적입니다.

예를 들어 트랜스코딩이 필요한 비디오 파일 등 수행해야 하는 정의된 작업 양을 고려하십시오. 작업이 빠르게 완료되기 때문에 트랜스코딩이 전체 전원에서 수행되면 컴퓨터가 더 적은 전력을 소비할 수 있으며 머신이 유휴 상태로 시작되고 매우 효율적인 전력 절약 모드로 자동 전환될 수 있습니다. 반면, 스로틀링된 시스템으로 파일을 트랜스코딩하는 경우 시스템은 트랜스코딩 중에 전력을 적게 소비하지만 프로세스는 더 오래 걸리고 전반적으로 소비된 전력이 더 높을 수 있습니다.

따라서 균형 잡힌 프로필은 일반적으로 더 나은 옵션이 될 수 있습니다.

throughput-performance

높은 처리량에 최적화된 서버 프로필입니다. 전원 절감 메커니즘을 비활성화하고 디스크 및 네트워크 IO의 처리량 성능을 향상시키는 sysctl 설정을 활성화합니다. CPU governor가 성능 으로 설정됩니다.

energy_performance_preferencescaling_governor 속성을 성능 프로필로 변경합니다.

accelerator-performance
액셀러레이터-성능 프로파일에throughput-performance 프로필과 동일한 튜닝이 포함되어 있습니다. 또한 CPU가 낮은 C 상태로 잠금되므로 대기 시간이 100us 미만입니다. 이를 통해 GPU와 같은 특정 가속기의 성능이 향상됩니다.
latency-performance

짧은 대기 시간을 위해 최적화된 서버 프로필입니다. 전원 절감 메커니즘을 비활성화하고 대기 시간을 개선하는 sysctl 설정을 활성화합니다. CPU governor가 성능 으로 설정되어 CPU가 낮은 C 상태(PM QoS에 의해)에 고정됩니다.

energy_performance_preferencescaling_governor 속성을 성능 프로필로 변경합니다.

network-latency

대기 시간이 짧은 네트워크 튜닝을 위한 프로필입니다. latency-performance 프로필을 기반으로 합니다. 또한 투명한 대규모 페이지 및 NUMA 분산을 비활성화하고 다른 여러 네트워크 관련 sysctl 매개변수를 튜닝합니다.

latency-performance 프로필을 상속하여 energy_performance_preferencescaling_governor 속성을 성능 프로필로 변경합니다.

hpc-compute
고성능 컴퓨팅에 최적화된 프로필입니다. latency-performance 프로필을 기반으로 합니다.
network-throughput

처리량 네트워크 튜닝을 위한 프로필입니다. throughput-performance 프로필을 기반으로 합니다. 커널 네트워크 버퍼를 추가로 늘립니다.

latency-performance 또는 throughput-performance 프로필을 상속하고, energy_performance_preferencescaling_governor 속성을 성능 프로필로 변경합니다.

virtual-guest

Red Hat Enterprise Linux 9 가상 시스템용으로 설계된 프로필과 throughput-performance 프로필 중 다른 작업 중 하나를 기반으로 하는 VMWare 게스트로, 가상 메모리 스왑piness 감소 및 디스크 readahead 값이 증가합니다. 디스크 장벽을 비활성화하지 않습니다.

throughput-performance 프로필을 상속하고 energy_performance_preferencescaling_governor 속성을 성능 프로필로 변경합니다.

virtual-host

throughput-performance 프로필을 기반으로 하는 가상 호스트를 위해 설계된 프로필로, 다른 작업 중에 가상 메모리 스왑piness를 줄이며, 디스크 readahead 값을 늘리며, 더 공격적인 더티 페이지 쓰기 값을 활성화합니다.

throughput-performance 프로필을 상속하고 energy_performance_preferencescaling_governor 속성을 성능 프로필로 변경합니다.

Oracle
Oracle 데이터베이스에 최적화된 프로필은 throughput-performance 프로필을 기반으로 로드됩니다. 또한 투명한 대규모 페이지를 비활성화하고 기타 성능 관련 커널 매개변수를 수정합니다. 이 프로필은 tuned-profiles-oracle 패키지에서 제공합니다.
desktop
balanced 프로필을 기반으로 하는 데스크탑에 최적화된 프로필입니다. 또한 스케줄러 자동 그룹을 활성화하여 대화형 애플리케이션의 대응을 개선할 수 있습니다.
optimize-serial-console

printk 값을 줄임으로써 직렬 콘솔에 I/O 활동을 조정하는 프로필입니다. 직렬 콘솔의 응답성이 향상되어야 합니다. 이 프로필은 다른 프로필에서 오버레이로 사용하기 위한 것입니다. 예를 들어 다음과 같습니다.

# tuned-adm profile throughput-performance optimize-serial-console
mssql
Microsoft SQL Server에 제공된 프로필입니다. throughput-performance 프로필을 기반으로 합니다.
intel-sst

사용자 정의 Intel Speed Select Technology 구성이 있는 시스템에 최적화된 프로필입니다. 이 프로필은 다른 프로필에서 오버레이로 사용하기 위한 것입니다. 예를 들어 다음과 같습니다.

# tuned-adm profile cpu-partitioning intel-sst

1.7. tuned cpu-partitioning 프로필

대기 시간에 민감한 워크로드에 맞게 Red Hat Enterprise Linux 9를 튜닝하려면 cpu-partitioning TuneD 프로필을 사용하는 것이 좋습니다.

Red Hat Enterprise Linux 9 이전에는 대기 시간이 짧은 Red Hat 문서에서는 대기 시간이 짧은 튜닝을 수행하는 데 필요한 수많은 낮은 수준의 단계를 설명했습니다. Red Hat Enterprise Linux 9에서는 cpu-partitioning TuneD 프로필을 사용하여 대기 시간이 짧은 튜닝을 보다 효율적으로 수행할 수 있습니다. 이 프로필은 대기 시간이 짧은 개별 애플리케이션의 요구 사항에 따라 쉽게 사용자 지정할 수 있습니다.

다음 그림은 cpu-partitioning 프로필을 사용하는 방법을 보여줍니다. 이 예에서는 CPU 및 노드 레이아웃을 사용합니다.

그림 1.1. figure cpu-partitioning

CPU 파티션

다음 구성 옵션을 사용하여 /etc/tuned/cpu-partitioning-ECDHEs.conf 파일에서 cpu-partitioning 프로필을 구성할 수 있습니다.

로드 밸런싱이 있는 격리된 CPU

cpu-partitioning figure에서 4에서 23으로 번호가 매겨진 블록은 기본 분리된 CPU입니다. 커널 스케줄러의 프로세스 부하 분산이 이러한 CPU에서 활성화됩니다. 커널 스케줄러 부하 분산이 필요한 여러 스레드가 있는 대기 시간이 짧은 프로세스를 위해 설계되었습니다.

kernel 스케줄러 로드 밸런싱을 사용할 CPU를 나열하는 isolated_cores= cpu-list 옵션을 사용하여 /etc/tuned/cpu-partitions.conf 파일에서 cpu-partitioning 프로필을 구성할 수 있습니다.

분리된 CPU 목록은 쉼표로 구분하거나 dash(예: )를 사용하여 범위를 지정할 수 있습니다. 이 옵션은 필수입니다. 이 목록에서 누락된 CPU는 자동으로 하우스키핑 CPU로 간주됩니다.

로드 밸런싱이 없는 격리된 CPU

cpu-partitioning 그림에서 번호가 지정된 블록 2와 3은 추가 커널 스케줄러 프로세스 부하 분산을 제공하지 않는 격리된 CPU입니다.

커널 스케줄러 로드 밸런싱을 사용하지 않는 CPU를 나열하는 no_balance_cores= cpu-list 옵션을 사용하여 /etc/tuned/cpu-partitions.conf 파일에서 cpu-partitioning 프로필을 구성할 수 있습니다.

no_balance_cores 옵션을 지정하는 것은 선택 사항이지만 이 목록의 모든 CPU는 isolated_cores 목록에 나열된 CPU의 하위 집합이어야 합니다.

이러한 CPU를 사용하는 애플리케이션 스레드를 각 CPU에 개별적으로 고정해야 합니다.

하우스키핑 CPU
cpu-partitioning-postgresqls.conf 파일에서 분리된 CPU는 자동으로 하우스키핑 CPU로 간주됩니다. 하우스키핑 CPU에서 모든 서비스, 데몬, 사용자 프로세스, 이동 가능한 커널 스레드, 인터럽트 처리기, 커널 타이머를 실행할 수 있습니다.

추가 리소스

  • tuned-profiles-cpu-partitioning(7) man page

1.8. 대기 시간이 짧은 튜닝을 위해 TuneD cpu-partitioning 프로파일 사용

이 프로세스에서는 TuneD의 cpu-partitioning 프로필을 사용하여 대기 시간이 짧은 시스템을 조정하는 방법을 설명합니다. cpu-partitioningcpu-partitioning 수치에 언급된 CPU 레이아웃을 사용할 수 있는 대기 시간이 짧은 애플리케이션의 예를 사용합니다.

이 경우 애플리케이션은 다음을 사용합니다.

  • 네트워크에서 데이터를 읽는 하나의 전용 리더 스레드가 CPU 2에 고정되어 있습니다.
  • 이 네트워크 데이터를 처리하는 많은 수의 스레드가 CPU 4-23에 고정되어 있습니다.
  • 처리된 데이터를 네트워크에 쓰는 전용 작성기 스레드는 CPU 3에 고정되어 있습니다.

사전 요구 사항

  • dnf install tuned-profiles- cpu-partitioning 명령을 root로 사용하여 cpu-partitioning TuneD 프로필 을 설치했습니다.

절차

  1. /etc/tuned/cpu-partitioning-ECDHEs.conf 파일을 편집하고 다음 정보를 추가합니다.

    # All isolated CPUs:
    isolated_cores=2-23
    # Isolated CPUs without the kernel’s scheduler load balancing:
    no_balance_cores=2,3
  2. cpu-partitioning TuneD 프로필을 설정합니다.

    # tuned-adm profile cpu-partitioning
  3. reboot

    재부팅 후 cpu-partitioning figure의 격리에 따라 대기 시간이 짧아지도록 시스템이 조정됩니다. 애플리케이션은 taskset을 사용하여 reader 및 writer 스레드를 2 및 3에 고정하고 CPU 4-23의 나머지 애플리케이션 스레드를 CPU 2 및 3에 고정할 수 있습니다.

추가 리소스

  • tuned-profiles-cpu-partitioning(7) man page

1.9. cpu-partitioning TuneD 프로파일 사용자 정의

TuneD 프로필을 확장하여 추가 튜닝을 변경할 수 있습니다.

예를 들어 cpu-partitioning 프로필은 CPU가 cstate=1 을 사용하도록 설정합니다. cpu-partitioning 프로필을 사용하지만 CPU cstate를 cstate1에서 cstate0으로 추가로 변경하려면 다음 절차에서는 cpu-partitioning 프로필을 상속하고 C state-0을 설정하는 my_profile 이라는 새 TuneD 프로필을 설명합니다.

절차

  1. /etc/tuned/my_profile 디렉토리를 만듭니다.

    # mkdir /etc/tuned/my_profile
  2. 이 디렉터리에 tuned.conf 파일을 생성하고 다음 콘텐츠를 추가합니다.

    # vi /etc/tuned/my_profile/tuned.conf
    [main]
    summary=Customized tuning on top of cpu-partitioning
    include=cpu-partitioning
    [cpu]
    force_latency=cstate.id:0|1
  3. 새 프로필을 사용합니다.

    # tuned-adm profile my_profile
참고

공유 예에서는 재부팅이 필요하지 않습니다. 그러나 my_profile 프로필의 변경 사항을 적용하려면 재부팅을 수행한 다음 시스템을 재부팅합니다.

추가 리소스

  • tuned-profiles-cpu-partitioning(7) man page

1.10. RHEL을 사용하여 실시간 TuneD 프로필 배포

실시간 프로필은 실시간 커널을 실행하는 시스템을 위한 것입니다. 특별한 커널 빌드가 없으면 시스템을 실시간으로 구성하지 않습니다. RHEL에서는 추가 리포지토리에서 프로필을 사용할 수 있습니다.

다음 실시간 프로필을 사용할 수 있습니다.

realtime

베어메탈 실시간 시스템에서 를 사용합니다.

RT 또는 NFV 리포지토리에서 사용할 수 있는 tuned-profiles-realtime 패키지에서 제공합니다.

realtime-virtual-host

실시간으로 구성된 가상화 호스트에서 를 사용합니다.

NFV 리포지토리에서 사용할 수 있는 tuned-profiles-nfv-host 패키지에서 제공합니다.

realtime-virtual-guest

실시간으로 구성된 가상화 게스트에서 를 사용합니다.

NFV 리포지토리에서 사용할 수 있는 tuned-profiles-nfv-guest 패키지에서 제공합니다.

1.11. TuneD의 정적 및 동적 튜닝

TuneD 가 적용하는 시스템 튜닝의 두 가지 범주의 차이점을 이해하는 것은 지정된 상황 또는 목적에 사용할 대상을 결정하는 경우 중요합니다.

정적 튜닝
주로 사전 정의된 sysctlsysfs 설정 애플리케이션과 함께 ethtool 과 같은 여러 구성 툴의 일회성 활성화로 구성됩니다.
동적 튜닝

시스템의 가동 시간 동안 다양한 시스템 구성 요소가 사용되는 방식을 감시합니다. tuned 는 모니터링 정보를 기반으로 시스템 설정을 동적으로 조정합니다.

예를 들어 하드 드라이브는 시작 및 로그인 중에 크게 사용되지만 나중에 사용자가 주로 웹 브라우저 또는 이메일 클라이언트 같은 애플리케이션에서 작업할 수 있는 경우 거의 사용되지 않습니다. 마찬가지로 CPU 및 네트워크 장치는 다른 시간에 다르게 사용됩니다. tuned 는 이러한 구성 요소의 활동을 모니터링하고 사용 중인 변경 사항에 반응합니다.

동적 튜닝은 기본적으로 비활성화되어 있습니다. 이를 활성화하려면 /etc/tuned/tuned-main.conf 파일을 편집하고 dynamic_tuning 옵션을 1 로 변경합니다. 그런 다음 tuned는 정기적으로 시스템 통계를 분석하고 이를 사용하여 시스템 튜닝 설정을 업데이트합니다. 이러한 업데이트 사이의 시간 간격을 초 단위로 구성하려면 update_interval 옵션을 사용합니다.

현재 동적 튜닝 알고리즘은 성능 및 절전의 균형을 유지하려고 시도하므로 성능 프로필에서 비활성화됩니다. 개별 플러그인에 대한 동적 튜닝은 TuneD 프로필에서 활성화하거나 비활성화할 수 있습니다.

예 1.2. 워크스테이션의 정적 및 동적 튜닝

일반적인 사무실 워크스테이션에서 이더넷 네트워크 인터페이스는 대부분의 시간 동안 비활성화됩니다. 일부 이메일만 들어오거나 나가거나 일부 웹 페이지가 로드될 수 있습니다.

이러한 종류의 로드의 경우 네트워크 인터페이스는 기본적으로와 같이 항상 전체 속도로 실행할 필요가 없습니다. tuned 에는 이 낮은 활동을 감지한 다음 해당 인터페이스의 속도를 자동으로 낮추어 일반적으로 전력 사용량을 줄일 수 있는 네트워크 장치에 대한 모니터링 및 튜닝 플러그인이 있습니다.

인터페이스의 활동이 더 긴 기간 동안 증가하는 경우, 예를 들어 DVD 이미지가 다운로드되고 있는 이메일이나 큰 첨부 파일이 있는 이메일이 열리기 때문에, TuneD 는 이를 감지하고 활동 수준이 높은 동안 최상의 성능을 제공하기 위해 인터페이스 속도를 최대로 설정합니다.

이 원칙은 CPU 및 디스크의 다른 플러그인에도 사용됩니다.

1.12. tuned no-daemon 모드

no-daemon 모드에서 TuneD 를 실행하면 상주 메모리가 필요하지 않습니다. 이 모드에서 TuneD 는 설정을 적용하고 종료합니다.

이 모드에서는 다음을 포함하여 많은 TuneD 기능이 없기 때문에 기본적으로 no-daemon 모드가 비활성화되어 있습니다.

  • D-Bus 지원
  • 핫플러그 지원
  • 설정 롤백 지원

no-daemon 모드를 활성화하려면 /etc/tuned/tuned-main.conf 파일에 다음 행을 포함합니다.

daemon = 0

1.13. TuneD 설치 및 활성화

이 절차에서는 TuneD 애플리케이션을 설치 및 활성화하고, TuneD 프로필을 설치하며, 시스템의 기본 TuneD 프로필을 사전 설정합니다.

절차

  1. TuneD 패키지를 설치합니다.

    # dnf install tuned
  2. TuneD 서비스를 활성화하고 시작합니다.

    # systemctl enable --now tuned
  3. 필요한 경우 실시간 시스템에 대한 TuneD 프로필을 설치합니다.

    실시간 시스템의 TuneD 프로필의 경우 rhel-9 리포지토리를 활성화합니다.

    # subscription-manager repos --enable=rhel-9-for-x86_64-nfv-beta-rpms

    설치합니다.

    # dnf install tuned-profiles-realtime tuned-profiles-nfv
  4. TuneD 프로필이 활성화되어 적용되는지 확인합니다.

    $ tuned-adm active
    
    Current active profile: throughput-performance
    참고

    활성 프로필 TuneD는 머신 유형 및 시스템 설정에 따라 자동으로 사전 설정됩니다.

    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

1.14. 사용 가능한 TuneD 프로필 나열

다음 절차에서는 시스템에서 현재 사용 가능한 모든 TuneD 프로필을 나열합니다.

절차

  • 시스템에서 사용 가능한 모든 TuneD 프로필을 나열하려면 다음을 사용합니다.

    $ tuned-adm list
    
    Available profiles:
    - accelerator-performance - Throughput performance based tuning with disabled higher latency STOP states
    - balanced                - General non-specialized TuneD profile
    - desktop                 - Optimize for the desktop use-case
    - latency-performance     - Optimize for deterministic performance at the cost of increased power consumption
    - network-latency         - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
    - network-throughput      - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks
    - powersave               - Optimize for low power consumption
    - throughput-performance  - Broadly applicable tuning that provides excellent performance across a variety of common server workloads
    - virtual-guest           - Optimize for running inside a virtual guest
    - virtual-host            - Optimize for running KVM guests
    Current active profile: balanced
  • 현재 활성화된 프로필만 표시하려면 다음을 사용합니다.

    $ tuned-adm active
    
    Current active profile: throughput-performance

추가 리소스

  • tuned-adm(8) man page.

1.15. TuneD 프로필 설정

이 절차에서는 시스템에서 선택한 TuneD 프로필을 활성화합니다.

사전 요구 사항

  • TuneD 서비스가 실행 중입니다. 자세한 내용은 TuneD 설치 및 활성화를 참조하십시오.

절차

  1. 필요한 경우 TuneD 가 시스템에 가장 적합한 프로필을 권장하도록 할 수 있습니다.

    # tuned-adm recommend
    
    throughput-performance
  2. 프로필을 활성화합니다.

    # tuned-adm profile selected-profile

    또는 여러 프로필의 조합을 활성화할 수도 있습니다.

    # tuned-adm profile selected-profile1 selected-profile2

    예 1.3. 낮은 전력 사용을 위해 최적화된 가상 머신

    다음 예제에서는 시스템을 최적화하여 최상의 성능을 갖춘 가상 시스템에서 실행하고 전력 소비가 낮은 전력을 위해 동시에 튜닝하는 것이 우선 순위입니다.

    # tuned-adm profile virtual-guest powersave
  3. 시스템에서 현재 활성화된 TuneD 프로필을 확인합니다.

    # tuned-adm active
    
    Current active profile: selected-profile
  4. 시스템을 재부팅합니다.

    # reboot

검증 단계

  • TuneD 프로필이 활성화되어 적용되는지 확인합니다.

    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

추가 리소스

  • tuned-adm(8) man page

1.16. TuneD D-Bus 인터페이스 사용

TuneD D-Bus 인터페이스를 통해 런타임 시 TuneD와 직접 통신하여 다양한 TuneD 서비스를 제어할 수 있습니다.

busctl 또는 dbus-send 명령을 사용하여 D-Bus API에 액세스할 수 있습니다.

참고

busctl 또는 dbus-send 명령을 사용할 수 있지만 busctl 명령은 systemd 의 일부이므로 이미 대부분의 호스트에 있습니다.

1.16.1. TuneD D-Bus 인터페이스를 사용하여 사용 가능한 TuneD D-Bus API 방법 표시

TuneD D-Bus 인터페이스를 사용하여 TuneD와 함께 사용할 수 있는 D-Bus API 메서드를 확인할 수 있습니다.

사전 요구 사항

절차

  • 사용 가능한 TuneD API 방법을 보려면 다음을 실행합니다.

    $ busctl introspect com.redhat.tuned /Tuned com.redhat.tuned.control

    출력은 다음과 유사해야 합니다.

    NAME                       	TYPE  	SIGNATURE RESULT/VALUE FLAGS
    .active_profile            	method	-     	  s            -
    .auto_profile              	method	-     	  (bs)         -
    .disable                   	method	-      	  b            -
    .get_all_plugins           	method	-     	  a{sa{ss}}    -
    .get_plugin_documentation  	method	s     	  s            -
    .get_plugin_hints          	method	s     	  a{ss}        -
    .instance_acquire_devices  	method	ss    	  (bs)         -
    .is_running                	method	-     	  b            -
    .log_capture_finish        	method	s     	  s            -
    .log_capture_start         	method	ii    	  s            -
    .post_loaded_profile       	method	-     	  s            -
    .profile_info              	method	s     	  (bsss)       -
    .profile_mode              	method	-     	  (ss)         -
    .profiles                  	method	-     	  as           -
    .profiles2                 	method	-     	  a(ss)        -
    .recommend_profile         	method	-     	  s            -
    .register_socket_signal_path    method	s     	  b            -
    .reload                    	method	-     	  b            -
    .start                     	method	-     	  b            -
    .stop                      	method	-     	  b            -
    .switch_profile            	method	s     	  (bs)         -
    .verify_profile            	method	-     	  b            -
    .verify_profile_ignore_missing  method	-     	  b            -
    .profile_changed           	signal	sbs   	  -            -

    TuneD 업스트림 리포지토리에서 사용 가능한 다양한 방법에 대한 설명을 찾을 수 있습니다.

1.16.2. TuneD D-Bus 인터페이스를 사용하여 활성 TuneD 프로필 변경

TuneD D-Bus 인터페이스를 사용하여 활성 TuneD 프로필을 원하는 TuneD 프로필로 교체할 수 있습니다.

사전 요구 사항

절차

  • 활성 TuneD 프로필을 변경하려면 다음을 실행합니다.

    $ busctl call com.redhat.tuned /Tuned com.redhat.tuned.control switch_profile s profile
    (bs) true "OK"

    프로필을 원하는 프로필의 이름으로 바꿉니다.

검증

  • 현재 활성화된 TuneD 프로필을 보려면 다음을 실행합니다.

    $ busctl call com.redhat.tuned /Tuned com.redhat.tuned.control active_profile
    s "profile"

1.17. TuneD 비활성화

이 절차에서는 TuneD 를 비활성화하고 TuneD 를 변경하기 전에 영향을 받는 모든 시스템 설정을 원래 상태로 재설정합니다.

절차

  • 모든 튜닝을 일시적으로 비활성화하려면 다음을 수행합니다.

    # tuned-adm off

    TuneD 서비스를 다시 시작한 후 튜닝이 다시 적용됩니다.

  • 또는 TuneD 서비스를 영구적으로 중지하고 비활성화하려면 다음을 수행합니다.

    # systemctl disable --now tuned

추가 리소스

  • tuned-adm(8) man page

2장. TuneD 프로필 사용자 정의

TuneD 프로필을 생성하거나 수정하여 원하는 사용 사례에 맞게 시스템 성능을 최적화할 수 있습니다.

사전 요구 사항

2.1. tuned 프로필

시스템의 상세한 분석은 매우 오래 걸릴 수 있습니다. tuned 는 일반적인 사용 사례에 대해 사전 정의된 여러 프로필을 제공합니다. 프로필을 생성, 수정 및 삭제할 수도 있습니다.

TuneD 로 제공되는 프로필은 다음 범주로 나뉩니다.

  • 절전 프로필
  • performance-boosting 프로필

performance-boosting 프로필에는 다음과 같은 측면에 중점을 둔 프로필이 포함됩니다.

  • 스토리지 및 네트워크에 대한 짧은 대기 시간
  • 스토리지 및 네트워크의 높은 처리량
  • 가상 머신 성능
  • 가상화 호스트 성능

프로필 구성의 구문

tuned.conf 파일에는 하나의 [main] 섹션과 플러그인 인스턴스를 구성하기 위한 다른 섹션을 포함할 수 있습니다. 그러나 모든 섹션은 선택 사항입니다.

해시 기호(#)로 시작하는 행은 주석입니다.

추가 리소스

  • tuned.conf(5) man page.

2.2. 기본 TuneD 프로필

설치하는 동안 시스템에 가장 적합한 프로필이 자동으로 선택됩니다. 현재 기본 프로필은 다음과 같은 사용자 정의 규칙에 따라 선택됩니다.

환경기본 프로필목표

컴퓨팅 노드

throughput-performance

최대 처리량 성능

가상 머신

virtual-guest

최상의 성능. 최상의 성능에 관심이 없는 경우 균형 잡힌 또는 절전 프로필로 변경할 수 있습니다.

기타 사례

balanced

균형 있는 성능 및 전력 소비

추가 리소스

  • tuned.conf(5) man page.

2.3. 병합된 TuneD 프로필

실험적 기능으로는 한 번에 더 많은 프로필을 선택할 수 있습니다. tuned 는 로드 중에 병합하려고 합니다.

충돌이 발생하면 마지막으로 지정된 프로필의 설정이 우선합니다.

예 2.1. 가상 게스트의 전력 소비 감소

다음 예제에서는 가상 머신에서 실행하도록 시스템을 최적화하여 최상의 성능을 발휘하고 전력 소비가 낮고 전력 소비가 낮을 때 동시에 조정할 수 있습니다.

# tuned-adm profile virtual-guest powersave
주의

결과 매개변수 조합이 의미가 있는지 확인하지 않고 병합이 자동으로 수행됩니다. 결과적으로 이 기능은 일부 매개 변수를 반대로 튜닝할 수 있습니다. 예를 들어, counterproductive일 수 있습니다. 예를 들어 throughput-performance 프로필을 사용하여 높은 처리량에 대해 디스크를 설정하고, 디스크 회전을 spindown-disk 프로필을 통해 낮은 값으로 디스크를 설정할 수 있습니다.

추가 리소스

*tuned-adm man 페이지. * tuned.conf(5) man page.

2.4. TuneD 프로필의 위치

tuned 는 프로필을 다음 디렉터리에 저장합니다.

/usr/lib/tuned/
배포별 프로필은 디렉터리에 저장됩니다. 각 프로필에는 자체 디렉터리가 있습니다. 프로필은 tuned.conf 라는 기본 구성 파일과 선택적으로 기타 파일(예: 도우미 스크립트)으로 구성됩니다.
/etc/tuned/
프로필을 사용자 지정해야 하는 경우 사용자 지정 프로필에 사용되는 디렉터리에 프로필 디렉터리를 복사합니다. 동일한 이름의 프로필이 두 개 있는 경우 /etc/tuned/ 에 있는 사용자 지정 프로필이 사용됩니다.

추가 리소스

  • tuned.conf(5) man page.

2.5. TuneD 프로필 간 상속

tuned 프로필은 다른 프로필을 기반으로 하며 해당 상위 프로필의 특정 측면만 수정할 수 있습니다.

TuneD 프로파일의 [main] 섹션은 include 옵션을 인식합니다.

[main]
include=parent

부모 프로필의 모든 설정은 이 하위 프로필에 로드됩니다. 다음 섹션의 하위 프로필은 상위 프로필에서 상속된 특정 설정을 재정의하거나 상위 프로필에 없는 새 설정을 추가할 수 있습니다.

일부 매개변수만 조정된 /usr/lib/tuned/ 의 사전 설치된 프로필을 기반으로 /etc/tuned/ 디렉터리에 자체 하위 프로필을 생성할 수 있습니다.

TuneD 업그레이드 후와 같이 상위 프로필이 업데이트되면 변경 사항이 하위 프로필에 반영됩니다.

예 2.2. 균형을 기반으로 한 전력 절감 프로필

다음은 균형 있는 프로필을 확장하고 모든 장치에 대한 Aggressive Link Power Management (ALPM)를 최대 전력으로 설정하는 사용자 정의 프로필의 예입니다.

[main]
include=balanced

[scsi_host]
alpm=min_power

추가 리소스

  • tuned.conf(5) man page

2.6. TuneD의 정적 및 동적 튜닝

TuneD 가 적용하는 시스템 튜닝의 두 가지 범주의 차이점을 이해하는 것은 지정된 상황 또는 목적에 사용할 대상을 결정하는 경우 중요합니다.

정적 튜닝
주로 사전 정의된 sysctlsysfs 설정 애플리케이션과 함께 ethtool 과 같은 여러 구성 툴의 일회성 활성화로 구성됩니다.
동적 튜닝

시스템의 가동 시간 동안 다양한 시스템 구성 요소가 사용되는 방식을 감시합니다. tuned 는 모니터링 정보를 기반으로 시스템 설정을 동적으로 조정합니다.

예를 들어 하드 드라이브는 시작 및 로그인 중에 크게 사용되지만 나중에 사용자가 주로 웹 브라우저 또는 이메일 클라이언트 같은 애플리케이션에서 작업할 수 있는 경우 거의 사용되지 않습니다. 마찬가지로 CPU 및 네트워크 장치는 다른 시간에 다르게 사용됩니다. tuned 는 이러한 구성 요소의 활동을 모니터링하고 사용 중인 변경 사항에 반응합니다.

동적 튜닝은 기본적으로 비활성화되어 있습니다. 이를 활성화하려면 /etc/tuned/tuned-main.conf 파일을 편집하고 dynamic_tuning 옵션을 1 로 변경합니다. 그런 다음 tuned는 정기적으로 시스템 통계를 분석하고 이를 사용하여 시스템 튜닝 설정을 업데이트합니다. 이러한 업데이트 사이의 시간 간격을 초 단위로 구성하려면 update_interval 옵션을 사용합니다.

현재 동적 튜닝 알고리즘은 성능 및 절전의 균형을 유지하려고 시도하므로 성능 프로필에서 비활성화됩니다. 개별 플러그인에 대한 동적 튜닝은 TuneD 프로필에서 활성화하거나 비활성화할 수 있습니다.

예 2.3. 워크스테이션의 정적 및 동적 튜닝

일반적인 사무실 워크스테이션에서 이더넷 네트워크 인터페이스는 대부분의 시간 동안 비활성화됩니다. 일부 이메일만 들어오거나 나가거나 일부 웹 페이지가 로드될 수 있습니다.

이러한 종류의 로드의 경우 네트워크 인터페이스는 기본적으로와 같이 항상 전체 속도로 실행할 필요가 없습니다. tuned 에는 이 낮은 활동을 감지한 다음 해당 인터페이스의 속도를 자동으로 낮추어 일반적으로 전력 사용량을 줄일 수 있는 네트워크 장치에 대한 모니터링 및 튜닝 플러그인이 있습니다.

인터페이스의 활동이 더 긴 기간 동안 증가하는 경우, 예를 들어 DVD 이미지가 다운로드되고 있는 이메일이나 큰 첨부 파일이 있는 이메일이 열리기 때문에, TuneD 는 이를 감지하고 활동 수준이 높은 동안 최상의 성능을 제공하기 위해 인터페이스 속도를 최대로 설정합니다.

이 원칙은 CPU 및 디스크의 다른 플러그인에도 사용됩니다.

2.7. tuned 플러그인

플러그인은 TuneD 프로필에서 시스템의 다른 장치를 모니터링하거나 최적화하기 위해 사용하는 모듈입니다.

tuned 는 다음 두 가지 유형의 플러그인을 사용합니다.

모니터링 플러그인

모니터링 플러그인은 실행 중인 시스템에서 정보를 가져오는 데 사용됩니다. 동적 튜닝을 위해 플러그인을 튜닝하는 경우 모니터링 플러그인 출력을 사용할 수 있습니다.

활성화된 튜닝 플러그인에서 메트릭이 필요할 때마다 모니터링 플러그인이 자동으로 인스턴스화됩니다. 두 개의 튜닝 플러그인에 동일한 데이터가 필요한 경우 모니터링 플러그인의 인스턴스 1개만 생성되고 데이터가 공유됩니다.

플러그인 튜닝
각 튜닝 플러그인은 개별 하위 시스템을 튜닝하고 TuneD 프로필에서 채워지는 여러 매개변수를 사용합니다. 각 하위 시스템에는 튜닝 플러그인의 개별 인스턴스에서 처리하는 여러 CPU 또는 네트워크 카드와 같은 여러 장치가 있을 수 있습니다. 개별 장치의 특정 설정도 지원됩니다.

TuneD 프로필의 플러그인 구문

플러그인 인스턴스를 설명하는 섹션은 다음과 같이 포맷됩니다.

[NAME]
type=TYPE
devices=DEVICES
NAME
로그에 사용되는 플러그인 인스턴스의 이름입니다. 임의의 문자열이 될 수 있습니다.
유형
는 튜닝 플러그인 유형입니다.
DEVICES

이 플러그인 인스턴스에서 처리하는 장치 목록입니다.

devices 행에는 목록, 와일드카드(*) 및 부정(!)이 포함될 수 있습니다. 장치 줄이 없는 경우 TYPE 시스템에 연결된 모든 장치가 플러그인 인스턴스에서 처리됩니다. devices=* 옵션을 사용하는 것과 동일합니다.

예 2.4. 플러그인을 사용하여 블록 장치 일치

다음 예제는 sda 또는 sdb 와 같이 sd 로 시작하는 모든 블록 장치와 일치하며, 이러한 장치에 대한 장벽을 비활성화하지 않습니다.

[data_disk]
type=disk
devices=sd*
disable_barriers=false

다음 예제는 sda1sda2 를 제외한 모든 블록 장치와 일치합니다.

[data_disk]
type=disk
devices=!sda1, !sda2
disable_barriers=false

플러그인 인스턴스를 지정하지 않으면 플러그인이 활성화되지 않습니다.

플러그인이 더 많은 옵션을 지원하는 경우 플러그인 섹션에서 지정할 수도 있습니다. 옵션을 지정하지 않고 이전에 포함된 플러그인에 지정하지 않은 경우 기본값이 사용됩니다.

짧은 플러그인 구문

플러그인 인스턴스에 사용자 정의 이름이 필요하지 않고 구성 파일에 인스턴스에 대한 정의가 하나만 있는 경우 TuneD 는 다음과 같은 짧은 구문을 지원합니다.

[TYPE]
devices=DEVICES

이 경우 type 행을 생략할 수 있습니다. 그런 다음 인스턴스를 type과 동일한 이름으로 참조합니다. 이전 예제는 다음과 같이 다시 작성할 수 있습니다.

예 2.5. 짧은 구문을 사용하여 블록 장치 일치

[disk]
devices=sdb*
disable_barriers=false

프로필에서 플러그인 정의 충돌

include 옵션을 사용하여 동일한 섹션을 두 번 이상 지정하면 설정이 병합됩니다. 충돌로 인해 병합할 수 없는 경우 마지막으로 충돌하는 정의가 이전 설정을 덮어씁니다. 이전에 정의한 내용을 모르는 경우 replace 부울 옵션을 사용하여 true 로 설정할 수 있습니다. 이로 인해 이름이 같은 이전 정의를 모두 덮어쓰고 병합이 발생하지 않습니다.

enabled=false 옵션을 지정하여 플러그인을 비활성화할 수도 있습니다. 이 방법은 인스턴스가 정의되지 않은 경우와 동일합니다. 플러그인을 비활성화하면 include 옵션에서 이전 정의를 다시 정의하고 사용자 정의 프로필에서 플러그인을 활성화하지 않으려면 유용합니다.

참고

tuned 에는 튜닝 프로파일 활성화 또는 비활성화의 일부로 쉘 명령을 실행하는 기능이 포함되어 있습니다. 이를 통해 아직 TuneD 에 통합되지 않은 기능을 사용하여 TuneD 프로필을 확장할 수 있습니다.

script 플러그인을 사용하여 임의의 쉘 명령을 지정할 수 있습니다.

추가 리소스

  • tuned.conf(5) man page

2.8. 사용 가능한 TuneD 플러그인

모니터링 플러그인

현재 다음과 같은 모니터링 플러그인이 구현되어 있습니다.

disk
장치 및 측정 간격당 디스크 로드( IO 작업 수)를 가져옵니다.
net
네트워크 카드 및 측정 간격당 네트워크 로드(전송된 패킷 수)를 가져옵니다.
load
CPU 및 측정 간격당 CPU 부하를 가져옵니다.

플러그인 튜닝

현재 다음과 같은 튜닝 플러그인이 구현되어 있습니다. 이러한 플러그인 중 일부만 동적 튜닝을 구현합니다. 플러그인에서 지원하는 옵션도 나열됩니다.

cpu

CPU governor 옵션을 통해 지정된 값으로 CPU governor 를 설정하고 CPU 로드에 따라 PM QoS(Power Management Quality of Service) CPU Direct Memory Access(DMA) 대기 시간을 동적으로 변경합니다.

CPU 로드가 load_threshold 옵션에 지정된 값보다 작으면 대기 시간이 latency_high 옵션에 지정된 값으로 설정되고, 그렇지 않으면 latency_low 에 의해 지정된 값으로 설정됩니다.

또한 대기 시간을 특정 값으로 강제 적용하고 동적으로 변경되는 것을 방지할 수 있습니다. 이렇게 하려면 force_latency 옵션을 필요한 대기 시간으로 설정합니다.

eeepc_she

CPU 로드에 따라 프런트 사이드 버스(FSB) 속도를 동적으로 설정합니다.

이 기능은 일부 netbook에서 찾을 수 있으며 ASUS Super Hybrid Engine (SHE)이라고도합니다.

CPU 로드가 load_threshold_powersave 옵션에 지정된 값보다 작거나 같은 경우 플러그인은 FSB 속도를 she_powersave 옵션에 지정된 값으로 설정합니다. CPU 로드가 load_threshold_normal 옵션에 지정된 값과 크거나 같은 경우 FSB 속도를 she_normal 옵션에 지정된 값으로 설정합니다.

정적 튜닝이 지원되지 않으며 TuneD 에서 이 기능에 대한 하드웨어 지원을 감지하지 않으면 플러그인이 투명하게 비활성화됩니다.

net
Wake-on-LAN 기능을 wake_on_lan 옵션에 지정된 값으로 구성합니다. ethtool 유틸리티와 동일한 구문을 사용합니다. 또한 인터페이스 사용률에 따라 인터페이스 속도를 동적으로 변경합니다.
sysctl

플러그인 옵션으로 지정된 다양한 sysctl 설정을 설정합니다.

구문은 name=value 이며, 여기서 namesysctl 유틸리티에서 제공하는 이름과 동일합니다.

TuneD 에서 사용할 수 있는 다른 플러그인에서 다루지 않는 시스템 설정을 변경해야 하는 경우 sysctl 플러그인을 사용합니다. 일부 특정 플러그인에서 설정이 적용되는 경우 이러한 플러그인을 선호합니다.

usb

USB 장치의 자동 일시 중지 시간 제한을 autosuspend 매개 변수에서 지정한 값으로 설정합니다.

0 은 자동 일시 중지가 비활성화되어 있음을 의미합니다.

vm

transparent_hugepages 옵션의 값에 따라 투명한 대규모 페이지를 활성화하거나 비활성화합니다.

transparent_hugepages 옵션의 유효한 값은 다음과 같습니다.

  • "always"
  • "never"
  • "madvise"
audio

시간 제한 옵션으로 지정된 값으로 오디오 codecs의 자동 대기 시간 제한을 설정합니다.

현재 snd_hda_intelsnd_ac97_codec codecs가 지원됩니다. 값 0 은 자동 일시 중지가 비활성화되어 있음을 의미합니다. 부울 옵션 reset_controllertrue 로 설정하여 컨트롤러 재설정을 적용할 수도 있습니다.

disk

디스크 로켓을 엘리베이터 옵션에 지정된 값으로 설정합니다.

또한 다음을 설정합니다.

  • APM 옵션을 통해 지정한 값으로 설정
  • 스케줄러 _quantum 옵션에 의해 지정된 값에 대한 스케줄러 full
  • 회전 옵션에서 지정한 값에 대한 디스크 회전 시간 초과
  • readahead 매개변수로 지정된 값에 대한 디스크 readahead
  • current disk readahead to a value multiplied by the constant specified by the readahead_multiply 옵션

또한 이 플러그인은 현재 드라이브 사용률에 따라 드라이브에 대한 고급 전원 관리 및 회전 시간 초과 설정을 동적으로 변경합니다. 동적 튜닝은 부울 옵션 동적 로 제어할 수 있으며 기본적으로 활성화되어 있습니다.

scsi_host

SCSI 호스트의 옵션을 조정합니다.

Aggressive Link Power Management (ALPM)를 alpm 옵션에 지정된 값으로 설정합니다.

mounts
disable_barriers 옵션의 부울 값에 따라 마운트 장벽을 활성화하거나 비활성화합니다.
script

프로필이 로드되거나 언로드될 때 외부 스크립트 또는 바이너리를 실행합니다. 임의의 실행 파일을 선택할 수 있습니다.

중요

스크립트 플러그인은 주로 이전 릴리스와의 호환성을 위해 제공됩니다. 필요한 기능을 포함하는 경우 다른 TuneD 플러그인을 선호하십시오.

tuned 는 다음 인수 중 하나를 사용하여 실행 파일을 호출합니다.

  • 프로필을 로드할 때 시작
  • 프로필을 언로드할 때 중지

실행 파일에 stop 작업을 올바르게 구현하고 시작 작업 중에 변경한 모든 설정을 되돌립니다. 그러지 않으면 TuneD 프로필을 변경한 후 롤백 단계가 작동하지 않습니다.

Bash 스크립트는 /usr/lib/tuned/functions Bash 라이브러리를 가져오고 여기에 정의된 함수를 사용할 수 있습니다. 이러한 기능은 TuneD 에서 기본적으로 제공하지 않는 기능에만 사용하십시오. 함수 이름이 _wifi_set_power_level 과 같은 밑줄로 시작하는 경우 함수를 비공개로 간주하고 나중에 변경될 수 있으므로 스크립트에서 이 함수를 사용하지 마십시오.

플러그인 구성에서 script 매개 변수를 사용하여 실행 파일의 경로를 지정합니다.

예 2.6. 프로필에서 Bash 스크립트 실행

프로필 디렉터리에 있는 script.sh 라는 Bash 스크립트를 실행하려면 다음을 사용합니다.

[script]
script=${i:PROFILE_DIR}/script.sh
sysfs

플러그인 옵션으로 지정된 다양한 sysfs 설정을 설정합니다.

구문은 name=value 이며, 여기서 name 은 사용할 sysfs 경로입니다.

다른 플러그인에서 다루지 않는 일부 설정을 변경해야 하는 경우 이 플러그인을 사용하십시오. 필요한 설정을 포함하는 경우 특정 플러그인을 선호합니다.

video

비디오 카드에 다양한 전원 저장 수준을 설정합니다. 현재 Radeon 카드만 지원됩니다.

powersave 수준은 radeon_powersave 옵션을 사용하여 지정할 수 있습니다. 지원되는 값은 다음과 같습니다.

  • default
  • auto
  • 낮음 (LOW)
  • mid
  • 높음
  • dynpm
  • dpm-battery
  • dpm-balanced
  • dpm-perfomance

자세한 내용은 www.x.org 을 참조하십시오. 이 플러그인은 실험적이며 향후 릴리스에서 옵션이 변경될 수 있습니다.

bootloader

커널 명령줄에 옵션을 추가합니다. 이 플러그인은 GRUB 2 부트 로더만 지원합니다.

GRUB 2 설정 파일의 사용자 지정 비표준 위치는 grub2_cfg_file 옵션으로 지정할 수 있습니다.

커널 옵션이 현재 GRUB 설정 및 해당 템플릿에 추가됩니다. 커널 옵션을 적용하려면 시스템을 재부팅해야 합니다.

다른 프로필로 전환하거나 TuneD 서비스를 수동으로 중지하면 추가 옵션이 제거됩니다. 시스템을 종료하거나 재부팅하는 경우 커널 옵션은 grub.cfg 파일에 유지됩니다.

커널 옵션은 다음 구문으로 지정할 수 있습니다.

cmdline=arg1 arg2 ... argN

예 2.7. 커널 명령줄 수정

예를 들어, quiet 커널 옵션을 TuneD 프로필에 추가하려면 tuned.conf 파일에 다음 행을 포함합니다.

[bootloader]
cmdline=quiet

다음은 isolcpus=2 옵션을 커널 명령줄에 추가하는 사용자 정의 프로필의 예입니다.

[bootloader]
cmdline=isolcpus=2
service

플러그인 옵션으로 지정된 다양한 sysvinit,sysv-rc,openrcsystemd 서비스를 처리합니다.

구문은 service.service_name=command[,file:file] 입니다.

지원되는 서비스 처리 명령은 다음과 같습니다.

  • start
  • 중지
  • 활성화
  • disable

쉼표(,) 또는 ;(;)를 사용하여 여러 명령을 구분합니다. 지시문이 충돌하면 서비스 플러그인에서 마지막으로 나열된 항목을 사용합니다.

선택적 file:file 지시문을 사용하여 systemd 에 대해서만 오버레이 구성 파일인 file 을 설치합니다. 다른 init 시스템은 이 지시문을 무시합니다. 서비스 플러그인은 오버레이 구성 파일을 /etc/systemd/system/service_name.service.d/ 디렉터리에 복사합니다. 프로필이 언로드되면 서비스 플러그인은 이러한 디렉터리가 비어 있는 경우 해당 디렉터리를 제거합니다.

참고

서비스 플러그인은systemd init 이외의 시스템에서만 작동합니다.

예 2.8. 오버레이 파일을 사용하여 sendmail sendmail 서비스 시작 및 활성화

[service]
service.sendmail=start,enable,file:${i:PROFILE_DIR}/tuned-sendmail.conf

내부 변수 ${i:PROFILE_DIR} 은 플러그인이 프로필을 로드하는 디렉터리를 가리킵니다.

scheduler
스케줄링 우선 순위, CPU 코어 격리 및 프로세스, 스레드 및 IRQ 작업의 조정에 대한 다양한 옵션을 제공합니다.

사용 가능한 다양한 옵션의 세부 사항은 스케줄러 TuneD 플러그인의 기능을 참조하십시오.

2.9. 스케줄러 TuneD 플러그인의 기능

스케줄러 TuneD 플러그인을 사용하여 스케줄링 우선 순위, CPU 코어 격리 및 프로세스, 스레드 및 IRQ afinities를 제어하고 조정합니다.

CPU 격리

프로세스, 스레드 및 IRQ가 특정 CPU를 사용하지 못하도록 하려면 isolated_cores 옵션을 사용합니다. 프로세스 및 스레드 특성을 변경하고 IRQ에 대한 default_smp_affinity 매개변수를 설정합니다.

CPU 선호도 마스크는 sched_setaffinity() 시스템 호출의 성공 여부에 따라 ps_whitelist 옵션과 일치하는 모든 프로세스 및 스레드에 맞게 조정됩니다. ps_whitelist 정규식의 기본 설정은 모든 프로세스 및 스레드 이름과 일치하는 .* 입니다. 특정 프로세스 및 스레드를 제외하려면 ps_blacklist 옵션을 사용합니다. 이 옵션의 값은 정규식으로도 해석됩니다. 프로세스 및 스레드 이름은 해당 표현식과 일치합니다. 프로필 롤백을 사용하면 일치하는 모든 프로세스 및 스레드를 모든 CPU에서 실행하고 profile 애플리케이션 전에 IRQ 설정을 복원합니다.

ps_whitelistps_blacklist 옵션은 .로 구분된 여러 정규식이 지원됩니다. \; 은 문자 그대로 사용됩니다.

예 2.9. CPU 2-4 분리

다음 구성은 CPU 2-4를 분리합니다. ps_blacklist 정규식과 일치하는 프로세스 및 스레드는 격리와 관계없이 모든 CPU를 사용할 수 있습니다.

[scheduler]
isolated_cores=2-4
ps_blacklist=.*pmd.*;.*PMD.*;^DPDK;.*qemu-kvm.*

IRQ SMP 선호도

/proc/irq/default_smp_affinity 파일에는 모든 비활성 인터럽트 요청(IRQ) 소스에 대해 시스템의 기본 대상 CPU 코어를 나타내는 비트마스크가 포함되어 있습니다. IRQ가 활성화되거나 할당되면 /proc/irq/default_smp_affinity 파일의 값이 IRQ의 선호도 비트마스크를 결정합니다.

default_irq_smp_affinity 매개변수는 /proc/irq/default_smp_affinity 파일에 쓰는 TuneD 를 제어합니다. default_irq_smp_affinity 매개변수는 다음 값과 동작을 지원합니다.

calc

isolated_cores 매개변수에서 /proc/irq/default_smp_affinity 파일의 내용을 계산합니다. isolated_cores 매개변수의 반전은 격리되지 않은 코어를 계산합니다.

그러면 격리되지 않은 코어와 /proc/irq/default_smp_affinity 파일의 이전 콘텐츠가 /proc/irq/default_smp_affinity 파일에 기록됩니다.

default_irq_smp_affinity 매개변수가 생략된 경우 기본 동작입니다.

ignore
tuned/proc/irq/default_smp_affinity 파일을 수정하지 않습니다.
CPU 목록

1 과 같은 단일 숫자 형식, 1,3 과 같은 쉼표로 구분된 목록 또는 3-5 와 같은 범위를 가져옵니다.

CPU 목록의 압축을 풀고 /proc/irq/default_smp_affinity 파일에 직접 씁니다.

예 2.10. 명시적 CPU 목록을 사용하여 기본 IRQ smp 유사성 설정

다음 예제에서는 명시적 CPU 목록을 사용하여 기본 IRQ SMP 선호도를 CPU 0 및 2로 설정합니다.

[scheduler]
isolated_cores=1,3
default_irq_smp_affinity=0,2

스케줄링 정책

프로세스 또는 스레드 그룹의 우선 순위 및 선호도를 조정하려면 다음 구문을 사용합니다.

group.groupname=rule_prio:sched:prio:affinity:regex

여기서 rule_prio 는 규칙의 내부 TuneD 우선 순위를 정의합니다. 규칙은 우선 순위에 따라 정렬됩니다. 이는 상속이 이전에 정의된 규칙을 다시 정렬할 수 있도록 하는 데 필요합니다. 동일한 rule_prio 규칙을 정의한 순서대로 처리해야 합니다. 그러나 이것은 Python 인터프리터에 의존하는 것입니다. 그룹 이름에 대해 상속된 규칙을 비활성화하려면 다음을 사용합니다.

group.groupname=

Sched는 다음 중 하나여야 합니다.

f
for first in, first out (FIFO)
b
일괄 처리의 경우
r
라운드 로빈의 경우
o
기타의 경우
*
for do not change

유사성 은 16진수의 CPU 선호도입니다. 변경하지 않으려면 * 를 사용하십시오.

P rio 는 스케줄링 우선 순위입니다( chrt -m참조).

regex 는 Python 정규식입니다. ps -eo cmd 명령의 출력과 일치합니다.

지정된 프로세스 이름은 둘 이상의 그룹과 일치할 수 있습니다. 이러한 경우 마지막 일치 regex 는 우선 순위 및 스케줄링 정책을 결정합니다.

예 2.11. 스케줄링 정책 및 우선순위 설정

다음 예제에서는 스케줄링 정책 및 우선순위를 커널 스레드 및 워치독으로 설정합니다.

[scheduler]
group.kthreads=0:*:1:*:\[.*\]$
group.watchdog=0:f:99:*:\[watchdog.*\]

스케줄러 플러그인은 perf 이벤트 루프를 사용하여 새로 생성된 프로세스를 식별합니다. 기본적으로 perf.RECORD_COMMperf.RECORD_EXIT 이벤트를 수신합니다.

perf_process_fork 매개변수를 true 로 설정하면 플러그인이 perf.RECORD_FORK 이벤트를 수신 대기하도록 지시합니다. 즉, fork() 시스템 호출에 의해 생성된 하위 프로세스가 처리됩니다.

참고

perf 이벤트를 처리하면 상당한 CPU 오버헤드가 발생할 수 있습니다.

스케줄러 런타임 옵션을 사용하여 0 으로 설정하여 스케줄러 플러그인의 CPU 오버헤드를 완화할 수 있습니다. 이렇게 하면 동적 스케줄러 기능이 완전히 비활성화되고 perf 이벤트가 모니터링되지 않고 작동합니다. 이에 대한 단점은 프로세스 및 스레드 튜닝이 프로필 애플리케이션에서만 수행된다는 것입니다.

예 2.12. 동적 스케줄러 기능 비활성화

다음 예제에서는 CPU 1과 3을 격리하는 동안 동적 스케줄러 기능을 비활성화합니다.

[scheduler]
runtime=0
isolated_cores=1,3

mmapped 버퍼는 perf 이벤트에 사용됩니다. 로드가 많은 경우 이 버퍼가 오버플로될 수 있으므로 플러그인이 누락된 이벤트를 시작하고 새로 생성된 일부 프로세스를 처리하지 못할 수 있습니다. 이러한 경우 perf_mmap_pages 매개변수를 사용하여 버퍼 크기를 늘립니다. perf_mmap_pages 매개변수의 값은 2의 power여야 합니다. perf_mmap_pages 매개변수가 수동으로 설정되지 않은 경우 기본값 128이 사용됩니다.

cgroup을 사용한 제한

스케줄러 플러그인은 cgroups v1을 사용하여 프로세스 및 스레드 제한을 지원합니다.

cgroup_mount_point 옵션은 cgroup 파일 시스템을 마운트할 경로를 지정하거나 TuneD 에서 마운트할 것으로 예상합니다. 설정되지 않은 경우 /sys/fs/cgroup/cpuset 이 예상됩니다.

cgroup_groups_init 옵션이 1 로 설정된 경우TuneDcgroup* 옵션으로 정의된 모든 cgroup 을 생성하고 제거합니다. 이는 기본 동작입니다. cgroup_mount_point 옵션이 0 으로 설정된 경우 다른 방법으로 cgroup 을 사전 설정해야 합니다.

cgroup_mount_point_init 옵션이 1 로 설정된 경우TuneD 는 cgroup 마운트 지점을 생성하고 제거합니다. cgroup_groups_init = 1 임을 의미합니다. cgroup_mount_point_init 옵션이 0 으로 설정된 경우 cgroups 마운트 지점을 다른 방법으로 사전 설정해야 합니다. 이는 기본 동작입니다.

cgroup_for_isolated_cores 옵션은 isolated_cores 옵션 기능의 cgroup 이름입니다. 예를 들어 시스템에 CPU가 4개인 경우 isolated_cores=1Tuned 가 모든 프로세스와 스레드를 CPU 0, 2 및 3으로 이동함을 의미합니다. 스케줄러 플러그인은 계산된 CPU 선호도를 지정된 cgroup의 cpuset.cpus 제어 파일에 작성하고 일치하는 모든 프로세스 및 스레드를 이 그룹으로 이동하여 지정된 코어를 분리합니다. 이 옵션이 설정되지 않은 경우 sched_setaffinity() 를 사용하여 클래식 cpuset 선호도가 CPU 선호도를 설정합니다.

cgroup.cgroup_name 옵션은 임의의 cgroup 에 대한 연결을 정의합니다. hierarchic cgroups도 사용할 수 있지만 계층 구조를 올바른 순서로 지정해야 합니다. tunedcgroup_mount_point 옵션에 의해 지정된 위치에 cgroup 을 강제 적용하는 것을 제외하고 여기에 정당성 검사를 수행하지 않습니다.

group 으로 시작하는 스케줄러 옵션의 구문은 16진수 선호도 대신 cgroup.cgroup_name 을 사용하도록 보강되었습니다. 일치하는 프로세스가 cgroup cgroup_name 으로 이동합니다. 위에 설명된 대로 cgroup. 옵션에 정의되지 않은 cgroup을 사용할 수도 있습니다. 예를 들어 cgroupTuneD 에서 관리하지 않습니다.

모든 cgroup 이름은 모든 마침표(.)를 슬래시(/)로 교체하여 종료됩니다. 이렇게 하면 플러그인이 cgroup_mount_point 옵션으로 지정된 위치 외부에 기록되지 않습니다.

예 2.13. 스케줄러 플러그인과 함께 cgroups v1 사용

다음 예제에서는 cgroup 2개,group1group2 를 생성합니다. cgroup group1 선호도를 CPU 2로 설정하고 cgroup group2 를 CPU 0 및 2로 설정합니다. 4 CPU 설정이 지정된 경우 isolated_cores=1 옵션은 모든 프로세스와 스레드를 CPU 코어 0, 2 및 3으로 이동합니다. ps_blacklist 정규식으로 지정된 프로세스 및 스레드는 이동되지 않습니다.

[scheduler]
cgroup_mount_point=/sys/fs/cgroup/cpuset
cgroup_mount_point_init=1
cgroup_groups_init=1
cgroup_for_isolated_cores=group
cgroup.group1=2
cgroup.group2=0,2

group.ksoftirqd=0:f:2:cgroup.group1:ksoftirqd.*
ps_blacklist=ksoftirqd.*;rcuc.*;rcub.*;ktimersoftd.*
isolated_cores=1

cgroup_ps_blacklist 옵션은 지정된 cgroup 에 속하는 프로세스를 제외합니다. 이 옵션으로 지정된 정규식은 /proc/PID/cgroupscgroup 계층 구조와 일치합니다. 쉼표(,)는 정규식과 일치하기 전에 cgroup v1 계층을 /proc/PID/cgroups 에서 분리합니다. 다음은 정규식이 일치하는 콘텐츠의 예입니다.

10:hugetlb:/,9:perf_event:/,8:blkio:/

여러 정규 표현식은 together(;)으로 구분할 수 있습니다. together는 논리 '또는' 연산자를 나타냅니다.

예 2.14. cgroup을 사용하여 스케줄러에서 프로세스 제외

다음 예에서 스케줄러 플러그인은 cgroup /daemons 에 속하는 프로세스를 제외하고 모든 프로세스를 코어 1에서 이동합니다. \b 문자열은 단어 경계와 일치하는 정규식 메타 문자입니다.

[scheduler]
isolated_cores=1
cgroup_ps_blacklist=:/daemons\b

다음 예에서 스케줄러 플러그인은 hierarchy-ID가 8이고 controller-list blkio 인 cgroup에 속하는 모든 프로세스를 제외합니다.

[scheduler]
isolated_cores=1
cgroup_ps_blacklist=\b8:blkio:

최근 커널은 sysctl 유틸리티에서 관리하는 /proc/sys/kernel 디렉터리에서 일반적으로 /sys/kernel/ debug 디렉터리에 마운트된 일부 sched_numa_balancing_ 커널 런타임 매개변수를 /proc/sys/kernel 디렉터리에 이동했습니다. tuned는 스케줄러 플러그인을 통해 다음 매개변수에 대한 추상화 메커니즘을 제공합니다. 여기서 사용된 커널을 기반으로 TuneD 는 지정된 값을 올바른 위치에 씁니다.

  • sched_min_granularity_ns
  • sched_latency_ns,
  • sched_wakeup_granularity_ns
  • sched_tunable_scaling,
  • sched_migration_cost_ns
  • sched_nr_migrate
  • numa_balancing_scan_delay_ms
  • numa_balancing_scan_period_min_ms
  • numa_balancing_scan_period_max_ms
  • numa_balancing_scan_size_mb

    예 2.15. 마이그레이션 결정에 대한 작업의 "캐시 핫" 값을 설정합니다.

    이전 커널에서 다음 매개변수를 설정하면 sysctl/proc/sys/kernel/sched_migration_cost_ns 파일에 500000 값을 작성했습니다.

    [sysctl]
    kernel.sched_migration_cost_ns=500000

    이는 스케줄러 플러그인을 통해 다음 매개변수를 설정하는 것과 동일한 최신 커널에서 다음과 같습니다.

    [scheduler]
    sched_migration_cost_ns=500000

    TuneD/sys/kernel/debug/sched/migration_cost_ns 파일에 500000 값을 씁니다.

2.10. TuneD 프로필의 변수

TuneD 프로필이 활성화되면 런타임에 변수가 확장됩니다.

TuneD 변수를 사용하면 TuneD 프로필에서 필요한 입력 수를 줄일 수 있습니다.

TuneD 프로파일에는 사전 정의된 변수가 없습니다. 프로필에서 [Variables] 섹션을 생성하고 다음 구문을 사용하여 고유한 변수 를 정의할 수 있습니다.

[variables]

variable_name=value

프로필의 변수 값을 확장하려면 다음 구문을 사용합니다.

${variable_name}

예 2.16. 변수를 사용하여 CPU 코어 분리

다음 예에서 ${isolated_cores} 변수는 12로 확장됩니다. 따라서 커널은 isolcpus=1,2 옵션으로 부팅됩니다.

[variables]
isolated_cores=1,2

[bootloader]
cmdline=isolcpus=${isolated_cores}

변수는 별도의 파일에 지정할 수 있습니다. 예를 들어 tuned.conf 에 다음 행을 추가할 수 있습니다.

[variables]
include=/etc/tuned/my-variables.conf

[bootloader]
cmdline=isolcpus=${isolated_cores}

isolated_cores=1,2 옵션을 /etc/tuned/my-aliass.conf 파일에 추가하면 커널은 isolcpus=1,2 옵션으로 부팅됩니다.

추가 리소스

  • tuned.conf(5) man page

2.11. TuneD 프로파일의 기본 제공 함수

기본 제공 함수는 TuneD 프로필이 활성화되면 런타임에 확장됩니다.

다음을 수행할 수 있습니다.

  • TuneD 변수와 함께 다양한 기본 제공 함수 사용
  • Python에서 사용자 정의 함수를 생성하고 플러그인 형태로 TuneD 에 추가합니다.

함수를 호출하려면 다음 구문을 사용합니다.

${f:function_name:argument_1:argument_2}

프로필 및 tuned.conf 파일이 있는 디렉터리 경로를 확장하려면 특수 구문이 필요한 PROFILE_DIR 함수를 사용합니다.

${i:PROFILE_DIR}

예 2.17. 변수 및 기본 제공 함수를 사용하여 CPU 코어 분리

다음 예에서 ${non_isolated_cores} 변수는 03-5 로 확장되고 cpulist_invert 기본-invert 함수는 0,3-5 인수를 사용하여 호출됩니다.

[variables]
non_isolated_cores=0,3-5

[bootloader]
cmdline=isolcpus=${f:cpulist_invert:${non_isolated_cores}}

cpulist_invert 함수는 CPU 목록을 반전합니다. 6-CPU 시스템의 경우 inversion은 1,2 이며 커널은 isolcpus=1,2 명령줄 옵션으로 부팅됩니다.

추가 리소스

  • tuned.conf(5) man page

2.12. TuneD 프로필에서 사용할 수 있는 기본 제공 함수

다음 기본 제공 함수는 모든 TuneD 프로필에서 사용할 수 있습니다.

PROFILE_DIR
프로필과 tuned.conf 파일이 있는 디렉터리 경로를 반환합니다.
exec
프로세스를 실행하고 출력을 반환합니다.
assertion
두 개의 인수를 비교합니다. 이 값이 일치하지 않으면 함수에서 첫 번째 인수의 텍스트를 기록하고 프로필 로드를 중단합니다.
assertion_non_equal
두 개의 인수를 비교합니다. 이 값이 일치하면 함수는 첫 번째 인수의 텍스트를 기록하고 프로필 로드를 중단합니다.
kb2s
킬로바이트를 디스크 섹터로 변환합니다.
s2kb
디스크 섹터를 킬로바이트로 변환합니다.
strip
전달된 모든 인수에서 문자열을 만들고 선행 및 후행 공백을 모두 삭제합니다.
virt_check

가상 머신(VM) 내에서 TuneD 가 실행 중인지 또는 베어 메탈에서 실행 중인지 확인합니다.

  • VM 내에서 함수는 첫 번째 인수를 반환합니다.
  • 베어 메탈에서 함수는 오류가 발생하는 경우에도 두 번째 인수를 반환합니다.
cpulist_invert
CPU 목록을 반전하여 보완합니다. 예를 들어 CPU가 4개인 시스템에서는 0에서 3으로 번호가 매겨지면 목록 0,2,3 의 버전이 1 입니다.
cpulist2hex
CPU 목록을 16진수 CPU 마스크로 변환합니다.
cpulist2hex_invert
CPU 목록을 16진수 CPU 마스크로 변환하고 반전합니다.
hex2cpulist
16진수 CPU 마스크를 CPU 목록으로 변환합니다.
cpulist_online
목록의 CPU가 온라인 상태인지 확인합니다. 온라인 CPU만 포함하는 목록을 반환합니다.
cpulist_present
목록의 CPU가 있는지 확인합니다. 현재 CPU만 포함하는 목록을 반환합니다.
cpulist_unpack
1-3,4 에서 1,2,3,4 형식으로 CPU 목록의 압축을 풉니다.
cpulist_pack
1,2,3,5 에서 1-3,5 형식의 CPU 목록을 포함합니다.

2.13. 새 TuneD 프로필 생성

이 절차에서는 사용자 정의 성능 규칙을 사용하여 새 TuneD 프로필을 생성합니다.

사전 요구 사항

  • TuneD 서비스가 실행 중입니다. 자세한 내용은 TuneD 설치 및 활성화를 참조하십시오.

절차

  1. /etc/tuned/ 디렉터리에서 생성하려는 프로필과 동일한 라는 새 디렉터리를 생성합니다.

    # mkdir /etc/tuned/my-profile
  2. 새 디렉터리에 tuned.conf 라는 파일을 생성합니다. 요구 사항에 따라 [main] 섹션 및 플러그인 정의를 추가합니다.

    예를 들어 balanced 프로파일 구성을 참조하십시오.

    [main]
    summary=General non-specialized TuneD profile
    
    [cpu]
    governor=conservative
    energy_perf_bias=normal
    
    [audio]
    timeout=10
    
    [video]
    radeon_powersave=dpm-balanced, auto
    
    [scsi_host]
    alpm=medium_power
  3. 프로필을 활성화하려면 다음을 사용합니다.

    # tuned-adm profile my-profile
  4. TuneD 프로필이 활성 상태이고 시스템 설정이 적용되었는지 확인합니다.

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

추가 리소스

  • tuned.conf(5) man page

2.14. 기존 TuneD 프로필 수정

이 절차에서는 기존 TuneD 프로필을 기반으로 수정된 하위 프로필을 생성합니다.

사전 요구 사항

  • TuneD 서비스가 실행 중입니다. 자세한 내용은 TuneD 설치 및 활성화를 참조하십시오.

절차

  1. /etc/tuned/ 디렉터리에서 생성하려는 프로필과 동일한 라는 새 디렉터리를 생성합니다.

    # mkdir /etc/tuned/modified-profile
  2. 새 디렉터리에서 tuned.conf 라는 파일을 생성하고 [main] 섹션을 다음과 같이 설정합니다.

    [main]
    include=parent-profile

    parent-profile 을 수정 중인 프로필 이름으로 교체합니다.

  3. 프로파일 수정 사항을 포함합니다.

    예 2.18. throughput-performance 프로필에서 swappiness 감소

    throughput-performance 프로필의 설정을 사용하고 기본값 10이 아닌 vm.swappiness 값을 5로 변경하려면 다음을 사용합니다.

    [main]
    include=throughput-performance
    
    [sysctl]
    vm.swappiness=5
  4. 프로필을 활성화하려면 다음을 사용합니다.

    # tuned-adm profile modified-profile
  5. TuneD 프로필이 활성 상태이고 시스템 설정이 적용되었는지 확인합니다.

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

추가 리소스

  • tuned.conf(5) man page

2.15. TuneD를 사용하여 디스크 스케줄러 설정

이 절차에서는 선택한 블록 장치에 지정된 디스크 스케줄러를 설정하는 TuneD 프로필을 생성하고 활성화합니다. 시스템 재부팅 시 설정이 유지됩니다.

다음 명령 및 구성에서 다음을 교체합니다.

  • 블록 장치 의 이름이 있는 장치(예: sdf)
  • 장치에 설정하려는 디스크 스케줄러가 있는 선택된- scheduler(예: bfq)

사전 요구 사항

절차

  1. 선택 사항: 프로필을 기반으로 할 기존 TuneD 프로필을 선택합니다. 사용 가능한 프로필 목록은 RHEL을 사용하여 배포된 TuneD 프로필을 참조하십시오.

    현재 활성화되어 있는 프로필을 확인하려면 다음을 사용합니다.

    $ tuned-adm active
  2. TuneD 프로필을 저장할 새 디렉터리를 생성합니다.

    # mkdir /etc/tuned/my-profile
  3. 선택한 블록 장치의 시스템 고유 식별자를 찾습니다.

    $ udevadm info --query=property --name=/dev/device | grep -E '(WWN|SERIAL)'
    
    ID_WWN=0x5002538d00000000_
    ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0
    ID_SERIAL_SHORT=20120501030900000
    참고

    이 예제의 명령은 지정된 블록 장치와 연결된 WWN(WWN) 또는 일련 번호로 식별되는 모든 값을 반환합니다. WWN을 사용하는 것이 바람직하지만, 지정된 장치에 WWN을 항상 사용할 수는 없으며 example 명령에서 반환된 모든 값은 장치 시스템 고유 ID 로 사용할 수 있습니다.

  4. /etc/tuned/my-profile/tuned.conf 구성 파일을 만듭니다. 파일에서 다음 옵션을 설정합니다.

    1. 선택 사항: 기존 프로필이 포함되어 있습니다.

      [main]
      include=existing-profile
    2. WWN 식별자와 일치하는 장치에 선택한 디스크 스케줄러를 설정합니다.

      [disk]
      devices_udev_regex=IDNAME=device system unique id
      elevator=selected-scheduler

      여기:

      • IDNAME 을 사용 중인 식별자 이름(예: ID_WWN)으로 바꿉니다.
      • 장치 시스템 고유 ID 를 선택한 식별자의 값으로 바꿉니다(예: 0x5002538d00000000).

        devices_udev_regex 옵션의 여러 장치와 일치하려면 식별자를 괄호로 묶고 세로 막대로 분리합니다.

        devices_udev_regex=(ID_WWN=0x5002538d00000000)|(ID_WWN=0x1234567800000000)
  5. 프로필을 활성화합니다.

    # tuned-adm profile my-profile

검증 단계

  1. TuneD 프로필이 활성화되어 적용되는지 확인합니다.

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See TuneD log file ('/var/log/tuned/tuned.log') for details.
  2. /sys/block/device/queue/scheduler 파일의 내용을 읽습니다.

    # cat /sys/block/device/queue/scheduler
    
    [mq-deadline] kyber bfq none

    파일 이름에서 장치를 블록 장치 이름으로 바꿉니다(예: sdc ).

    활성 스케줄러는 대괄호([])로 나열됩니다.

추가 리소스

3장. tuna 인터페이스를 사용하여 시스템 검토

tuna 툴은 튜닝 작업 수행의 복잡성을 줄입니다. tuna 를 사용하여 스케줄러 튜닝 가능 항목을 조정하고 스레드 우선 순위, IRQ 처리기를 조정하며 CPU 코어와 소켓을 분리합니다. tuna 툴을 사용하면 다음 작업을 수행할 수 있습니다.

  • 시스템의 CPU를 나열합니다.
  • 시스템에서 현재 실행 중인 인터럽트 요청(IRQ)을 나열합니다.
  • 스레드에 대한 정책 및 우선 순위 정보를 변경합니다.
  • 시스템의 현재 정책 및 우선 순위를 표시합니다.

3.1. tuna 툴 설치

tuna 툴은 실행 중인 시스템에서 사용하도록 설계되었습니다. 이를 통해 애플리케이션별 측정 툴을 사용하여 변경 후 즉시 시스템 성능을 확인하고 분석할 수 있습니다.

절차

  • tuna 툴을 설치합니다.

    # dnf install tuna

검증 단계

  • 사용 가능한 tuna CLI 옵션을 표시합니다.

    # tuna -h

추가 리소스

  • tuna(8) 매뉴얼 페이지

3.2. tuna 툴을 사용하여 시스템 상태 보기

tuna CLI(명령줄 인터페이스) 툴을 사용하여 시스템 상태를 볼 수 있습니다.

사전 요구 사항

  • tuna 툴이 설치되어 있습니다. 자세한 내용은 tuna 툴 설치를 참조하십시오.

절차

  1. 현재 정책 및 우선 순위를 확인합니다.

    # tuna show_threads
    pid   SCHED_ rtpri affinity             cmd
    1      OTHER     0      0,1            init
    2       FIFO    99        0     migration/0
    3      OTHER     0        0     ksoftirqd/0
    4       FIFO    99        0      watchdog/0

    또는 PID에 해당하는 특정 스레드를 보거나 명령 이름과 일치하는 특정 스레드를 보려면 다음을 입력합니다.

    # tuna show_threads -t pid_or_cmd_list

    pid_or_cmd_list 인수는 쉼표로 구분된 PID 또는 command-name 패턴 목록입니다.

  2. 시나리오에 따라 다음 작업 중 하나를 수행합니다.

  3. 변경된 구성을 저장합니다.

    # tuna save filename

    이 명령은 현재 실행 중인 커널 스레드만 저장합니다. 실행 중이 아닌 프로세스는 저장되지 않습니다.

추가 리소스

  • 시스템의 tuna(8) 도움말 페이지

3.3. tuna 툴을 사용하여 CPU 튜닝

tuna 툴 명령은 개별 CPU를 대상으로 지정할 수 있습니다. tuna 툴을 사용하면 다음 작업을 수행할 수 있습니다.

CPU 격리
지정된 CPU에서 실행되는 모든 작업은 사용 가능한 다음 CPU로 이동합니다. CPU를 격리하면 모든 스레드의 선호도 마스크에서 이 CPU를 제거할 수 없습니다.
CPU 포함
지정된 CPU에서 작업을 실행할 수 있습니다.
CPU 복원
지정된 CPU를 이전 구성으로 복원합니다.

사전 요구 사항

  • tuna 툴이 설치되어 있습니다. 자세한 내용은 tuna 툴 설치를 참조하십시오.

절차

  1. 모든 CPU를 나열하고 명령의 영향을 받을 CPU 목록을 지정합니다.

    # ps ax | awk 'BEGIN { ORS="," }{ print $1 }'
    PID,1,2,3,4,5,6,8,10,11,12,13,14,15,16,17,19
  2. tuna 인터페이스에서 스레드 목록을 표시합니다.

    # tuna show_threads -t 'thread_list from above cmd'
  3. 명령의 영향을 받을 CPU 목록을 지정합니다.

    # *tuna [command] --cpus cpu_list *

    cpu_list 인수는 쉼표로 구분된 CPU 번호 목록입니다(예: --cpus 0,2 ).

    현재 cpu_list 에 특정 CPU를 추가하려면 (예: --cpus +0 )를 사용합니다.

  4. 시나리오에 따라 다음 작업 중 하나를 수행합니다.

    • CPU를 분리하려면 다음을 입력합니다.

      # tuna isolate --cpus cpu_list
    • CPU를 포함하려면 다음을 입력합니다.

      # tuna include --cpus cpu_list
  5. 4개 이상의 프로세서가 있는 시스템을 사용하려면 모든 ssh 스레드가 CPU 01 과 CPU 23 에서 모든 http 스레드에서 실행되도록 합니다.

    # tuna move --cpus 0,1 -t ssh*
    # tuna move --cpus 2,3 -t http\*

검증 단계

  • 현재 구성을 표시하고 변경 사항이 적용되었는지 확인합니다.

    # tuna show_threads -t ssh*
    
    pid   SCHED_  rtpri  affinity   voluntary   nonvoluntary   cmd
    855   OTHER   0      0,1        23           15            sshd
    
    # tuna show_threads -t http\*
    pid   SCHED_  rtpri  affinity   voluntary   nonvoluntary   cmd
    855   OTHER   0       2,3        23           15           http

추가 리소스

  • /proc/cpuinfo 파일
  • 시스템의 tuna(8) 도움말 페이지

3.4. tuna 툴을 사용하여 IRQ 조정

/proc/interrupts 파일은 IRQ당 인터럽트 수, 인터럽트 유형, IRQ에 있는 장치의 이름을 기록합니다.

사전 요구 사항

  • tuna 툴이 설치되어 있습니다. 자세한 내용은 tuna 툴 설치를 참조하십시오.

절차

  1. 현재 IRQ 및 해당 선호도를 확인합니다.

    # tuna show_irqs
    # users            affinity
    0 timer                   0
    1 i8042                   0
    7 parport0                0
  2. 명령의 영향을 받을 IRQ 목록을 지정합니다.

    # tuna [command] --irqs irq_list --cpus cpu_list

    irq_list 인수는 쉼표로 구분된 IRQ 번호 또는 사용자 이름 패턴 목록입니다.

    [명령]을 (예: --spread )로 바꿉니다.

  3. 인터럽트를 지정된 CPU로 이동합니다.

    # tuna show_irqs --irqs 128
    users            affinity
    128 iwlwifi           0,1,2,3
    
    # tuna move --irqs 128 --cpus 3

    128 을 irq_list 인수 및 3 으로 cpu_list 인수로 바꿉니다.

    cpu_list 인수는 쉼표로 구분된 CPU 번호 목록입니다(예: --cpus 0,2 ). 자세한 내용은 tuna 툴을 사용하여 CPU 튜닝을 참조하십시오.

검증 단계

  • 인터럽트를 지정된 CPU로 이동하기 전과 후에 선택한 IRQ의 상태를 비교합니다.

    # tuna show_irqs --irqs 128
         users            affinity
     128 iwlwifi                 3

추가 리소스

  • /Procs/interrupts 파일
  • 시스템의 tuna(8) 도움말 페이지

4장. RHEL 시스템 역할을 사용하여 성능 모니터링

시스템 관리자는 메트릭 RHEL 시스템 역할을 사용하여 시스템의 성능을 모니터링할 수 있습니다.

4.1. RHEL 시스템 역할을 사용하도록 컨트롤 노드 및 관리형 노드 준비

개별 RHEL 시스템 역할을 사용하여 서비스 및 설정을 관리하려면 먼저 제어 노드와 관리 노드를 준비해야 합니다.

4.1.1. RHEL 9에서 제어 노드 준비

RHEL 시스템 역할을 사용하기 전에 제어 노드를 구성해야 합니다. 그런 다음 이 시스템은 플레이북에 따라 인벤토리에서 관리 호스트를 구성합니다.

사전 요구 사항

  • 시스템이 고객 포털에 등록되어 있습니다.
  • Red Hat Enterprise Linux Server 서브스크립션이 시스템에 연결되어 있습니다.
  • 선택 사항: Ansible Automation Platform 서브스크립션이 시스템에 연결되어 있습니다.

절차

  1. ansible 이라는 사용자를 생성하여 플레이북을 관리하고 실행합니다.

    [root@control-node]# useradd ansible
  2. 새로 생성된 ansible 사용자로 전환합니다.

    [root@control-node]# su - ansible

    이 사용자로 나머지 절차를 수행합니다.

  3. SSH 공개 및 개인 키를 생성합니다.

    [ansible@control-node]$ ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/ansible/.ssh/id_rsa):
    Enter passphrase (empty for no passphrase): <password>
    Enter same passphrase again: <password>
    ...

    키 파일에 제안된 기본 위치를 사용합니다.

  4. 선택 사항: Ansible에서 연결을 설정할 때마다 SSH 키 암호를 입력하라는 메시지를 표시하지 않도록 SSH 에이전트를 구성합니다.
  5. 다음 콘텐츠를 사용하여 ~/.ansible.cfg 파일을 생성합니다.

    [defaults]
    inventory = /home/ansible/inventory
    remote_user = ansible
    
    [privilege_escalation]
    become = True
    become_method = sudo
    become_user = root
    become_ask_pass = True
    참고

    ~/.ansible.cfg 파일의 설정은 우선 순위가 높으며 전역 /etc/ansible/ansible.cfg 파일의 설정을 재정의합니다.

    이러한 설정을 통해 Ansible은 다음 작업을 수행합니다.

    • 지정된 인벤토리 파일의 호스트를 관리합니다.
    • 관리 노드에 대한 SSH 연결을 설정할 때 remote_user 매개변수에 설정된 계정을 사용합니다.
    • sudo 유틸리티를 사용하여 관리 노드에서 root 사용자로 작업을 실행합니다.
    • 플레이북을 적용할 때마다 원격 사용자의 루트 암호를 입력하라는 메시지를 표시합니다. 이는 보안상의 이유로 권장됩니다.
  6. 관리 호스트의 호스트 이름을 나열하는 INI 또는 YAML 형식으로 ~/inventory 파일을 생성합니다. 인벤토리 파일에서 호스트 그룹을 정의할 수도 있습니다. 예를 들어 다음은 3개의 호스트와 US 라는 호스트 그룹 1개가 있는 INI 형식의 인벤토리 파일입니다.

    managed-node-01.example.com
    
    [US]
    managed-node-02.example.com ansible_host=192.0.2.100
    managed-node-03.example.com

    제어 노드에서 호스트 이름을 확인할 수 있어야 합니다. DNS 서버가 특정 호스트 이름을 확인할 수 없는 경우 호스트 항목 옆에 있는 ansible_host 매개변수를 추가하여 IP 주소를 지정합니다.

  7. RHEL 시스템 역할을 설치합니다.

    • Ansible Automation Platform이 없는 RHEL 호스트에서 rhel-system-roles 패키지를 설치합니다.

      [root@control-node]# dnf install rhel-system-roles

      이 명령은 /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/ 디렉터리에 컬렉션을 설치하고 ansible-core 패키지를 종속성으로 설치합니다.

    • Ansible Automation Platform에서 ansible 사용자로 다음 단계를 수행합니다.

      1. Red Hat 자동화 허브를 ~/.ansible.cfg 파일의 기본 콘텐츠 소스로 정의합니다.
      2. Red Hat 자동화 허브에서 redhat.rhel_system_roles 컬렉션을 설치합니다.

        [ansible@control-node]$ ansible-galaxy collection install redhat.rhel_system_roles

        이 명령은 ~/.ansible/collections/ansible_collections/redhat/rhel_system_roles/ 디렉터리에 컬렉션을 설치합니다.

다음 단계

4.1.2. 관리형 노드 준비

관리형 노드는 인벤토리에 나열되는 시스템이며, 플레이북에 따라 제어 노드에서 구성합니다. 관리 호스트에 Ansible을 설치할 필요가 없습니다.

사전 요구 사항

  • 제어 노드를 준비합니다. 자세한 내용은 RHEL 9에서 제어 노드 준비를 참조하십시오.
  • 제어 노드에서 SSH 액세스 권한이 있어야 합니다.

    중요

    root 사용자로 직접 SSH 액세스는 보안 위험이 있습니다. 이 위험을 줄이기 위해 이 노드에 로컬 사용자를 생성하고 관리 노드를 준비할 때 sudo 정책을 구성합니다. 그런 다음 제어 노드의 Ansible은 로컬 사용자 계정을 사용하여 관리 노드에 로그인하고 root 와 같은 다른 사용자로 플레이북을 실행할 수 있습니다.

절차

  1. ansible 이라는 사용자를 생성합니다.

    [root@managed-node-01]# useradd ansible

    나중에 제어 노드는 이 사용자를 사용하여 이 호스트에 대한 SSH 연결을 설정합니다.

  2. ansible 사용자의 암호를 설정합니다.

    [root@managed-node-01]# passwd ansible
    Changing password for user ansible.
    New password: <password>
    Retype new password: <password>
    passwd: all authentication tokens updated successfully.

    Ansible에서 sudo 를 사용하여 작업을 root 사용자로 수행할 때 이 암호를 입력해야 합니다.

  3. 관리 노드에 ansible 사용자의 SSH 공개 키를 설치합니다.

    1. 제어 노드에 ansible 사용자로 로그인하고 SSH 공개 키를 관리 노드에 복사합니다.

      [ansible@control-node]$ ssh-copy-id managed-node-01.example.com
      /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/ansible/.ssh/id_rsa.pub"
      The authenticity of host 'managed-node-01.example.com (192.0.2.100)' can't be established.
      ECDSA key fingerprint is SHA256:9bZ33GJNODK3zbNhybokN/6Mq7hu3vpBXDrCxe7NAvo.
    2. 프롬프트가 표시되면 yes 를 입력하여 연결합니다.

      Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
      /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
      /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
    3. 암호를 입력하라는 메시지가 표시되면 암호를 입력합니다.

      ansible@managed-node-01.example.com's password: <password>
      
      Number of key(s) added: 1
      
      Now try logging into the machine, with:   "ssh 'managed-node-01.example.com'"
      and check to make sure that only the key(s) you wanted were added.
    4. 제어 노드에서 명령을 원격으로 실행하여 SSH 연결을 확인합니다.

      [ansible@control-node]$ ssh managed-node-01.example.com whoami
      ansible
  4. ansible 사용자에 대한 sudo 구성을 생성합니다.

    1. visudo 명령을 사용하여 /etc/sudoers.d/ansible 파일을 만들고 편집합니다.

      [root@managed-node-01]# visudo /etc/sudoers.d/ansible

      일반 편집기에서 visudo 를 사용하면 이 유틸리티에서 기본 온전성 검사를 제공하고 파일을 설치하기 전에 구문 분석 오류를 점검할 수 있습니다.

    2. 요구 사항을 충족하는 /etc/ sudoers.d/ansible 파일에서 sudoers 정책을 구성합니다. 예를 들면 다음과 같습니다.

      • ansible 사용자 암호를 입력한 후 이 호스트의 모든 사용자 및 그룹으로 모든 명령을 실행할 수 있는 권한을 ansible 사용자에게 부여하려면 다음을 사용합니다.

        ansible   ALL=(ALL) ALL
      • ansible 사용자 암호를 입력하지 않고 이 호스트의 모든 사용자 및 그룹으로 모든 명령을 실행할 수 있는 권한을 ansible 사용자에게 부여하려면 다음을 사용합니다.

        ansible   ALL=(ALL) NOPASSWD: ALL

    또는 보안 요구 사항과 일치하는 더 세분화된 정책을 구성합니다. sudoers 정책에 대한 자세한 내용은 sudoers(5) 매뉴얼 페이지를 참조하십시오.

검증

  1. 모든 관리형 노드의 제어 노드에서 명령을 실행할 수 있는지 확인합니다.

    [ansible@control-node]$ ansible all -m ping
    BECOME password: <password>
    managed-node-01.example.com | SUCCESS => {
        	"ansible_facts": {
        	    "discovered_interpreter_python": "/usr/bin/python3"
        	},
        	"changed": false,
        	"ping": "pong"
    }
    ...

    하드 코딩된 모든 그룹에는 인벤토리 파일에 나열된 모든 호스트가 동적으로 포함됩니다.

  2. Ansible command 모듈을 사용하여 관리 호스트에서 whoami 유틸리티를 실행하여 권한 상승이 올바르게 작동하는지 확인합니다.

    [ansible@control-node]$ ansible managed-node-01.example.com -m command -a whoami
    BECOME password: <password>
    managed-node-01.example.com | CHANGED | rc=0 >>
    root

    명령이 root를 반환하면 관리 노드에서 sudo 를 올바르게 구성한 것입니다.

추가 리소스

4.2. 메트릭 시스템 역할 소개

RHEL 시스템 역할은 여러 RHEL 시스템을 원격으로 관리하는 일관된 구성 인터페이스를 제공하는 Ansible 역할 및 모듈의 컬렉션입니다. 지표 시스템 역할은 로컬 시스템에 대한 성능 분석 서비스를 구성하고 선택적으로 로컬 시스템에서 모니터링할 원격 시스템 목록을 포함합니다. 지표 시스템 역할을 사용하면 플레이북에서 pcp 설정 및 배포를 처리하므로 pcp를 사용하여 pcp 를 별도로 구성할 필요 없이 시스템 성능을 모니터링할 수 있습니다.

추가 리소스

  • /usr/share/ansible/roles/rhel-system-roles.metrics/README.md 파일
  • /usr/share/doc/rhel-system-roles/metrics/ 디렉터리

4.3. 메트릭 시스템 역할을 사용하여 시각화로 로컬 시스템 모니터링

다음 절차에서는 지표 RHEL 시스템 역할을 사용하여 Grafana 를 통해 동시에 데이터 시각화를 프로비저닝하는 동시에 로컬 시스템을 모니터링하는 방법을 설명합니다.

사전 요구 사항

  • 컨트롤 노드 및 관리형 노드를 준비했습니다.
  • 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
  • 관리 노드에 연결하는 데 사용하는 계정에는 sudo 권한이 있습니다.
  • localhost 는 제어 노드의 인벤토리 파일에 구성되어 있습니다.

    localhost ansible_connection=local

절차

  1. 다음 콘텐츠를 사용하여 플레이북 파일(예: ~/playbook.yml )을 생성합니다.

    ---
    - name: Manage metrics
      hosts: localhost
      roles:
        - rhel-system-roles.metrics
      vars:
        metrics_graph_service: yes
        metrics_manage_firewall: true
        metrics_manage_selinux: true

    metrics_graph_service 부울이 value="yes" 로 설정되므로 Grafana 는 데이터 소스로 추가된 pcp 를 사용하여 자동으로 설치 및 프로비저닝됩니다. metrics_manage_firewallmetrics_manage_selinux 가 모두 true 로 설정되므로 지표 역할은 firewallselinux 시스템 역할을 사용하여 metrics 역할에서 사용하는 포트를 관리합니다.

  2. 플레이북 구문을 확인합니다.

    $ ansible-playbook --syntax-check ~/playbook.yml

    이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

  3. Playbook을 실행합니다.

    $ ansible-playbook ~/playbook.yml

검증

추가 리소스

  • /usr/share/ansible/roles/rhel-system-roles.metrics/README.md 파일
  • /usr/share/doc/rhel-system-roles/metrics/ 디렉터리

4.4. 메트릭 시스템 역할을 사용하여 자체적으로 모니터링할 개별 시스템 설정

다음 절차에서는 메트릭 시스템 역할을 사용하여 자체적으로 모니터링할 시스템을 설정하는 방법을 설명합니다.

사전 요구 사항

절차

  1. 다음 콘텐츠를 사용하여 플레이북 파일(예: ~/playbook.yml )을 생성합니다.

    ---
    - name: Configure a fleet of machines to monitor themselves
      hosts: managed-node-01.example.com
      roles:
        - rhel-system-roles.metrics
      vars:
        metrics_retention_days: 0
        metrics_manage_firewall: true
        metrics_manage_selinux: true

    metrics_manage_firewallmetrics_manage_selinux 가 모두 true 로 설정되므로 지표 역할은 firewallselinux 역할을 사용하여 metrics 역할에서 사용하는 포트를 관리합니다.

  2. 플레이북 구문을 확인합니다.

    $ ansible-playbook --syntax-check ~/playbook.yml

    이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

  3. Playbook을 실행합니다.

    $ ansible-playbook ~/playbook.yml

추가 리소스

  • /usr/share/ansible/roles/rhel-system-roles.metrics/README.md 파일
  • /usr/share/doc/rhel-system-roles/metrics/ 디렉터리

4.5. 메트릭 시스템 역할을 사용하여 로컬 시스템을 통해 중앙에서 시스템을 모니터링

다음 절차에서는 메트릭 시스템 역할을 사용하여 시스템 플릿을 중앙에서 모니터링하면서 grafana 를 통해 데이터 시각화를 프로비저닝하고 redis 를 통해 데이터를 쿼리하는 방법을 설명합니다.

사전 요구 사항

  • 컨트롤 노드 및 관리형 노드를 준비했습니다.
  • 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
  • 관리 노드에 연결하는 데 사용하는 계정에는 sudo 권한이 있습니다.
  • localhost 는 제어 노드의 인벤토리 파일에 구성되어 있습니다.

    localhost ansible_connection=local

절차

  1. 다음 콘텐츠를 사용하여 플레이북 파일(예: ~/playbook.yml )을 생성합니다.

    - name: Set up your local machine to centrally monitor a fleet of machines
      hosts: localhost
      roles:
        - rhel-system-roles.metrics
      vars:
        metrics_graph_service: yes
        metrics_query_service: yes
        metrics_retention_days: 10
        metrics_monitored_hosts: ["database.example.com", "webserver.example.com"]
        metrics_manage_firewall: yes
        metrics_manage_selinux: yes

    metrics_graph_servicemetrics_query_service 부울이 value="yes" 로 설정되므로 grafana pcp 데이터 레코딩을 redis 로 인덱싱하여 데이터 소스로 추가되도록 자동으로 설치 및 프로비저닝되므로 pcp 쿼리 언어를 사용하여 데이터의 복잡한 쿼리에 사용할 수 있습니다. metrics_manage_firewallmetrics_manage_selinux 가 모두 true 로 설정되므로 지표 역할은 firewallselinux 역할을 사용하여 metrics 역할에서 사용하는 포트를 관리합니다.

  2. 플레이북 구문을 확인합니다.

    $ ansible-playbook --syntax-check ~/playbook.yml

    이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

  3. Playbook을 실행합니다.

    $ ansible-playbook ~/playbook.yml

검증

추가 리소스

  • /usr/share/ansible/roles/rhel-system-roles.metrics/README.md 파일
  • /usr/share/doc/rhel-system-roles/metrics/ 디렉터리

4.6. 메트릭 시스템 역할을 사용하여 시스템을 모니터링하는 동안 인증 설정

PCP는 SASL(Simple Authentication Security Layer) 프레임워크를 통해 scram-sha-256 인증 메커니즘을 지원합니다. 지표 RHEL 시스템 역할은 scram-sha-256 인증 메커니즘을 사용하여 인증을 설정하는 단계를 자동화합니다. 다음 절차에서는 RHEL 시스템 역할을 사용하여 인증을 설정하는 방법을 설명합니다.

사전 요구 사항

절차

  1. 기존 플레이북 파일(예: ~/playbook.yml )을 편집하고 인증 관련 변수를 추가합니다.

    ---
    - name: Set up authentication by using the scram-sha-256 authentication mechanism
      hosts: managed-node-01.example.com
      roles:
        - rhel-system-roles.metrics
      vars:
        metrics_retention_days: 0
        metrics_manage_firewall: true
        metrics_manage_selinux: true
        metrics_username: <username>
        metrics_password: <password>
  2. 플레이북 구문을 확인합니다.

    $ ansible-playbook --syntax-check ~/playbook.yml

    이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

  3. Playbook을 실행합니다.

    $ ansible-playbook ~/playbook.yml

검증

  • sasl 구성을 확인합니다.

    # pminfo -f -h "pcp://managed-node-01.example.com?username=<username>" disk.dev.read
    Password: <password>
    disk.dev.read
    inst [0 or "sda"] value 19540

추가 리소스

  • /usr/share/ansible/roles/rhel-system-roles.metrics/README.md 파일
  • /usr/share/doc/rhel-system-roles/metrics/ 디렉터리

4.7. 메트릭 시스템 역할을 사용하여 SQL Server에 대한 메트릭 컬렉션을 구성하고 활성화

다음 절차에서는 RHEL 시스템 역할을 사용하여 로컬 시스템의 pcp 를 통해 Microsoft SQL Server에 대한 메트릭 컬렉션을 자동화하고 활성화하는 방법을 설명합니다.

사전 요구 사항

절차

  1. 다음 콘텐츠를 사용하여 플레이북 파일(예: ~/playbook.yml )을 생성합니다.

    ---
    - name: Configure and enable metrics collection for Microsoft SQL Server
      hosts: localhost
      roles:
        - rhel-system-roles.metrics
      vars:
        metrics_from_mssql: true
        metrics_manage_firewall: true
        metrics_manage_selinux: true

    metrics_manage_firewallmetrics_manage_selinux 가 모두 true 로 설정되므로 지표 역할은 firewallselinux 역할을 사용하여 metrics 역할에서 사용하는 포트를 관리합니다.

  2. 플레이북 구문을 확인합니다.

    $ ansible-playbook --syntax-check ~/playbook.yml

    이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

  3. Playbook을 실행합니다.

    $ ansible-playbook ~/playbook.yml

검증

  • pcp 명령을 사용하여 SQL Server PMDA 에이전트(mssql)가 로드되고 실행되고 있는지 확인합니다.

    # pcp
    platform: Linux sqlserver.example.com 4.18.0-167.el8.x86_64 #1 SMP Sun Dec 15 01:24:23 UTC 2019 x86_64
     hardware: 2 cpus, 1 disk, 1 node, 2770MB RAM
     timezone: PDT+7
     services: pmcd pmproxy
         pmcd: Version 5.0.2-1, 12 agents, 4 clients
         pmda: root pmcd proc pmproxy xfs linux nfsclient mmv kvm mssql
               jbd2 dm
     pmlogger: primary logger: /var/log/pcp/pmlogger/sqlserver.example.com/20200326.16.31
         pmie: primary engine: /var/log/pcp/pmie/sqlserver.example.com/pmie.log

추가 리소스

  • /usr/share/ansible/roles/rhel-system-roles.metrics/README.md 파일
  • /usr/share/doc/rhel-system-roles/metrics/ 디렉터리

5장. PCP 설정

PCP(Performance Co-915)는 시스템 수준 성능 측정을 모니터링, 시각화, 저장 및 분석하기 위한 도구, 서비스 및 라이브러리 제품군입니다.

5.1. PCP 개요

Python, Perl, C++ 및 C 인터페이스를 사용하여 성능 지표를 추가할 수 있습니다. 분석 툴은 Python, C++, C 클라이언트 API를 직접 사용할 수 있으며 풍부한 웹 애플리케이션은 JSON 인터페이스를 사용하여 사용 가능한 모든 성능 데이터를 탐색할 수 있습니다.

라이브 결과를 아카이브 데이터와 비교하여 데이터 패턴을 분석할 수 있습니다.

PCP의 기능:

  • 경량의 분산 아키텍처는 복잡한 시스템을 분석하는 동안 유용합니다.
  • 실시간 데이터를 모니터링하고 관리할 수 있습니다.
  • 기록 데이터를 로깅 및 검색할 수 있습니다.

PCP에는 다음과 같은 구성 요소가 있습니다.

  • Performance Metric Collector Daemon(pmcd)은 설치된 Performance Metric Domain Agents(pmda)에서 성능 데이터를 수집합니다. PMDA 는 시스템에서 개별적으로 로드되거나 언로드될 수 있으며, 동일한 호스트의 PMCD 에 의해 제어됩니다.
  • pminfo 또는 pmstat 와 같은 다양한 클라이언트 도구는 동일한 호스트 또는 네트워크를 통해 이 데이터를 검색, 표시, 아카이브 및 처리할 수 있습니다.
  • pcp 패키지는 명령줄 도구 및 기본 기능을 제공합니다.
  • pcp-gui 패키지는 그래픽 애플리케이션을 제공합니다. dnf install pcp-gui 명령을 실행하여 pcp-gui 패키지를 설치합니다. 자세한 내용은 PCP 차트 애플리케이션을 사용하여 PCP 로그 아카이브 시각화를 참조하십시오.

5.2. PCP 설치 및 활성화

PCP 사용을 시작하려면 필요한 모든 패키지를 설치하고 PCP 모니터링 서비스를 활성화하십시오.

이 절차에서는 pcp 패키지를 사용하여 PCP를 설치하는 방법을 설명합니다. PCP 설치를 자동화하려면 pcp-zeroconf 패키지를 사용하여 설치합니다. pcp-zeroconf 를 사용하여 PCP를 설치하는 방법에 대한 자세한 내용은 pcp-zeroconf를 사용하여 PCP 설정을 참조하십시오.

절차

  1. pcp 패키지를 설치합니다.

    # dnf install pcp
  2. 호스트 시스템에서 pmcd 서비스를 활성화하고 시작합니다.

    # systemctl enable pmcd
    
    # systemctl start pmcd

검증 단계

  • pmcd 프로세스가 호스트에서 실행 중인지 확인합니다.

    # pcp
    
    Performance Co-Pilot configuration on workstation:
    
    platform: Linux workstation 4.18.0-80.el8.x86_64 #1 SMP Wed Mar 13 12:02:46 UTC 2019 x86_64
    hardware: 12 cpus, 2 disks, 1 node, 36023MB RAM
    timezone: CEST-2
    services: pmcd
    pmcd: Version 4.3.0-1, 8 agents
    pmda: root pmcd proc xfs linux mmv kvm jbd2

추가 리소스

5.3. 최소 PCP 설정 배포

PCP 최소 설치는 Red Hat Enterprise Linux에서 성능 통계를 수집합니다. 설정에는 추가 분석을 위해 데이터를 수집하는 데 필요한 프로덕션 시스템에 최소 패키지 수를 추가해야 합니다.

생성된 tar.gz 파일과 다양한 PCP 툴을 사용하여 pmlogger 출력의 아카이브를 분석하고 다른 성능 정보 소스와 비교할 수 있습니다.

사전 요구 사항

절차

  1. pmlogger 구성을 업데이트합니다.

    # pmlogconf -r /var/lib/pcp/config/pmlogger/config.default
  2. pmcdpmlogger 서비스를 시작합니다.

    # systemctl start pmcd.service
    
    # systemctl start pmlogger.service
  3. 성능 데이터를 기록하는 데 필요한 작업을 실행합니다.
  4. pmcdpmlogger 서비스를 중지합니다.

    # systemctl stop pmcd.service
    
    # systemctl stop pmlogger.service
  5. 출력을 저장하고 호스트 이름과 현재 날짜와 시간을 기반으로 이름이 지정된 tar.gz 파일에 저장합니다.

    # cd /var/log/pcp/pmlogger/
    
    # tar -czf $(hostname).$(date +%F-%Hh%M).pcp.tar.gz $(hostname)

    이 파일을 추출하고 PCP 툴을 사용하여 데이터를 분석합니다.

추가 리소스

5.4. PCP와 함께 배포된 시스템 서비스 및 도구

PCP(Performance Co- Cryostat)에는 성능을 측정하는 데 사용할 수 있는 다양한 시스템 서비스 및 도구가 포함되어 있습니다. 기본 패키지 pcp 에는 시스템 서비스 및 기본 툴이 포함되어 있습니다. 추가 툴은 pcp-system-tools,pcp-guipcp-devel 패키지와 함께 제공됩니다.

PCP와 함께 배포되는 시스템 서비스의 역할

pmcd
PMCD(Performance Metric Collector Daemon)입니다.
pmie
성능 지표 유추 엔진.
pmlogger
성능 지표 로거입니다.
pmproxy
실시간 및 기록 성능 지표 프록시, 시계열 쿼리 및 REST API 서비스.

기본 PCP 패키지로 배포되는 툴

pcp
Performance Co-inspector 설치의 현재 상태를 표시합니다.
pcp-vmstat
5초마다 고급 시스템 성능 개요를 제공합니다. 프로세스, 메모리, 페이징, 블록 IO, 트랩 및 CPU 활동에 대한 정보를 표시합니다.
pmconfig
구성 매개변수 값을 표시합니다.
pmdiff
지정된 시간 창에서 하나 또는 두 아카이브의 모든 메트릭의 평균 값을 비교하여 성능 회귀를 검색할 때 관심이 있을 수 있는 변경 사항을 비교합니다.
pmdumplog
Performance Co-inspector 아카이브 파일의 제어, 메타데이터, 인덱스 및 상태 정보를 표시합니다.
pmfind
네트워크에서 PCP 서비스를 찾습니다.
pmie
정기적으로 산술, 논리 및 규칙 식 집합을 평가하는 유추 엔진입니다. 지표는 라이브 시스템 또는 Performance Co-inspector 아카이브 파일에서 수집됩니다.
pmieconf
구성 가능한 pmie 변수를 표시하거나 설정합니다.
pmiectl
pmie 의 기본이 아닌 인스턴스를 관리합니다.
pminfo
성능 지표에 대한 정보를 표시합니다. 지표는 라이브 시스템 또는 Performance Co-inspector 아카이브 파일에서 수집됩니다.
pmlc
활성 pmlogger 인스턴스를 대화식으로 설정합니다.
pmlogcheck
Performance Co-inspector 아카이브 파일에서 잘못된 데이터를 식별합니다.
pmlogconf
pmlogger 구성 파일을 생성하고 수정합니다.
pmlogctl
pmlogger 의 기본적이지 않은 인스턴스를 관리합니다.
pmloglabel
Performance Co-inspector 아카이브 파일의 레이블을 검증, 수정 또는 복구합니다.
pmlogsummary
Performance Co-inspector 아카이브 파일에 저장된 성능 지표에 대한 통계 정보를 계산합니다.
pmprobe
성능 지표의 가용성을 결정합니다.
pmsocks
방화벽을 통해 Performance Co-inspector 호스트에 액세스할 수 있습니다.
pmstat
정기적으로 시스템 성능에 대한 간략한 요약을 표시합니다.
pmstore
성능 지표 값을 수정합니다.
pmtrace
추적 PMDA에 명령줄 인터페이스를 제공합니다.
pmval
현재 성능 지표 값을 표시합니다.

별도로 설치된 pcp-system-tools 패키지와 함께 배포되는 툴

pcp-atop
CPU, 메모리, 디스크, 네트워크 등 성능 관점에서 가장 중요한 하드웨어 리소스의 시스템 수준 occupation을 보여줍니다.
pcp-atopsar
다양한 시스템 리소스 사용률에 대해 시스템 수준 활동 보고서를 생성합니다. 이 보고서는 pmlogger 또는 pcp-atop-w 옵션을 사용하여 이전에 기록된 원시 로그 파일에서 생성됩니다.
pcp-dmcache
장치 IOP, 캐시 및 메타데이터 장치 사용률과 각 캐시 장치에 대한 읽기 및 쓰기 비율 및 비율과 같은 구성된 장치 매퍼 캐시 대상에 대한 정보를 표시합니다.
pcp-dstat
한 번에 하나의 시스템의 지표를 표시합니다. 여러 시스템의 지표를 표시하려면 --host 옵션을 사용합니다.
pcp-free
시스템에서 사용 가능한 메모리 및 사용된 메모리에 대한 보고서
pcp-htop
에서 실행되는 모든 프로세스를 최상위 명령과 유사한 방식으로 명령줄 인수와 함께 표시하지만 마우스를 사용하여 세로로 스크롤하고 수평으로 이동할 수 있습니다. 또한 트리 형식으로 프로세스를 보고 여러 프로세스를 한 번에 선택 및 실행할 수도 있습니다.
pcp-ipcs
호출 프로세스에서 읽기 액세스 권한이 있는 프로세스 간 통신(IPC) 기능에 대한 정보를 표시합니다.
pcp-mpstat
CPU 및 인터럽트 관련 통계를 보고합니다.
pcp-numastat
커널 메모리 할당기의 NUMA 할당 통계를 표시합니다.
pcp-pidstat
CPU 백분율, 메모리 및 스택 사용량, 스케줄링 및 우선 순위와 같이 시스템에서 실행되는 개별 작업 또는 프로세스에 대한 정보를 표시합니다. 기본적으로 로컬 호스트의 실시간 데이터를 보고합니다.
pcp-shping
pmdashping Performance Metrics Domain Agent(PMDA)에서 내보낸 쉘-핑 서비스 메트릭을 샘플 및 보고합니다.
pcp-ss
pmdasockets PMDA에서 수집한 소켓 통계를 표시합니다.
pcp-tapestat
ExternalIP 장치에 대한 I/O 통계를 보고합니다.
pcp-uptime
는 시스템이 실행 중인 기간, 현재 로그인한 사용자 수 및 시스템 부하 평균 지난 1, 5, 15분을 표시합니다.
pcp-verify
Performance Co- Cryostat 수집기 설치의 다양한 측면을 검사하고 특정 작동 모드에 대해 올바르게 구성되었는지 보고합니다.
pmiostat
SCSI 장치(기본적으로) 또는 장치 매퍼 장치에 대한 I/O 통계를 보고합니다( -x device-mapper 옵션 사용).
pmrep
선택한, 쉽게 사용자 지정 가능, 성능 지표 값에 대한 보고서.

별도로 설치된 pcp-gui 패키지로 배포되는 툴

pmchart
Performance Co-inspector 기능을 통해 사용 가능한 성능 지표 값을 작성하고 있습니다.
pmdumptext
실시간 또는 Performance Co-inspector 아카이브에서 수집한 성능 지표 값을 출력합니다.

별도로 설치된 pcp-devel 패키지와 함께 배포되는 툴

pmclient
PMAPI(Performance Metrics Application Programming Interface)를 사용하여 고급 시스템 성능 지표를 표시합니다.
pmdbg
사용 가능한 Performance Co-inspector debug 제어 플래그 및 해당 값을 표시합니다.
pmerr
사용 가능한 Performance Co-inspector 오류 코드 및 해당 오류 메시지를 표시합니다.

5.5. PCP 배포 아키텍처

PCP(Performance Co-Pilot)는 PCP 배포 규모에 따라 여러 배포 아키텍처를 지원하며 고급 설정을 수행할 수 있는 많은 옵션을 제공합니다.

Red Hat에서 설정한 권장 배포에 따라 사용 가능한 확장 배포 설정 변형, 크기 조정 요인 및 구성 옵션은 다음과 같습니다.

localhost

각 서비스는 모니터링된 시스템에서 로컬로 실행됩니다. 구성을 변경하지 않고 서비스를 시작하면 기본 배포입니다. 이 경우 개별 노드 이상으로 스케일링할 수 없습니다.

기본적으로 Redis에 대한 배포 설정은 독립 실행형 localhost입니다. 그러나 Redis는 필요에 따라 고가용성 및 확장성이 뛰어난 클러스터형 방식으로 작업을 수행할 수 있습니다. 여기서 데이터는 여러 호스트에서 공유됩니다. 또 다른 실행 가능한 옵션은 클라우드에 Redis 클러스터를 배포하거나 클라우드 벤더의 관리형 Redis 클러스터를 사용하는 것입니다.

Decentralized

localhost와 분산 설정의 유일한 차이점은 중앙 집중식 Redis 서비스입니다. 이 모델에서 호스트는 모니터링되는 각 호스트에서 pmlogger 서비스를 실행하고 로컬 pmcd 인스턴스에서 지표를 검색합니다. 그런 다음 로컬 pmproxy 서비스는 성능 지표를 중앙 Redis 인스턴스로 내보냅니다.

그림 5.1. 분산된 로깅

분산된 로깅
중앙 집중식 로깅 - pmloggerarm

모니터링된 호스트의 리소스 사용량이 제한되면 다른 배포 옵션은 중앙 집중식 로깅이라고도 하는 pmlogger arm입니다. 이 설정에서 단일 로거 호스트는 여러 pmlogger 프로세스를 실행하고 각각 다른 원격 pmcd 호스트에서 성능 지표를 검색하도록 구성됩니다. 중앙 집중식 로거 호스트는 결과 PCP 아카이브 로그를 검색하고 지표 데이터를 Redis 인스턴스로 로드하는 pmproxy 서비스를 실행하도록 구성됩니다.

그림 5.2. 중앙 집중식 로깅 - pmloggerarm

중앙 집중식 로깅 - pmloggerarm
페더레이션 - 여러 pmloggerarms

대규모 배포의 경우 Red Hat은 여러 pmlogger 팜을 연합 방식으로 배포하는 것이 좋습니다. 예를 들어 랙 또는 데이터 센터당 하나의 pmlogger arm이 있습니다. 각 pmlogger arm은 중앙 Redis 인스턴스로 메트릭을 로드합니다.

그림 5.3. 페더레이션 - 여러 pmloggerarms

페더레이션 - 여러 pmloggerarms
참고

기본적으로 Redis에 대한 배포 설정은 독립 실행형 localhost입니다. 그러나 Redis는 필요에 따라 고가용성 및 확장성이 뛰어난 클러스터형 방식으로 작업을 수행할 수 있습니다. 여기서 데이터는 여러 호스트에서 공유됩니다. 또 다른 실행 가능한 옵션은 클라우드에 Redis 클러스터를 배포하거나 클라우드 벤더의 관리형 Redis 클러스터를 사용하는 것입니다.

추가 리소스

5.7. 크기 조정 요인

다음은 스케일링에 필요한 크기 조정 요인입니다.

원격 시스템 크기
CPU, 디스크, 네트워크 인터페이스 및 기타 하드웨어 리소스의 수는 중앙 집중식 로깅 호스트의 각 pmlogger 에서 수집한 데이터 양에 영향을 미칩니다.
기록된 메트릭
기록된 지표의 수와 유형이 중요한 역할을 합니다. 특히 프로세스별 proc.* 메트릭에는 표준 pcp- zeroconf 설정, 10s 로깅 간격 10MB, proc 메트릭이 없는 11MB - proc 메트릭이 포함된 약 10배 더 많은 디스크 공간이 필요합니다. 또한 각 메트릭의 인스턴스 수(예: CPU 수, 블록 장치 및 네트워크 인터페이스 수)도 필요한 스토리지 용량에 영향을 미칩니다.
로깅 간격
지표가 기록되는 간격은 스토리지 요구 사항에 영향을 미칩니다. 예상되는 일일 PCP 아카이브 파일 크기는 각 pmlogger 인스턴스의 pmlogger.log 파일에 작성됩니다. 이러한 값은 압축되지 않은 추정치입니다. PCP 아카이브가 매우 잘 압축되므로 약 10:1이 특정 사이트에 대해 실제 장기 디스크 공간 요구 사항을 확인할 수 있습니다.
pmlogrewrite
모든 PCP 업그레이드 후 pmlogrewrite 도구가 실행되고 이전 버전의 지표 메타데이터와 새 버전의 PCP가 변경된 경우 이전 아카이브를 다시 작성합니다. 이 프로세스 기간은 저장된 아카이브 수로 선형으로 확장됩니다.

추가 리소스

  • pmlogrewrite(1)pmlogger(1) 도움말 페이지

5.8. PCP 스케일링을 위한 구성 옵션

다음은 확장에 필요한 구성 옵션입니다.

sysctl 및 rlimit 설정
아카이브 검색이 활성화되면 pmproxy 에는 모니터링 또는 로그 세부 정보인 모든 pm proxy에 대해 서비스 로그 및 pmproxy 클라이언트 소켓의 추가 파일 설명자와 함께 4개의 설명자가 필요합니다. 각 pmlogger 프로세스는 원격 pmcd 소켓, 아카이브 파일, 서비스 로그 등에 약 20개의 파일 설명자를 사용합니다. 약 200 pmlogger 프로세스를 실행하는 시스템의 기본 1024 소프트 제한을 초과할 수 있습니다. pcp-5.3.0 이상의 pmproxy 서비스가 하드 제한으로 자동으로 증가합니다. 이전 버전의 PCP에서는 다수의 pmlogger 프로세스를 배포할 경우 튜닝이 필요하며, pmlogger 의 소프트 또는 하드 제한을 늘려 이를 수행할 수 있습니다. 자세한 내용은 systemd에서 실행하는 서비스의 제한(ulimit)을 설정하는 방법을 참조하십시오.
로컬 아카이브
pmlogger 서비스는 /var/log/pcp/pmlogger/ 디렉터리에 로컬 및 원격 pmcds 의 지표를 저장합니다. 로컬 시스템의 로깅 간격을 제어하려면 /etc/pcp/pmlogger/control.d/configfile 파일을 업데이트하고 인수에 -t X 를 추가합니다. 여기서 X 는 로깅 간격(초)입니다. 로깅해야 하는 메트릭을 구성하려면 pmlogconf /var/lib/pcp/config/pmlogger/config.clienthostname 을 실행합니다. 이 명령은 기본 지표 세트를 사용하여 구성 파일을 배포합니다. 이러한 지표는 선택적으로 추가로 사용자 지정할 수 있습니다. 보존 설정을 지정하려면 이전 PCP 아카이브를 제거하고, /etc/sysconfig/pmlogger_timers 파일을 업데이트하고 PMLOGGER_DAILY_PARAMS="-E -k X", 여기서 X 는 PCP 아카이브를 유지하기 위한 일 수입니다.
Redis

pmproxy 서비스는 로깅된 지표를 pmlogger 에서 Redis 인스턴스로 보냅니다. 다음은 /etc/pcp/pmproxy/pmproxy.conf 설정 파일에 보존 설정을 지정하는 두 가지 옵션입니다.

  • stream.expire 는 오래된 지표를 제거해야 하는 기간, 지정된 시간 내에 업데이트되지 않은 지표를 지정합니다.
  • stream.maxlen 은 호스트당 하나의 메트릭 값의 최대 메트릭 값을 지정합니다. 이 설정은 보존 간격(예: 20160)에서 14일 동안의 보존 및 60s 로깅 간격(60*60*24*14/60)으로 나눈 보존 시간이어야 합니다.

추가 리소스

  • pmproxy(1), pmlogger(1)sysctl(8) 매뉴얼 페이지

5.9. 예: 중앙 집중식 로깅 배포 분석

다음 결과는 기본 pcp-zeroconf 5.3.0 설치로 알려진 중앙 집중식 로깅 설정에서 수집되었으며, 각 원격 호스트는 64 CPU 코어, 376GB RAM 및 1개의 디스크가 있는 서버에서 pmcd 를 실행하는 동일한 컨테이너 인스턴스입니다.

로깅 간격은 10s이며, 원격 노드의 proc 메트릭은 포함되지 않으며 메모리 값은 RSS(Resident Set Size) 값을 나타냅니다.

표 5.2. 10s 로깅 간격에 대한 자세한 사용률 통계

호스트 수1050

PCP Archives 스토리지 일당

91MB

522 MB

pmlogger Memory

160MB

580MB

pmlogger 네트워크 1일당 (In)

2MB

9MB

pmproxy 메모리

1.4GB

6.3GB

Redis Memory per Day

2.6 GB

12GB

표 5.3. 60s 로깅 간격에 대해 모니터링된 호스트에 따라 사용되는 리소스

호스트 수1050100

PCP Archives 스토리지 일당

20 MB

120MB

271MB

pmlogger Memory

104MB

524MB

1049MB

pmlogger 네트워크 1일당 (In)

0.38MB

1.75MB

3.48MB

pmproxy 메모리

2.67GB

5.5GB

9GB

Redis Memory per Day

0.54GB

2.65GB

5.3GB

참고

pmproxy 대기열 Redis는 Redis pipelining 요청을 요청하고 Redis 파이프lining을 사용하여 Redis 쿼리 속도를 높입니다. 이로 인해 메모리 사용량이 증가할 수 있습니다. 이 문제를 해결하려면 높은 메모리 사용량 문제 해결을 참조하십시오.

5.10. 예: 페더레이션 설정 배포 분석

다음 결과는 세 가지 중앙 집중식 로깅 ( pmlogger farm) 설정으로 구성된 여러pmlogger arms로 알려진 페더레이션 설정에서 관찰되었으며, 각 pmlogger farm는 총 300 개의 원격 호스트를 모니터링했습니다.

pmlogger 의 이 설정은 다음에 언급된 구성과 동일합니다.

예: Redis 서버가 클러스터 모드에서 작동 중이라는 점을 제외하고 60s 로깅 간격으로 중앙 집중식 로깅 배포를 분석합니다.

표 5.4. 60s 로깅 간격을 위한 페더레이션 호스트에 따라 사용되는 리소스

PCP Archives 스토리지 일당pmlogger Memory네트워크 1일당 (In/Out)pmproxy 메모리Redis Memory per Day

277 MB

1058MB

15.6 MB / 12.3 MB

6-8GB

5.5GB

여기서는 모든 값은 호스트당입니다. Redis 클러스터의 노드 간 통신으로 인해 네트워크 대역폭이 더 높습니다.

5.11. 보안 PCP 연결 설정

보안 PCP 프로토콜 교환에 참여하도록 PCP 수집기 및 모니터링 구성 요소를 구성할 수 있습니다.

5.11.1. 보안 PCP 연결

PCP(Performance Co-Pilot) 수집기와 모니터링 구성 요소 간에 보안 연결을 설정할 수 있습니다. PCP 수집기 구성 요소는 다른 소스에서 성능 데이터를 수집하고 추출하는 PCP의 일부입니다. PCP 모니터 구성 요소는 PCP 수집기 구성 요소가 설치된 호스트 또는 아카이브에서 수집된 데이터를 표시하는 PCP의 일부입니다. 이러한 구성 요소 간 보안 연결을 설정하면 인증되지 않은 당사자가 수집 및 모니터링되는 데이터에 액세스하거나 수정하는 것을 방지할 수 있습니다.

성능 지표 수집기 데몬(pmcd)과의 모든 연결은 TCP/IP 기반 PCP 프로토콜을 사용하여 수행됩니다. 프로토콜 프록시 및 PCP REST API는 pmproxy 데몬에서 제공합니다. REST API는 HTTPS를 통해 액세스할 수 있으므로 보안 연결을 보장할 수 있습니다.

pmcdpmproxy 데몬은 단일 포트에서 TLS 및 비 TLS 통신을 동시에 수행할 수 있습니다. pmcd 의 기본 포트는 pmproxy 의 경우 44321 및 44322입니다. 즉, PCP 수집기 시스템의 TLS 또는 비 TLS 통신 중에서 선택할 필요가 없으며 둘 다 동시에 사용할 수 있습니다.

5.11.2. PCP 수집기 구성 요소에 대한 보안 연결 구성

모든 PCP 수집기 시스템에는 보안 PCP 프로토콜 교환에 참여하려면 유효한 인증서가 있어야 합니다.

참고

pmproxy 데몬은 TLS 관점에서 클라이언트와 서버로 작동합니다.

사전 요구 사항

  • PCP가 설치되어 있습니다. 자세한 내용은 PCP 설치 및 활성화를 참조하십시오.
  • 개인 클라이언트 키는 /etc/pcp/tls/client.key 파일에 저장됩니다. 다른 경로를 사용하는 경우 절차의 해당 단계를 조정합니다.

    개인 키 및 CSR(인증서 서명 요청) 생성 및 CA(인증 기관)에서 인증서를 요청하는 방법에 대한 자세한 내용은 CA 문서를 참조하십시오.

  • TLS 클라이언트 인증서는 /etc/pcp/tls/client.crt 파일에 저장됩니다. 다른 경로를 사용하는 경우 절차의 해당 단계를 조정합니다.
  • CA 인증서는 /etc/pcp/tls/ca.crt 파일에 저장됩니다. 다른 경로를 사용하는 경우 절차의 해당 단계를 조정합니다. 또한 pmproxy 데몬의 경우 다음을 수행합니다.
  • 개인 서버 키는 /etc/pcp/tls/server.key 파일에 저장됩니다. 다른 경로를 사용하는 경우 프로세스의 해당 단계를 조정합니다.
  • TLS 서버 인증서는 /etc/pcp/tls/server.crt 파일에 저장됩니다. 다른 경로를 사용하는 경우 절차의 해당 단계를 조정합니다.

절차

  1. CA 발행 인증서를 사용하여 보안 연결을 설정하도록 수집기 시스템에서 PCP TLS 구성 파일을 업데이트합니다.

    # cat > /etc/pcp/tls.conf << END
    tls-ca-cert-file = /etc/pcp/tls/ca.crt
    tls-key-file = /etc/pcp/tls/server.key
    tls-cert-file = /etc/pcp/tls/server.crt
    tls-client-key-file = /etc/pcp/tls/client.key
    tls-client-cert-file = /etc/pcp/tls/client.crt
    END
  2. PCP 수집기 인프라를 다시 시작합니다.

    # systemctl restart pmcd.service
    # systemctl restart pmproxy.service

검증

  • TLS 구성을 확인합니다.

    • pmcd 서비스에서 다음을 수행합니다.

      # grep 'Info:' /var/log/pcp/pmcd/pmcd.log
      [Tue Feb 07 11:47:33] pmcd(6558) Info: OpenSSL 3.0.7 setup
    • pmproxy 서비스에서 다음을 수행합니다.

      # grep 'Info:' /var/log/pcp/pmproxy/pmproxy.log
      [Tue Feb 07 11:44:13] pmproxy(6014) Info: OpenSSL 3.0.7 setup

5.11.3. PCP 모니터링 구성 요소에 대한 보안 연결 구성

보안 PCP 프로토콜 교환에 참여하도록 PCP 모니터링 구성 요소를 구성합니다.

사전 요구 사항

  • PCP가 설치되어 있습니다. 자세한 내용은 PCP 설치 및 활성화를 참조하십시오.
  • 개인 클라이언트 키는 ~/.pcp/tls/client.key 파일에 저장됩니다. 다른 경로를 사용하는 경우 절차의 해당 단계를 조정합니다.

    개인 키 및 CSR(인증서 서명 요청) 생성 및 CA(인증 기관)에서 인증서를 요청하는 방법에 대한 자세한 내용은 CA 문서를 참조하십시오.

  • TLS 클라이언트 인증서는 ~/.pcp/tls/client.crt 파일에 저장됩니다. 다른 경로를 사용하는 경우 절차의 해당 단계를 조정합니다.
  • CA 인증서는 /etc/pcp/tls/ca.crt 파일에 저장됩니다. 다른 경로를 사용하는 경우 절차의 해당 단계를 조정합니다.

절차

  1. 다음 정보를 사용하여 TLS 구성 파일을 생성합니다.

    $ home=echo ~
    $ cat > ~/.pcp/tls.conf << END
    tls-ca-cert-file = /etc/pcp/tls/ca.crt
    tls-key-file = $home/.pcp/tls/client.key
    tls-cert-file = $home/.pcp/tls/client.crt
    END
  2. 보안 연결을 설정합니다.

    $ export PCP_SECURE_SOCKETS=enforce
    $ export PCP_TLSCONF_PATH=~/.pcp/tls.conf

검증

  • 보안 연결이 구성되었는지 확인합니다.

    $ pminfo --fetch --host pcps://localhost kernel.all.load
    
    kernel.all.load
        inst [1 or "1 minute"] value 1.26
        inst [5 or "5 minute"] value 1.29
        inst [15 or "15 minute"] value 1.28

5.12. 높은 메모리 사용량 문제 해결

다음 시나리오에서는 메모리 사용량이 증가할 수 있습니다.

  • pmproxy 프로세스는 새 PCP 아카이브를 처리하는 데 사용 중이며 Redis 요청 및 응답을 처리하는 데 필요한 CPU 사이클은 없습니다.
  • Redis 노드 또는 클러스터가 과부하되어 제 시간에 들어오는 요청을 처리할 수 없습니다.

pmproxy 서비스 데몬은 Redis 스트림을 사용하며 PCP 튜닝 매개변수인 구성 매개 변수를 지원하며 Redis 메모리 사용량 및 키 보존에 영향을 미칩니다. /etc/pcp/pmproxy/pmproxy.conf 파일에는 pmproxy 및 관련 API에 사용 가능한 설정 옵션이 나열됩니다.

다음 절차에서는 높은 메모리 사용 문제를 해결하는 방법을 설명합니다.

사전 요구 사항

  1. pcp-pmda-redis 패키지를 설치합니다.

    # dnf install pcp-pmda-redis
  2. redis PMDA를 설치합니다.

    # cd /var/lib/pcp/pmdas/redis && ./Install

절차

  • 메모리 사용량의 문제를 해결하려면 다음 명령을 실행하고 inflight 열을 관찰합니다.

    $ pmrep :pmproxy
             backlog  inflight  reqs/s  resp/s   wait req err  resp err  changed  throttled
              byte     count   count/s  count/s  s/s  count/s   count/s  count/s   count/s
    14:59:08   0         0       N/A       N/A   N/A    N/A      N/A      N/A        N/A
    14:59:09   0         0    2268.9    2268.9    28     0        0       2.0        4.0
    14:59:10   0         0       0.0       0.0     0     0        0       0.0        0.0
    14:59:11   0         0       0.0       0.0     0     0        0       0.0        0.0

    이 열에는 진행 중인 Redis 요청 수가 표시됩니다. 즉, 대기하거나 전송되며 지금까지 응답이 수신되지 않았습니다.

    숫자가 높으면 다음 조건 중 하나를 나타냅니다.

    • pmproxy 프로세스는 새 PCP 아카이브를 처리하는 데 사용 중이며 Redis 요청 및 응답을 처리하는 데 필요한 CPU 사이클은 없습니다.
    • Redis 노드 또는 클러스터가 과부하되어 제 시간에 들어오는 요청을 처리할 수 없습니다.
  • 메모리 사용량이 많은 문제를 해결하려면 이 팜의 pmlogger 프로세스 수를 줄이고 다른 pmloggerarm을 추가합니다. 페더레이션 - 여러 pmloggerarms 설정을 사용합니다.

    Redis 노드가 장기간에 100% CPU를 사용하는 경우 더 나은 성능을 갖춘 호스트로 이동하거나 클러스터형 Redis 설정을 대신 사용하십시오.

  • pmproxy.redis.* 메트릭을 보려면 다음 명령을 사용합니다.

    $ pminfo -ftd pmproxy.redis
    pmproxy.redis.responses.wait [wait time for responses]
        Data Type: 64-bit unsigned int  InDom: PM_INDOM_NULL 0xffffffff
        Semantics: counter  Units: microsec
        value 546028367374
    pmproxy.redis.responses.error [number of error responses]
        Data Type: 64-bit unsigned int  InDom: PM_INDOM_NULL 0xffffffff
        Semantics: counter  Units: count
        value 1164
    [...]
    pmproxy.redis.requests.inflight.bytes [bytes allocated for inflight requests]
        Data Type: 64-bit int  InDom: PM_INDOM_NULL 0xffffffff
        Semantics: discrete  Units: byte
        value 0
    
    pmproxy.redis.requests.inflight.total [inflight requests]
        Data Type: 64-bit unsigned int  InDom: PM_INDOM_NULL 0xffffffff
        Semantics: discrete  Units: count
        value 0
    [...]

    진행 중인 Redis 요청 수를 보려면 pmproxy.redis.requests.inflight.total 지표 및 pmproxy.redis.requests.inflight.bytes 지표를 참조하여 현재의 모든 inflight Redis 요청에 의해 사용되는 바이트 수를 확인합니다.

    일반적으로 redis 요청 대기열은 0이지만 대규모 pmloggerarms를 사용하여 빌드할 수 있으므로 확장성은 제한되고 pmproxy 클라이언트에 대한 높은 대기 시간이 발생할 수 있습니다.

  • pminfo 명령을 사용하여 성능 지표에 대한 정보를 확인합니다. 예를 들어 redis.* 메트릭을 보려면 다음 명령을 사용합니다.

    $ pminfo -ftd redis
    redis.redis_build_id [Build ID]
        Data Type: string  InDom: 24.0 0x6000000
        Semantics: discrete  Units: count
        inst [0 or "localhost:6379"] value "87e335e57cffa755"
    redis.total_commands_processed [Total number of commands processed by the server]
        Data Type: 64-bit unsigned int  InDom: 24.0 0x6000000
        Semantics: counter  Units: count
        inst [0 or "localhost:6379"] value 595627069
    [...]
    
    redis.used_memory_peak [Peak memory consumed by Redis (in bytes)]
        Data Type: 32-bit unsigned int  InDom: 24.0 0x6000000
        Semantics: instant  Units: count
        inst [0 or "localhost:6379"] value 572234920
    [...]

    최대 메모리 사용량을 보려면 redis.used_memory_peak 지표를 참조하십시오.

추가 리소스

6장. pmlogger로 성능 데이터 로깅

PCP 도구를 사용하면 성능 지표 값을 기록하고 나중에 다시 재생할 수 있습니다. 이를 통해 소급 성능 분석을 수행할 수 있습니다.

pmlogger 도구를 사용하면 다음을 수행할 수 있습니다.

  • 시스템에서 선택한 메트릭의 보관된 로그 생성
  • 시스템에 기록된 메트릭과 얼마나 자주 기록되는지 지정합니다.

6.1. pmlogconf로 pmlogger 구성 파일 수정

pmlogger 서비스가 실행 중이면 PCP는 호스트에 기본 지표 세트를 기록합니다.

pmlogconf 유틸리티를 사용하여 기본 구성을 확인합니다. pmlogger 구성 파일이 없으면 pmlogconf 에서 기본 지표 값으로 생성합니다.

사전 요구 사항

절차

  1. pmlogger 구성 파일을 생성하거나 수정합니다.

    # pmlogconf -r /var/lib/pcp/config/pmlogger/config.default
  2. pmlogconf 프롬프트에 따라 관련 성능 지표 그룹을 활성화하거나 비활성화하고 활성화된 각 그룹의 로깅 간격을 제어합니다.

추가 리소스

6.2. pmlogger 구성 파일을 수동으로 편집

특정 지표 및 지정된 간격을 사용하여 맞춤형 로깅 구성을 생성하려면 pmlogger 구성 파일을 수동으로 편집합니다. 기본 pmlogger 설정 파일은 /var/lib/pcp/config/pmlogger/config.default 입니다. 구성 파일은 기본 로깅 인스턴스에서 로깅되는 메트릭을 지정합니다.

수동 구성에서 다음을 수행할 수 있습니다.

  • 자동 구성에 나열되지 않은 지표를 기록합니다.
  • 사용자 정의 로깅 빈도를 선택합니다.
  • 애플리케이션 메트릭으로 PMDA 를 추가합니다.

사전 요구 사항

절차

  • /var/lib/pcp/config/pmlogger/config.default 파일을 열고 편집하여 특정 메트릭을 추가합니다.

    # It is safe to make additions from here on ...
    #
    
    log mandatory on every 5 seconds {
        xfs.write
        xfs.write_bytes
        xfs.read
        xfs.read_bytes
    }
    
    log mandatory on every 10 seconds {
        xfs.allocs
        xfs.block_map
        xfs.transactions
        xfs.log
    
    }
    
    [access]
    disallow * : all;
    allow localhost : enquire;

추가 리소스

6.3. pmlogger 서비스 활성화

pmlogger 서비스를 시작하고 로컬 시스템에서 지표 값을 로깅하도록 활성화해야 합니다.

다음 절차에서는 pmlogger 서비스를 활성화하는 방법을 설명합니다.

사전 요구 사항

절차

  • pmlogger 서비스를 시작하고 활성화합니다.

    # systemctl start pmlogger
    
    # systemctl enable pmlogger

검증 단계

  • pmlogger 서비스가 활성화되어 있는지 확인합니다.

    # pcp
    
    Performance Co-Pilot configuration on workstation:
    
    platform: Linux workstation 4.18.0-80.el8.x86_64 #1 SMP Wed Mar 13 12:02:46 UTC 2019 x86_64
    hardware: 12 cpus, 2 disks, 1 node, 36023MB RAM
    timezone: CEST-2
    services: pmcd
    pmcd: Version 4.3.0-1, 8 agents, 1 client
    pmda: root pmcd proc xfs linux mmv kvm jbd2
    pmlogger: primary logger: /var/log/pcp/pmlogger/workstation/20190827.15.54

추가 리소스

6.4. 메트릭 컬렉션에 대한 클라이언트 시스템 설정

이 절차에서는 중앙 서버가 PCP를 실행하는 클라이언트에서 메트릭을 수집할 수 있도록 클라이언트 시스템을 설정하는 방법을 설명합니다.

사전 요구 사항

절차

  1. pcp-system-tools 패키지를 설치합니다.

    # dnf install pcp-system-tools
  2. pmcd 의 IP 주소를 구성합니다.

    # echo "-i 192.168.4.62" >>/etc/pcp/pmcd/pmcd.options

    192.168.4.62 를 IP 주소로 교체하면 클라이언트가 수신 대기해야 합니다.

    기본적으로 pmcd 는 localhost에서 수신 대기 중입니다.

  3. 공용 영역을 영구적으로 추가하도록 방화벽을 구성합니다.

    # firewall-cmd --permanent --zone=public --add-port=44321/tcp
    success
    
    # firewall-cmd --reload
    success
  4. SELinux 부울을 설정합니다.

    # setsebool -P pcp_bind_all_unreserved_ports on
  5. pmcdpmlogger 서비스를 활성화합니다.

    # systemctl enable pmcd pmlogger
    # systemctl restart pmcd pmlogger

검증 단계

  • pmcd 가 구성된 IP 주소에서 올바르게 수신 대기 중인지 확인합니다.

    # ss -tlp | grep 44321
    LISTEN   0   5     127.0.0.1:44321   0.0.0.0:*   users:(("pmcd",pid=151595,fd=6))
    LISTEN   0   5  192.168.4.62:44321   0.0.0.0:*   users:(("pmcd",pid=151595,fd=0))
    LISTEN   0   5         [::1]:44321      [::]:*   users:(("pmcd",pid=151595,fd=7))

추가 리소스

6.5. 데이터 수집을 위해 중앙 서버 설정

이 절차에서는 PCP를 실행하는 클라이언트에서 지표를 수집하는 중앙 서버를 생성하는 방법을 설명합니다.

사전 요구 사항

절차

  1. pcp-system-tools 패키지를 설치합니다.

    # dnf install pcp-system-tools
  2. 다음 콘텐츠를 사용하여 /etc/pcp/pmlogger/control.d/remote 파일을 생성하십시오.

    # DO NOT REMOVE OR EDIT THE FOLLOWING LINE
    $version=1.1
    
    192.168.4.13 n n PCP_ARCHIVE_DIR/rhel7u4a -r -T24h10m -c config.rhel7u4a
    192.168.4.14 n n PCP_ARCHIVE_DIR/rhel6u10a -r -T24h10m -c config.rhel6u10a
    192.168.4.62 n n PCP_ARCHIVE_DIR/rhel8u1a -r -T24h10m -c config.rhel8u1a
    192.168.4.69 n n PCP_ARCHIVE_DIR/rhel9u3a -r -T24h10m -c config.rhel9u3a

    192.168.4.13,192.168.4.14,192.168.4.62192.168.4.69 를 클라이언트 IP 주소로 교체합니다.

  3. pmcdpmlogger 서비스를 활성화합니다.

    # systemctl enable pmcd pmlogger
    # systemctl restart pmcd pmlogger

검증 단계

  • 각 디렉터리에서 최신 아카이브 파일에 액세스할 수 있는지 확인합니다.

    # for i in /var/log/pcp/pmlogger/rhel*/*.0; do pmdumplog -L $i; done
    Log Label (Log Format Version 2)
    Performance metrics from host rhel6u10a.local
      commencing Mon Nov 25 21:55:04.851 2019
      ending     Mon Nov 25 22:06:04.874 2019
    Archive timezone: JST-9
    PID for pmlogger: 24002
    Log Label (Log Format Version 2)
    Performance metrics from host rhel7u4a
      commencing Tue Nov 26 06:49:24.954 2019
      ending     Tue Nov 26 07:06:24.979 2019
    Archive timezone: CET-1
    PID for pmlogger: 10941
    [..]

    추가 분석 및 그래프 작성에 /var/log/pcp/pmlogger/ 디렉토리의 아카이브 파일을 사용할 수 있습니다.

추가 리소스

6.6. pmrep로 PCP 로그 아카이브 재생

지표 데이터를 기록한 후 PCP 로그 아카이브를 재생할 수 있습니다. 로그를 텍스트 파일로 내보내고 서드 시트로 가져오려면 pcp2csv,pcp2xml,pmrep 또는 pmlogsummary 와 같은 PCP 유틸리티를 사용하십시오.

pmrep 툴을 사용하면 다음을 수행할 수 있습니다.

  • 로그 파일 보기
  • 선택한 PCP 로그 아카이브를 구문 분석하고 값을 ASCII 테이블로 내보냅니다.
  • 명령줄에 개별 지표를 지정하여 전체 아카이브 로그를 추출하거나 로그에서 지표 값만 선택합니다.

사전 요구 사항

  • PCP가 설치되어 있습니다. 자세한 내용은 PCP 설치 및 활성화를 참조하십시오.
  • pmlogger 서비스가 활성화되어 있습니다. 자세한 내용은 pmlogger 서비스 활성화를 참조하십시오.
  • pcp-system-tools 패키지를 설치합니다.

    # dnf install pcp-gui

절차

  • 메트릭에 데이터를 표시합니다.

    $ pmrep --start @3:00am --archive 20211128 --interval 5seconds --samples 10 --output csv disk.dev.write
    Time,"disk.dev.write-sda","disk.dev.write-sdb"
    2021-11-28 03:00:00,,
    2021-11-28 03:00:05,4.000,5.200
    2021-11-28 03:00:10,1.600,7.600
    2021-11-28 03:00:15,0.800,7.100
    2021-11-28 03:00:20,16.600,8.400
    2021-11-28 03:00:25,21.400,7.200
    2021-11-28 03:00:30,21.200,6.800
    2021-11-28 03:00:35,21.000,27.600
    2021-11-28 03:00:40,12.400,33.800
    2021-11-28 03:00:45,9.800,20.600

    언급된 예에서는 아카이브에 수집된 disk.dev.write 지표의 데이터를 쉼표로 구분된 값 형식으로 5초 간격으로 표시합니다.

    참고

    이 예제의 20211128 을 데이터 표시하려는 pmlogger 아카이브가 포함된 파일 이름으로 교체합니다.

추가 리소스

6.7. PCP 버전 3 아카이브 활성화

PCP(Performance Co-Pilot) 아카이브는 단일 호스트에서 기록된 PCP 지표의 과거 값을 저장하고 성능 분석 기능을 지원합니다. PCP 아카이브에는 오프라인 또는 오프사이트 분석에 필요한 모든 중요한 지표 데이터 및 메타데이터가 포함되어 있습니다. 이러한 아카이브는 대부분의 PCP 클라이언트 툴에서 읽거나 pmdumplog 툴에서 원시로 덤프할 수 있습니다.

PCP 6.0에서 버전 3 아카이브는 버전 2 아카이브 외에 지원됩니다. 버전 2 아카이브는 기본값으로 유지되며 RHEL 9.2에서 장기적인 지원을 받는 버전 3 아카이브 외에도 이전 버전과의 호환성을 위한 장기적인 지원을 계속 받습니다.

PCP 버전 3 아카이브를 사용하면 버전 2에 비해 다음과 같은 이점이 있습니다.

  • 인스턴스 도메인 change-deltas 지원
  • Y2038 안전 타임스탬프
  • 나노초-지정 타임스탬프
  • 임의의 시간대 지원
  • 2GB보다 큰 개별 볼륨에 사용되는 64비트 파일 오프셋

사전 요구 사항

절차

  1. 선택한 텍스트 편집기에서 /etc/pcp.conf 파일을 열고 PCP 아카이브 버전을 설정합니다.

    PCP_ARCHIVE_VERSION=3
  2. pmlogger 서비스를 다시 시작하여 구성 변경 사항을 적용합니다.

    # systemctl restart pmlogger.service
  3. 새 구성을 사용하여 새 PCP 아카이브 로그를 만듭니다. 자세한 내용은 pmlogger를 사용하여 성능 데이터 로깅 을 참조하십시오.

검증

  • 새 구성으로 생성된 아카이브의 버전을 확인합니다.

    # pmloglabel -l /var/log/pcp/pmlogger/20230208
    Log Label (Log Format Version 3)
    Performance metrics from host host1
            commencing Wed Feb   08 00:11:09.396 2023
            ending           Thu  Feb   07 00:13:54.347 2023

추가 리소스

7장. Performance Co-inspector를 사용하여 성능 모니터링

PCP(Performance Co-915)는 시스템 수준 성능 측정을 모니터링, 시각화, 저장 및 분석하기 위한 도구, 서비스 및 라이브러리 제품군입니다.

시스템 관리자는 Red Hat Enterprise Linux 9에서 PCP 애플리케이션을 사용하여 시스템의 성능을 모니터링할 수 있습니다.

7.1. pmda-journald로 postfix 모니터링

이 절차에서는 pmda- journald로 postfix 메일 서버의 성능 지표를 모니터링하는 방법에 대해 설명합니다. 초당 받은 이메일 수를 확인하는 데 도움이 됩니다.

사전 요구 사항

절차

  1. 다음 패키지를 설치합니다.

    1. pcp-system-tools 를 설치합니다.

      # dnf install pcp-system-tools
    2. pmda-cnv 패키지를 설치하여 postfix 를 모니터링합니다.

      # dnf install pcp-pmda-postfix postfix
    3. 로깅 데몬을 설치합니다.

      # dnf install rsyslog
    4. 테스트를 위해 메일 클라이언트를 설치합니다.

      # dnf install mutt
  2. postfixrsyslog 서비스를 활성화합니다.

    # systemctl enable postfix rsyslog
    # systemctl restart postfix rsyslog
  3. pmda-journald가 필요한 로그 파일에 액세스할 수 있도록 SELinux 부울을 활성화합니다.

    # setsebool -P pcp_read_generic_logs=on
  4. PMDA 를 설치합니다.

    # cd /var/lib/pcp/pmdas/postfix/
    
    # ./Install
    
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Waiting for pmcd to terminate ...
    Starting pmcd ...
    Check postfix metrics have appeared ... 7 metrics and 58 values

검증 단계

  • pmda-octets 작업을 확인합니다.

    echo testmail | mutt root
  • 사용 가능한 지표를 확인합니다.

    # pminfo postfix
    
    postfix.received
    postfix.sent
    postfix.queues.incoming
    postfix.queues.maildrop
    postfix.queues.hold
    postfix.queues.deferred
    postfix.queues.active

추가 리소스

7.2. PCP 차트 애플리케이션을 사용하여 PCP 로그 아카이브를 시각적으로 추적

지표 데이터를 기록한 후 PCP 로그 아카이브를 그래프로 재생할 수 있습니다. 메트릭은 PCP 로그 아카이브의 지표 데이터를 기록 데이터의 소스로 사용하기 위한 대체 옵션으로 하나 이상의 라이브 호스트에서 가져옵니다. 성능 지표의 데이터를 표시하도록 PCP 차트 애플리케이션 인터페이스를 사용자 지정하려면 행 플롯, 막대 그래프 또는 사용률 그래프를 사용할 수 있습니다.

PCP 차트 애플리케이션을 사용하면 다음을 수행할 수 있습니다.

  • PCP 차트 애플리케이션 애플리케이션에서 데이터를 리플레이하고 그래프를 사용하여 시스템의 실시간 데이터와 함께 소급 데이터를 시각화합니다.
  • 성능 지표 값을 그래프로 플롯합니다.
  • 여러 개의 차트를 동시에 표시합니다.

사전 요구 사항

절차

  1. 명령 줄에서 PCP 차트 애플리케이션을 시작합니다.

    # pmchart

    그림 7.1. PCP 차트 애플리케이션

    pmchart가 시작됨

    pmtime 서버 설정은 아래에 있습니다. 시작일시 중지 버튼을 사용하면 다음을 제어할 수 있습니다.

    • PCP가 메트릭 데이터를 폴링하는 간격
    • 기록 데이터 지표의 날짜 및 시간
  2. File (파일)을 클릭한 다음 New Chart (새 차트)를 클릭하여 호스트 이름 또는 주소를 지정하여 로컬 시스템과 원격 머신 모두에서 메트릭을 선택합니다. 고급 구성 옵션에는 차트의 축 값을 수동으로 설정하고 플롯의 색상을 수동으로 선택할 수 있는 기능이 포함되어 있습니다.
  3. PCP 차트 애플리케이션에 생성된 보기를 기록합니다.

    다음은 이미지를 사용하거나 PCP 차트 애플리케이션에 생성된 보기를 기록하는 옵션입니다.

    • 파일을 클릭한 다음 내보내기 를 클릭하여 현재 뷰의 이미지를 저장합니다.
    • 레코드 를 클릭한 다음 녹화를 시작하여 레코딩을 시작합니다. 레코드 를 클릭한 다음 중지 하여 레코딩을 중지합니다. 레코딩을 중지하면 기록된 지표가 나중에 볼 수 있도록 보관됩니다.
  4. 선택 사항: PCP 차트 애플리케이션에서 보기 라고 하는 기본 구성 파일을 사용하면 하나 이상의 차트와 연결된 메타데이터를 저장할 수 있습니다. 이 메타데이터는 사용된 메트릭과 차트 열을 포함하여 모든 차트 측면을 설명합니다. File (파일)을 클릭한 다음 Save View ( 보기 저장)를 클릭하여 사용자 지정 보기 구성을 저장하고 나중에 보기 구성을 로드합니다.

    PCP 차트 애플리케이션 보기 구성 파일의 다음 예제에서는 지정된 XFS 파일 시스템 loop1 에 읽고 쓰는 총 바이트 수를 보여주는 스택 차트 그래프를 설명합니다.

    #kmchart
    version 1
    
    chart title "Filesystem Throughput /loop1" style stacking antialiasing off
        plot legend "Read rate"   metric xfs.read_bytes   instance  "loop1"
        plot legend "Write rate"  metric xfs.write_bytes  instance  "loop1"

추가 리소스

7.3. PCP를 사용하여 SQL 서버에서 데이터 수집

SQL Server 에이전트는 데이터베이스 성능 문제를 모니터링하고 분석하는 데 도움이 되는 PCP(Performance Co-inspector)에서 사용할 수 있습니다.

이 절차에서는 시스템의 pcp 를 통해 Microsoft SQL Server에 대한 데이터를 수집하는 방법을 설명합니다.

사전 요구 사항

  • Microsoft SQL Server for Red Hat Enterprise Linux를 설치하고 SQL 서버에 대한 '신뢰' 연결을 설정했습니다.
  • SQL Server for Red Hat Enterprise Linux용 Microsoft QoS 드라이버를 설치했습니다.

절차

  1. PCP를 설치합니다.

    # dnf install pcp-zeroconf
  2. pyodbc 드라이버에 필요한 패키지를 설치합니다.

    # dnf install python3-pyodbc
  3. mssql 에이전트를 설치합니다.

    1. PCP용 Microsoft SQL Server 도메인 에이전트를 설치합니다.

      # dnf install pcp-pmda-mssql
    2. /etc/pcp/mssql/mssql.conf 파일을 편집하여 mssql 에이전트에 대한 SQL 서버 계정의 사용자 이름과 암호를 구성합니다. 구성하는 계정에 성능 데이터에 대한 액세스 권한이 있는지 확인합니다.

      username: user_name
      password: user_password

      user_name 을 SQL Server 계정으로, user_password 를 이 계정의 SQL Server 사용자 암호로 바꿉니다.

  4. 에이전트를 설치합니다.

    # cd /var/lib/pcp/pmdas/mssql
    # ./Install
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Check mssql metrics have appeared ... 168 metrics and 598 values
    [...]

검증 단계

  • pcp 명령을 사용하여 SQL Server PMDA(mssql)가 로드되고 실행되고 있는지 확인합니다.

    $ pcp
    Performance Co-Pilot configuration on rhel.local:
    
    platform: Linux rhel.local 4.18.0-167.el8.x86_64 #1 SMP Sun Dec 15 01:24:23 UTC 2019 x86_64
     hardware: 2 cpus, 1 disk, 1 node, 2770MB RAM
     timezone: PDT+7
     services: pmcd pmproxy
         pmcd: Version 5.0.2-1, 12 agents, 4 clients
         pmda: root pmcd proc pmproxy xfs linux nfsclient mmv kvm mssql
               jbd2 dm
     pmlogger: primary logger: /var/log/pcp/pmlogger/rhel.local/20200326.16.31
         pmie: primary engine: /var/log/pcp/pmie/rhel.local/pmie.log
  • PCP가 SQL Server에서 수집할 수 있는 전체 메트릭 목록을 확인합니다.

    # pminfo mssql
  • 지표 목록을 확인한 후 트랜잭션 비율을 보고할 수 있습니다. 예를 들어 초당 전체 트랜잭션 수를 보고하려면 5초의 기간 동안 다음을 수행합니다.

    # pmval -t 1 -T 5 mssql.databases.transactions
  • pmchart 명령을 사용하여 시스템에서 이러한 지표의 그래픽 차트를 확인합니다. 자세한 내용은 PCP 차트 애플리케이션을 사용하여 PCP 로그 아카이브 시각화를 참조하십시오.

추가 리소스

7.4. wec 아카이브에서 PCP 아카이브 생성

NetNamespace 패키지에서 제공하는 슬픈f 도구를 사용하여 네이티브 슬라이 아카이브에서 PCP 아카이브를 생성할 수 있습니다.

사전 요구 사항

  • 슬픈 아카이브가 생성되었습니다.

    # /usr/lib64/sa/sadc 1 5 -

    이 예에서 슬픈 은 5초 간격으로 시스템 데이터를 샘플링합니다. outfile은 - 로 지정되며, 이로 인해 슬픈 이 매일 데이터 파일에 데이터를 표준 시스템 활동에 씁니다. 이 파일의 이름은 saDD이며 기본적으로 /var/log/sa 디렉터리에 있습니다.

절차

  • 슬퍼크 아카이브에서 PCP 아카이브를 생성합니다.

    # sadf -l -O pcparchive=/tmp/recording -2

    이 예에서 -2 옵션을 사용하면 슬픈f 가 2일 전에 기록된 슬픈 아카이브에서 PCP 아카이브를 생성합니다.

검증 단계

PCP 명령을 사용하면 네이티브 PCP 아카이브와 마찬가지로 슬픈 아카이브에서 생성된 PCP 아카이브를 검사하고 분석할 수 있습니다. 예를 들어 다음과 같습니다.

  • 슬픈 아카이브 아카이브에서 생성된 PCP 아카이브에 메트릭 목록을 표시하려면 다음을 실행합니다.

    $ pminfo --archive /tmp/recording
    Disk.dev.avactive
    Disk.dev.read
    Disk.dev.write
    Disk.dev.blkread
    [...]
  • PCP 아카이브의 아카이브 및 호스트 이름의 시간 공간을 표시하려면 다음을 실행합니다.

    $ pmdumplog --label /tmp/recording
    Log Label (Log Format Version 2)
    Performance metrics from host shard
            commencing Tue Jul 20 00:10:30.642477 2021
            ending     Wed Jul 21 00:10:30.222176 2021
  • 성능 지표 값을 그래프로 분석하려면 다음을 실행합니다.

    $ pmchart --archive /tmp/recording

8장. PCP를 사용한 XFS의 성능 분석

XFS PMDA는 pcp 패키지의 일부로 제공되며 설치 중에 기본적으로 활성화됩니다. PCP(Performance Co-databind)에서 XFS 파일 시스템의 성능 지표 데이터를 수집하는 데 사용됩니다.

PCP를 사용하여 XFS 파일 시스템의 성능을 분석할 수 있습니다.

8.1. XFS PMDA를 수동으로 설치

XFS PMDA가 pcp 구성 출력에 나열되지 않은 경우 PMDA 에이전트를 수동으로 설치합니다.

이 절차에서는 PMDA 에이전트를 수동으로 설치하는 방법을 설명합니다.

사전 요구 사항

절차

  1. xfs 디렉터리로 이동합니다.

    # cd /var/lib/pcp/pmdas/xfs/
  2. XFS PMDA를 수동으로 설치합니다.

    xfs]# ./Install
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Check xfs metrics have appeared ... 387 metrics and 387 values

검증 단계

  • pmcd 프로세스가 호스트에서 실행 중이고 XFS PMDA가 구성에 활성화된 것으로 나열되는지 확인합니다.

    # pcp
    
    Performance Co-Pilot configuration on workstation:
    
    platform: Linux workstation 4.18.0-80.el8.x86_64 #1 SMP Wed Mar 13 12:02:46 UTC 2019 x86_64
    hardware: 12 cpus, 2 disks, 1 node, 36023MB RAM
    timezone: CEST-2
    services: pmcd
    pmcd: Version 4.3.0-1, 8 agents
    pmda: root pmcd proc xfs linux mmv kvm jbd2

추가 리소스

8.2. pminfo를 사용하여 XFS 성능 지표 검사

PCP를 사용하면 XFS PMDA를 사용하여 마운트된 XFS 파일 시스템별로 특정 XFS 지표를 보고할 수 있습니다. 이렇게 하면 마운트된 특정 파일 시스템 문제를 더 쉽게 찾아 성능을 평가할 수 있습니다.

pminfo 명령은 마운트된 각 XFS 파일 시스템에 대해 장치별 XFS 지표를 제공합니다.

이 절차에서는 XFS PMDA에서 제공하는 사용 가능한 모든 지표 목록을 표시합니다.

사전 요구 사항

절차

  • XFS PMDA에서 제공하는 사용 가능한 모든 지표 목록을 표시합니다.

    # pminfo xfs
  • 개별 지표에 대한 정보를 표시합니다. 다음 예제에서는 pminfo 툴을 사용하여 특정 XFS에서 지표를 읽고 씁니다.

    • xfs.write_bytes 메트릭에 대한 간단한 설명을 표시합니다.

      # pminfo --oneline xfs.write_bytes
      
      xfs.write_bytes [number of bytes written in XFS file system write operations]
    • xfs.read_bytes 메트릭에 대한 자세한 설명을 표시합니다.

      # pminfo --helptext xfs.read_bytes
      
      xfs.read_bytes
      Help:
      This is the number of bytes read via read(2) system calls to files in
      XFS file systems. It can be used in conjunction with the read_calls
      count to calculate the average size of the read operations to file in
      XFS file systems.
    • xfs.read_bytes 지표의 현재 성능 값을 가져옵니다.

      # pminfo --fetch xfs.read_bytes
      
      xfs.read_bytes
          value 4891346238
    • pminfo 를 사용하여 장치별 XFS 지표를 가져옵니다.

      # pminfo --fetch --oneline xfs.perdev.read xfs.perdev.write
      
      xfs.perdev.read [number of XFS file system read operations]
      inst [0 or "loop1"] value 0
      inst [0 or "loop2"] value 0
      
      xfs.perdev.write [number of XFS file system write operations]
      inst [0 or "loop1"] value 86
      inst [0 or "loop2"] value 0

추가 리소스

8.3. pmstore를 사용하여 XFS 성능 지표 재설정

PCP를 사용하면 특히 지표가 xfs.control.reset 지표와 같은 제어 변수 역할을 하는 경우 특정 지표의 값을 수정할 수 있습니다. 지표 값을 수정하려면 pmstore 툴을 사용합니다.

이 절차에서는 pmstore 툴을 사용하여 XFS 지표를 재설정하는 방법을 설명합니다.

사전 요구 사항

절차

  1. 지표 값을 표시합니다.

    $ pminfo -f xfs.write
    
    xfs.write
        value 325262
  2. 모든 XFS 지표를 재설정합니다.

    # pmstore xfs.control.reset 1
    
    xfs.control.reset old value=0 new value=1

검증 단계

  • 지표를 재설정한 후 정보를 확인합니다.

    $ pminfo --fetch xfs.write
    
    xfs.write
        value 0

추가 리소스

8.4. XFS의 PCP 메트릭 그룹

다음 표에서는 XFS에 사용 가능한 PCP 지표 그룹을 설명합니다.

표 8.1. XFS의 지표 그룹

메트릭 그룹

제공된 지표

xfs.*

읽기 및 쓰기 작업 수, 바이트 수 읽기 및 쓰기를 포함한 일반 XFS 지표. inode가 플러시되고 클러스터형 및 클러스터에 실패 횟수의 카운터와 함께 사용할 수 있습니다.

xfs.allocs.*

xfs.alloc_btree.*

파일 시스템에서 오브젝트 할당과 관련된 지표 범위에는 범위 및 블록 생성/없음이 포함됩니다. 할당 트리 조회 및 btree에서 레코드 생성 및 삭제 확장과 비교합니다.

xfs.block_map.*

xfs.bmap_btree.*

지표에는 블록 맵 읽기/쓰기 및 블록 삭제 수, 삽입 목록 작업, 삭제 및 조회가 포함됩니다. 또한 blockmap의 비교, 조회, 삽입 및 삭제 작업을 위한 작업 카운터도 있습니다.

xfs.dir_ops.*

생성, 입력 삭제, "getdent" 작업 수를 위한 XFS 파일 시스템의 디렉터리 작업에 대한 카운터입니다.

xfs.transactions.*

메타 데이터 트랜잭션 수에 대한 카운터에는 빈 트랜잭션 수와 함께 동기 및 비동기 트랜잭션 수가 포함됩니다.

xfs.inode_ops.*

운영 체제가 inode 캐시의 XFS inode를 찾는 횟수에 대한 카운터는 다양한 결과를 제공합니다. 이러한 개수 캐시 적중, 캐시 누락 등입니다.

xfs.log.*

xfs.log_tail.*

XFS 파일 암호화에 대한 로그 버퍼 수에 대한 카운터에는 디스크에 기록된 블록 수가 포함됩니다. 또한 로그 플러시 및 고정 수에 대한 메트릭입니다.

xfs.xstrat.*

XFS 플러시 중단으로 플러시한 파일 데이터의 바이트 수와 디스크의 연속 및 비동기 공간이 플러시되는 버퍼 수에 대한 카운터를 계산합니다.

xfs.attr.*

모든 XFS 파일 시스템에 대한 속성 get, set, remove 및 list 작업의 수를 계산합니다.

xfs.quota.*

XFS 파일 시스템에 대한 할당량 작업 지표에는 할당량 회수 횟수, 할당량 캐시 누락, 캐시 적중 및 할당량 데이터 회수에 대한 카운터가 포함됩니다.

xfs.buffer.*

XFS 버퍼 오브젝트와 관련된 지표 범위. 카운터에는 요청된 버퍼 호출 수, 성공한 버퍼 잠금, 대기 중인 버퍼 잠금, miss_locks, miss_retries 및 버퍼 적중 수가 포함됩니다.

xfs.btree.*

XFS btree의 작업에 관한 지표.

xfs.control.reset

XFS 통계의 지표 카운터를 재설정하는 데 사용되는 구성 지표입니다. 제어 메트릭은 pmstore 툴을 통해 전환됩니다.

8.5. XFS용 장치별 PCP 지표 그룹

다음 표에서는 XFS에 대해 사용 가능한 장치별 PCP 지표 그룹을 설명합니다.

표 8.2. XFS용 장치별 PCP 지표 그룹

메트릭 그룹

제공된 지표

xfs.perdev.*

읽기 및 쓰기 작업 수, 바이트 수 읽기 및 쓰기를 포함한 일반 XFS 지표. inode가 플러시되고 클러스터형 및 클러스터에 실패 횟수의 카운터와 함께 사용할 수 있습니다.

xfs.perdev.allocs.*

xfs.perdev.alloc_btree.*

파일 시스템에서 오브젝트 할당과 관련된 지표 범위에는 범위 및 블록 생성/없음이 포함됩니다. 할당 트리 조회 및 btree에서 레코드 생성 및 삭제 확장과 비교합니다.

xfs.perdev.block_map.*

xfs.perdev.bmap_btree.*

지표에는 블록 맵 읽기/쓰기 및 블록 삭제 수, 삽입 목록 작업, 삭제 및 조회가 포함됩니다. 또한 blockmap의 비교, 조회, 삽입 및 삭제 작업을 위한 작업 카운터도 있습니다.

xfs.perdev.dir_ops.*

생성, 입력 삭제, "getdent" 작업 수를 위한 XFS 파일 시스템의 디렉터리 작업에 대한 카운터입니다.

xfs.perdev.transactions.*

메타 데이터 트랜잭션 수에 대한 카운터에는 빈 트랜잭션 수와 함께 동기 및 비동기 트랜잭션 수가 포함됩니다.

xfs.perdev.inode_ops.*

운영 체제가 inode 캐시의 XFS inode를 찾는 횟수에 대한 카운터는 다양한 결과를 제공합니다. 이러한 개수 캐시 적중, 캐시 누락 등입니다.

xfs.perdev.log.*

xfs.perdev.log_tail.*

로그 버퍼 수에 대한 카운터는 XFS 파일SERVICEms를 통해 쓰는 블록 수가 디스크에 기록된 블록 수를 포함합니다. 또한 로그 플러시 및 고정 수에 대한 메트릭입니다.

xfs.perdev.xstrat.*

XFS 플러시 중단으로 플러시한 파일 데이터의 바이트 수와 디스크의 연속 및 비동기 공간이 플러시되는 버퍼 수에 대한 카운터를 계산합니다.

xfs.perdev.attr.*

모든 XFS 파일 시스템에 대한 속성 get, set, remove 및 list 작업의 수를 계산합니다.

xfs.perdev.quota.*

XFS 파일 시스템에 대한 할당량 작업 지표에는 할당량 회수 횟수, 할당량 캐시 누락, 캐시 적중 및 할당량 데이터 회수에 대한 카운터가 포함됩니다.

xfs.perdev.buffer.*

XFS 버퍼 오브젝트와 관련된 지표 범위. 카운터에는 요청된 버퍼 호출 수, 성공한 버퍼 잠금, 대기 중인 버퍼 잠금, miss_locks, miss_retries 및 버퍼 적중 수가 포함됩니다.

xfs.perdev.btree.*

XFS btree의 작업에 관한 지표.

9장. PCP 메트릭의 그래픽 표현 설정

pcp ,grafana, pcp redis,pcp bpftrace 벡터 의 조합을 사용하면 라이브 데이터 또는 PCP(Performance Co-Pilot)에서 수집한 데이터에 대한 그래픽 표현이 제공됩니다.

9.1. pcp-zeroconf로 PCP 설정

이 절차에서는 pcp-zeroconf 패키지가 있는 시스템에서 PCP를 설정하는 방법을 설명합니다. pcp-zeroconf 패키지가 설치되면 시스템에서 기본 지표 세트를 아카이브 파일에 기록합니다.

절차

  • pcp-zeroconf 패키지를 설치합니다.

    # dnf install pcp-zeroconf

검증 단계

  • pmlogger 서비스가 활성화되어 있는지 확인하고 메트릭 보관을 시작합니다.

    # pcp | grep pmlogger
     pmlogger: primary logger: /var/log/pcp/pmlogger/localhost.localdomain/20200401.00.12

추가 리소스

9.2. grafana-server 설정

Grafana는 브라우저에서 액세스할 수 있는 그래프를 생성합니다. grafana-server 는 Grafana 대시보드의 백엔드 서버입니다. 기본적으로 모든 인터페이스에서 수신 대기하고 웹 브라우저를 통해 액세스하는 웹 서비스를 제공합니다. grafana-pcp 플러그인은 백엔드의 pmproxy 프로토콜과 상호 작용합니다.

이 절차에서는 grafana-server 를 설정하는 방법을 설명합니다.

사전 요구 사항

절차

  1. 다음 패키지를 설치합니다.

    # dnf install grafana grafana-pcp
  2. 다음 서비스를 다시 시작하고 활성화합니다.

    # systemctl restart grafana-server
    # systemctl enable grafana-server
  3. Grafana 서비스에 대한 네트워크 트래픽에 대한 서버 방화벽을 엽니다.

    # firewall-cmd --permanent --add-service=grafana
    success
    
    # firewall-cmd --reload
    success

검증 단계

  • grafana-server 가 수신 대기 중이며 요청에 응답하는지 확인합니다.

    # ss -ntlp | grep 3000
    LISTEN  0  128  *:3000  *:*  users:(("grafana-server",pid=19522,fd=7))
  • grafana-pcp 플러그인이 설치되었는지 확인합니다.

    # grafana-cli plugins ls | grep performancecopilot-pcp-app
    
    performancecopilot-pcp-app @ 3.1.0

추가 리소스

  • pmproxy(1)grafana-server 도움말 페이지

9.3. Grafana 웹 UI 액세스

다음 절차에서는 Grafana 웹 인터페이스에 액세스하는 방법을 설명합니다.

Grafana 웹 인터페이스를 사용하면 다음을 수행할 수 있습니다.

  • PCP Redis, PCP bpftrace 및 PCP 벡터 데이터 소스 추가
  • 대시보드 만들기
  • 유용한 메트릭의 개요 보기
  • PCP Redis에 경고 생성

사전 요구 사항

  1. PCP가 구성되어 있습니다. 자세한 내용은 pcp-zeroconf를 사용하여 PCP 설정을 참조하십시오.
  2. grafana-server 가 구성되어 있습니다. 자세한 내용은 grafana-server 설정을 참조하십시오.

절차

  1. 클라이언트 시스템에서 브라우저를 열고 http://192.0.2.0:3000 링크를 사용하여 포트 3000grafana-server 에 액세스합니다.

    192.0.2.0 을 사용자 시스템 IP로 바꿉니다.

  2. 첫 번째 로그인의 경우 Email 또는 usernamePassword 필드에 admin 을 입력합니다.

    Grafana는 보안 계정을 생성하기 위해 새 암호를 설정하라는 메시지를 표시합니다. 나중에 설정하려는 경우 Skip 을 클릭합니다.

  3. 메뉴에서 grafana gear icon 구성 아이콘 위에 커서를 이동한 다음 플러그인 을 클릭합니다.
  4. 플러그인 탭에서 이름 또는 유형 텍스트 상자에서 검색에 성능 co-pilot을 입력한 다음 Performance Co- 915 (PCP) 플러그인을 클릭합니다.
  5. 플러그인 / Performance Co-inspector 창에서 사용을 클릭합니다.
  6. Grafana grafana home page whirl icon 아이콘을 클릭합니다. Grafana 페이지가 표시됩니다.

    그림 9.1. 홈 대시보드

    Grafana 홈 대시보드
    참고

    화면의 상단에는 유사한 grafana top corner settings icon 아이콘이 있지만 일반 대시보드 설정을 제어합니다.

  7. Grafana Home 페이지에서 첫 번째 데이터 소스 추가를 클릭하여 PCP Redis, PCP bpftrace 및 PCP Vector 데이터 소스를 추가합니다. 데이터 소스 추가에 대한 자세한 내용은 다음을 참조하십시오.

  8. 선택 사항: 메뉴에서 admin 프로필 grafana logout option icon 아이콘을 커서로 이동 하여 프로필 편집,암호 변경 또는 Sign out 을 포함한NodePolicy를 변경합니다.

추가 리소스

  • Grafana-cligrafana-server 도움말 페이지

9.4. Grafana의 보안 연결 구성

Grafana와 Performance Co-Pilot(PCP) 구성 요소 간에 보안 연결을 설정할 수 있습니다. 이러한 구성 요소 간 보안 연결을 설정하면 인증되지 않은 당사자가 수집 및 모니터링되는 데이터에 액세스하거나 수정하는 것을 방지할 수 있습니다.

사전 요구 사항

  • PCP가 설치되어 있습니다. 자세한 내용은 PCP 설치 및 활성화를 참조하십시오.
  • grafana-server 가 구성되어 있습니다. 자세한 내용은 grafana-server 설정을 참조하십시오.
  • 개인 클라이언트 키는 /etc/grafana/grafana.key 파일에 저장됩니다. 다른 경로를 사용하는 경우 프로세스의 해당 단계에서 경로를 수정합니다.

    개인 키 및 CSR(인증서 서명 요청) 생성 및 CA(인증 기관)에서 인증서를 요청하는 방법에 대한 자세한 내용은 CA 문서를 참조하십시오.

  • TLS 클라이언트 인증서는 /etc/grafana/grafana.crt 파일에 저장됩니다. 다른 경로를 사용하는 경우 프로세스의 해당 단계에서 경로를 수정합니다.

절차

  1. 루트 사용자로 /etc/grafana/grana.ini 파일을 열고 [server] 섹션에서 다음 옵션을 조정하여 다음을 반영합니다.

    protocol = https
    cert_key = /etc/grafana/grafana.key
    cert_file = /etc/grafana/grafana.crt
  2. grafana가 인증서에 액세스할 수 있는지 확인합니다.

    # su grafana -s /bin/bash -c \
      'ls -1 /etc/grafana/grafana.crt /etc/grafana/grafana.key'
    /etc/grafana/grafana.crt
    /etc/grafana/grafana.key
  3. Grafana 서비스를 다시 시작하고 활성화하여 구성 변경 사항을 적용합니다.

    # systemctl restart grafana-server
    # systemctl enable grafana-server

검증

  1. 클라이언트 시스템에서 브라우저를 열고 https://192.0.2.0:3000 링크를 사용하여 포트 3000의 grafana-server 시스템에 액세스합니다. 192.0.2.0을 시스템 IP로 바꿉니다.
  2. 주소 표시줄 옆에 lock icon 잠금 아이콘이 표시되는지 확인합니다.

    참고

    프로토콜이 http 로 설정되고 HTTPS 연결이 시도되면 ERR_SSL_PROTOCOL_ERROR 오류가 표시됩니다. 프로토콜이 https 로 설정되고 HTTP 연결이 시도되면 Grafana 서버는 "Client에서 HTTP 요청을 HTTPS 서버로 전송" 메시지로 응답합니다.

9.5. PCP Redis 구성

PCP Redis 데이터 소스를 사용하여 다음을 수행합니다.

  • 데이터 아카이브 보기
  • pmseries 언어를 사용하여 시계열 쿼리
  • 여러 호스트에서 데이터 분석

사전 요구 사항

  1. PCP가 구성되어 있습니다. 자세한 내용은 pcp-zeroconf를 사용하여 PCP 설정을 참조하십시오.
  2. grafana-server 가 구성되어 있습니다. 자세한 내용은 grafana-server 설정에서 참조하십시오.
  3. 메일 전송 에이전트(예: sendmail 또는 postfix )가 설치 및 구성됩니다.

절차

  1. redis 패키지를 설치합니다.

    # dnf install redis
  2. 다음 서비스를 시작하고 활성화합니다.

    # systemctl start pmproxy redis
    # systemctl enable pmproxy redis
  3. grafana-server 를 다시 시작하십시오.

    # systemctl restart grafana-server

검증 단계

  • pmproxyredis 가 작동하는지 확인합니다.

    # pmseries disk.dev.read
    2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df

    이 명령은 redis 패키지가 설치되지 않은 경우 데이터를 반환하지 않습니다.

추가 리소스

  • PMseries(1) 도움말 페이지

9.6. PCP redis의 보안 연결 구성

PCP(Performance co-pilot), Grafana 및 PCP redis 간에 보안 연결을 설정할 수 있습니다. 이러한 구성 요소 간 보안 연결을 설정하면 인증되지 않은 당사자가 수집 및 모니터링되는 데이터에 액세스하거나 수정하는 것을 방지할 수 있습니다.

사전 요구 사항

  • PCP가 설치되어 있습니다. 자세한 내용은 PCP 설치 및 활성화를 참조하십시오.
  • grafana-server 가 구성되어 있습니다. 자세한 내용은 grafana-server 설정을 참조하십시오.
  • PCP redis가 설치되어 있어야 합니다. 자세한 내용은 PCP Redis 구성을 참조하십시오.
  • 개인 클라이언트 키는 /etc/redis/client.key 파일에 저장됩니다. 다른 경로를 사용하는 경우 프로세스의 해당 단계에서 경로를 수정합니다.

    개인 키 및 CSR(인증서 서명 요청) 생성 및 CA(인증 기관)에서 인증서를 요청하는 방법에 대한 자세한 내용은 CA 문서를 참조하십시오.

  • TLS 클라이언트 인증서는 /etc/redis/client.crt 파일에 저장됩니다. 다른 경로를 사용하는 경우 프로세스의 해당 단계에서 경로를 수정합니다.
  • TLS 서버 키는 /etc/redis/redis.key 파일에 저장됩니다. 다른 경로를 사용하는 경우 프로세스의 해당 단계에서 경로를 수정합니다.
  • TLS 서버 인증서는 /etc/redis/redis.crt 파일에 저장됩니다. 다른 경로를 사용하는 경우 프로세스의 해당 단계에서 경로를 수정합니다.
  • CA 인증서는 /etc/redis/ca.crt 파일에 저장됩니다. 다른 경로를 사용하는 경우 프로세스의 해당 단계에서 경로를 수정합니다.

또한 pmproxy 데몬의 경우 다음을 수행합니다.

  • 개인 서버 키는 /etc/pcp/tls/server.key 파일에 저장됩니다. 다른 경로를 사용하는 경우 프로세스의 해당 단계에서 경로를 수정합니다.

절차

  1. 루트 사용자로 /etc/redis/redis.conf 파일을 열고 다음 속성을 반영하도록 TLS/SSL 옵션을 조정합니다.

    port 0
    tls-port 6379
    tls-cert-file /etc/redis/redis.crt
    tls-key-file /etc/redis/redis.key
    tls-client-key-file /etc/redis/client.key
    tls-client-cert-file /etc/redis/client.crt
    tls-ca-cert-file /etc/redis/ca.crt
  2. redis 가 TLS 인증서에 액세스할 수 있는지 확인합니다.

    # su redis -s /bin/bash -c \
      'ls -1 /etc/redis/ca.crt /etc/redis/redis.key /etc/redis/redis.crt'
    /etc/redis/ca.crt
    /etc/redis/redis.crt
    /etc/redis/redis.key
  3. redis 서버를 다시 시작하여 구성 변경 사항을 적용합니다.

    # systemctl restart redis

검증

  • TLS 구성이 작동하는지 확인합니다.

    # redis-cli --tls --cert /etc/redis/client.crt \
        --key /etc/redis/client.key \
        --cacert /etc/redis/ca.crt <<< "PING"
    PONG

    TLS 구성에 실패하면 다음과 같은 오류 메시지가 표시될 수 있습니다.

    Could not negotiate a TLS connection: Invalid CA Certificate File/Directory

9.7. PCP Redis 데이터 소스에서 패널 생성 및 경고

PCP Redis 데이터 소스를 추가한 후 유용한 지표에 대한 개요를 사용하여 대시보드를 보고, 로드 그래프를 시각화하는 쿼리를 추가하고, 시스템 문제가 발생한 후 시스템 문제를 확인하는 데 도움이 되는 경고를 생성할 수 있습니다.

사전 요구 사항

  1. PCP Redis가 구성되어 있습니다. 자세한 내용은 Configuring PCP Redis 를 참조하십시오.
  2. grafana-server 에 액세스할 수 있습니다. 자세한 내용은 Grafana 웹 UI 액세스를 참조하십시오.

절차

  1. Grafana 웹 UI에 로그인합니다.
  2. Grafana Home 페이지에서 첫 번째 데이터 소스 추가를 클릭합니다.
  3. 데이터 소스 추가 창의 이름으로 필터링하거나 텍스트 유형으로 redis를 입력한 다음 PCP Redis 를 클릭합니다.
  4. 데이터 소스 / PCP Redis 창에서 다음을 수행합니다.

    1. URL 필드에 http://localhost:44322 을 추가한 다음 저장 및 테스트를 클릭합니다.
    2. Dashboards tabImportPCP Redis: Host Overview (PCP Redis: 호스트 개요)를 클릭하여 유용한 지표의 개요가 포함된 대시보드를 확인합니다.

      그림 9.2. PCP Redis: 호스트 개요

      PCP redis 호스트 개요
  5. 새 패널을 추가합니다.

    1. 메뉴에서 grafana plus sign 아이콘 생성 대시보드 추가 새 패널 아이콘 위에 커서를 이동하여 패널을 추가합니다.
    2. 쿼리 탭에서 선택한 기본 옵션 대신 쿼리 목록에서 PCP Redis 를 선택하고 A 의 텍스트 필드에 metric를 입력합니다. 예를 들어 kernel.all.load 를 입력하여 커널 로드 그래프를 시각화합니다.
    3. 선택 사항: 패널 제목설명 을 추가하고 설정에서 다른 옵션을 업데이트합니다.
    4. 저장을 클릭하여 변경 사항을 적용하고 대시보드를 저장합니다. 대시보드 이름 추가 .
    5. 적용을 클릭하여 변경 사항을 적용하고 대시보드로 돌아갑니다.

      그림 9.3. PCP Redis 쿼리 패널

      PCP 빨간색 쿼리 패널
  6. 경고 규칙을 만듭니다.

    1. PCP Redis 쿼리 패널에서 redis alert icon 경고 를 클릭한 다음 경고 생성을 클릭합니다.
    2. Name (이름),Evaluate 쿼리 (Evalluate ) 쿼리 및 규칙의 경우 필드를 편집하고 경고에 대한 조건을 지정합니다.
    3. 저장을 클릭하여 변경 사항을 적용하고 대시보드를 저장합니다. 적용을 클릭하여 변경 사항을 적용하고 대시보드로 돌아갑니다.

      그림 9.4. PCP Redis 패널에서 경고 생성

      PCP redis 쿼리 경고 패널
    4. 선택 사항: 동일한 패널에서 아래로 스크롤하고 삭제 아이콘을 클릭하여 생성된 규칙을 삭제합니다.
    5. 선택 사항: 메뉴에서 alerting bell icon 경고 아이콘을 클릭하여 다른 경고 상태로 생성된 경고 규칙을 확인하고, 경고 규칙을 편집하거나, 경고 규칙 탭에서 기존 규칙을 일시 중지합니다.

      Grafana에서 경고 알림을 수신하는 생성된 경고 규칙에 대한 알림 채널을 추가하려면 알림에 대한 알림 채널 추가를 참조하십시오.

9.8. 경고에 대한 알림 채널 추가

알림 채널을 추가하면 경고 규칙 조건이 충족되고 시스템 모니터링이 필요할 때마다 Grafana에서 경고 알림을 수신할 수 있습니다.

지원되는 알림 목록에서 DingDing,Discord,Email,Google Hangouts chat ,HipChat , LINE ,LINE LINE ,Microsoft Teams 를 선택한 후 이러한 알림을 수신할 수 있습니다. Opsgenie,PagerDuty,Prometheus Alertmanager,Pushover,Sensu,Slack, 전이ma 게이트웨이,VictorOpsWebhook.

사전 요구 사항

  1. grafana-server 에 액세스할 수 있습니다. 자세한 내용은 Grafana 웹 UI 액세스를 참조하십시오.
  2. 경고 규칙이 생성됩니다. 자세한 내용은 PCP Redis 데이터 소스에서 패널 및 경고 생성을 참조하십시오.
  3. SMTP를 구성하고 grafana/grafana.ini 파일에 유효한 보낸 사람의 이메일 주소를 추가합니다.

    # vi /etc/grafana/grafana.ini
    
    [smtp]
    enabled = true
    from_address = abc@gmail.com

    abc@gmail.com 을 유효한 이메일 주소로 바꿉니다.

  4. grafana-server다시 시작

    # systemctl restart grafana-server.service

절차

  1. 메뉴에서 alerting bell icon 경고 아이콘 위에 커서를 올려 놓으면문의 포인트 새 연락처포인트를 클릭합니다.
  2. 새 연락처 세부 정보 보기에서 다음을 수행합니다.

    1. 이름 텍스트 상자에 이름을 입력합니다.
    2. 연락처 유형 (예: 이메일)을 선택하고 이메일 주소를 입력합니다. ; 구분자를 사용하여 많은 이메일 주소를 추가할 수 있습니다.
    3. 선택 사항: 선택적 이메일 설정알림 설정을 구성합니다.
  3. Save contact point 를 클릭합니다.
  4. 경고 규칙에서 알림 채널을 선택합니다.

    1. 메뉴에서 알림 정책 아이콘을 선택한 다음 + 새 특정 정책을 클릭합니다.
    2. 방금 만든 연락처 를 선택합니다.
    3. 정책 저장 버튼을 클릭합니다.

9.9. PCP 구성 요소 간 인증 설정

SASL(Simple Authentication Security Layer) 프레임워크를 통해 PCP에서 지원하는 scram-sha-256 인증 메커니즘을 사용하여 인증을 설정할 수 있습니다.

절차

  1. scram-sha-256 인증 메커니즘을 위한 sasl 프레임워크를 설치합니다.

    # dnf install cyrus-sasl-scram cyrus-sasl-lib
  2. pmcd.conf 파일에서 지원되는 인증 메커니즘과 사용자 데이터베이스 경로를 지정합니다.

    # vi /etc/sasl2/pmcd.conf
    
    mech_list: scram-sha-256
    
    sasldb_path: /etc/pcp/passwd.db
  3. 새 사용자를 생성합니다.

    # useradd -r metrics

    지표를 사용자 이름으로 교체합니다.

  4. 사용자 데이터베이스에 생성된 사용자를 추가합니다.

    # saslpasswd2 -a pmcd metrics
    
    Password:
    Again (for verification):

    생성된 사용자를 추가하려면 지표 계정 암호를 입력해야 합니다.

  5. 사용자 데이터베이스의 권한을 설정합니다.

    # chown root:pcp /etc/pcp/passwd.db
    # chmod 640 /etc/pcp/passwd.db
  6. pmcd 서비스를 다시 시작합니다.

    # systemctl restart pmcd

검증 단계

  • sasl 구성을 확인합니다.

    # pminfo -f -h "pcp://127.0.0.1?username=metrics" disk.dev.read
    Password:
    disk.dev.read
    inst [0 or "sda"] value 19540

9.10. PCP bpftrace 설치

PCP bpftrace 에이전트를 설치하여 시스템을 검사하고 커널 및 사용자 공간 추적점에서 지표를 수집합니다.

bpftrace 에이전트는 bpftrace 스크립트를 사용하여 메트릭을 수집합니다. bpftrace 스크립트는 강화된 Berkeley Packet Filter (eBPF)를 사용합니다.

이 절차에서는 pcp bpftrace 를 설치하는 방법을 설명합니다.

사전 요구 사항

  1. PCP가 구성되어 있습니다. 자세한 내용은 pcp-zeroconf를 사용하여 PCP 설정을 참조하십시오.
  2. grafana-server 가 구성되어 있습니다. 자세한 내용은 grafana-server 설정에서 참조하십시오.
  3. scram-sha-256 인증 메커니즘이 구성되어 있습니다. 자세한 내용은 PCP 구성 요소 간 인증 설정을 참조하십시오.

절차

  1. pcp-pmda-bpftrace 패키지를 설치합니다.

    # dnf install pcp-pmda-bpftrace
  2. bpftrace.conf 파일을 편집하고 {setting-up-authentication-between-pcp-components}에서 만든 사용자를 추가합니다.

    # vi /var/lib/pcp/pmdas/bpftrace/bpftrace.conf
    
    [dynamic_scripts]
    enabled = true
    auth_enabled = true
    allowed_users = root,metrics

    지표를 사용자 이름으로 교체합니다.

  3. bpftrace PMDA를 설치합니다.

    # cd /var/lib/pcp/pmdas/bpftrace/
    # ./Install
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Check bpftrace metrics have appeared ... 7 metrics and 6 values

    pmda-bpftrace 가 이제 설치되었으며 사용자를 인증한 후에만 사용할 수 있습니다. 자세한 내용은 PCP bpftrace 시스템 분석 대시보드 보기를 참조하십시오.

추가 리소스

  • pmdabpftrace(1)bpftrace 매뉴얼 페이지

9.11. PCP bpftrace 시스템 분석 대시보드 보기

PCP bpftrace 데이터 소스를 사용하면 pmlogger 또는 아카이브에서 일반 데이터로 사용할 수 없는 소스의 실시간 데이터에 액세스할 수 있습니다.

PCP bpftrace 데이터 소스에서 유용한 지표의 개요를 사용하여 대시보드를 볼 수 있습니다.

사전 요구 사항

  1. PCP bpftrace가 설치되어 있습니다. 자세한 내용은 Installing PCP bpftrace 를 참조하십시오.
  2. grafana-server 에 액세스할 수 있습니다. 자세한 내용은 Grafana 웹 UI 액세스를 참조하십시오.

절차

  1. Grafana 웹 UI에 로그인합니다.
  2. Grafana Home 페이지에서 첫 번째 데이터 소스 추가를 클릭합니다.
  3. Add data source (데이터 소스 추가) 창에서 Filter by name or type text box에 bpftrace를 입력한 다음 PCP bpftrace 를 클릭합니다.
  4. 데이터 소스 / PCP bpftrace 창에서 다음을 수행합니다.

    1. URL 필드에 http://localhost:44322 을 추가합니다.
    2. Basic Auth 옵션을 전환하고 UserPassword 필드에 생성된 사용자 자격 증명을 추가합니다.
    3. Save & Test 를 클릭합니다.

      그림 9.5. 데이터 소스에 PCP bpftrace 추가

      bpftrace auth
    4. Dashboards 탭ImportPCP bpftrace: System Analysis 를 클릭하여 유용한 지표에 대한 개요가 포함된 대시보드를 확인합니다.

      그림 9.6. PCP bpftrace: 시스템 분석

      PCP bpftrace bpftrace 시스템 분석

9.12. PCP 벡터 설치

이 절차에서는 pcp 벡터 를 설치하는 방법을 설명합니다.

사전 요구 사항

  1. PCP가 구성되어 있습니다. 자세한 내용은 pcp-zeroconf를 사용하여 PCP 설정을 참조하십시오.
  2. grafana-server 가 구성되어 있습니다. 자세한 내용은 grafana-server 설정에서 참조하십시오.

절차

  1. pcp-pmda-bcc 패키지를 설치합니다.

    # dnf install pcp-pmda-bcc
  2. bcc PMDA를 설치합니다.

    # cd /var/lib/pcp/pmdas/bcc
    # ./Install
    [Wed Apr  1 00:27:48] pmdabcc(22341) Info: Initializing, currently in 'notready' state.
    [Wed Apr  1 00:27:48] pmdabcc(22341) Info: Enabled modules:
    [Wed Apr  1 00:27:48] pmdabcc(22341) Info: ['biolatency', 'sysfork',
    [...]
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Check bcc metrics have appeared ... 1 warnings, 1 metrics and 0 values

추가 리소스

  • pmdabcc(1) man page

9.13. PCP 벡터 체크리스트 보기

PCP 벡터 데이터 소스는 실시간 지표를 표시하고 pcp 지표를 사용합니다. 개별 호스트에 대한 데이터를 분석합니다.

PCP 벡터 데이터 소스를 추가한 후 유용한 지표에 대한 개요를 사용하여 대시보드를 보고 체크리스트의 관련 문제 해결 또는 참조 링크를 볼 수 있습니다.

사전 요구 사항

  1. PCP 벡터가 설치되어 있습니다. 자세한 내용은 Installing PCP Vector 를 참조하십시오.
  2. grafana-server 에 액세스할 수 있습니다. 자세한 내용은 Grafana 웹 UI 액세스를 참조하십시오.

절차

  1. Grafana 웹 UI에 로그인합니다.
  2. Grafana Home 페이지에서 첫 번째 데이터 소스 추가를 클릭합니다.
  3. 데이터 소스 추가 창의 이름으로 필터링하거나 텍스트 유형으로 벡터를 입력한 다음 PCP 벡터 를 클릭합니다.
  4. 데이터 소스 / PCP 벡터 창에서 다음을 수행합니다.

    1. URL 필드에 http://localhost:44322 을 추가한 다음 저장 및 테스트를 클릭합니다.
    2. Dashboards(대시보드) 탭ImportPCP Vector: Host Overview (PCP 벡터: 호스트 개요)를 클릭하여 유용한 지표에 대한 개요가 포함된 대시보드를 확인합니다.

      그림 9.7. PCP 벡터: 호스트 개요

      PCP 벡터 호스트 개요
  5. 메뉴에서 pcp plugin in grafana Performance Co-Pilot 플러그인 위에 커서를 이동한 다음 PCP Vector Checklist 를 클릭합니다.

    PCP 체크리스트에서 pcp vector checklist troubleshooting doc 도움말 또는 pcp vector checklist warning 경고 아이콘을 클릭하여 관련 문제 해결 또는 참조 링크를 확인합니다.

    그림 9.8. Performance Co-915 / PCP Vector Checklist

    PCP 벡터 체크리스트

9.14. Grafana 문제 해결

Grafana와 같은 문제를 해결하는 것은neccesary로, Grafana가 데이터를 표시하지 않으며, 대시보드는 검정 또는 유사한 문제가 발생하는 경우가 있습니다.

절차

  • 다음 명령을 실행하여 pmlogger 서비스가 실행 중인지 확인합니다.

    $ systemctl status pmlogger
  • 다음 명령을 실행하여 파일이 디스크에 생성되거나 수정되었는지 확인합니다.

    $ ls /var/log/pcp/pmlogger/$(hostname)/ -rlt
    total 4024
    -rw-r--r--. 1 pcp pcp   45996 Oct 13  2019 20191013.20.07.meta.xz
    -rw-r--r--. 1 pcp pcp     412 Oct 13  2019 20191013.20.07.index
    -rw-r--r--. 1 pcp pcp   32188 Oct 13  2019 20191013.20.07.0.xz
    -rw-r--r--. 1 pcp pcp   44756 Oct 13  2019 20191013.20.30-00.meta.xz
    [..]
  • 다음 명령을 실행하여 pmproxy 서비스가 실행 중인지 확인합니다.

    $ systemctl status pmproxy
  • pmproxy 가 실행 중이고, 시계열 지원이 활성화되었으며 /var/log/pcp/pmproxy/pmproxy.log 파일을 보고 Redis에 대한 연결이 설정되어 있는지 확인하고 다음 텍스트가 포함되어 있는지 확인합니다.

    pmproxy(1716) Info: Redis slots, command keys, schema version setup

    여기에서 1716pmproxy 의 PID이며, pmproxy를 호출할 때마다 다릅니다.

  • 다음 명령을 실행하여 Redis 데이터베이스에 키가 포함되어 있는지 확인합니다.

    $ redis-cli dbsize
    (integer) 34837
  • PCP 메트릭이 Redis 데이터베이스에 있고 pmproxy 가 다음 명령을 실행하여 액세스할 수 있는지 확인합니다.

    $ pmseries disk.dev.read
    2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    
    $ pmseries "disk.dev.read[count:10]"
    2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
        [Mon Jul 26 12:21:10.085468000 2021] 117971 70e83e88d4e1857a3a31605c6d1333755f2dd17c
        [Mon Jul 26 12:21:00.087401000 2021] 117758 70e83e88d4e1857a3a31605c6d1333755f2dd17c
        [Mon Jul 26 12:20:50.085738000 2021] 116688 70e83e88d4e1857a3a31605c6d1333755f2dd17c
    [...]
    $ redis-cli --scan --pattern "*$(pmseries 'disk.dev.read')"
    
    pcp:metric.name:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:values:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:desc:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:labelvalue:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:instances:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:labelflags:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
  • 다음 명령을 실행하여 Grafana 로그에 오류가 있는지 확인합니다.

    $ journalctl -e -u grafana-server
    -- Logs begin at Mon 2021-07-26 11:55:10 IST, end at Mon 2021-07-26 12:30:15 IST. --
    Jul 26 11:55:17 localhost.localdomain systemd[1]: Starting Grafana instance...
    Jul 26 11:55:17 localhost.localdomain grafana-server[1171]: t=2021-07-26T11:55:17+0530 lvl=info msg="Starting Grafana" logger=server version=7.3.6 c>
    Jul 26 11:55:17 localhost.localdomain grafana-server[1171]: t=2021-07-26T11:55:17+0530 lvl=info msg="Config loaded from" logger=settings file=/usr/s>
    Jul 26 11:55:17 localhost.localdomain grafana-server[1171]: t=2021-07-26T11:55:17+0530 lvl=info msg="Config loaded from" logger=settings file=/etc/g>
    [...]

10장. 웹 콘솔을 사용하여 시스템 성능 최적화

RHEL 웹 콘솔에서 성능 프로필을 설정하여 선택한 작업에 맞게 시스템의 성능을 최적화하는 방법을 알아봅니다.

10.1. 웹 콘솔의 성능 튜닝 옵션

Red Hat Enterprise Linux 9는 다음 작업을 위해 시스템을 최적화하는 여러 성능 프로필을 제공합니다.

  • 데스크탑을 사용하는 시스템
  • 처리량 성능
  • 대기 시간 성능
  • 네트워크 성능
  • 낮은 전력 소비
  • 가상 머신

TuneD 서비스는 선택한 프로필과 일치하도록 시스템 옵션을 최적화합니다.

웹 콘솔에서 시스템에서 사용하는 성능 프로필을 설정할 수 있습니다.

추가 리소스

10.2. 웹 콘솔에서 성능 프로파일 설정

수행하려는 작업에 따라 웹 콘솔을 사용하여 적절한 성능 프로필을 설정하여 시스템 성능을 최적화할 수 있습니다.

사전 요구 사항

  • 웹 콘솔이 설치되어 있고 액세스할 수 있는지 확인합니다. 자세한 내용은 웹 콘솔 설치를 참조하십시오.

절차

  1. 9 웹 콘솔에 로그인합니다. 자세한 내용은 웹 콘솔 로그인을 참조하십시오.
  2. 개요 를 클릭합니다.
  3. 구성 섹션에서 현재 성능 프로필을 클릭합니다.

    Image displaying the Overview pane of the cockpit interface.

  4. 성능 프로필 변경 대화 상자에서 필요한 프로필을 설정합니다.

    Image displaying the Change performance profile dialog box.

  5. 프로필 변경을 클릭합니다.

검증 단계

  • 이제 개요 탭에 구성 섹션에서 선택한 성능 프로필이 표시됩니다.

10.3. 웹 콘솔을 사용하여 로컬 시스템에서 성능 모니터링

Red Hat Enterprise Linux 웹 콘솔에서는 문제 해결을 위해 UE(Utilization Saturation and Errors) 방법을 사용합니다. 새로운 성능 지표 페이지에는 데이터의 과거 보기가 고전적으로 맨 위에 있는 최신 데이터와 함께 체계화되어 있습니다.

지표 및 기록 페이지에서 리소스 사용률 및 포화 상태에 대한 이벤트, 오류 및 그래픽 표시를 볼 수 있습니다.

사전 요구 사항

  • 웹 콘솔이 설치되고 액세스할 수 있습니다. 자세한 내용은 웹 콘솔 설치를 참조하십시오.
  • 성능 지표를 수집할 수 있는 cockpit-pcp 패키지가 설치됩니다.

    1. 웹 콘솔 인터페이스에서 패키지를 설치하려면 다음을 수행합니다.

      1. 관리 권한으로 웹 콘솔에 로그인합니다. 자세한 내용은 웹 콘솔 로그인을 참조하십시오.
      2. 개요 페이지에서 메트릭 및 기록 보기를 클릭합니다.
      3. Install cockpit-pcp 버튼을 클릭합니다.
      4. 소프트웨어 설치 대화 상자 창에서 설치 를 클릭합니다.
    2. 명령줄 인터페이스에서 패키지를 설치하려면 다음을 사용합니다.

      # dnf install cockpit-pcp
  • PCP(Performance Co- Cryostat) 서비스가 활성화되어 있습니다.

    # systemctl enable --now pmlogger.service pmproxy.service

절차

  1. 9 웹 콘솔에 로그인합니다. 자세한 내용은 웹 콘솔 로그인을 참조하십시오.
  2. 개요 를 클릭합니다.
  3. 사용 섹션에서 메트릭 및 기록 보기를 클릭합니다.

    Image displaying the Overview pane of the cockpit interface.

    Metrics 및 history 섹션이 열립니다.

    • 현재 시스템 구성 및 사용법: Image displaying the current system configuration and usage
    • 사용자 지정 시간 간격에 따라 그래픽 형식의 성능 지표입니다. Image displaying the performance metrics of the CPU

10.4. 웹 콘솔 및 Grafana를 사용하여 여러 시스템에서 성능 모니터링

Grafana를 사용하면 여러 시스템의 데이터를 한 번에 수집하고 수집된 PCP(Performance Co- Cryostat) 메트릭의 그래픽 표현을 검토할 수 있습니다. 웹 콘솔 인터페이스에서 여러 시스템에 대한 성능 지표 모니터링 및 내보내기를 설정할 수 있습니다.

사전 요구 사항

  • 웹 콘솔을 설치하고 액세스할 수 있어야 합니다. 자세한 내용은 링크:웹 콘솔 설치를 참조하십시오.
  • cockpit-pcp 패키지를 설치합니다.

    1. 웹 콘솔 인터페이스에서 다음을 수행합니다.

      1. 관리 권한으로 웹 콘솔에 로그인합니다. 자세한 내용은 웹 콘솔 로그인을 참조하십시오.
      2. 개요 페이지에서 세부 정보 보기 및 기록 을 클릭합니다.
      3. Install cockpit-pcp 버튼을 클릭합니다.
      4. 소프트웨어 설치 대화 상자 창에서 설치 를 클릭합니다.
      5. 로그아웃한 후 다시 로그인하여 메트릭 기록을 확인합니다.
    2. 명령줄 인터페이스에서 패키지를 설치하려면 다음을 사용합니다.

      # dnf install cockpit-pcp
  • PCP 서비스를 활성화합니다.

    # systemctl enable --now pmlogger.service pmproxy.service
  • Grafana 대시보드를 설정합니다. 자세한 내용은 grafana-server 설정을 참조하십시오.
  • redis 패키지를 설치합니다.

    # dnf install redis

    또는 나중에 절차의 웹 콘솔 인터페이스에서 패키지를 설치할 수 있습니다.

절차

  1. 개요 페이지에서 사용 표의 지표 및 기록 보기를 클릭합니다.
  2. Metrics 설정 버튼을 클릭합니다.
  3. Export를 네트워크 슬라이 더로 이동합니다.

    Metrics settings

    redis 패키지가 설치되어 있지 않은 경우 웹 콘솔에서 설치하라는 메시지를 표시합니다.

  4. pmproxy 서비스를 열려면 드롭다운 목록에서 영역을 선택하고 pmproxy 추가 버튼을 클릭합니다.
  5. 저장을 클릭합니다.

검증

  1. 네트워킹 을 클릭합니다.
  2. 방화벽 테이블에서 규칙 및 영역 편집 버튼을 클릭합니다.
  3. 선택한 영역에서 pmproxy 를 검색합니다.
중요

보고 싶은 모든 시스템에 대해 이 절차를 반복합니다.

11장. 디스크 스케줄러 설정

디스크 스케줄러는 스토리지 장치에 전송된 I/O 요청을 정렬합니다.

다음과 같은 다양한 방법으로 스케줄러를 구성할 수 있습니다.

참고

Red Hat Enterprise Linux 9에서 블록 장치는 다중 대기열 스케줄링만 지원합니다. 이를 통해 솔리드 스테이트 드라이브(SSD) 및 멀티 코어 시스템으로 블록 계층 성능을 확장할 수 있습니다.

Red Hat Enterprise Linux 7 및 이전 버전에서 사용할 수 있는 기존의 단일 대기열 스케줄러가 제거되었습니다.

11.1. 사용 가능한 디스크 스케줄러

Red Hat Enterprise Linux 9에서 지원되는 다중 대기열 디스크 스케줄러는 다음과 같습니다.

none
first-in first-out(databind) 스케줄링 알고리즘을 구현합니다. 간단한 마지막 캐시를 통해 일반 블록 계층의 요청을 병합합니다.
mq-deadline

요청이 스케줄러에 도달하는 시점의 요청에 대해 보장되는 대기 시간을 제공하려고 합니다.

mq-deadline 스케줄러는 대기 중인 I/O 요청을 읽기 또는 쓰기 일괄 처리로 정렬한 다음 논리 블록 주소 지정(LBA) 순서를 늘리기 위해 해당 요청을 실행하도록 예약합니다. 기본적으로 읽기 배치는 애플리케이션이 읽기 I/O 작업에서 차단될 가능성이 높기 때문에 쓰기 일괄 처리보다 우선합니다. mq-deadline 이 배치를 처리한 후 쓰기 작업이 프로세서 시간을 능가하는 기간을 확인하고 필요에 따라 다음 읽기 또는 쓰기 배치를 예약합니다.

이 스케줄러는 대부분의 사용 사례에 적합하지만, 특히 쓰기 작업이 대부분 비동기인 경우도 있습니다.

bfq

데스크탑 시스템 및 대화형 작업을 대상으로 합니다.

bfq 스케줄러는 단일 애플리케이션이 모든 대역폭을 절대 사용하지 않도록 합니다. 실제로 스토리지 장치는 유휴 상태인 것처럼 항상 반응하는 것처럼 반응합니다. 기본 구성에서 bfq 는 최대 처리량을 달성하는 대신 가장 짧은 대기 시간을 제공하는 데 중점을 둡니다.

BFQ는 cfq 코드를 기반으로 합니다. 고정 시간 슬라이스의 각 프로세스에 디스크를 부여하지 않지만 섹터 수로 측정된 예산을 프로세스에 할당합니다.

이 스케줄러는 대용량 파일을 복사하는 동안 적합하며 이 경우 시스템이 응답하지 않습니다.

kyber

스케줄러는 블록 I/O 계층에 제출된 모든 I/O 요청의 대기 시간을 계산하여 대기 시간 목표를 달성하기 위해 자체적으로 튜닝합니다. 캐시 허용 및 동기 쓰기 요청의 경우 읽기, 대상 대기 시간을 구성할 수 있습니다.

이 스케줄러는 NVMe, SSD 또는 기타 낮은 대기 시간 장치와 같은 빠른 장치에 적합합니다.

11.2. 다른 사용 사례에 대한 다양한 디스크 스케줄러

시스템에서 수행하는 작업에 따라 분석 및 튜닝 작업 전에 다음 디스크 스케줄러가 기준선으로 권장됩니다.

표 11.1. 다양한 사용 사례의 디스크 스케줄러

사용 사례디스크 스케줄러

SCSI 인터페이스가 있는 기존HD

mq-deadline 또는 bfq 를 사용합니다.

고성능 SSD 또는 빠른 스토리지가 있는 CPU 바인딩 시스템

특히 엔터프라이즈 애플리케이션을 실행할 때 아무 것도 사용하지 않습니다. 또는 kyber 를 사용합니다.

데스크탑 또는 대화형 작업

bfq 를 사용합니다.

가상 게스트

mq-deadline 을 사용합니다. 멀티 대기열이 가능한 호스트 버스 어댑터(HBA) 드라이버를 사용하면 아무 것도 사용하지 않습니다.

11.3. 기본 디스크 스케줄러

블록 장치는 다른 스케줄러를 지정하지 않는 한 기본 디스크 스케줄러를 사용합니다.

참고

NUMA (Non-volatile Memory Express) 블록 장치의 경우 기본 스케줄러는 none 이며 Red Hat은 이를 변경하지 않는 것이 좋습니다.

커널은 장치 유형에 따라 기본 디스크 스케줄러를 선택합니다. 일반적으로 자동 선택된 스케줄러는 최적의 설정입니다. 다른 스케줄러가 필요한 경우 Red Hat은 udev 규칙 또는 TuneD 애플리케이션을 사용하여 구성하는 것이 좋습니다. 선택한 장치와 일치하고 해당 장치에 대해서만 스케줄러를 전환합니다.

11.4. 활성 디스크 스케줄러 확인

이 절차에서는 지정된 블록 장치에서 현재 활성화되어 있는 디스크 스케줄러를 결정합니다.

절차

  • /sys/block/device/queue/scheduler 파일의 내용을 읽습니다.

    # cat /sys/block/device/queue/scheduler
    
    [mq-deadline] kyber bfq none

    파일 이름에서 장치를 블록 장치 이름으로 바꿉니다(예: sdc ).

    활성 스케줄러는 대괄호([ ])로 나열됩니다.

11.5. TuneD를 사용하여 디스크 스케줄러 설정

이 절차에서는 선택한 블록 장치에 지정된 디스크 스케줄러를 설정하는 TuneD 프로필을 생성하고 활성화합니다. 시스템 재부팅 시 설정이 유지됩니다.

다음 명령 및 구성에서 다음을 교체합니다.

  • 블록 장치 의 이름이 있는 장치(예: sdf)
  • 장치에 설정하려는 디스크 스케줄러가 있는 선택된- scheduler(예: bfq)

사전 요구 사항

절차

  1. 선택 사항: 프로필을 기반으로 할 기존 TuneD 프로필을 선택합니다. 사용 가능한 프로필 목록은 RHEL을 사용하여 배포된 TuneD 프로필을 참조하십시오.

    현재 활성화되어 있는 프로필을 확인하려면 다음을 사용합니다.

    $ tuned-adm active
  2. TuneD 프로필을 저장할 새 디렉터리를 생성합니다.

    # mkdir /etc/tuned/my-profile
  3. 선택한 블록 장치의 시스템 고유 식별자를 찾습니다.

    $ udevadm info --query=property --name=/dev/device | grep -E '(WWN|SERIAL)'
    
    ID_WWN=0x5002538d00000000_
    ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0
    ID_SERIAL_SHORT=20120501030900000
    참고

    이 예제의 명령은 지정된 블록 장치와 연결된 WWN(WWN) 또는 일련 번호로 식별되는 모든 값을 반환합니다. WWN을 사용하는 것이 바람직하지만, 지정된 장치에 WWN을 항상 사용할 수는 없으며 example 명령에서 반환된 모든 값은 장치 시스템 고유 ID 로 사용할 수 있습니다.

  4. /etc/tuned/my-profile/tuned.conf 구성 파일을 만듭니다. 파일에서 다음 옵션을 설정합니다.

    1. 선택 사항: 기존 프로필이 포함되어 있습니다.

      [main]
      include=existing-profile
    2. WWN 식별자와 일치하는 장치에 선택한 디스크 스케줄러를 설정합니다.

      [disk]
      devices_udev_regex=IDNAME=device system unique id
      elevator=selected-scheduler

      여기:

      • IDNAME 을 사용 중인 식별자 이름(예: ID_WWN)으로 바꿉니다.
      • 장치 시스템 고유 ID 를 선택한 식별자의 값으로 바꿉니다(예: 0x5002538d00000000).

        devices_udev_regex 옵션의 여러 장치와 일치하려면 식별자를 괄호로 묶고 세로 막대로 분리합니다.

        devices_udev_regex=(ID_WWN=0x5002538d00000000)|(ID_WWN=0x1234567800000000)
  5. 프로필을 활성화합니다.

    # tuned-adm profile my-profile

검증 단계

  1. TuneD 프로필이 활성화되어 적용되는지 확인합니다.

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See TuneD log file ('/var/log/tuned/tuned.log') for details.
  2. /sys/block/device/queue/scheduler 파일의 내용을 읽습니다.

    # cat /sys/block/device/queue/scheduler
    
    [mq-deadline] kyber bfq none

    파일 이름에서 장치를 블록 장치 이름으로 바꿉니다(예: sdc ).

    활성 스케줄러는 대괄호([])로 나열됩니다.

추가 리소스

11.6. udev 규칙을 사용하여 디스크 스케줄러 설정

이 절차에서는 udev 규칙을 사용하여 특정 블록 장치에 대해 지정된 디스크 스케줄러를 설정합니다. 시스템 재부팅 시 설정이 유지됩니다.

다음 명령 및 구성에서 다음을 교체합니다.

  • 블록 장치 의 이름이 있는 장치(예: sdf)
  • 장치에 설정하려는 디스크 스케줄러가 있는 선택된- scheduler(예: bfq)

절차

  1. 블록 장치의 시스템 고유 식별자를 찾습니다.

    $ udevadm info --name=/dev/device | grep -E '(WWN|SERIAL)'
    E: ID_WWN=0x5002538d00000000
    E: ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0
    E: ID_SERIAL_SHORT=20120501030900000
    참고

    이 예제의 명령은 지정된 블록 장치와 연결된 WWN(WWN) 또는 일련 번호로 식별되는 모든 값을 반환합니다. WWN을 사용하는 것이 바람직하지만, 지정된 장치에 WWN을 항상 사용할 수는 없으며 example 명령에서 반환된 모든 값은 장치 시스템 고유 ID 로 사용할 수 있습니다.

  2. udev 규칙을 구성합니다. 다음 콘텐츠를 사용하여 /etc/udev/rules.d/99-scheduler.rules 파일을 생성합니다.

    ACTION=="add|change", SUBSYSTEM=="block", ENV{IDNAME}=="device system unique id", ATTR{queue/scheduler}="selected-scheduler"

    여기:

    • IDNAME 을 사용 중인 식별자 이름(예: ID_WWN)으로 바꿉니다.
    • 장치 시스템 고유 ID 를 선택한 식별자의 값으로 바꿉니다(예: 0x5002538d00000000).
  3. udev 규칙을 다시 로드합니다.

    # udevadm control --reload-rules
  4. 스케줄러 구성을 적용합니다.

    # udevadm trigger --type=devices --action=change

검증 단계

  • 활성 스케줄러를 확인합니다.

    # cat /sys/block/device/queue/scheduler

11.7. 특정 디스크에 대한 스케줄러를 임시로 설정

이 절차에서는 특정 블록 장치에 대해 지정된 디스크 스케줄러를 설정합니다. 시스템 재부팅 시 설정이 유지되지 않습니다.

절차

  • 선택한 스케줄러의 이름을 /sys/block/device/queue/scheduler 파일에 씁니다.

    # echo selected-scheduler > /sys/block/device/queue/scheduler

    파일 이름에서 장치를 블록 장치 이름으로 바꿉니다(예: sdc ).

검증 단계

  • 장치에서 스케줄러가 활성화되어 있는지 확인합니다.

    # cat /sys/block/device/queue/scheduler

12장. Samba 서버의 성능 튜닝

특정 상황에서 Samba의 성능을 향상시킬 수 있는 설정과 성능에 부정적인 영향을 미칠 수 있는 설정에 대해 알아봅니다.

이 섹션의 일부는 Sambasouth에 게시된 성능 튜닝 문서에서 채택되었습니다. 라이센스: CC BY 4.0. 작성자 및 기여자: Wiki 페이지의 기록 탭을 참조하십시오.

사전 요구 사항

  • Samba가 파일 또는 인쇄 서버로 설정

12.1. SMB 프로토콜 버전 설정

각각의 새로운 SMB 버전은 기능을 추가하고 프로토콜의 성능을 향상시킵니다. 최근의 Windows 및 Windows Server 운영 체제는 항상 최신 프로토콜 버전을 지원합니다. 또한 Samba가 최신 프로토콜 버전을 사용하는 경우 Samba에 연결된 Windows 클라이언트는 성능 개선의 이점을 누릴 수 있습니다. Samba에서 서버 max 프로토콜의 기본값은 지원되는 최신 stable SMB 프로토콜 버전으로 설정됩니다.

참고

항상 안정적인 최신 SMB 프로토콜 버전을 사용하려면 server max protocol 매개 변수를 설정하지 마십시오. 매개 변수를 수동으로 설정하는 경우 최신 프로토콜 버전을 사용하도록 새 버전의 SMB 프로토콜을 사용하여 설정을 수정해야 합니다.

다음 절차에서는 server max protocol 매개 변수에서 기본값을 사용하는 방법을 설명합니다.

절차

  1. /etc/ controlPlane/octets.conf 파일의 [global] 섹션에서 server max protocol 매개 변수를 제거합니다.
  2. Samba 구성 다시 로드

    # smbcontrol all reload-config

12.2. 많은 수의 파일이 포함된 디렉터리와의 공유 튜닝

Linux는 대/소문자를 구분하지 않는 파일 이름을 지원합니다. 따라서 파일을 검색하거나 액세스할 때 Samba에서 대문자 및 소문자 파일 이름의 디렉터리를 스캔해야 합니다. 소문자 또는 대문자에서만 새 파일을 만들어 성능을 개선하도록 공유를 구성할 수 있습니다.

사전 요구 사항

  • Samba가 파일 서버로 구성되어 있습니다.

절차

  1. 공유의 모든 파일의 이름을 소문자로 바꿉니다.

    참고

    이 절차의 설정을 사용하여 소문자가 아닌 이름이 있는 파일은 더 이상 표시되지 않습니다.

  2. 공유 섹션에서 다음 매개변수를 설정합니다.

    case sensitive = true
    default case = lower
    preserve case = no
    short preserve case = no

    매개변수에 대한 자세한 내용은 rootfs .conf(5) 매뉴얼 페이지에서 해당 설명을 참조하십시오.

  3. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  4. Samba 구성을 다시 로드합니다.

    # smbcontrol all reload-config

이러한 설정을 적용한 후 이 공유에서 새로 생성된 모든 파일의 이름은 소문자를 사용합니다. 이러한 설정으로 인해 Samba는 더 이상 대문자 및 소문자로 디렉터리를 스캔할 필요가 없으므로 성능이 향상됩니다.

12.3. 성능에 부정적인 영향을 줄 수 있는 설정

기본적으로 Red Hat Enterprise Linux의 커널은 높은 네트워크 성능을 위해 조정됩니다. 예를 들어 커널은 버퍼 크기에 자동 튜닝 메커니즘을 사용합니다. /etc/ controlPlane/octets.conf 파일에서 socket options 매개 변수를 설정하면 이러한 커널 설정이 재정의됩니다. 결과적으로 이 매개 변수를 설정하면 대부분의 경우 Samba 네트워크 성능이 저하됩니다.

커널에서 최적화된 설정을 사용하려면 /etc/ controlPlane/octets.conf의 [global] 섹션에서 socket options 매개 변수를 제거합니다.

13장. 가상 머신 성능 최적화

가상 머신(VM)은 항상 호스트와 비교하여 어느 정도 성능 저하가 발생합니다. 다음 섹션에서는 이러한 완화의 이유를 설명하고 RHEL 9에서 가상화의 성능 영향을 최소화하는 방법에 대한 지침을 제공하여 하드웨어 인프라 리소스를 최대한 효율적으로 사용할 수 있도록 합니다.

13.1. 가상 머신 성능에 미치는 영향

VM은 호스트에서 사용자 공간 프로세스로 실행됩니다. 따라서 하이퍼바이저는 VM이 사용할 수 있도록 호스트의 시스템 리소스를 변환해야 합니다. 그 결과 변환에서 리소스 일부를 사용하고 VM은 호스트와 동일한 성능 효율성을 달성할 수 없습니다.

가상화가 시스템 성능에 미치는 영향

VM 성능 저하에 대한 구체적인 이유는 다음과 같습니다.

  • 가상 CPU(vCPU)는 호스트에서 스레드로 구현되며 Linux 스케줄러에서 처리합니다.
  • VM은 호스트 커널에서 NUMA 또는 대규모 페이지와 같은 최적화 기능을 자동으로 상속하지 않습니다.
  • 호스트의 디스크 및 네트워크 I/O 설정이 VM에 상당한 성능 영향을 미칠 수 있습니다.
  • 일반적으로 네트워크 트래픽은 소프트웨어 기반 브릿지를 통해 VM으로 이동합니다.
  • 호스트 장치와 해당 모델에 따라 특정 하드웨어 에뮬레이션으로 인해 상당한 오버헤드가 발생할 수 있습니다.

VM 성능에 미치는 가상화의 심각도는 다음과 같은 다양한 요인의 영향을 받습니다.

  • 동시에 실행 중인 VM 수입니다.
  • 각 VM에서 사용하는 가상 장치의 양입니다.
  • VM에서 사용하는 장치 유형입니다.

VM 성능 손실 감소

RHEL 9는 가상화의 부정적인 성능 영향을 줄이는 데 사용할 수 있는 다양한 기능을 제공합니다. 특히:

중요

VM 성능 튜닝은 다른 가상화 기능에 부정적인 영향을 미칠 수 있습니다. 예를 들어, 수정된 VM을 마이그레이션하는 것이 더 어려워질 수 있습니다.

13.2. TuneD를 사용하여 가상 머신 성능 최적화

TuneD 유틸리티는 CPU 집약적인 작업 또는 스토리지 네트워크 처리량 응답성 요구 사항과 같은 특정 워크로드 특성에 RHEL을 조정하는 튜닝 프로필 전달 메커니즘입니다. 성능을 향상시키고 여러 특정 사용 사례에서 전력 소비를 줄이기 위해 사전 구성된 여러 튜닝 프로필을 제공합니다. 이러한 프로필을 편집하거나 새로운 프로필을 생성하여 가상화된 환경을 포함하여 사용자 환경에 맞는 성능 솔루션을 생성할 수 있습니다.

가상화를 위해 RHEL 9를 최적화하려면 다음 프로필을 사용하십시오.

  • RHEL 9 가상 머신의 경우 virtual-guest 프로필을 사용합니다. 일반적으로 적용 가능한 throughput-performance 프로필을 기반으로 하지만 가상 메모리의 스왑도 감소합니다.
  • RHEL 9 가상화 호스트의 경우 virtual-host 프로필을 사용합니다. 이렇게 하면 더 공격적으로 더티 메모리 페이지의 쓰기를 수행할 수 있으므로 호스트 성능이 향상됩니다.

사전 요구 사항

절차

특정 TuneD 프로필을 활성화하려면 다음을 수행합니다.

  1. 사용 가능한 TuneD 프로필을 나열합니다.

    # tuned-adm list
    
    Available profiles:
    - balanced             - General non-specialized TuneD profile
    - desktop              - Optimize for the desktop use-case
    [...]
    - virtual-guest        - Optimize for running inside a virtual guest
    - virtual-host         - Optimize for running KVM guests
    Current active profile: balanced
  2. 선택 사항:TuneD 프로필을 생성하거나 기존 TuneD 프로필을 편집합니다.

    자세한 내용은 TuneD 프로필 사용자 지정을 참조하십시오.

  3. TuneD 프로필을 활성화합니다.

    # tuned-adm profile selected-profile
    • 가상화 호스트를 최적화하려면 virtual-host 프로필을 사용합니다.

      # tuned-adm profile virtual-host
    • RHEL 게스트 운영 체제에서 virtual-guest 프로필을 사용합니다.

      # tuned-adm profile virtual-guest

13.3. libvirt 데몬 최적화

libvirt 가상화 제품군은 RHEL 하이퍼바이저의 관리 계층으로 작동하며 libvirt 구성이 가상화 호스트에 큰 영향을 미칩니다. 특히 RHEL 9에는 두 가지 유형의 libvirt 데몬, 모놀리식 또는 모듈식이 포함되어 있으며 사용하는 데몬 유형이 개별 가상화 드라이버를 구성하는 방법에 미치는 영향에 영향을 미칩니다.

13.3.1. libvirt 데몬 유형

RHEL 9는 다음과 같은 libvirt 데몬 유형을 지원합니다.

모놀리식 libvirt

기존 libvirt 데몬인 libvirtd 는 단일 구성 파일인 /etc/libvirt/libvirtd.conf 를 사용하여 다양한 가상화 드라이버를 제어합니다.

따라서 libvirtd 는 중앙 집중식 하이퍼바이저 구성을 허용하지만 시스템 리소스를 효율적으로 사용할 수 있습니다. 따라서 libvirtd 는 향후 RHEL의 주요 릴리스에서 지원되지 않습니다.

그러나 RHEL 8에서 RHEL 9로 업데이트한 경우에도 호스트는 기본적으로 libvirtd 를 사용합니다.

모듈식 libvirt

RHEL 9에 새로 도입된 모듈식 libvirt 는 각 가상화 드라이버에 대해 특정 데몬을 제공합니다. 여기에는 다음이 포함됩니다.

  • virtqemud - 하이퍼바이저 관리를 위한 기본 데몬
  • virtinterfaced - 호스트 NIC 관리를 위한 보조 데몬
  • virtnetworkd - 가상 네트워크 관리를 위한 보조 데몬
  • virtnodedevd - 호스트 물리적 장치 관리를 위한 보조 데몬
  • virtnwfilterd - 호스트 방화벽 관리를 위한 보조 데몬
  • virtsecretd - 호스트 보안 관리를 위한 보조 데몬
  • virtstoraged - 스토리지 관리를 위한 보조 데몬

각 데몬에는 별도의 구성 파일(예: /etc/libvirt/virtqemud.conf )이 있습니다. 따라서 모듈식 libvirt 데몬은 libvirt 리소스 관리를 세부적으로 조정할 수 있는 더 나은 옵션을 제공합니다.

RHEL 9 새로 설치를 수행한 경우 모듈식 libvirt 가 기본적으로 구성됩니다.

다음 단계

  • RHEL 9에서 libvirtd 를 사용하는 경우 Red Hat은 모듈식 데몬으로 전환하는 것이 좋습니다. 자세한 내용은 모듈식 libvirt 데몬 활성화를 참조하십시오.

13.3.2. 모듈식 libvirt 데몬 활성화

RHEL 9에서 libvirt 라이브러리는 호스트의 개별 가상화 드라이버 세트를 처리하는 모듈식 데몬을 사용합니다. 예를 들어 virtqemud 데몬은 QEMU 드라이버를 처리합니다.

RHEL 9 호스트 새로 설치를 수행한 경우 하이퍼바이저는 기본적으로 모듈식 libvirt 데몬을 사용합니다. 그러나 호스트를 RHEL 8에서 RHEL 9로 업그레이드하는 경우 하이퍼바이저는 RHEL 8의 기본값인 모놀리식 libvirtd 데몬을 사용합니다.

이러한 경우 libvirt 리소스 관리를 세밀하게 조정할 수 있는 더 나은 옵션을 제공하기 때문에 대신 모듈식 libvirt 데몬을 활성화하는 것이 좋습니다. 또한 libvirtd 는 향후 RHEL의 주요 릴리스에서 지원되지 않습니다.

사전 요구 사항

  • 하이퍼바이저는 모놀리식 libvirtd 서비스를 사용합니다.

    # systemctl is-active libvirtd.service
    active

    이 명령이 활성 으로 표시되면 libvirtd 를 사용합니다.

  • 가상 머신이 종료되었습니다.

절차

  1. libvirtd 및 해당 소켓을 중지합니다.

    $ systemctl stop libvirtd.service
    $ systemctl stop libvirtd{,-ro,-admin,-tcp,-tls}.socket
  2. libvirtd 를 비활성화하여 부팅 시 시작되지 않도록 합니다.

    $ systemctl disable libvirtd.service
    $ systemctl disable libvirtd{,-ro,-admin,-tcp,-tls}.socket
  3. 모듈식 libvirt 데몬을 활성화합니다.

    # for drv in qemu interface network nodedev nwfilter secret storage; do systemctl unmask virt${drv}d.service; systemctl unmask virt${drv}d{,-ro,-admin}.socket; systemctl enable virt${drv}d.service; systemctl enable virt${drv}d{,-ro,-admin}.socket; done
  4. 모듈식 데몬의 소켓을 시작합니다.

    # for drv in qemu network nodedev nwfilter secret storage; do systemctl start virt${drv}d{,-ro,-admin}.socket; done
  5. 선택 사항: 원격 호스트에서 호스트에 연결해야 하는 경우 가상화 프록시 데몬을 활성화하고 시작합니다.

    1. 시스템에서 libvirtd-tls.socket 서비스가 활성화되어 있는지 확인합니다.

      # grep listen_tls /etc/libvirt/libvirtd.conf
      
      listen_tls = 0
    2. libvirtd-tls.socket 이 활성화되지 않은 경우(listen_tls = 0) virtproxyd 를 다음과 같이 활성화합니다.

      # systemctl unmask virtproxyd.service
      # systemctl unmask virtproxyd{,-ro,-admin}.socket
      # systemctl enable virtproxyd.service
      # systemctl enable virtproxyd{,-ro,-admin}.socket
      # systemctl start virtproxyd{,-ro,-admin}.socket
    3. libvirtd-tls.socket 이 활성화되면(listen_tls = 1) virtproxyd 를 다음과 같이 활성화합니다.

      # systemctl unmask virtproxyd.service
      # systemctl unmask virtproxyd{,-ro,-admin,-tls}.socket
      # systemctl enable virtproxyd.service
      # systemctl enable virtproxyd{,-ro,-admin,-tls}.socket
      # systemctl start virtproxyd{,-ro,-admin,-tls}.socket

      virtproxyd 의 TLS 소켓을 활성화하려면 호스트에 libvirt 와 작동하도록 TLS 인증서가 구성되어 있어야 합니다. 자세한 내용은 Upstream libvirt 설명서 를 참조하십시오.

검증

  1. 활성화된 가상화 데몬을 활성화합니다.

    # virsh uri
    qemu:///system
  2. 호스트가 virtqemud 모듈식 데몬을 사용하고 있는지 확인합니다.

    # systemctl is-active virtqemud.service
    active

    상태가 활성 상태인 경우 모듈식 libvirt 데몬이 성공적으로 활성화되었습니다.

13.4. 가상 머신 메모리 구성

VM(가상 머신)의 성능을 개선하기 위해 VM에 추가 호스트 RAM을 할당할 수 있습니다. 마찬가지로 VM에 할당된 메모리 양을 감소시켜 호스트 메모리를 다른 VM 또는 작업에 할당할 수 있습니다.

이러한 작업을 수행하려면 웹 콘솔 또는 명령줄 인터페이스를 사용할 수 있습니다.

13.4.1. 웹 콘솔을 사용하여 가상 머신 메모리 추가 및 제거

VM(가상 머신)의 성능을 개선하거나 사용 중인 호스트 리소스를 확보하기 위해 웹 콘솔을 사용하여 VM에 할당된 메모리 양을 조정할 수 있습니다.

사전 요구 사항

  • 게스트 OS는 메모리 balloon 드라이버를 실행하고 있습니다. 이 경우를 확인하려면 다음을 수행하십시오.

    1. VM 구성에 memballoon 장치가 포함되어 있는지 확인합니다.

      # virsh dumpxml testguest | grep memballoon
      <memballoon model='virtio'>
          </memballoon>

      이 명령이 모든 출력을 표시하고 모델이 none 으로 설정되지 않은 경우 memballoon 장치가 있습니다.

    2. 게스트 OS에서 balloon 드라이버가 실행 중인지 확인합니다.

      • Windows 게스트에서 드라이버는 virtio-win 드라이버 패키지의 일부로 설치됩니다. 자세한 내용은 Windows 가상 머신용 반가상화 KVM 드라이버 설치를 참조하십시오.
      • Linux 게스트에서는 일반적으로 드라이버가 기본적으로 포함되어 있으며 memballoon 장치가 있을 때 활성화됩니다.
  • 웹 콘솔 VM 플러그인이 시스템에 설치되어 있습니다.

절차

  1. 선택 사항: 최대 메모리 및 VM에 현재 사용된 메모리에 대한 정보를 획득합니다. 이는 변경 사항에 대한 기준선 역할을 하고 확인을 위한 역할을 합니다.

    # virsh dominfo testguest
    Max memory:     2097152 KiB
    Used memory:    2097152 KiB
  2. 가상 머신 인터페이스에서 정보를 확인할 VM을 클릭합니다.

    선택한 VM 및 콘솔 섹션에 대한 기본 정보가 포함된 개요 섹션이 있는 새 페이지가 열리고 VM의 그래픽 인터페이스에 액세스합니다.

  3. 개요 창에서 Memory 행 옆에 있는 편집 을 클릭합니다.

    메모리 조정 대화 상자가 표시됩니다.

    VM 메모리 조정 대화 상자를 표시하는 이미지입니다.
  4. 선택한 VM의 가상 CPU를 구성합니다.

    • 최대 할당 - VM에서 프로세스에 사용할 수 있는 최대 호스트 메모리 양을 설정합니다. VM을 생성할 때 최대 메모리를 지정하거나 나중에 늘릴 수 있습니다. 메모리를 다수의 MiB 또는 GiB로 지정할 수 있습니다.

      최대 메모리 할당 조정은 종료된 VM에서만 가능합니다.

    • 현재 할당 - VM에 할당된 실제 메모리 양을 설정합니다. 이 값은 최대 할당보다 작을 수 있지만 초과할 수는 없습니다. 해당 프로세스에 대해 VM에서 사용할 수 있는 메모리를 규제하도록 값을 조정할 수 있습니다. 메모리를 다수의 MiB 또는 GiB로 지정할 수 있습니다.

      이 값을 지정하지 않으면 기본 할당은 최대 할당 값입니다.

  5. 저장을 클릭합니다.

    VM의 메모리 할당이 조정됩니다.

13.4.2. 명령줄 인터페이스를 사용하여 가상 머신 메모리 추가 및 제거

VM(가상 머신)의 성능을 개선하거나 사용 중인 호스트 리소스를 확보하기 위해 CLI를 사용하여 VM에 할당된 메모리 양을 조정할 수 있습니다.

사전 요구 사항

  • 게스트 OS는 메모리 balloon 드라이버를 실행하고 있습니다. 이 경우를 확인하려면 다음을 수행하십시오.

    1. VM 구성에 memballoon 장치가 포함되어 있는지 확인합니다.

      # virsh dumpxml testguest | grep memballoon
      <memballoon model='virtio'>
          </memballoon>

      이 명령이 모든 출력을 표시하고 모델이 none 으로 설정되지 않은 경우 memballoon 장치가 있습니다.

    2. 게스트 OS에서 ballon 드라이버가 실행 중인지 확인합니다.

      • Windows 게스트에서 드라이버는 virtio-win 드라이버 패키지의 일부로 설치됩니다. 자세한 내용은 Windows 가상 머신용 반가상화 KVM 드라이버 설치를 참조하십시오.
      • Linux 게스트에서는 일반적으로 드라이버가 기본적으로 포함되어 있으며 memballoon 장치가 있을 때 활성화됩니다.

절차

  1. 선택 사항: 최대 메모리 및 VM에 현재 사용된 메모리에 대한 정보를 획득합니다. 이는 변경 사항에 대한 기준선 역할을 하고 확인을 위한 역할을 합니다.

    # virsh dominfo testguest
    Max memory:     2097152 KiB
    Used memory:    2097152 KiB
  2. VM에 할당된 최대 메모리를 조정합니다. 이 값을 늘리면 VM의 성능 가능성이 향상되고, VM이 호스트에 있는 성능 풋프린트를 줄일 수 있습니다. 이 변경 사항은 종료된 VM에서만 수행할 수 있으므로 실행 중인 VM을 조정하는 작업을 적용하려면 재부팅이 필요합니다.

    예를 들어 testguest VM에서 사용할 수 있는 최대 메모리를 4096MiB로 변경하려면 다음을 수행합니다.

    # virt-xml testguest --edit --memory memory=4096,currentMemory=4096
    Domain 'testguest' defined successfully.
    Changes will take effect after the domain is fully powered off.

    실행 중인 VM의 최대 메모리를 늘리려면 메모리 장치를 VM에 연결할 수 있습니다. 이를 메모리 핫 플러그 라고도 합니다. 자세한 내용은 가상 머신에 장치 연결을 참조하십시오.

    주의

    실행 중인 VM(메모리 핫 언플러그라고도 함)에서 메모리 장치를 제거하는 것은 지원되지 않으며 Red Hat은 크게 권장되지 않습니다.

  3. 선택 사항: VM에서 현재 사용하는 메모리를 최대 할당까지 조정할 수도 있습니다. 이렇게 하면 최대 VM 할당을 변경하지 않고 다음 재부팅까지 VM에 있는 메모리 로드가 조정됩니다.

    # virsh setmem testguest --current 2048

검증

  1. VM에서 사용하는 메모리가 업데이트되었는지 확인합니다.

    # virsh dominfo testguest
    Max memory:     4194304 KiB
    Used memory:    2097152 KiB
  2. 선택 사항: 현재 VM 메모리를 조정한 경우 VM의 메모리 balloon 통계를 가져와 메모리 사용을 얼마나 효과적으로 조정할 수 있습니다.

     # virsh domstats --balloon testguest
    Domain: 'testguest'
      balloon.current=365624
      balloon.maximum=4194304
      balloon.swap_in=0
      balloon.swap_out=0
      balloon.major_fault=306
      balloon.minor_fault=156117
      balloon.unused=3834448
      balloon.available=4035008
      balloon.usable=3746340
      balloon.last-update=1587971682
      balloon.disk_caches=75444
      balloon.hugetlb_pgalloc=0
      balloon.hugetlb_pgfail=0
      balloon.rss=1005456

13.4.3. virtio-mem을 사용하여 가상 머신 메모리 추가 및 제거

RHEL 9는 기술 프리뷰로 virtio-mem paravirtualized 메모리 장치를 제공합니다. virtio-mem 은 VM(가상 머신)에서 호스트 메모리를 동적으로 추가하거나 제거하는 데 사용할 수 있습니다. 예를 들어 이 장치를 사용하여 실행 중인 VM 간에 메모리 리소스를 이동하거나 현재 요구 사항에 따라 클라우드 설정에서 VM 메모리 크기를 조정할 수 있습니다.

중요

virtio-mem 은 RHEL 9에 기술 프리뷰로 포함되어 있으며 이는 지원되지 않습니다.

13.4.3.1. 사전 요구 사항

  • 호스트에는 Intel 64 또는 AMD64 CPU 아키텍처가 있습니다.
  • 호스트와 VM은 RHEL 9를 운영 체제로 사용합니다.

13.4.3.2. virtio-mem 개요

virtio-mem 은 VM(가상 머신)에서 호스트 메모리를 동적으로 추가하거나 제거하는 데 사용할 수 있는 반가상화 메모리 장치입니다. 예를 들어 이 장치를 사용하여 실행 중인 VM 간에 메모리 리소스를 이동하거나 현재 요구 사항에 따라 클라우드 설정에서 VM 메모리 크기를 조정할 수 있습니다.

virtio-mem 을 사용하면 VM의 메모리를 초기 크기 이상으로 늘리고 원래 크기로 다시 축소할 수 있으며 크기가 2~100MB(MiB)로 축소할 수 있습니다. 그러나 virtio-mem 은 특히 메모리를 안정적으로 연결 해제하기 위해 특정 게스트 운영 체제 구성에도 의존합니다.

중요

virtio-mem 은 RHEL 9에 기술 프리뷰로 포함되어 있으며 이는 지원되지 않습니다.

virtio-mem 기술 프리뷰 제한 사항

virtio-mem 은 현재 다음 기능과 호환되지 않습니다.

  • 호스트에서 메모리 사전 할당 사용
  • 호스트에서 HugePages 사용
  • 호스트에서 실시간 애플리케이션에 메모리 잠금 사용
  • 호스트에서 암호화된 가상화 사용
  • 호스트의 동적 메모리 메타데이터 할당
  • virtio-memmemballoon 인플레이션 및 호스트의 조각 결합
  • VM에서 virtio-mem 장치 연결 해제
  • VM에서 virtio_mem 드라이버를 언로드하거나 다시 로드
  • virtio_mem 드라이버가 로드된 VM 일시 중단 또는 일시 중단

가상 머신의 메모리 강화

실행 중인 RHEL VM(메모리 핫플러그라고도 함)에 메모리를 연결할 때 핫플러그 메모리를 VM 운영 체제의 온라인 상태로 설정해야 합니다. 그렇지 않으면 시스템이 메모리를 사용할 수 없습니다.

다음 표에는 사용 가능한 메모리 설정 중에서 선택할 때 고려해야 할 사항이 요약되어 있습니다.

표 13.1. 메모리 설정 비교

구성 이름VM에서 메모리 연결 해제메모리 영역의 불균형을 생성할 수 있는 위험잠재적 사용 사례의도된 워크로드의 메모리 요구 사항

online_movable

핫플러그 메모리는 안정적으로 연결 해제될 수 있습니다.

있음

비교적 적은 양의 메모리를 핫플러그

대부분의 사용자 공간 메모리

auto-movable

핫플러그 메모리의 이동 가능한 부분은 안정적으로 연결되지 않을 수 있습니다.

최소

대량의 메모리 핫플러그

대부분의 사용자 공간 메모리

online_kernel

핫플러그된 메모리는 안정적으로 연결 해제될 수 없습니다.

없음

신뢰할 수 없는 메모리 연결 해제가 허용됩니다.

사용자 공간 또는 커널 공간 메모리

영역의 불균형은 Linux 메모리 영역 중 하나에서 사용 가능한 메모리 페이지가 없다는 것입니다. 영역의 불균형은 시스템 성능에 부정적인 영향을 미칠 수 있습니다. 예를 들어, 불가능한 할당에 대해 사용 가능한 메모리가 부족하면 커널이 충돌할 수 있습니다. 일반적으로 이동 가능한 할당에는 대부분 사용자 공간 메모리 페이지가 포함되어 있으며 불가능한 할당에는 대부분 커널 공간 메모리 페이지가 포함됩니다.

메모리 튜닝 고려 사항에 대한 자세한 설명은 Onlining and Offlining Memory Blocks and Zone Imbalances를 참조하십시오.

13.4.3.3. 가상 머신에서 메모리 설정

virtio-mem 을 사용하여 실행 중인 가상 머신(메모리 핫플러그라고도 함)에 메모리를 연결하기 전에 가상 머신(VM) 운영 체제를 구성하여 핫플러그 메모리를 온라인 상태로 자동으로 설정해야 합니다. 그렇지 않으면 게스트 운영 체제가 추가 메모리를 사용할 수 없습니다. 메모리 설정에 대해 다음 구성 중 하나를 선택할 수 있습니다.

  • online_movable
  • online_kernel
  • auto-movable

이러한 구성의 차이점에 대한 자세한 내용은 가상 머신의 메모리 강화를참조하십시오.

메모리 강화는 RHEL에서 기본적으로 udev 규칙으로 구성됩니다. 그러나 virtio-mem 을 사용하는 경우 커널에서 직접 메모리 부여를 구성하는 것이 좋습니다.

중요

virtio-mem 은 RHEL 9에 기술 프리뷰로 포함되어 있으며 이는 지원되지 않습니다.

사전 요구 사항

  • 호스트에는 Intel 64 또는 AMD64 CPU 아키텍처가 있습니다.
  • 호스트와 VM은 RHEL 9를 운영 체제로 사용합니다.

절차

  • VM에서 online_movable 구성을 사용하도록 메모리 설정:

    1. memhp_default_state 커널 명령행 매개변수를 online_movable:로 설정합니다.

      # grubby --update-kernel=ALL --remove-args=memhp_default_state --args=memhp_default_state=online_movable
    2. VM을 재부팅합니다.
  • VM에서 online_kernel 구성을 사용하도록 메모리 설정:

    1. memhp_default_state 커널 명령줄 매개 변수를 online_kernel:로 설정합니다.

      # grubby --update-kernel=ALL --remove-args=memhp_default_state --args=memhp_default_state=online_kernel
    2. VM을 재부팅합니다.
  • VM에서 자동 이동식 메모리 설정 정책을 사용하려면 다음을 수행합니다.

    1. memhp_default_state 커널 명령행 매개변수를 online 로 설정합니다.

      # grubby --update-kernel=ALL --remove-args=memhp_default_state --args=memhp_default_state=online
    2. memory_hotplug.online_policy 커널 명령줄 매개 변수를 auto-movable:로 설정합니다.

      # grubby --update-kernel=ALL --remove-args="memory_hotplug.online_policy" --args=memory_hotplug.online_policy=auto-movable
    3. 선택 사항: 자동 이동식 설정 정책을 추가로 조정하려면 memory_hotplug.auto_movable_ratiomemory_hotplug.auto_movable_numa_aware 매개변수를 변경합니다.

      # grubby --update-kernel=ALL --remove-args="memory_hotplug.auto_movable_ratio" --args=memory_hotplug.auto_movable_ratio=<percentage>
      
      # grubby --update-kernel=ALL --remove-args="memory_hotplug.memory_auto_movable_numa_aware" --args=memory_hotplug.auto_movable_numa_aware=<y/n>
      • memory_hotplug.auto_movable_ratio 매개변수는 모든 할당에 사용 가능한 메모리와 비교하여 이동 가능한 할당에만 사용할 수 있는 최대 메모리 비율을 설정합니다. 비율은 백분율로 표시되고 기본값은 301 (%)이며 이는 3 : 1 비율입니다.
      • memory_hotplug.auto_movable_numa_aware 매개변수는 memory_hotplug.auto_movable_ratio 매개변수가 모든 사용 가능한 NUMA 노드의 메모리에 적용되거나 단일 NUMA 노드 내의 메모리에만 적용되는지 여부를 제어합니다. 기본값은 y (yes)입니다.

        예를 들어, 최대 비율이 301%로 설정되고 memory_hotplug.auto_movable_numa_awarey (yes)로 설정된 경우, 연결된 virtio-mem 장치가 있는 NUMA 노드 내에서도 적용됩니다. 매개변수가 n (아니오)로 설정된 경우 최대 3:1 비율은 전체 NUMA 노드에만 적용됩니다.

        또한 비율이 초과되지 않은 경우 새로 핫플러그된 메모리는 이동 가능한 할당에만 사용할 수 있습니다. 그렇지 않으면 이동 가능 및 실행 불가능한 할당 모두에 새로 핫플러그된 메모리를 사용할 수 있습니다.

    4. VM을 재부팅합니다.

검증

  • online_movable 구성이 올바르게 설정되었는지 확인하려면 memhp_default_state 커널 매개변수의 현재 값을 확인합니다.

    # cat /sys/devices/system/memory/auto_online_blocks
    
    online_movable
  • online_kernel 구성이 올바르게 설정되었는지 확인하려면 memhp_default_state 커널 매개변수의 현재 값을 확인합니다.

    # cat /sys/devices/system/memory/auto_online_blocks
    
    online_kernel
  • 자동 이동식 구성이 올바르게 설정되었는지 확인하려면 다음 커널 매개변수를 확인합니다.

    • memhp_default_state:

      # cat /sys/devices/system/memory/auto_online_blocks
      
      online
    • memory_hotplug.online_policy:

      # cat /sys/module/memory_hotplug/parameters/online_policy
      
      auto-movable
    • memory_hotplug.auto_movable_ratio:

      # cat /sys/module/memory_hotplug/parameters/auto_movable_ratio
      
      301
    • memory_hotplug.auto_movable_numa_aware:

      # cat /sys/module/memory_hotplug/parameters/auto_movable_numa_aware
      
      y

13.4.3.4. 가상 머신에 virtio-mem 장치 연결

실행 중인 가상 시스템(메모리 핫플러그라고도 함)에 추가 메모리를 연결하고 핫플러그 메모리의 크기를 조정하려면 virtio-mem 장치를 사용할 수 있습니다. 특히 libvirt XML 구성 파일과 virsh 명령을 사용하여 virtio-mem 장치를 정의하고 VM(가상 머신)에 연결할 수 있습니다.

중요

virtio-mem 은 RHEL 9에 기술 프리뷰로 포함되어 있으며 이는 지원되지 않습니다.

사전 요구 사항

  • 호스트에는 Intel 64 또는 AMD64 CPU 아키텍처가 있습니다.
  • 호스트와 VM은 RHEL 9를 운영 체제로 사용합니다.
  • VM에 메모리 강화가 구성되어 있습니다. 자세한 내용은 가상 머신의 메모리 설정 구성을참조하십시오.

절차

  1. 대상 VM의 XML 구성에 maxMemory 매개변수가 포함되어 있는지 확인합니다.

    # virsh edit testguest1
    
    <domain type='kvm'>
      <name>testguest1</name>
      ...
      <maxMemory slots='2' unit='GiB'>128</maxMemory>
      ...
    </domain>

    이 예제에서 testguest1 VM의 XML 구성은 2개의 슬롯과 128GB(GiB) 크기의 maxMemory 매개변수를 정의합니다. maxMemory 크기는 VM에서 사용할 수 있는 최대 메모리를 지정합니다. 여기에는 초기 및 핫플러그된 메모리가 모두 포함됩니다. 현재는 연결된 각 virtio-mem 장치에 대해 하나의 슬롯을 예약해야 합니다.

  2. 대상 VM의 XML 구성에 하나 이상의 NUMA 노드가 정의되어 있는지 확인합니다. 예를 들면 다음과 같습니다.

    # virsh edit testguest1
    
    <domain type='kvm'>
      <name>testguest1</name>
      ...
      <vcpu placement='static'>8</vcpu>
      ...
      <cpu ...>
        <numa>
          <cell id='0' cpus='0-7' memory='16' unit='GiB'/>
        </numa>
      ...
    </domain>

    이 예에서는 초기 메모리가 16GiB인 하나의 NUMA 노드가 정의되고 testguest1 VM의 CPU 8개에 할당됩니다. VM에서 메모리 장치를 사용하려면 NUMA 노드가 하나 이상 정의되어 있어야 합니다.

  3. XML 파일을 생성하고 열어 호스트에 virtio-mem 장치를 정의합니다. 예를 들면 다음과 같습니다.

    # vim virtio-mem-device.xml
  4. virtio-mem 장치의 XML 정의를 파일에 추가하고 저장합니다.

    <memory model='virtio-mem'>
            <target>
                    <size unit='GiB'>48</size>
                    <node>0</node>
                    <block unit='MiB'>2</block>
                    <requested unit='GiB'>16</requested>
                    <current unit='GiB'>16</current>
            </target>
            <alias name='ua-virtiomem0'/>
            <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </memory>
    <memory model='virtio-mem'>
            <target>
                    <size unit='GiB'>48</size>
                    <node>1</node>
                    <block unit='MiB'>2</block>
                    <requested unit='GiB'>0</requested>
                    <current unit='GiB'>0</current>
            </target>
            <alias name='ua-virtiomem1'/>
            <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </memory>

    이 예에서는 두 개의 virtio-mem 장치는 다음 매개변수를 사용하여 정의됩니다.

    • size: 장치의 최대 크기입니다. 이 예제에서는 48GiB입니다. 크기는 블록 크기의 배수여야 합니다.
    • node: virtio-mem 장치에 할당된 vNUMA 노드입니다.
    • block: 장치의 블록 크기입니다. Intel 64 또는 AMD64 CPU 아키텍처에서는 최소 THP(Transparent Huge Page) 크기여야 합니다. Intel 64 또는 AMD64 아키텍처의 2MiB 블록 크기는 일반적으로 좋은 선택입니다. VFIO(가상 기능 I/O) 또는 중재 장치(mdev) 와 함께 virtio-mem 을 사용하는 경우 모든 virtio-mem 장치의 총 블록 수가 32768보다 크지 않아야 합니다. 그렇지 않으면 RAM 연결이 실패할 수 있습니다.
    • requested: virtio-mem 장치를 사용하여 VM에 연결하는 메모리 양입니다. 그러나 VM에 대한 요청일 뿐이며 VM이 올바르게 구성되지 않은 경우와 같이 성공적으로 해결되지 않을 수 있습니다. 요청된 크기는 블록 크기의 배수여야 하며 정의된 최대 크기를 초과할 수 없습니다.
    • Current: virtio-mem 장치가 VM에 제공하는 현재 크기를 나타냅니다. 현재 크기는 요청을 완료할 수 없거나 VM을 재부팅할 때와 같이 요청된 크기와 다를 수 있습니다.
    • alias: 이 별칭은 원하는 virtio-mem 장치를 지정하는 데 사용할 수 있는 선택적 사용자 정의 별칭입니다(예: libvirt 명령으로 장치를 편집할 때). libvirt의 모든 사용자 정의 별칭은 "ua-" 접두사로 시작해야 합니다.

      libvirt 는 이러한 특정 매개 변수 외에도 다른 PCI 장치와 마찬가지로 virtio-mem 장치를 처리합니다.

  5. XML 파일을 사용하여 정의된 virtio-mem 장치를 VM에 연결합니다. 예를 들어 virtio-mem-device.xml 에 정의된 두 장치를 실행 중인 testguest1 VM에 영구적으로 연결하려면 다음을 수행합니다.

    # virsh attach-device testguest1 virtio-mem-device.xml --live --config

    --live 옵션은 부팅 간 지속성 없이 실행 중인 VM에만 장치를 연결합니다. --config 옵션을 사용하면 구성을 영구적으로 변경합니다. --live 옵션 없이 시스템을 종료 VM에 연결할 수도 있습니다.

  6. 선택 사항: 실행 중인 VM에 연결된 virtio-mem 장치의 요청된 크기를 동적으로 변경하려면 virsh update-memory-device 명령을 사용합니다.

    # virsh update-memory-device testguest1 --alias ua-virtiomem0 --requested-size 4GiB

    이 예제에서는 다음을 수행합니다.

    • testguest1 은 업데이트할 VM입니다.
    • --alias ua-virtiomem0 은 이전에 정의된 별칭으로 지정된 virtio-mem 장치입니다.
    • --requested-size 4GiBvirtio-mem 장치의 요청된 크기를 4GiB로 변경합니다.

검증

  • VM에서 사용 가능한 RAM을 확인하고 총 크기에 핫플러그 메모리가 포함되어 있는지 확인합니다.

    # free -h
    
            total    used    free   shared  buff/cache   available
    Mem:    31Gi     5.5Gi   14Gi   1.3Gi   11Gi         23Gi
    Swap:   8.0Gi    0B      8.0Gi
    # numactl -H
    
    available: 1 nodes (0)
    node 0 cpus: 0 1 2 3 4 5 6 7
    node 0 size: 29564 MB
    node 0 free: 13351 MB
    node distances:
    node   0
      0:  10
  • 현재 플러그인 RAM 양은 실행 중인 VM의 XML 구성을 표시하여 호스트에서도 볼 수 있습니다.

    # virsh dumpxml testguest1
    
    <domain type='kvm'>
      <name>testguest1</name>
      ...
      <currentMemory unit='GiB'>31</currentMemory>
      ...
      <memory model='virtio-mem'>
          <target>
            <size unit='GiB'>48</size>
            <node>0</node>
            <block unit='MiB'>2</block>
            <requested unit='GiB'>16</requested>
            <current unit='GiB'>16</current>
          </target>
          <alias name='ua-virtiomem0'/>
          <address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x0'/>
      ...
    </domain>

    이 예제에서는 다음을 수행합니다.

    • < currentMemory unit='GiB'>31</currentMemory >은 모든 소스의 VM에서 사용 가능한 총 RAM을 나타냅니다.
    • <current unit='GiB'>16</current >는 virtio-mem 장치에서 제공하는 플러그인 RAM의 현재 크기를 나타냅니다.

13.4.4. 추가 리소스

  • 장치를 가상 머신에 연결하는 가상 머신에 장치 연결.

13.5. 가상 머신 I/O 성능 최적화

VM(가상 머신)의 입력 및 출력(I/O) 기능은 VM의 전반적인 효율성을 크게 제한할 수 있습니다. 이를 해결하기 위해 블록 I/O 매개변수를 구성하여 VM의 I/O를 최적화할 수 있습니다.

13.5.1. 가상 머신에서 블록 I/O 튜닝

하나 이상의 VM에서 여러 블록 장치를 사용하는 경우 I/O 가중치 를 수정하여 특정 가상 장치의 I/O 우선 순위를 조정하는 것이 중요할 수 있습니다.

장치의 I/O 가중치를 늘리면 I/O 대역폭에 대한 우선 순위가 증가하므로 더 많은 호스트 리소스가 제공됩니다. 마찬가지로 장치의 가중치를 줄이면 호스트 리소스를 적게 사용합니다.

참고

각 장치의 가중치 값은 100 ~1000 범위 내에 있어야 합니다. 또는 값은 0 일 수 있으며 장치별 목록에서 해당 장치를 제거할 수 있습니다.

절차

VM의 블록 I/O 매개변수를 표시하고 설정하려면 다음을 수행합니다.

  1. VM의 현재 & lt;blkio > 매개변수를 표시합니다.

    # virsh dumpxml VM-name

    <domain>
      [...]
      <blkiotune>
        <weight>800</weight>
        <device>
          <path>/dev/sda</path>
          <weight>1000</weight>
        </device>
        <device>
          <path>/dev/sdb</path>
          <weight>500</weight>
        </device>
      </blkiotune>
      [...]
    </domain>
  2. 지정된 장치의 I/O 가중치를 편집합니다.

    # virsh blkiotune VM-name --device-weights device, I/O-weight

    예를 들어, 다음에서는 리프트 VM의 /dev/sda 장치의 가중치를 500으로 변경합니다.

    # virsh blkiotune liftbrul --device-weights /dev/sda, 500

13.5.2. 가상 머신에서 디스크 I/O 제한

여러 VM이 동시에 실행되는 경우 과도한 디스크 I/O를 사용하여 시스템 성능을 방해할 수 있습니다. KVM 가상화의 디스크 I/O 제한을 사용하면 VM에서 호스트 시스템으로 전송된 디스크 I/O 요청에 제한을 설정할 수 있습니다. 이를 통해 VM이 공유 리소스를 과도하게 활용하는 것을 방지하고 다른 VM의 성능에 영향을 미칠 수 있습니다.

디스크 I/O 제한을 활성화하려면 VM에 연결된 각 블록 장치에서 호스트 시스템에 전송된 디스크 I/O 요청 제한을 설정합니다.

절차

  1. virsh domblklist 명령을 사용하여 지정된 VM에 있는 모든 디스크 장치의 이름을 나열합니다.

    # virsh domblklist rollin-coal
    Target     Source
    ------------------------------------------------
    vda        /var/lib/libvirt/images/rollin-coal.qcow2
    sda        -
    sdb        /home/horridly-demanding-processes.iso
  2. 추적할 가상 디스크가 마운트된 호스트 블록 장치를 찾습니다.

    예를 들어 이전 단계에서 sdb 가상 디스크를 제한하려는 경우 다음 출력에서는 디스크가 /dev/nvme0n1p3 파티션에 마운트되었음을 보여줍니다.

    $ lsblk
    NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
    zram0                                         252:0    0     4G  0 disk  [SWAP]
    nvme0n1                                       259:0    0 238.5G  0 disk
    ├─nvme0n1p1                                   259:1    0   600M  0 part  /boot/efi
    ├─nvme0n1p2                                   259:2    0     1G  0 part  /boot
    └─nvme0n1p3                                   259:3    0 236.9G  0 part
      └─luks-a1123911-6f37-463c-b4eb-fxzy1ac12fea 253:0    0 236.9G  0 crypt /home
  3. virsh blkiotune 명령을 사용하여 블록 장치의 I/O 제한을 설정합니다.

    # virsh blkiotune VM-name --parameter device,limit

    다음 예제에서는 Rollin-coal VM의 sdb 디스크를 초당 1000개의 읽기 및 쓰기 I/O 작업과 초당 50MB 읽기 및 쓰기 처리량을 제한합니다.

    # virsh blkiotune rollin-coal --device-read-iops-sec /dev/nvme0n1p3,1000 --device-write-iops-sec /dev/nvme0n1p3,1000 --device-write-bytes-sec /dev/nvme0n1p3,52428800 --device-read-bytes-sec /dev/nvme0n1p3,52428800

추가 정보

  • 디스크 I/O 제한은 여러 고객에 속한 VM이 동일한 호스트에서 실행 중이거나 다른 VM에 대해 서비스 품질 보장이 제공되는 경우와 같이 다양한 상황에서 유용할 수 있습니다. 디스크 I/O 제한을 사용하여 느린 디스크를 시뮬레이션할 수도 있습니다.
  • I/O 제한은 VM에 연결된 각 블록 장치에 독립적으로 적용할 수 있으며 처리량 및 I/O 작업에 대한 제한을 지원합니다.
  • Red Hat은 VM에서 I/O 제한을 설정하기 위해 virsh blkdeviotune 명령을 사용하는 것을 지원하지 않습니다. RHEL 9를 VM 호스트로 사용할 때 지원되지 않는 기능에 대한 자세한 내용은 RHEL 9 가상화에서 지원되지 않는 기능을 참조하십시오.

13.5.3. 다중 대기열 virtio-scsi 활성화

VM(가상 머신)에서 virtio-scsi 스토리지 장치를 사용하는 경우 다중 대기열 virtio-scsi 기능은 향상된 스토리지 성능과 확장성을 제공합니다. 이를 통해 각 가상 CPU(vCPU)는 다른 vCPU에 영향을 주지 않고 별도의 대기열과 인터럽트를 사용할 수 있습니다.

절차

  • 특정 VM에 대해 다중 대기열 virtio-scsi 지원을 활성화하려면 VM의 XML 구성에 다음을 추가합니다. 여기서 N 은 총 vCPU 대기열 수입니다.

    <controller type='scsi' index='0' model='virtio-scsi'>
       <driver queues='N' />
    </controller>

13.6. 가상 머신 CPU 성능 최적화

호스트 시스템의 물리적 CPU와 마찬가지로 vCPU는 VM(가상 머신) 성능에 매우 중요합니다. 따라서 vCPU 최적화는 VM의 리소스 효율성에 상당한 영향을 미칠 수 있습니다. vCPU를 최적화하려면 다음을 수행합니다.

  1. VM에 할당되는 호스트 CPU 수를 조정합니다. CLI 또는 웹 콘솔 을 사용하여 이 작업을 수행할 수 있습니다.
  2. vCPU 모델이 호스트의 CPU 모델에 맞게 조정되었는지 확인합니다. 예를 들어, 호스트의 CPU 모델을 사용하도록 testguest1 VM을 설정하려면 다음을 수행합니다.

    # virt-xml testguest1 --edit --cpu host-model
  3. 커널 동일한 페이지 병합(KSM)을 관리합니다.
  4. 호스트 시스템에서 NUMA(Non-Uniform Memory Access)를 사용하는 경우 해당 VM에 대해 NUMA를 구성할 수도 있습니다. 이렇게 하면 호스트의 CPU 및 메모리 프로세스가 VM의 CPU 및 메모리 프로세스에 최대한 밀접하게 매핑됩니다. 실제로 NUMA 튜닝은 vCPU에 할당된 시스템 메모리에 보다 간소화된 액세스를 제공하여 vCPU 처리 효율성을 향상시킬 수 있습니다.

    자세한 내용은 가상 머신의 NUMA 구성Sample vCPU 성능 튜닝 시나리오를 참조하십시오.

13.6.1. 명령줄 인터페이스를 사용하여 가상 CPU 추가 및 제거

VM(가상 머신)의 CPU 성능을 늘리거나 최적화하기 위해 VM에 할당된 가상 CPU(vCPU)를 추가하거나 제거할 수 있습니다.

실행 중인 VM에서 수행할 때 이 작업을 vCPU 핫 플러그링 및 핫 플러그 연결이라고도 합니다. 그러나 RHEL 9에서는 vCPU 핫 언플러그가 지원되지 않으며 Red Hat은 사용하지 않는 것이 좋습니다.

사전 요구 사항

  • 선택 사항: 대상 VM에서 vCPU의 현재 상태를 확인합니다. 예를 들어 testguest VM에 vCPU 수를 표시하려면 다음을 수행합니다.

    # virsh vcpucount testguest
    maximum      config         4
    maximum      live           2
    current      config         2
    current      live           1

    이 출력은 현재 testguest 가 1 vCPU를 사용하고 있으며 VM 성능을 높이기 위해 1개의 vCPu를 핫 플러그로 연결할 수 있음을 나타냅니다. 그러나 재부팅 후 testguest 의 수는 2로 변경되며 두 개의 vCPU를 핫 플러그로 변경할 수 있습니다.

절차

  1. VM에 연결할 수 있는 최대 vCPU 수를 조정하여 VM의 다음 부팅에 적용됩니다.

    예를 들어 testguest VM의 최대 vCPU 수를 8로 늘리려면 다음을 수행합니다.

    # virsh setvcpus testguest 8 --maximum --config

    CPU 토폴로지, 호스트 하드웨어, 하이퍼바이저 및 기타 요인에 의해 최대값이 제한될 수 있습니다.

  2. VM에 연결된 현재 vCPU 수를 이전 단계에서 구성한 최대값까지 조정합니다. 예를 들어 다음과 같습니다.

    • 실행 중인 testguest VM에 연결된 vCPU 수를 4로 늘리려면 다음을 수행합니다.

      # virsh setvcpus testguest 4 --live

      이렇게 하면 VM의 다음 부팅이 될 때까지 VM의 성능 및 호스트 로드 공간이 testguest 의 성능 및 호스트 로드가 증가합니다.

    • testguest VM에 연결된 vCPU 수를 1로 영구적으로 줄입니다.

      # virsh setvcpus testguest 1 --config

      이렇게 하면 VM의 다음 부팅 후 VM의 성능 및 호스트 로드 풋프린트가 감소됩니다. 하지만 필요한 경우 추가 vCPU를 VM에 핫 플러그하여 일시적으로 성능을 향상시킬 수 있습니다.

검증

  • VM의 현재 vCPU 상태가 변경 사항을 반영하는지 확인합니다.

    # virsh vcpucount testguest
    maximum      config         8
    maximum      live           4
    current      config         1
    current      live           4

13.6.2. 웹 콘솔을 사용하여 가상 CPU 관리

RHEL 9 웹 콘솔을 사용하면 웹 콘솔이 연결된 VM(가상 머신)에서 사용하는 가상 CPU를 검토하고 구성할 수 있습니다.

사전 요구 사항

절차

  1. 가상 머신 인터페이스에서 정보를 확인할 VM을 클릭합니다.

    선택한 VM 및 콘솔 섹션에 대한 기본 정보가 포함된 개요 섹션이 있는 새 페이지가 열리고 VM의 그래픽 인터페이스에 액세스합니다.

  2. 개요 창에서 vCPU 수 옆에 있는 편집 을 클릭합니다.

    vCPU 세부 정보 대화 상자가 나타납니다.

    VM CPU 세부 정보 대화 상자를 표시하는 이미지입니다.
  1. 선택한 VM의 가상 CPU를 구성합니다.

    • vCPU 수 - 현재 사용 중인 vCPU 수입니다.

      참고

      vCPU 수는 vCPU 최대값보다 클 수 없습니다.

    • vCPU 최대 - VM에 대해 구성할 수 있는 가상 CPU의 최대 수입니다. 이 값이 vCPU 개수보다 높으면 추가 vCPU 를 VM에 연결할 수 있습니다.
    • sockets - VM에 노출하는 소켓 수입니다.
    • 코어당 코어 수 - VM에 노출하는 각 소켓의 코어 수입니다.
    • 코어당 스레드 수 - VM에 노출될 각 코어의 스레드 수입니다.

      소켓,소켓당 코어 수 및 코어 옵션당 스레드 는 VM의 CPU 토폴로지를 조정합니다. 이는 vCPU 성능에 유용할 수 있으며 게스트 OS에서 특정 소프트웨어의 기능에 영향을 미칠 수 있습니다. 배포에 다른 설정이 필요하지 않은 경우 기본값을 유지합니다.

  2. 적용을 클릭합니다.

    VM의 가상 CPU가 구성됩니다.

    참고

    가상 CPU 설정 변경 사항은 VM을 재시작한 후에만 적용됩니다.

13.6.3. 가상 머신에서 NUMA 구성

다음 방법을 사용하여 RHEL 9 호스트에서 가상 머신(VM)의 NUMA(Non-Uniform Memory Access) 설정을 구성할 수 있습니다.

사전 요구 사항

  • 호스트는 NUMA 호환 시스템입니다. 대소문자를 감지하려면 virsh nodeinfo 명령을 사용하여 NUMA 셀 을 확인합니다.

    # virsh nodeinfo
    CPU model:           x86_64
    CPU(s):              48
    CPU frequency:       1200 MHz
    CPU socket(s):       1
    Core(s) per socket:  12
    Thread(s) per core:  2
    NUMA cell(s):        2
    Memory size:         67012964 KiB

    행 값이 2 이상인 경우 호스트는 NUMA와 호환됩니다.

절차

사용하기 쉽도록 자동화된 유틸리티 및 서비스를 사용하여 VM의 NUMA 구성을 설정할 수 있습니다. 그러나 수동 NUMA 설정은 성능이 크게 향상될 가능성이 높습니다.

자동 방법

  • VM의 NUMA 정책을 Preferred 로 설정합니다. 예를 들어 testguest5 VM에 대해 이렇게 하려면 다음을 수행합니다.

    # virt-xml testguest5 --edit --vcpus placement=auto
    # virt-xml testguest5 --edit --numatune mode=preferred
  • 호스트에서 자동 NUMA 분산을 활성화합니다.

    # echo 1 > /proc/sys/kernel/numa_balancing
  • numad 서비스를 시작하여 VM CPU를 메모리 리소스에 자동으로 조정합니다.

    # systemctl start numad

수동 방법

  1. 특정 vCPU 스레드를 특정 호스트 CPU 또는 CPU 범위에 고정합니다. 이는 NUMA 이외의 호스트 및 VM에서도 가능하며 안전한 vCPU 성능 향상 방법으로 권장됩니다.

    예를 들어 다음 명령은 vCPU 스레드 0~5를 testguest6 VM의 호스트 CPU 1, 3, 5, 7, 9, 11에 고정합니다.

    # virsh vcpupin testguest6 0 1
    # virsh vcpupin testguest6 1 3
    # virsh vcpupin testguest6 2 5
    # virsh vcpupin testguest6 3 7
    # virsh vcpupin testguest6 4 9
    # virsh vcpupin testguest6 5 11

    그런 다음 이것이 성공했는지 확인할 수 있습니다.

    # virsh vcpupin testguest6
    VCPU   CPU Affinity
    ----------------------
    0      1
    1      3
    2      5
    3      7
    4      9
    5      11
  2. vCPU 스레드를 고정한 후 지정된 VM과 연결된 QEMU 프로세스 스레드를 특정 호스트 CPU 또는 CPU 범위에 고정할 수도 있습니다. 예를 들어 다음 명령은 testguest6 의 QEMU 프로세스 스레드를 CPU 13 및 15에 고정하고 성공적으로 완료되었는지 확인합니다.

    # virsh emulatorpin testguest6 13,15
    # virsh emulatorpin testguest6
    emulator: CPU Affinity
    ----------------------------------
           *: 13,15
  3. 마지막으로 특정 VM에 구체적으로 할당할 호스트 NUMA 노드를 지정할 수도 있습니다. 이를 통해 VM의 vCPU에 의해 호스트 메모리 사용량을 개선할 수 있습니다. 예를 들어 다음 명령은 호스트 NUMA 노드 3을 5로 사용하도록 testguest6 를 설정하고 성공적인지 확인합니다.

    # virsh numatune testguest6 --nodeset 3-5
    # virsh numatune testguest6
참고

최상의 성능 결과를 얻으려면 위에 나열된 수동 튜닝 방법을 모두 사용하는 것이 좋습니다.

추가 리소스

13.6.4. 샘플 vCPU 성능 튜닝 시나리오

가능한 한 최상의 vCPU 성능을 얻으려면 다음 시나리오와 같이 수동 vcpupin,emulatorpinnumatune 설정을 함께 사용하는 것이 좋습니다.

시작 시나리오

  • 호스트에는 다음과 같은 하드웨어 관련 사항이 있습니다.

    • NUMA 노드 2개
    • 각 노드의 CPU 코어 3개
    • 각 코어의 2개 스레드

    이러한 머신의 virsh nodeinfo 출력은 다음과 유사합니다.

    # virsh nodeinfo
    CPU model:           x86_64
    CPU(s):              12
    CPU frequency:       3661 MHz
    CPU socket(s):       2
    Core(s) per socket:  3
    Thread(s) per core:  2
    NUMA cell(s):        2
    Memory size:         31248692 KiB
  • 기존 VM을 8개의 vCPU를 사용하도록 수정하려고 합니다. 즉, 단일 NUMA 노드에 맞지 않습니다.

    따라서 각 NUMA 노드에 4개의 vCPU를 배포하고 vCPU 토폴로지를 호스트 토폴로지와 최대한 가깝게 만들어야 합니다. 즉, 지정된 물리적 CPU의 형제 스레드로 실행되는 vCPU를 동일한 코어의 호스트 스레드에 고정해야 합니다. 자세한 내용은 아래 솔루션을 참조하십시오.

해결책

  1. 호스트 토폴로지에 대한 정보를 가져옵니다.

    # virsh capabilities

    출력에는 다음과 유사한 섹션이 포함되어야 합니다.

    <topology>
      <cells num="2">
        <cell id="0">
          <memory unit="KiB">15624346</memory>
          <pages unit="KiB" size="4">3906086</pages>
          <pages unit="KiB" size="2048">0</pages>
          <pages unit="KiB" size="1048576">0</pages>
          <distances>
            <sibling id="0" value="10" />
            <sibling id="1" value="21" />
          </distances>
          <cpus num="6">
            <cpu id="0" socket_id="0" core_id="0" siblings="0,3" />
            <cpu id="1" socket_id="0" core_id="1" siblings="1,4" />
            <cpu id="2" socket_id="0" core_id="2" siblings="2,5" />
            <cpu id="3" socket_id="0" core_id="0" siblings="0,3" />
            <cpu id="4" socket_id="0" core_id="1" siblings="1,4" />
            <cpu id="5" socket_id="0" core_id="2" siblings="2,5" />
          </cpus>
        </cell>
        <cell id="1">
          <memory unit="KiB">15624346</memory>
          <pages unit="KiB" size="4">3906086</pages>
          <pages unit="KiB" size="2048">0</pages>
          <pages unit="KiB" size="1048576">0</pages>
          <distances>
            <sibling id="0" value="21" />
            <sibling id="1" value="10" />
          </distances>
          <cpus num="6">
            <cpu id="6" socket_id="1" core_id="3" siblings="6,9" />
            <cpu id="7" socket_id="1" core_id="4" siblings="7,10" />
            <cpu id="8" socket_id="1" core_id="5" siblings="8,11" />
            <cpu id="9" socket_id="1" core_id="3" siblings="6,9" />
            <cpu id="10" socket_id="1" core_id="4" siblings="7,10" />
            <cpu id="11" socket_id="1" core_id="5" siblings="8,11" />
          </cpus>
        </cell>
      </cells>
    </topology>
  2. 선택 사항: 해당 도구 및 유틸리티 를 사용하여 VM의 성능을 테스트합니다.
  3. 호스트에서 1GiB 대규모 페이지를 설정하고 마운트합니다.

    1. 호스트의 커널 명령줄에 다음 행을 추가합니다.

      default_hugepagesz=1G hugepagesz=1G
    2. 다음 콘텐츠를 사용하여 /etc/systemd/system/hugetlb-gigantic-pages.service 파일을 만듭니다.

      [Unit]
      Description=HugeTLB Gigantic Pages Reservation
      DefaultDependencies=no
      Before=dev-hugepages.mount
      ConditionPathExists=/sys/devices/system/node
      ConditionKernelCommandLine=hugepagesz=1G
      
      [Service]
      Type=oneshot
      RemainAfterExit=yes
      ExecStart=/etc/systemd/hugetlb-reserve-pages.sh
      
      [Install]
      WantedBy=sysinit.target
    3. 다음 콘텐츠를 사용하여 /etc/systemd/hugetlb-reserve-pages.sh 파일을 만듭니다.

      #!/bin/sh
      
      nodes_path=/sys/devices/system/node/
      if [ ! -d $nodes_path ]; then
      	echo "ERROR: $nodes_path does not exist"
      	exit 1
      fi
      
      reserve_pages()
      {
      	echo $1 > $nodes_path/$2/hugepages/hugepages-1048576kB/nr_hugepages
      }
      
      reserve_pages 4 node1
      reserve_pages 4 node2

      이렇게 하면 node1 에서 4GiB 대규모 페이지를 예약하고 node2 에서 4GiB 대규모 페이지를 예약합니다.

    4. 이전 단계에서 생성한 스크립트를 실행 파일로 만듭니다.

      # chmod +x /etc/systemd/hugetlb-reserve-pages.sh
    5. 부팅 시 대규모 페이지 예약을 활성화합니다.

      # systemctl enable hugetlb-gigantic-pages
  4. 이 예제에서는 super-VM 예제에서 최적화하려는 VM의 XML 구성을 편집하려면 virsh edit 명령을 사용합니다.

    # virsh edit super-vm
  5. VM의 XML 구성을 다음과 같이 조정합니다.

    1. 8개의 정적 vCPU를 사용하도록 VM을 설정합니다. < vcpu/> 요소를 사용하여 이 작업을 수행합니다.
    2. 각 vCPU 스레드를 토폴로지에서 미러링하는 해당 호스트 CPU 스레드에 고정합니다. 이렇게 하려면 < cpu tune> 섹션의 <vcpu pin/ > 요소를 사용합니다.

      위의 virsh capabilities 유틸리티에서와 같이 호스트 CPU 스레드는 해당 코어에서 순차적으로 정렬되지 않습니다. 또한 vCPU 스레드는 동일한 NUMA 노드에서 사용 가능한 최고 호스트 코어 세트에 고정되어야 합니다. 테이블 그림은 아래의 샘플 토폴로지 섹션을 참조하십시오.

      1단계와 b 단계를 위한 XML 구성은 다음과 같습니다.

      <cputune>
        <vcpupin vcpu='0' cpuset='1'/>
        <vcpupin vcpu='1' cpuset='4'/>
        <vcpupin vcpu='2' cpuset='2'/>
        <vcpupin vcpu='3' cpuset='5'/>
        <vcpupin vcpu='4' cpuset='7'/>
        <vcpupin vcpu='5' cpuset='10'/>
        <vcpupin vcpu='6' cpuset='8'/>
        <vcpupin vcpu='7' cpuset='11'/>
        <emulatorpin cpuset='6,9'/>
      </cputune>
    3. 1GiB 대규모 페이지를 사용하도록 VM을 설정합니다.

      <memoryBacking>
        <hugepages>
          <page size='1' unit='GiB'/>
        </hugepages>
      </memoryBacking>
    4. 호스트의 해당 NUMA 노드의 메모리를 사용하도록 VM의 NUMA 노드를 구성합니다. 이렇게 하려면 < numatune /> 섹션의 <memnode / > 요소를 사용합니다.

      <numatune>
        <memory mode="preferred" nodeset="1"/>
        <memnode cellid="0" mode="strict" nodeset="0"/>
        <memnode cellid="1" mode="strict" nodeset="1"/>
      </numatune>
    5. CPU 모드가 host-passthrough 로 설정되어 있고 CPU가 passthrough 모드에서 캐시를 사용하는지 확인합니다.

      <cpu mode="host-passthrough">
        <topology sockets="2" cores="2" threads="2"/>
        <cache mode="passthrough"/>

검증

  1. VM의 결과 XML 구성에 다음과 유사한 섹션이 포함되어 있는지 확인합니다.

    [...]
      <memoryBacking>
        <hugepages>
          <page size='1' unit='GiB'/>
        </hugepages>
      </memoryBacking>
      <vcpu placement='static'>8</vcpu>
      <cputune>
        <vcpupin vcpu='0' cpuset='1'/>
        <vcpupin vcpu='1' cpuset='4'/>
        <vcpupin vcpu='2' cpuset='2'/>
        <vcpupin vcpu='3' cpuset='5'/>
        <vcpupin vcpu='4' cpuset='7'/>
        <vcpupin vcpu='5' cpuset='10'/>
        <vcpupin vcpu='6' cpuset='8'/>
        <vcpupin vcpu='7' cpuset='11'/>
        <emulatorpin cpuset='6,9'/>
      </cputune>
      <numatune>
        <memory mode="preferred" nodeset="1"/>
        <memnode cellid="0" mode="strict" nodeset="0"/>
        <memnode cellid="1" mode="strict" nodeset="1"/>
      </numatune>
      <cpu mode="host-passthrough">
        <topology sockets="2" cores="2" threads="2"/>
        <cache mode="passthrough"/>
        <numa>
          <cell id="0" cpus="0-3" memory="2" unit="GiB">
            <distances>
              <sibling id="0" value="10"/>
              <sibling id="1" value="21"/>
            </distances>
          </cell>
          <cell id="1" cpus="4-7" memory="2" unit="GiB">
            <distances>
              <sibling id="0" value="21"/>
              <sibling id="1" value="10"/>
            </distances>
          </cell>
        </numa>
      </cpu>
    </domain>
  2. 선택 사항: 해당 툴 및 유틸리티를 사용하여 VM 최적화의 영향을 평가하는 방식으로 VM의 성능을 테스트합니다.

토폴로지 샘플

  • 다음 표에서는 vCPU와 해당 CPU가 고정된 호스트 CPU 간 연결을 보여줍니다.

    표 13.2. 호스트 토폴로지

    CPU 스레드

    0

    3

    1

    4

    2

    5

    6

    9

    7

    10

    8

    11

    코어

    0

    1

    2

    3

    4

    5

    소켓

    0

    1

    NUMA 노드

    0

    1

    표 13.3. VM 토폴로지

    vCPU 스레드

    0

    1

    2

    3

    4

    5

    6

    7

    코어

    0

    1

    2

    3

    소켓

    0

    1

    NUMA 노드

    0

    1

    표 13.4. 결합된 호스트 및 VM 토폴로지

    vCPU 스레드

     

    0

    1

    2

    3

     

    4

    5

    6

    7

    호스트 CPU 스레드

    0

    3

    1

    4

    2

    5

    6

    9

    7

    10

    8

    11

    코어

    0

    1

    2

    3

    4

    5

    소켓

    0

    1

    NUMA 노드

    0

    1

    이 시나리오에는 NUMA 노드 2개와 8개의 vCPU가 있습니다. 따라서 4 vCPU 스레드를 각 노드에 고정해야 합니다.

    또한 Red Hat은 호스트 시스템 작업을 위해 각 노드에서 적어도 하나의 CPU 스레드를 사용할 수 있도록 하는 것이 좋습니다.

    이 예제에서 각 NUMA 노드에는 각각 2개의 호스트 CPU 스레드가 있는 코어 3개가 있으므로 노드 0에 대한 세트가 다음과 같이 변환됩니다.

    <vcpupin vcpu='0' cpuset='1'/>
    <vcpupin vcpu='1' cpuset='4'/>
    <vcpupin vcpu='2' cpuset='2'/>
    <vcpupin vcpu='3' cpuset='5'/>

13.6.5. 커널 동일한 페이지 병합 관리

KSM(커널 동일 페이지 병합)은 VM(가상 머신) 간에 동일한 메모리 페이지를 공유하여 메모리 밀도를 향상시킵니다. 그러나 KSM을 활성화하면 CPU 사용률이 증가하며 워크로드에 따라 전체 성능에 부정적인 영향을 미칠 수 있습니다.

요구 사항에 따라 단일 세션에 대해 KSM을 활성화하거나 비활성화할 수 있습니다.

참고

RHEL 9 이상에서는 KSM이 기본적으로 비활성화되어 있습니다.

사전 요구 사항

  • 호스트 시스템에 대한 루트 액세스.

절차

  • KSM을 비활성화합니다.

    • 단일 세션에 대해 KSM을 비활성화하려면 systemctl 유틸리티를 사용하여 ksmksmtuned 서비스를 중지합니다.

      # systemctl stop ksm
      
      # systemctl stop ksmtuned
    • KSM을 영구적으로 비활성화하려면 systemctl 유틸리티를 사용하여 ksmksmtuned 서비스를 비활성화합니다.

      # systemctl disable ksm
      Removed /etc/systemd/system/multi-user.target.wants/ksm.service.
      # systemctl disable ksmtuned
      Removed /etc/systemd/system/multi-user.target.wants/ksmtuned.service.
참고

KSM을 비활성화하기 전에 VM 간에 공유되는 메모리 페이지는 공유로 유지됩니다. 공유를 중지하려면 다음 명령을 사용하여 시스템의 모든 PageKSM 페이지를 삭제합니다.

# echo 2 > /sys/kernel/mm/ksm/run

익명 페이지가 KSM 페이지를 교체한 후 khugepaged 커널 서비스는 VM의 실제 메모리에서 투명한 hugepages를 다시 빌드합니다.

  • KSM을 활성화합니다.
주의

KSM을 활성화하면 CPU 사용률이 증가하고 전체 CPU 성능에 영향을 미칩니다.

  1. ksmtuned 서비스를 설치합니다.

    # dnf install ksmtuned

  2. 서비스를 시작합니다.

    • 단일 세션에 KSM을 활성화하려면 systemctl 유틸리티를 사용하여 ksmksmtuned 서비스를 시작합니다.

      # systemctl start ksm
      # systemctl start ksmtuned
    • KSM을 영구적으로 활성화하려면 systemctl 유틸리티를 사용하여 ksmksmtuned 서비스를 활성화합니다.

      # systemctl enable ksm
      Created symlink /etc/systemd/system/multi-user.target.wants/ksm.service → /usr/lib/systemd/system/ksm.service
      
      # systemctl enable ksmtuned
      Created symlink /etc/systemd/system/multi-user.target.wants/ksmtuned.service → /usr/lib/systemd/system/ksmtuned.service

13.7. 가상 머신 네트워크 성능 최적화

VM의 NIC(네트워크 인터페이스 카드)의 가상 특성으로 인해 VM은 할당된 호스트 네트워크 대역폭의 일부를 손실하므로 VM의 전체 워크로드 효율성을 줄일 수 있습니다. 다음 팁은 가상 NIC(vNIC) 처리량에 가상화의 부정적인 영향을 최소화할 수 있습니다.

절차

다음 방법 중 하나를 사용하고 VM 네트워크 성능에 유용한 영향을 미치는지 확인합니다.

vhost_net 모듈 활성화

호스트에서 vhost_net 커널 기능이 활성화되었는지 확인합니다.

# lsmod | grep vhost
vhost_net              32768  1
vhost                  53248  1 vhost_net
tap                    24576  1 vhost_net
tun                    57344  6 vhost_net

이 명령의 출력이 비어 있으면 vhost_net 커널 모듈을 활성화합니다.

# modprobe vhost_net
다중 큐 virtio-net 설정

VM의 다중 대기열 virtio-net 기능을 설정하려면 virsh edit 명령을 사용하여 VM의 XML 구성에 대해 편집합니다. XML에서 < devices&gt; 섹션에 다음을 추가하고 N 을 VM의 vCPU 수로 최대 16개씩 바꿉니다.

<interface type='network'>
      <source network='default'/>
      <model type='virtio'/>
      <driver name='vhost' queues='N'/>
</interface>

VM이 실행 중인 경우 변경 사항이 적용되도록 다시 시작합니다.

네트워크 패킷 배치

긴 전송 경로가 있는 Linux VM 구성에서 패킷을 커널에 제출하기 전에 배치하면 캐시 사용률이 향상될 수 있습니다. 패킷 배치를 설정하려면 호스트에서 다음 명령을 사용하고 tap0 을 VM에서 사용하는 네트워크 인터페이스 이름으로 바꿉니다.

# ethtool -C tap0 rx-frames 64
SR-IOV
호스트 NIC에서 SR-IOV를 지원하는 경우 vNICs에 SR-IOV 장치 할당을 사용합니다. 자세한 내용은 SR-IOV 장치 관리를 참조하십시오.

추가 리소스

13.8. 가상 머신 성능 모니터링 툴

가장 많은 VM 리소스를 소비하는 항목과 최적화가 필요한 VM 성능 측면을 식별하려면 일반 및 VM별 성능 진단 툴을 모두 사용할 수 있습니다.

기본 OS 성능 모니터링 툴

표준 성능 평가를 위해 호스트 및 게스트 운영 체제에서 기본적으로 제공되는 유틸리티를 사용할 수 있습니다.

  • RHEL 9 호스트에서 root로 top 유틸리티 또는 시스템 모니터 애플리케이션을 사용하고 출력에서 qemuvirt 을 찾습니다. VM에서 사용하는 호스트 시스템 리소스의 양을 보여줍니다.

    • 모니터링 도구가 qemu 또는 virt 프로세스가 호스트 CPU 또는 메모리 용량의 많은 부분을 소비하는 것을 표시하는 경우, perf 유틸리티를 사용하여 조사합니다. 자세한 내용은 아래를 참조하십시오.
    • 또한 vhost_net 스레드 프로세스(예: vhost_net -1234)가 과도하게 많은 호스트 CPU 용량을 소비하는 경우 다중 대기열 virtio-net 과 같은 가상 네트워크 최적화 기능을 사용하는 것이 좋습니다.
  • 게스트 운영 체제에서는 시스템에서 사용 가능한 성능 유틸리티 및 애플리케이션을 사용하여 가장 많은 시스템 리소스를 사용하는 프로세스를 평가합니다.

    • Linux 시스템에서는 top 유틸리티를 사용할 수 있습니다.
    • Windows 시스템에서는 작업 관리자 애플리케이션을 사용할 수 있습니다.

perf kvm

perf 유틸리티를 사용하여 RHEL 9 호스트의 성능에 대한 가상화별 통계를 수집하고 분석할 수 있습니다. 이렇게 하려면 다음을 수행합니다.

  1. 호스트에서 perf 패키지를 설치합니다.

    # dnf install perf
  2. 가상화 호스트의 각 통계를 표시하려면 perf kvm stat 명령 중 하나를 사용합니다.

    • 하이퍼바이저에 대한 실시간 모니터링을 위해서는 perf kvm stat 라이브 명령을 사용하십시오.
    • 일정 기간 동안 하이퍼바이저의 perf 데이터를 기록하려면 perf kvm stat record 명령을 사용하여 로깅을 활성화합니다. 명령이 취소되거나 중단된 후 데이터는 perf kvm stat report 명령을 사용하여 분석할 수 있는 perf.data.guest 파일에 저장됩니다.
  3. VM-EXIT 이벤트 유형 및 해당 배포에 대한 perf 출력을 분석합니다. 예를 들어 PAUSE_INSTRUCTION 이벤트는 자주 발생하지 않아야 하지만 다음 출력에서는 호스트 CPU가 실행 중인 vCPU를 제대로 처리하지 않는다고 제안합니다. 이러한 시나리오에서는 활성 VM 중 일부를 종료하거나, 이러한 VM에서 vCPU를 제거하거나, vCPU의 성능을 조정하는 것이 좋습니다.

    # perf kvm stat report
    
    Analyze events for all VMs, all VCPUs:
    
    
                 VM-EXIT    Samples  Samples%     Time%    Min Time    Max Time         Avg time
    
      EXTERNAL_INTERRUPT     365634    31.59%    18.04%      0.42us  58780.59us    204.08us ( +-   0.99% )
               MSR_WRITE     293428    25.35%     0.13%      0.59us  17873.02us      1.80us ( +-   4.63% )
        PREEMPTION_TIMER     276162    23.86%     0.23%      0.51us  21396.03us      3.38us ( +-   5.19% )
       PAUSE_INSTRUCTION     189375    16.36%    11.75%      0.72us  29655.25us    256.77us ( +-   0.70% )
                     HLT      20440     1.77%    69.83%      0.62us  79319.41us  14134.56us ( +-   0.79% )
                  VMCALL      12426     1.07%     0.03%      1.02us   5416.25us      8.77us ( +-   7.36% )
           EXCEPTION_NMI         27     0.00%     0.00%      0.69us      1.34us      0.98us ( +-   3.50% )
           EPT_MISCONFIG          5     0.00%     0.00%      5.15us     10.85us      7.88us ( +-  11.67% )
    
    Total Samples:1157497, Total events handled time:413728274.66us.

    perf kvm 통계 출력의 신호 문제를 신호할 수 있는 기타 이벤트 유형은 다음과 같습니다.

perf 를 사용하여 가상화 성능을 모니터링하는 방법에 대한 자세한 내용은 perf-kvm 도움말 페이지를 참조하십시오.

numastat

시스템의 현재 NUMA 구성을 보려면 numactl 패키지를 설치하여 제공하는 numastat 유틸리티를 사용하면 됩니다.

다음은 각각 여러 NUMA 노드에서 메모리를 가져오는 4개의 VM이 있는 호스트를 보여줍니다. 이는 vCPU 성능에 적합하지 않으며 보증 조정:

# numastat -c qemu-kvm

Per-node process memory usage (in MBs)
PID              Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
51722 (qemu-kvm)     68     16    357   6936      2      3    147    598  8128
51747 (qemu-kvm)    245     11      5     18   5172   2532      1     92  8076
53736 (qemu-kvm)     62    432   1661    506   4851    136     22    445  8116
53773 (qemu-kvm)   1393      3      1      2     12      0      0   6702  8114
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
Total              1769    463   2024   7462  10037   2672    169   7837 32434

반면 다음은 단일 노드에서 각 VM에 제공되는 메모리를 훨씬 더 효율적으로 보여줍니다.

# numastat -c qemu-kvm

Per-node process memory usage (in MBs)
PID              Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
51747 (qemu-kvm)      0      0      7      0   8072      0      1      0  8080
53736 (qemu-kvm)      0      0      7      0      0      0   8113      0  8120
53773 (qemu-kvm)      0      0      7      0      0      0      1   8110  8118
59065 (qemu-kvm)      0      0   8050      0      0      0      0      0  8051
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
Total                 0      0   8072      0   8072      0   8114   8110 32368

14장. 전력 관리의 중요성

컴퓨터 시스템의 전반적인 전력 소비를 줄이면 비용을 절감할 수 있습니다. 각 시스템 구성 요소의 전력 소비를 효과적으로 최적화하려면 시스템이 수행하는 다양한 작업을 연구하고 각 구성 요소를 구성하여 해당 작업에 적합한 성능을 보장할 수 있습니다. 특정 구성 요소 또는 시스템의 전력 소비를 전체적으로 낮추면 열과 성능이 저하됩니다.

적절한 전원 관리 결과:

  • 서버 및 컴퓨팅 센터의 열 감소
  • 마운딩, 공간, 연결, 생성기 및 중단되지 않는 전원 공급 장치(UPS)를 포함한 보조 비용 감소
  • 노트북을 위한 확장된 배터리 수 있습니다.
  • 더 낮은 이산화탄수
  • Green IT에 관한 정부 규정 또는 법적 요구 사항 충족 (예: Energy Star)
  • 새로운 시스템에 대한 회사 지침 충족

이 섹션에서는 Red Hat Enterprise Linux 시스템의 전원 관리에 대한 정보를 설명합니다.

14.1. 전원 관리 기본 사항

효과적인 전원 관리는 다음과 같은 원칙에 따라 구축됩니다.

유휴 CPU는 필요한 경우에만 활성화되어야 합니다.

Red Hat Enterprise Linux 6부터 커널은 틱리스( tickless )를 실행하므로 이전의 주기 타이머 인터럽트가 온 디맨드 인터럽트로 교체되었음을 의미합니다. 따라서 처리를 위해 새 작업이 대기될 때까지 유휴 CPU는 유휴 상태로 유지될 수 있으며 더 낮은 전원 상태를 입력한 CPU는 이러한 상태에 더 오래 남아 있을 수 있습니다. 그러나 불필요한 타이머 이벤트를 생성하는 애플리케이션이 있는 경우 이 기능의 이점을 오프셋할 수 있습니다. 폴링 이벤트(예: 볼륨 변경 또는 마우스 이동 확인)는 이러한 이벤트의 예입니다.

Red Hat Enterprise Linux에는 CPU 사용량에 따라 애플리케이션을 식별하고 감사할 수 있는 툴이 포함되어 있습니다. 자세한 내용은 감사 및 분석 개요 및 감사 툴을 참조하십시오.

사용되지 않는 하드웨어 및 장치를 완전히 비활성화해야 합니다.
이는 부분을 이동하는 장치(예: 하드 디스크)의 경우 해당합니다. 이 외에도 일부 애플리케이션은 사용되지 않고 활성화된 "오픈" 장치를 종료할 수 있습니다. 이 경우 커널은 장치가 사용 중이라고 가정하여 장치가 전력 절약 상태로 전환되지 않을 수 있습니다.
낮은 활동이 낮은 와트로 변환되어야 합니다.

그러나 대부분의 경우 이는 최신 하드웨어 및 비x86 아키텍처를 포함하여 최신 시스템의 올바른 BIOS 구성 또는 UEFI에 따라 달라집니다. 시스템에 대한 최신 공식 펌웨어를 사용하고 있는지 확인하고 BIOS의 전원 관리 또는 장치 구성 섹션에 전원 관리 기능이 활성화되어 있는지 확인합니다. 다음과 같은 몇 가지 기능은 다음과 같습니다.

  • ARM64에 대한 통합 프로세서 Performance Controls (CPPC) 지원
  • IBM Power Systems에 대한 PowerNV 지원
  • SpeedStep
  • PowerNow!
  • 콤팩트'Quiet
  • ACPI(C-state)
  • SMART

    하드웨어가 이러한 기능을 지원하고 BIOS에서 활성화된 경우 Red Hat Enterprise Linux는 기본적으로 해당 기능을 사용합니다.

다양한 CPU 상태 및 효과

최신 CPU와 Advanced Configuration and Power Interface (ACPI)는 다른 전원 상태를 제공합니다. 다른 세 가지 상태는 다음과 같습니다.

  • sleep (C-states)
  • 빈도 및 민감 (P-상태)
  • Heat 출력(T-states 또는 열 상태)

    가장 낮은 수면 상태에서 실행되는 CPU는 최소한의 와트 양을 사용하지만 필요한 경우 해당 상태에서 발생하는 데 시간이 더 걸립니다. 드문 경우로 인해 CPU가 잠자기 상태로 전환될 때마다 즉시 CPU가 급증해야 할 수 있습니다. 이 경우 효율적으로 영구적으로 사용하는 CPU가 발생하고 다른 상태가 사용 된 경우 잠재적인 전력 절약의 일부가 손실됩니다.

전원이 꺼진 시스템은 가장 적은 양의 전력을 사용합니다.
전력을 절약할 수 있는 가장 좋은 방법 중 하나는 시스템을 끄는 것입니다. 예를 들어, 귀하의 회사에서는 잠시 쉬우거나 집에 갈 때 시스템을 끄는 가이드 라인을 통해 "Green IT"에 중점을 둔 기업 문화를 개발할 수 있습니다. 또한 여러 물리적 서버를 하나의 더 큰 서버로 통합하고 Red Hat Enterprise Linux와 함께 제공되는 가상화 기술을 사용하여 가상화할 수도 있습니다.

14.2. 감사 및 분석 개요

단일 시스템의 자세한 수동 감사, 분석 및 튜닝은 일반적으로 그렇게하는 데 걸리는 시간과 비용이 일반적으로 이러한 마지막 시스템 튜닝에서 얻은 이점을 능가하기 때문에 예외입니다.

그러나 이러한 작업을 다수의 거의 동일한 시스템에 대해 한 번 수행하여 모든 시스템에 대해 동일한 설정을 재사용할 수 있는 것이 매우 유용할 수 있습니다. 예를 들어, 수천 개의 데스크탑 시스템 또는 시스템이 거의 동일한 HPC 클러스터를 배포하는 것을 고려해 보십시오. 감사 및 분석을 수행하는 또 다른 이유는 향후 시스템 동작의 회귀 또는 변경을 식별할 수 있는 것과 비교하기 위한 기반을 제공하는 것입니다. 이 분석의 결과는 하드웨어, BIOS 또는 소프트웨어 업데이트가 정기적으로 발생하고 전력 소비와 관련하여 예상치를 피하려는 경우에 매우 도움이 될 수 있습니다. 일반적으로 철저한 감사 및 분석은 특정 시스템에서 실제로 발생하는 일에 대해 훨씬 더 잘 이해할 수 있습니다.

전력 소비와 관련된 시스템을 감사하고 분석하는 것은 최신 시스템을 사용할 수 있더라도 비교적 어렵습니다. 대부분의 시스템은 소프트웨어를 통해 전력 사용을 측정하는 데 필요한 수단을 제공하지 않습니다. 그러나 예외가 있습니다.

  • Hewlett Packard 서버 시스템의 ILO 관리 콘솔에는 웹을 통해 액세스할 수 있는 전원 관리 모듈이 있습니다.
  • IBM은 BladeCenter 전원 관리 모듈에 유사한 솔루션을 제공합니다.
  • 일부 Dell 시스템에서 IT Assistant는 전원 모니터링 기능도 제공합니다.

다른 공급업체는 서버 플랫폼에 대해 유사한 기능을 제공할 수 있지만 모든 공급업체에서 지원하는 단일 솔루션이 없음을 확인할 수 있습니다. 직접 소비 전력 측정은 가능한 한 비용 절감을 극대화하기 위해서만 필요한 경우가 많습니다.

14.3. 감사 툴

Red Hat Enterprise Linux 8은 시스템 감사 및 분석을 수행할 수 있는 도구를 제공합니다. 대부분은 귀하가 이미 발견한 내용을 확인하거나 특정 부분에 대한 보다 심층적인 정보가 필요한 경우 정보의 보조 소스로 사용할 수 있습니다.

이러한 여러 툴은 다음과 같은 성능 튜닝에도 사용됩니다.

PowerTOP
CPU를 자주 사용하는 커널 및 사용자 공간 애플리케이션의 특정 구성 요소를 식별합니다. powertop 명령을 root로 사용하여 PowerTop 툴 및 powertop --calibrate 를 실행하여 전원 추정 엔진을 조정합니다. PowerTop에 대한 자세한 내용은 PowerTOP로 전력 소비 관리를 참조하십시오.
Diskdevstat 및 netdevstat

시스템에서 실행되는 모든 애플리케이션의 디스크 활동 및 네트워크 활동에 대한 자세한 정보를 수집하는 SystemTap 툴입니다. 이러한 툴의 수집된 통계를 사용하면 더 적은 수의 대규모 작업 대신 많은 작은 I/O 작업으로 전력을 소비하는 애플리케이션을 식별할 수 있습니다. dnf install tuned-utils-systemtap kernel-debuginfo 명령을 root로 사용하여 diskdevstatnetdevstat 툴을 설치합니다.

디스크 및 네트워크 활동에 대한 자세한 정보를 보려면 다음을 사용합니다.

# diskdevstat

PID   UID   DEV   WRITE_CNT   WRITE_MIN   WRITE_MAX   WRITE_AVG   READ_CNT   READ_MIN   READ_MAX   READ_AVG   COMMAND

3575  1000  dm-2   59          0.000      0.365        0.006        5         0.000        0.000      0.000      mozStorage #5
3575  1000  dm-2    7          0.000      0.000        0.000        0         0.000        0.000      0.000      localStorage DB
[...]


# netdevstat

PID   UID   DEV       XMIT_CNT   XMIT_MIN   XMIT_MAX   XMIT_AVG   RECV_CNT   RECV_MIN   RECV_MAX   RECV_AVG   COMMAND
3572  991  enp0s31f6    40       0.000      0.882       0.108        0         0.000       0.000       0.000     openvpn
3575  1000 enp0s31f6    27       0.000      1.363       0.160        0         0.000       0.000       0.000     Socket Thread
[...]

이러한 명령을 사용하면 세 가지 매개 변수를 지정할 수 있습니다. update_interval,total_duration, display_histogram.

TuneD
udev 장치 관리자를 사용하여 연결된 장치를 모니터링하고 시스템 설정의 정적 및 동적 튜닝을 둘 다 활성화하는 프로파일 기반 시스템 튜닝 도구입니다. tuned-adm recommend 명령을 사용하여 Red Hat이 특정 제품에 가장 적합한 프로파일을 결정할 수 있습니다. TuneD에 대한 자세한 내용은 TuneD 시작하기 및 TuneD 프로필 사용자 지정을 참조하십시오. powertop2tuned 유틸리티를 사용하여 PowerTOP 제안에서 사용자 정의 TuneD 프로필을 생성할 수 있습니다. powertop2tuned 유틸리티에 대한 자세한 내용은 전원 소비 최적화를 참조하십시오.
가상 메모리 통계(vmstat)

procps-ng 패키지에서 제공합니다. 이 도구를 사용하면 프로세스, 메모리, 페이징, 블록 I/O, 트랩 및 CPU 활동에 대한 자세한 정보를 볼 수 있습니다.

이 정보를 보려면 다음을 사용합니다.

$ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r  b  swpd  free    buff   cache   si   so  bi   bo   in  cs  us  sy id  wa  st
1  0   0   5805576 380856 4852848   0    0  119  73  814  640  2   2 96   0   0

vmstat -a 명령을 사용하여 활성 및 비활성 메모리를 표시할 수 있습니다. 기타 vmstat 옵션에 대한 자세한 내용은 vmstat 도움말 페이지를 참조하십시오.

iostat

NetNamespace 패키지에서 제공합니다. 이 툴은 vmstat 와 유사하지만 블록 장치에서는 I/O만 모니터링합니다. 또한 더 자세한 출력 및 통계도 제공합니다.

시스템 I/O를 모니터링하려면 다음을 사용합니다.

$ iostat
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.05    0.46    1.55    0.26    0.00   95.67

Device     tps     kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
nvme0n1    53.54     899.48     616.99      3445229     2363196
dm-0       42.84     753.72     238.71      2886921      914296
dm-1        0.03       0.60       0.00         2292           0
dm-2       24.15     143.12     379.80       548193     1454712
blktrace

I/O 하위 시스템에서 시간이 소비되는 방법에 대한 자세한 정보를 제공합니다.

이 정보를 사람이 읽을 수 있는 형식으로 보려면 다음을 사용합니다.

# blktrace -d /dev/dm-0 -o - | blkparse -i -

253,0   1    1   0.000000000  17694  Q   W 76423384 + 8 [kworker/u16:1]
253,0   2    1   0.001926913     0   C   W 76423384 + 8 [0]
[...]

여기서 첫 번째 열 253,0 은 장치의 메이저 및 마이너 result result입니다. 두 번째 열인 1 은 CPU에 대한 정보를 제공하고, 그 다음에는 IO 프로세스를 실행하는 프로세스의 타임 스탬프 및 PID에 대한 열을 제공합니다.

여섯 번째 열인 Q 는 이벤트 유형, 7번째 열인 쓰기 작업의 경우 8번째 열인 7번째 열인 7번째 열이며, 76423384 는 블록 번호이며, + 8 은 요청된 블록의 수입니다.

마지막 필드 [kworker/u16:1] 은 프로세스 이름입니다.

기본적으로 blktrace 명령은 프로세스가 명시적으로 종료될 때까지 영구적으로 실행됩니다. 런타임 기간을 지정하려면 -w 옵션을 사용합니다.

turbostat

kernel-tools 패키지에서 제공합니다. x86-64 프로세서의 프로세서 토폴로지, 빈도, 유휴 전원 상태 통계, 온도 및 전원 사용량을 보고합니다.

이 요약을 보려면 다음을 사용합니다.

# turbostat

CPUID(0): GenuineIntel 0x16 CPUID levels; 0x80000008 xlevels; family:model:stepping 0x6:8e:a (6:142:10)
CPUID(1): SSE3 MONITOR SMX EIST TM2 TSC MSR ACPI-TM HT TM
CPUID(6): APERF, TURBO, DTS, PTM, HWP, HWPnotify, HWPwindow, HWPepp, No-HWPpkg, EPB
[...]

기본적으로 turbostat 는 전체 화면에 대한 카운터 결과의 요약을 출력하고 카운터 결과는 5 초마다 인쇄됩니다. i 옵션을 사용하여 카운터 결과 간에 다른 기간을 지정합니다. 예를 들어 turbostat -i 10 을 실행하여 10초마다 결과를 출력합니다.

readstat 는 또한 전원 사용 또는 유휴 시간 측면에서 비효율적인 서버를 식별하는 데 유용합니다. 또한 시스템에서 발생하는 시스템 관리 인터럽트(SMI)의 속도를 식별하는 데 도움이 됩니다. 또한 전원 관리 튜닝의 영향을 확인하는 데 사용할 수 있습니다.

cpupower

IT는 프로세서의 관련 기능을 조사하고 조정하는 툴 컬렉션입니다. frequency-info,frequency-set,idle-info, idle-set,idle-set, ,info, monitor 옵션과 함께 cpupower 명령을 사용하여 프로세서 관련 값을 표시하고 설정합니다.

예를 들어 사용 가능한 cpufreq governors를 보려면 다음을 사용합니다.

$ cpupower frequency-info --governors
analyzing CPU 0:
  available cpufreq governors: performance powersave

cpupower 에 대한 자세한 내용은 CPU 관련 정보 보기를 참조하십시오.

GNOME Power Manager
GNOME 데스크탑 환경의 일부로 설치된 데몬입니다. GNOME Power Manager는 시스템의 전원 상태에 있는 변경 사항을 알립니다. 예를 들어, 건전지에서 AC 전원으로 변경 사항이 적용됩니다. 또한 건전지 상태를 보고하고 건전지 전력이 낮을 때 경고합니다.

추가 리소스

  • PowerTOP(1), diskdevstat(8), netdevstat(8), tuned(8), vmstat(8), iostat(1), blktrace(8), blkparse(8)turbostat(8) 도움말 페이지
  • cpupower(1), cpupower-set(1), cpupower-info(1), cpupower-idle(1), cpupower-frequency-set(1), cpupower-frequency-info(1)cpupower-monitor(1) 도움말 페이지

15장. PowerTOP를 사용하여 전력 소비 관리

시스템 관리자는 PowerTOP 도구를 사용하여 전력 소비를 분석하고 관리할 수 있습니다.

15.1. PowerTOP의 목적

PowerTOP 는 전력 소비와 관련된 문제를 진단하고 PV 수명을 연장하는 방법에 대한 제안을 제공하는 프로그램입니다.

PowerTOP 툴은 시스템의 총 전원 사용량과 각 프로세스, 장치, 커널 작업자, 타이머 및 인터럽트 처리기에 대한 개별 전원 사용량을 추정할 수 있습니다. 이 툴은 CPU를 자주 사용하는 커널 및 사용자 공간 애플리케이션의 특정 구성 요소를 식별할 수도 있습니다.

Red Hat Enterprise Linux 9는 PowerTOP 버전 2.x를 사용합니다.

15.2. PowerTOP 사용

사전 요구 사항

  • PowerTOP 를 사용할 수 있으려면 powertop 패키지가 시스템에 설치되어 있는지 확인합니다.

    # dnf install powertop

15.2.1. PowerTOP 시작

절차

  • PowerTOP 를 실행하려면 다음 명령을 사용하십시오.

    # powertop
중요

powertop 명령을 실행할 때 PC 전원에서 노트북을 실행해야 합니다.

15.2.2. PowerTOP 교정

절차

  1. 노트북에서 다음 명령을 실행하여 전력 추정 엔진을 교정할 수 있습니다.

    # powertop --calibrate
  2. 프로세스 중에 시스템과 상호 작용하지 않고 교정을 완료하도록 합니다.

    프로세스에서 다양한 테스트, 밝기 레벨 및 스위치 장치를 통해 사이클을 수행하고 켜거나 끄면 시간이 걸립니다.

  3. Calibration 프로세스가 완료되면 PowerTOP 가 정상적으로 시작됩니다. 데이터를 수집하기 위해 약 1시간 동안 실행되도록 합니다.

    충분한 데이터가 수집되면 출력 테이블의 첫 번째 열에 전력 추정치가 표시됩니다.

참고

powertop --calibrate 는 노트북에서만 사용할 수 있습니다.

15.2.3. 측정 간격 설정

기본적으로 PowerTOP 는 20초 간격으로 측정을 수행합니다.

이 측정 빈도를 변경하려면 다음 절차를 따르십시오.

절차

  • 시간 옵션을 사용하여 powertop 명령을 실행합니다.

    # powertop --time=time in seconds

15.3. PowerTOP 통계

실행되는 동안 PowerTOP 는 시스템에서 통계를 수집합니다.

PowerTOP의 출력은 여러 탭을 제공합니다.

  • 개요
  • 유휴 상태 통계
  • 빈도 통계
  • 장치 통계
  • 튜닝 가능 항목
  • WakeUp

TabShift+Tab 키를 사용하여 이러한 탭을 통해 반복할 수 있습니다.

15.3.1. 개요 탭

개요 탭에서 가장 자주 CPU로 wakeups를 보내거나 가장 많은 전원을 사용하는 구성 요소 목록을 볼 수 있습니다. 프로세스, 인터럽트, 장치 및 기타 리소스를 포함한 개요 탭의 항목은 사용률에 따라 정렬됩니다.

개요 탭 내의 인접 열은 다음과 같은 정보를 제공합니다.

사용법
리소스 사용 방법에 대한 전원 추정치입니다.
events/s
초당 Wakeup입니다. 초당 wakeups 수는 서비스 또는 장치 및 커널 드라이버가 얼마나 효율적으로 수행되는지를 나타냅니다. 압축은 더 적은 전력이 감소한다는 것을 의미합니다. 구성 요소는 전력 사용량을 얼마나 더 최적화할 수 있는지에 따라 정렬됩니다.
카테고리
프로세스, 장치 또는 타이머와 같은 구성 요소를 분류합니다.
설명
구성 요소에 대한 설명입니다.

적절하게 교정을하면 첫 번째 열의 나열된 모든 항목에 대한 전력 소비 추정치도 표시됩니다.

이 외에도 개요 탭에는 다음과 같은 요약 통계가 포함된 행이 포함되어 있습니다.

  • 총 전력 소비
  • 남은 수명은 (해당되는 경우에만)
  • 초당 총 절전 모드, 초당 GPU 작업 및 초당 가상 파일 시스템 작업 요약

15.3.2. Idle 통계 탭

Idle stats 탭에서는 모든 프로세서와 코어에 대한 C-states의 사용법을 보여주지만, Frequency stats 탭에는 모든 프로세서 및 코어에 대해 ScanSetting 모드를 포함한 P-states의 사용법을 보여줍니다. C- 또는 P-상태의 기간은 CPU 사용량이 얼마나 최적화되었는지를 나타냅니다. CPU가 더 높은 C- 또는 P-상태(예: C4가 C3)보다 더 긴 경우 CPU 사용량 최적화가 더 좋습니다. 이상적으로는 시스템이 유휴 상태일 때 가장 높은 C- 또는 P-상태에서 90% 이상이 됩니다.

15.3.3. 장치 통계 탭

장치 통계 탭은 개요 탭과 유사한 정보를 제공하지만 장치에 대해서만 정보를 제공합니다.

15.3.4. Tunables 탭

Tunables 탭에는 전력 소비를줄이기 위해 시스템을 최적화하기 위한 제안사항이 포함되어 있습니다.

위쪽아래 키를 사용하여 제안을 통해 이동하고, Enter 키를 사용하여 제안을 전환하거나 해제할 수 있습니다.

15.3.5. WakeUp 탭

WakeUp 탭에는 필요에 따라 사용자가 변경할 수 있는 장치 활성화 설정이 표시됩니다.

updown 키를 사용하여 사용 가능한 설정으로 이동하고 enter 키를 사용하여 설정을 활성화하거나 비활성화합니다.

그림 15.1. PowerTOP 출력

powertop2 14

추가 리소스

PowerTOP 에 대한 자세한 내용은 PowerTOP의 홈 페이지를 참조하십시오.

15.4. Powertop에서 일부 인스턴스에서 Frequency stats 값을 표시하지 않는 이유

Intel P-State 드라이버를 사용하는 동안 PowerTOP는 드라이버가 Passive 모드인 경우 Frequency statistics 탭에 값만 표시합니다. 그러나 이 경우에도 값이 불완전할 수 있습니다.

전체적으로 Intel P-State 드라이버의 세 가지 가능한 모드가 있습니다.

  • HWP(HWP) 하드웨어 P-States를 사용하는 활성 모드
  • HWP가 없는 활성 모드
  • Passive 모드

ACPI CPUfreq 드라이버로 전환하면 PowerTOP에서 완전한 정보가 표시됩니다. 그러나 시스템을 기본 설정으로 유지하는 것이 좋습니다.

로드된 드라이버를 확인하고 어떤 모드에서 다음을 실행합니다.

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
  • Intel P-State 드라이버가 로드되고 활성 모드에서 intel_pstate 가 반환됩니다.
  • Intel P-State 드라이버가 로드되고 passive 모드인 경우 intel_cpufreq 가 반환됩니다.
  • ACPI CPU freq 드라이버가 로드되면 ACPI-cpu freq가 반환됩니다.

Intel P-State 드라이버를 사용하는 동안 커널 부팅 명령줄에 다음 인수를 추가하여 드라이버를 패시브 모드로 강제 실행합니다.

intel_pstate=passive

Intel P-State 드라이버를 비활성화하고 를 사용하려면 ACPI CPUfreq 드라이버를 통해 커널 부팅 명령줄에 다음 인수를 추가합니다.

intel_pstate=disable

15.5. HTML 출력 생성

터미널의 powertop 출력 외에도 HTML 보고서를 생성할 수도 있습니다.

절차

  • --html 옵션을 사용하여 powertop 명령을 실행합니다.

    # powertop --html=htmlfile.html

    htmlfile.html 매개 변수를 출력 파일에 필요한 이름으로 바꿉니다.

15.6. 전력 소비 최적화

전력 소비를 최적화하기 위해 powertop 서비스 또는 powertop 2tuned 유틸리티를 사용할 수 있습니다.

15.6.1. powertop 서비스를 사용하여 전원 소비 최적화

powertop 서비스를 사용하여 부팅 시 Tunables 탭에서 모든 PowerTOP의 제안을 자동으로 활성화할 수 있습니다.

절차

  • powertop 서비스를 활성화합니다.

    # systemctl enable powertop

15.6.2. powertop2tuned 유틸리티

powertop2tuned 유틸리티를 사용하면 PowerTOP 제안에서 사용자 정의 TuneD 프로필을 생성할 수 있습니다.

기본적으로 powertop2tuned/etc/tuned/ 디렉터리에 프로필을 생성하고 현재 선택한 TuneD 프로필의 사용자 정의 프로필을 기반으로 합니다. 보안상의 이유로 새 프로필에서는 모든 PowerTOP 튜닝이 처음에 비활성화되어 있습니다.

튜닝을 활성화하려면 다음을 수행할 수 있습니다.

  • /etc/tuned/profile_name/tuned.conf 파일에서 해당 파일의 주석을 제거합니다.
  • enable 또는 -e 옵션을 사용하여 PowerTOP 에서 제공하는 대부분의 튜닝을 활성화하는 새 프로필을 생성합니다.

    USB 자동 중지와 같은 잠재적으로 문제가 있는 특정 튜닝은 기본적으로 비활성화되어 있으며 수동으로 주석 처리를 해제해야 합니다.

15.6.3. powertop2tuned 유틸리티를 사용하여 전원 소비 최적화

사전 요구 사항

  • powertop2tuned 유틸리티는 시스템에 설치되어 있습니다.

    # dnf install tuned-utils

절차

  1. 사용자 정의 프로필을 생성합니다.

    # powertop2tuned new_profile_name
  2. 새 프로필을 활성화합니다.

    # tuned-adm profile new_profile_name

추가 정보

  • powertop2tuned 에서 지원하는 전체 옵션 목록은 다음을 사용합니다.

    $ powertop2tuned --help

15.6.4. powertop.service 및 powertop2tuned 비교

다음과 같은 이유로 powertop2tuned 로 전력 소비를 최적화하는 것이 powertop.service 보다 우선합니다.

  • powertop2tuned 유틸리티는 PowerTOPTuneD 에 통합하므로 두 툴의 이점을 활용할 수 있습니다.
  • powertop2tuned 유틸리티를 사용하면 활성화된 튜닝을 세부적으로 제어할 수 있습니다.
  • powertop2tuned 를 사용하면 잠재적으로 위험한 튜닝이 자동으로 활성화되지 않습니다.
  • powertop2tuned 를 사용하면 재부팅하지 않고 롤백이 가능합니다.

16장. Perf 시작하기

시스템 관리자는 perf 툴을 사용하여 시스템의 성능 데이터를 수집하고 분석할 수 있습니다.

16.1. perf 소개

커널 기반 하위 시스템 성능 카운터(PCL)와 perf 사용자 공간 툴을 사용합니다. perf 는 PMU(Performance Monitoring Unit)를 사용하여 다양한 하드웨어 및 소프트웨어 이벤트를 측정, 기록 및 모니터링하는 강력한 도구입니다. perf 는 또한 tracepoints, kprobes, uprobes를 지원합니다.

16.2. perf 설치

이 절차에서는 perf 사용자 공간 툴을 설치합니다.

절차

  • perf 툴을 설치합니다.

    # dnf install perf

16.3. 일반적인 perf 명령

perf 통계
이 명령은 실행된 명령 실행 및 클럭 사이클을 포함하여 일반적인 성능 이벤트에 대한 전반적인 통계를 제공합니다. 옵션을 사용하면 기본 측정 이벤트 이외의 이벤트를 선택할 수 있습니다.
perf record
이 명령은 성능 데이터를 파일 perf.data 에 기록합니다. 이 파일은 나중에 perf report 명령을 사용하여 분석할 수 있습니다.
perf 보고서
이 명령은 perf 레코드에서 생성한 perf.data 파일의 성능 데이터를 읽고 표시합니다.
perf 목록
이 명령은 특정 시스템에서 사용 가능한 이벤트를 나열합니다. 이러한 이벤트는 시스템의 성능 모니터링 하드웨어 및 소프트웨어 구성에 따라 달라집니다.
perf top
이 명령은 top 유틸리티와 유사한 기능을 수행합니다. 실시간으로 성능 카운터 프로필을 생성하고 표시합니다.
perf 추적
이 명령은 strace 툴과 유사한 기능을 수행합니다. 지정된 스레드 또는 프로세스에서 사용하는 시스템 호출과 해당 애플리케이션에서 수신한 모든 신호를 모니터링합니다.
perf 도움말
이 명령을 수행하면 전체 perf 명령 목록이 표시됩니다.

추가 리소스

  • 하위 명령에 --help 옵션을 추가하여 도움말 페이지를 엽니다.

17장. perf를 사용하여 CPU 사용량을 실시간으로 프로파일링

perf top 명령을 사용하여 다른 함수의 CPU 사용량을 실시간으로 측정할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

17.1. perf의 목적

perf top 명령은 top 유틸리티와 유사한 실시간 시스템 프로파일링 및 기능에 사용됩니다. 그러나 top 유틸리티에서는 일반적으로 지정된 프로세스 또는 스레드가 사용 중인 CPU 시간을 표시합니다. 여기서 perf 는 각 특정 함수가 사용하는 CPU 시간을 보여줍니다. 기본 상태에서 perf 는 사용자 공간 및 커널 공간 모두에서 모든 CPU에서 사용되는 기능에 대해 알려줍니다. perf 를 사용하려면 루트 액세스가 필요합니다.

17.2. perf를 사용하여 CPU 사용량 프로파일링

이 절차에서는 perf top 및 프로필 CPU 사용량을 실시간으로 활성화합니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.
  • root 액세스 권한이 있어야 합니다.

절차

  • perf의 주요 모니터링 인터페이스를 시작합니다.

    # perf top

    모니터링 인터페이스는 다음과 유사합니다.

    Samples: 8K of event 'cycles', 2000 Hz, Event count (approx.): 4579432780 lost: 0/0 drop: 0/0
    Overhead  Shared Object       Symbol
       2.20%  [kernel]            [k] do_syscall_64
       2.17%  [kernel]            [k] module_get_kallsym
       1.49%  [kernel]            [k] copy_user_enhanced_fast_string
       1.37%  libpthread-2.29.so  [.] pthread_mutex_lock 1.31% [unknown] [.] 0000000000000000 1.07% [kernel] [k] psi_task_change 1.04% [kernel] [k] switch_mm_irqs_off 0.94% [kernel] [k] fget
       0.74%  [kernel]            [k] entry_SYSCALL_64
       0.69%  [kernel]            [k] syscall_return_via_sysret
       0.69%  libxul.so           [.] 0x000000000113f9b0
       0.67%  [kernel]            [k] kallsyms_expand_symbol.constprop.0
       0.65%  firefox             [.] moz_xmalloc
       0.65%  libpthread-2.29.so  [.] __pthread_mutex_unlock_usercnt
       0.60%  firefox             [.] free
       0.60%  libxul.so           [.] 0x000000000241d1cd
       0.60%  [kernel]            [k] do_sys_poll
       0.58%  [kernel]            [k] menu_select
       0.56%  [kernel]            [k] _raw_spin_lock_irqsave
       0.55%  perf                [.] 0x00000000002ae0f3

    이 예에서 커널 함수 do_syscall_64 는 대부분의 CPU 시간을 사용합니다.

추가 리소스

  • perf-top(1) 도움말 페이지

17.3. 상위 출력의 해석

perf 상단 모니터링 인터페이스는 여러 열에 데이터를 표시합니다.

"Overhead" 열
지정된 함수에서 사용하는 CPU의 백분율을 표시합니다.
"공유 오브젝트" 열
함수를 사용 중인 프로그램 또는 라이브러리 이름을 표시합니다.
<Symbol> 열
함수 이름 또는 기호를 표시합니다. 커널 공간에 실행되는 함수는 [k] 에 의해 식별되며 사용자 공간으로 실행되는 함수는 [.] 에 의해 식별됩니다.

17.4. perf가 일부 함수 이름을 원시 함수 주소로 표시하는 이유

커널 함수의 경우, perf/proc/kallsyms 파일의 정보를 사용하여 샘플을 각 함수 이름 또는 기호에 매핑합니다. 그러나 사용자 공간으로 실행되는 함수의 경우 바이너리가 제거되었기 때문에 원시 함수 주소가 표시될 수 있습니다.

실행 파일의 debuginfo 패키지를 설치하거나 실행 파일이 로컬에서 개발된 애플리케이션인 경우 이러한 상황에서 함수 이름 또는 기호를 표시하려면 애플리케이션(G의 -g 옵션)이 켜진 디버깅 정보로 컴파일해야 합니다.

참고

실행 파일과 연결된 debuginfo 를 설치한 후 perf record 명령을 다시 실행할 필요가 없습니다. perf report 명령을 다시 실행하면 됩니다.

17.5. 디버그 및 소스 리포지토리 활성화

Red Hat Enterprise Linux의 표준 설치는 디버그 및 소스 리포지토리를 활성화하지 않습니다. 이러한 리포지토리에는 시스템 구성 요소를 디버깅하고 성능을 측정하는 데 필요한 정보가 포함되어 있습니다.

절차

  • 소스 및 디버그 정보 패키지 채널 활성화: $(uname -i) 부분은 시스템의 아키텍처에 대해 일치하는 값으로 자동 교체됩니다.

    아키텍처 이름

    64비트 Intel 및 AMD

    x86_64

    64비트 ARM

    aarch64

    IBM POWER

    ppc64le

    64-bit IBM Z

    s390x

17.6. GDB를 사용하여 애플리케이션 또는 라이브러리를 위한 debuginfo 패키지 가져오기

코드를 디버깅하려면 디버깅 정보가 필요합니다. 패키지에서 설치된 코드의 경우 GNU Debugger(GDB)는 누락된 디버그 정보를 자동으로 인식하고 패키지 이름을 확인하고 패키지를 가져오는 방법에 대한 구체적인 조언을 제공합니다.

사전 요구 사항

  • 디버그하려는 애플리케이션 또는 라이브러리가 시스템에 설치되어 있어야 합니다.
  • GDB 및 debuginfo-install 툴이 시스템에 설치되어 있어야 합니다. 자세한 내용은 애플리케이션 디버그 설정을 참조하십시오.
  • debuginfodebugsource 패키지를 제공하는 리포지토리는 시스템에서 구성하고 활성화해야 합니다. 자세한 내용은 디버그 및 소스 리포지토리 활성화를 참조하십시오.

절차

  1. 디버깅하려는 애플리케이션 또는 라이브러리에 GDB 연결을 시작합니다. GDB는 누락된 디버깅 정보를 자동으로 인식하며 실행할 명령을 제안합니다.

    $ gdb -q /bin/ls
    Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done.
    (no debugging symbols found)...done.
    Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64
    (gdb)
  2. exit GDB: q 를 입력하고 Enter 를 사용하여 확인합니다.

    (gdb) q
  3. GDB에서 제안한 명령을 실행하여 필요한 debuginfo 패키지를 설치합니다.

    # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

    dnf 패키지 관리 도구는 변경 사항에 대한 요약을 제공하고 확인을 요청하며 확인 후 필요한 모든 파일을 다운로드하여 설치합니다.

  4. case GDB는 debuginfo 패키지를 제안할 수 없으며 애플리케이션 또는 라이브러리에 대한 debuginfo 패키지 가져오기에 설명된 절차를 수동으로 수행합니다.

18장. perf stat를 사용하여 프로세스 실행 중 이벤트 계산

perf stat 명령을 사용하여 프로세스 실행 중에 하드웨어 및 소프트웨어 이벤트를 계산할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

18.1. perf 통계의 목적

perf stat 명령은 지정된 명령을 실행하고, 명령을 실행하는 동안 실행 중인 하드웨어 및 소프트웨어 이벤트 수를 유지하고, 이러한 개수의 통계를 생성합니다. 이벤트를 지정하지 않으면 perf stat 는 공통 하드웨어 및 소프트웨어 이벤트 세트를 계산합니다.

18.2. 통계로 이벤트 계산

perf stat 를 사용하여 명령 실행 중에 하드웨어 및 소프트웨어 이벤트 발생을 계산하고 이러한 개수의 통계를 생성할 수 있습니다. 기본적으로 perf stat 는 스레드별 모드에서 작동합니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  • 이벤트를 계산합니다.

    • 루트 액세스 권한 없이 perf stat 명령을 실행하면 사용자 영역에서만 발생하는 이벤트 수입니다.

      $ perf stat ls

      예 18.1. 루트 액세스없이 실행되었던 perf stat의 출력

      Desktop  Documents  Downloads  Music  Pictures  Public  Templates  Videos
      
       Performance counter stats for 'ls':
      
                    1.28 msec task-clock:u               #    0.165 CPUs utilized
                       0      context-switches:u         #    0.000 M/sec
                       0      cpu-migrations:u           #    0.000 K/sec
                     104      page-faults:u              #    0.081 M/sec
               1,054,302      cycles:u                   #    0.823 GHz
               1,136,989      instructions:u             #    1.08  insn per cycle
                 228,531      branches:u                 #  178.447 M/sec
                  11,331      branch-misses:u            #    4.96% of all branches
      
             0.007754312 seconds time elapsed
      
             0.000000000 seconds user
             0.007717000 seconds sys

      이전 예에서 볼 수 있듯이, perf stat 가 root 액세스없이 실행되는 경우 이벤트 이름 뒤에 :u 가 뒤따르면 이러한 이벤트가 사용자 공간에만 계산되었음을 나타냅니다.

    • 사용자 공간 및 커널 공간 이벤트를 모두 계산하려면 stat 를 실행할 때 root 액세스 권한이 있어야 합니다.

      # perf stat ls

      예 18.2. perf stat의 출력은 루트 액세스 권한으로 실행됨

      Desktop  Documents  Downloads  Music  Pictures  Public  Templates  Videos
      
       Performance counter stats for 'ls':
      
                    3.09 msec task-clock                #    0.119 CPUs utilized
                      18      context-switches          #    0.006 M/sec
                       3      cpu-migrations            #    0.969 K/sec
                     108      page-faults               #    0.035 M/sec
               6,576,004      cycles                    #    2.125 GHz
               5,694,223      instructions              #    0.87  insn per cycle
               1,092,372      branches                  #  352.960 M/sec
                  31,515      branch-misses             #    2.89% of all branches
      
             0.026020043 seconds time elapsed
      
             0.000000000 seconds user
             0.014061000 seconds sys
      • 기본적으로 perf stat 는 스레드별 모드에서 작동합니다. CPU 전체 이벤트 수로 변경하려면 -a 옵션을 perf stat 에 전달합니다. CPU 전체 이벤트를 계산하려면 root 액세스 권한이 필요합니다.

        # perf stat -a ls

추가 리소스

  • perf-stat(1) 도움말 페이지

18.3. 통계 출력의 해석

perf stat 는 지정된 명령을 실행하고 명령을 실행하는 동안 이벤트 발생을 계산하고 세 개의 열에서 이러한 수의 통계를 표시합니다.

  1. 지정된 이벤트에 계산되는 발생 횟수
  2. 계산된 이벤트의 이름입니다.
  3. 관련 메트릭을 사용할 수 있는 경우 오른쪽 가장 큰 열에서 해시 기호(#) 뒤에 비율 또는 백분율이 표시됩니다.

    예를 들어 기본 모드에서 실행할 때 통계 는 사이클과 명령 모두를 계산하므로 가장 오른쪽 열에 사이클당 명령을 계산하고 표시합니다. 두 이벤트가 모두 기본적으로 계산되므로 분기와 유사한 동작을 모든 분기의 백분율로 볼 수 있습니다.

18.4. 실행 중인 프로세스에 perf stat 연결

실행 중인 프로세스에 perf stat 를 연결할 수 있습니다. 이 명령은 명령을 실행하는 동안 지정된 프로세스에서만 이벤트 발생을 계산하도록 perf stat 에 지시합니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  • 실행 중인 프로세스에 perf stat 를 연결합니다.

    $ perf stat -p ID1,ID2 sleep seconds

    이전 예제에서는 sleep 명령을 사용하여 지정된 동안 ID1ID2 의 ID가 있는 프로세스의 이벤트를 계산합니다.

추가 리소스

  • perf-stat(1) 도움말 페이지

19장. perf를 사용하여 성능 프로파일 기록 및 분석

perf 툴을 사용하면 성능 데이터를 기록하고 나중에 분석할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

19.1. perf 레코드의 목적

perf record 명령은 성능 데이터를 샘플링하여 다른 perf 명령으로 읽고 시각화할 수 있는 파일 perf.data 에 저장합니다. perf.data 는 현재 디렉터리에서 생성되며 나중에 다른 시스템에서 액세스할 수 있습니다.

기록하기 위해 perf 레코드에 대한 명령을 지정하지 않으면 Ctrl+C 를 눌러 프로세스를 수동으로 중지할 때까지 기록합니다. -p 옵션 다음에 하나 이상의 프로세스 ID를 전달하여 특정 프로세스에 perf 레코드 를 연결할 수 있습니다. 루트 액세스 권한 없이 perf 레코드 를 실행할 수 있지만 이렇게 하면 사용자 공간의 성능 데이터만 샘플링됩니다. 기본 모드에서 perf 레코드 는 CPU 사이클을 샘플링 이벤트로 사용하며 상속 모드가 활성화된 스레드별 모드에서 작동합니다.

19.2. 루트 액세스없이 성능 프로파일 기록

사용자 공간에만 샘플 및 레코드 성능 데이터에 대한 루트 액세스 권한 없이 perf 레코드를 사용할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  • 성능 데이터를 샘플을 기록합니다.

    $ perf record command

    명령을 샘플 데이터 중 데이터로 바꿉니다. 명령을 지정하지 않으면 Perf 레코드Ctrl+C.

추가 리소스

  • perf-record(1) man page

19.3. 루트 액세스 권한으로 성능 프로파일 기록

perf 레코드 를 루트 액세스와 함께 사용자 공간 및 커널 공간 모두에서 샘플 및 레코드 성능 데이터를 동시에 기록할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.
  • 루트 액세스 권한이 있습니다.

절차

  • 성능 데이터를 샘플을 기록합니다.

    # perf record command

    명령을 샘플 데이터 중 데이터로 바꿉니다. 명령을 지정하지 않으면 Perf 레코드Ctrl+C.

추가 리소스

  • perf-record(1) man page

19.4. CPU 모드에서 성능 프로파일 기록

CPU 모드의 perf 레코드 를 사용하여 모니터링된 CPU의 모든 스레드에서 및 사용자 공간 및 커널 공간 모두에서 성능 데이터를 샘플링하고 기록할 수 있습니다. 기본적으로 CPU당 모드에서는 모든 온라인 CPU를 모니터링합니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  • 성능 데이터를 샘플을 기록합니다.

    # perf record -a command

    명령을 샘플 데이터 중 데이터로 바꿉니다. 명령을 지정하지 않으면 Perf 레코드Ctrl+C.

추가 리소스

  • perf-record(1) man page

19.5. perf 레코드를 사용하여 호출 그래프 데이터 캡처

성능 프로필의 다른 함수를 호출하는 함수가 기록되도록 perf 레코드 도구를 구성할 수 있습니다. 이렇게 하면 여러 프로세스가 동일한 함수를 호출하는 경우 성능 장애를 확인하는 데 도움이 됩니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  • --call-graph 옵션을 사용하여 샘플 및 성능 데이터를 기록합니다.

    $ perf record --call-graph method command
    • 명령을 샘플 데이터 중 데이터로 바꿉니다. 명령을 지정하지 않으면 Perf 레코드Ctrl+C.
    • method 를 다음의 unwinding 방법 중 하나로 바꿉니다.

      fp
      프레임 포인터 메서드를 사용합니다. GCC 옵션으로 빌드된 바이너리와 같은 컴파일러 최적화에 따라 --fomit-frame-pointer.
      dwarf
      DWARF 호출 프레임 정보를 사용하여 스택의 배율을 해제합니다.
      lbr
      Intel 프로세서의 마지막 분기 레코드 하드웨어를 사용합니다.

추가 리소스

  • perf-record(1) man page

19.6. perf 보고서를 사용하여 perf.data 분석

perf 보고서를 사용하여 perf.data 파일을 표시하고 분석할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.
  • 현재 디렉터리에는 perf.data 파일이 있습니다.
  • perf.data 파일이 루트 액세스 권한으로 생성된 경우 루트 액세스 권한을 사용하여 perf 보고서를 실행해야 합니다.

절차

  • 추가 분석을 위해 perf.data 파일의 내용을 표시합니다.

    # perf report

    이 명령은 다음과 유사한 출력을 표시합니다.

    Samples: 2K of event 'cycles', Event count (approx.): 235462960
    Overhead  Command          Shared Object                     Symbol
       2.36%  kswapd0          [kernel.kallsyms]                 [k] page_vma_mapped_walk
       2.13%  sssd_kcm         libc-2.28.so                      [.] memset_avx2_erms 2.13% perf [kernel.kallsyms] [k] smp_call_function_single 1.53% gnome-shell libc-2.28.so [.] strcmp_avx2
       1.17%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_hash_table_lookup
       0.93%  Xorg             libc-2.28.so                      [.] memmove_avx_unaligned_erms 0.89% gnome-shell libgobject-2.0.so.0.5600.4 [.] g_object_unref 0.87% kswapd0 [kernel.kallsyms] [k] page_referenced_one 0.86% gnome-shell libc-2.28.so [.] memmove_avx_unaligned_erms
       0.83%  Xorg             [kernel.kallsyms]                 [k] alloc_vmap_area
       0.63%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_slice_alloc
       0.53%  gnome-shell      libgirepository-1.0.so.1.0.0      [.] g_base_info_unref
       0.53%  gnome-shell      ld-2.28.so                        [.] _dl_find_dso_for_object
       0.49%  kswapd0          [kernel.kallsyms]                 [k] vma_interval_tree_iter_next
       0.48%  gnome-shell      libpthread-2.28.so                [.] pthread_getspecific 0.47% gnome-shell libgirepository-1.0.so.1.0.0 [.] 0x0000000000013b1d 0.45% gnome-shell libglib-2.0.so.0.5600.4 [.] g_slice_free1 0.45% gnome-shell libgobject-2.0.so.0.5600.4 [.] g_type_check_instance_is_fundamentally_a 0.44% gnome-shell libc-2.28.so [.] malloc 0.41% swapper [kernel.kallsyms] [k] apic_timer_interrupt 0.40% gnome-shell ld-2.28.so [.] _dl_lookup_symbol_x 0.39% kswapd0 [kernel.kallsyms] [k] raw_callee_save___pv_queued_spin_unlock

추가 리소스

  • perf-report(1) 도움말 페이지

19.7. perf 보고서 출력 해석

perf report 명령을 실행하여 표시되는 표는 데이터를 여러 열로 정렬합니다.

'Overhead' 열
이 특정 함수에서 수집된 전체 샘플의 백분율을 나타냅니다.
<명령> 열
샘플이 수집되는 프로세스에 대해 알려줍니다.
'공유 오브젝트' 열
샘플이 들어오는 ELF 이미지의 이름을 표시합니다(샘플에서 가져온 샘플 [kernel.kallsyms] is used).
<Symbol> 열
함수 이름 또는 기호를 표시합니다.

기본 모드에서 함수는 가장 높은 오버헤드가 먼저 표시된 순서를 사용하여 내림차순으로 정렬됩니다.

19.8. 다른 장치에서 읽을 수 있는 perf.data 파일 생성

perf 툴을 사용하여 다른 장치에서 분석할 수 있도록 perf.data 파일에 성능 데이터를 기록할 수 있습니다.

사전 요구 사항

절차

  1. 더 조사하고자 하는 성능 데이터를 캡처합니다.

    # perf record -a --call-graph fp sleep seconds

    이 예제에서는 sleep 명령을 사용하여 지시한 시간( ) 동안 전체 시스템에 대해 perf.data 를 생성합니다. 또한 프레임 포인터 방법을 사용하여 호출 그래프 데이터를 캡처합니다.

  2. 기록된 데이터의 디버그 기호가 포함된 아카이브 파일을 생성합니다.

    # perf archive

검증 단계

  • 현재 활성 디렉터리에 아카이브 파일이 생성되었는지 확인합니다.

    # ls perf.data*

    출력에는 현재 디렉토리의 모든 파일이 perf.data 로 표시됩니다. 아카이브 파일의 이름은 다음과 같습니다.

    perf.data.tar.gz

    또는

    perf.data.tar.bz2

19.9. 다른 장치에서 생성된 perf.data 파일 분석

perf 툴을 사용하여 다른 장치에서 생성된 perf.data 파일을 분석할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.
  • 다른 장치에 생성된 perf.data 파일 및 연결된 아카이브 파일이 현재 장치에 있습니다.

절차

  1. perf.data 파일과 아카이브 파일을 현재 활성 디렉터리에 복사합니다.
  2. 아카이브 파일을 ~/.debug 로 추출합니다.

    # mkdir -p ~/.debug
    # tar xf perf.data.tar.bz2 -C ~/.debug
    참고

    아카이브 파일의 이름은 perf.data.tar.gz 로 지정됩니다.

  3. 추가 분석을 위해 perf.data 파일을 엽니다.

    # perf report

19.10. perf가 일부 함수 이름을 원시 함수 주소로 표시하는 이유

커널 함수의 경우, perf/proc/kallsyms 파일의 정보를 사용하여 샘플을 각 함수 이름 또는 기호에 매핑합니다. 그러나 사용자 공간으로 실행되는 함수의 경우 바이너리가 제거되었기 때문에 원시 함수 주소가 표시될 수 있습니다.

실행 파일의 debuginfo 패키지를 설치하거나 실행 파일이 로컬에서 개발된 애플리케이션인 경우 이러한 상황에서 함수 이름 또는 기호를 표시하려면 애플리케이션(G의 -g 옵션)이 켜진 디버깅 정보로 컴파일해야 합니다.

참고

실행 파일과 연결된 debuginfo 를 설치한 후 perf record 명령을 다시 실행할 필요가 없습니다. perf report 명령을 다시 실행하면 됩니다.

19.11. 디버그 및 소스 리포지토리 활성화

Red Hat Enterprise Linux의 표준 설치는 디버그 및 소스 리포지토리를 활성화하지 않습니다. 이러한 리포지토리에는 시스템 구성 요소를 디버깅하고 성능을 측정하는 데 필요한 정보가 포함되어 있습니다.

절차

  • 소스 및 디버그 정보 패키지 채널 활성화: $(uname -i) 부분은 시스템의 아키텍처에 대해 일치하는 값으로 자동 교체됩니다.

    아키텍처 이름

    64비트 Intel 및 AMD

    x86_64

    64비트 ARM

    aarch64

    IBM POWER

    ppc64le

    64-bit IBM Z

    s390x

19.12. GDB를 사용하여 애플리케이션 또는 라이브러리를 위한 debuginfo 패키지 가져오기

코드를 디버깅하려면 디버깅 정보가 필요합니다. 패키지에서 설치된 코드의 경우 GNU Debugger(GDB)는 누락된 디버그 정보를 자동으로 인식하고 패키지 이름을 확인하고 패키지를 가져오는 방법에 대한 구체적인 조언을 제공합니다.

사전 요구 사항

  • 디버그하려는 애플리케이션 또는 라이브러리가 시스템에 설치되어 있어야 합니다.
  • GDB 및 debuginfo-install 툴이 시스템에 설치되어 있어야 합니다. 자세한 내용은 애플리케이션 디버그 설정을 참조하십시오.
  • debuginfodebugsource 패키지를 제공하는 리포지토리는 시스템에서 구성하고 활성화해야 합니다. 자세한 내용은 디버그 및 소스 리포지토리 활성화를 참조하십시오.

절차

  1. 디버깅하려는 애플리케이션 또는 라이브러리에 GDB 연결을 시작합니다. GDB는 누락된 디버깅 정보를 자동으로 인식하며 실행할 명령을 제안합니다.

    $ gdb -q /bin/ls
    Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done.
    (no debugging symbols found)...done.
    Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64
    (gdb)
  2. exit GDB: q 를 입력하고 Enter 를 사용하여 확인합니다.

    (gdb) q
  3. GDB에서 제안한 명령을 실행하여 필요한 debuginfo 패키지를 설치합니다.

    # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

    dnf 패키지 관리 도구는 변경 사항에 대한 요약을 제공하고 확인을 요청하며 확인 후 필요한 모든 파일을 다운로드하여 설치합니다.

  4. case GDB는 debuginfo 패키지를 제안할 수 없으며 애플리케이션 또는 라이브러리에 대한 debuginfo 패키지 가져오기에 설명된 절차를 수동으로 수행합니다.

20장. perf로 사용 중인 CPU 조사

시스템의 성능 문제를 조사할 때 perf 툴을 사용하여 작업에 중점을 두기 위해 CPU를 식별하고 모니터링할 수 있습니다.

20.1. perf 통계로 계산된 CPU 이벤트 표시

CPU 수 집계를 비활성화하여 perf stat 를 사용하여 계산된 CPU 이벤트를 표시할 수 있습니다. 이 기능을 사용하려면 -a 플래그를 사용하여 시스템 전체 모드에서 이벤트를 계산해야 합니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  • CPU 수 집계가 비활성화된 이벤트 수를 계산합니다.

    # perf stat -a -A sleep seconds

    이전 예제는 CPU0 부터 각 개별 CPU를 통해 sleep 명령을 사용하여 지시한 대로 몇 동안 기록된 기본 하드웨어 및 소프트웨어 이벤트 세트의 수를 표시합니다. 따라서 사이클과 같은 이벤트를 지정하는 것이 유용할 수 있습니다.

    # perf stat -a -A -e cycles sleep seconds

20.2. perf 보고서에서 가져온 CPU 샘플 표시

perf record 명령은 성능 데이터를 샘플링하고 이 데이터를 perf report 명령으로 읽을 수 있는 perf.data 파일에 저장합니다. perf record 명령은 항상 수행된 CPU 샘플을 기록합니다. 이 정보를 표시하도록 perf 보고서를 구성할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.
  • 현재 디렉토리에 perf 레코드로 생성된 perf.data 파일이 있습니다. perf.data 파일이 루트 액세스 권한으로 생성된 경우 루트 액세스 권한을 사용하여 perf 보고서를 실행해야 합니다.

절차

  • CPU를 기준으로 정렬하는 동안 추가 분석을 위해 perf.data 파일의 내용을 표시합니다.

    # perf report --sort cpu
    • CPU 및 명령으로 정렬하여 CPU 시간이 소비되는 위치에 대한 자세한 정보를 표시할 수 있습니다.

      # perf report --sort cpu,comm

      이 예제에서는 오버헤드 사용량의 내림차순으로 총 오버헤드로 모니터링되는 모든 CPU의 명령을 나열하고 명령이 실행된 CPU를 식별합니다.

20.3. perf를 사용하여 프로파일링하는 동안 특정 CPU 표시

시스템을 실시간으로 프로파일링 하는 동안 특정 CPU 및 관련 사용량을 표시하도록 상단 을 구성할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  • CPU를 기준으로 정렬하는 동안 perf 최상위 인터페이스를 시작합니다.

    # perf top --sort cpu

    이 예제에서는 CPU 및 해당 오버헤드 사용량을 실시간으로 내림차순으로 나열합니다.

    • CPU 및 명령으로 CPU 시간이 소비되는 위치에 대한 자세한 정보를 정렬할 수 있습니다.

      # perf top --sort cpu,comm

      이 예제에서는 오버헤드 사용량의 내림차순으로 총 오버헤드별 명령을 나열하고 실시간으로 명령이 실행된 CPU를 식별합니다.

20.4. perf 레코드 및 perf 보고서를 사용하여 특정 CPU 모니터링

관심 있는 특정 CPU만 샘플하도록 perf 레코드 를 구성하고 추가 분석을 위해 perf 보고서를 사용하여 생성된 perf.data 파일을 분석할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  1. 샘플과 특정 CPU의 성능 데이터를 기록하여 perf.data 파일을 생성합니다.

    • 쉼표로 구분된 CPU 목록 사용:

      # perf record -C 0,1 sleep seconds

      이전 예제에서는 sleep 명령을 사용하여 지시한 시간 동안 CPU 0 및 1의 데이터를 몇 동안 샘플링하고 기록합니다.

    • 다양한 CPU 사용:

      # perf record -C 0-2 sleep seconds

      이전 예제에서는 sleep 명령의 사용에 따라 지정된 시간 동안 CPU 0에서 2 사이의 모든 CPU의 데이터를 샘플링하고 기록합니다.

  2. 추가 분석을 위해 perf.data 파일의 내용을 표시합니다.

    # perf report

    이 예제에서는 perf.data 의 내용을 표시합니다. 여러 CPU를 모니터링하고 샘플한 CPU 데이터를 알고자 하는 경우, perf 보고서에서 가져온 CPU 샘플 표시를 참조하십시오.

21장. perf로 애플리케이션 성능 모니터링

perf 툴을 사용하여 애플리케이션 성능을 모니터링하고 분석할 수 있습니다.

21.1. 실행 중인 프로세스에 perf 레코드 연결

실행 중인 프로세스에 perf 레코드 를 연결할 수 있습니다. 그러면 지정된 프로세스에 샘플 및 레코드 성능 데이터만 내리도록 perf 레코드에 지시합니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  • 실행 중인 프로세스에 perf 레코드 를 연결합니다.

    $ perf record -p ID1,ID2 sleep seconds

    이전 예제에서는 sleep 명령을 사용하여 지시한 시간 동안 프로세스 ID의 ID1ID2 를 사용하여 프로세스의 성능 데이터를 샘플링하고 기록합니다. 특정 스레드에서 이벤트를 기록하도록 perf 를 구성할 수도 있습니다.

    $ perf record -t ID1,ID2 sleep seconds
    참고

    -t 플래그를 사용하고 스레드 ID를 오케스트레이션하는 경우, perf 는 기본적으로 상속을 비활성화합니다. --inherit 옵션을 추가하여 상속을 활성화할 수 있습니다.

21.2. perf 레코드를 사용하여 호출 그래프 데이터 캡처

성능 프로필의 다른 함수를 호출하는 함수가 기록되도록 perf 레코드 도구를 구성할 수 있습니다. 이렇게 하면 여러 프로세스가 동일한 함수를 호출하는 경우 성능 장애를 확인하는 데 도움이 됩니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  • --call-graph 옵션을 사용하여 샘플 및 성능 데이터를 기록합니다.

    $ perf record --call-graph method command
    • 명령을 샘플 데이터 중 데이터로 바꿉니다. 명령을 지정하지 않으면 Perf 레코드Ctrl+C.
    • method 를 다음의 unwinding 방법 중 하나로 바꿉니다.

      fp
      프레임 포인터 메서드를 사용합니다. GCC 옵션으로 빌드된 바이너리와 같은 컴파일러 최적화에 따라 --fomit-frame-pointer.
      dwarf
      DWARF 호출 프레임 정보를 사용하여 스택의 배율을 해제합니다.
      lbr
      Intel 프로세서의 마지막 분기 레코드 하드웨어를 사용합니다.

추가 리소스

  • perf-record(1) man page

21.3. perf 보고서를 사용하여 perf.data 분석

perf 보고서를 사용하여 perf.data 파일을 표시하고 분석할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.
  • 현재 디렉터리에는 perf.data 파일이 있습니다.
  • perf.data 파일이 루트 액세스 권한으로 생성된 경우 루트 액세스 권한을 사용하여 perf 보고서를 실행해야 합니다.

절차

  • 추가 분석을 위해 perf.data 파일의 내용을 표시합니다.

    # perf report

    이 명령은 다음과 유사한 출력을 표시합니다.

    Samples: 2K of event 'cycles', Event count (approx.): 235462960
    Overhead  Command          Shared Object                     Symbol
       2.36%  kswapd0          [kernel.kallsyms]                 [k] page_vma_mapped_walk
       2.13%  sssd_kcm         libc-2.28.so                      [.] memset_avx2_erms 2.13% perf [kernel.kallsyms] [k] smp_call_function_single 1.53% gnome-shell libc-2.28.so [.] strcmp_avx2
       1.17%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_hash_table_lookup
       0.93%  Xorg             libc-2.28.so                      [.] memmove_avx_unaligned_erms 0.89% gnome-shell libgobject-2.0.so.0.5600.4 [.] g_object_unref 0.87% kswapd0 [kernel.kallsyms] [k] page_referenced_one 0.86% gnome-shell libc-2.28.so [.] memmove_avx_unaligned_erms
       0.83%  Xorg             [kernel.kallsyms]                 [k] alloc_vmap_area
       0.63%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_slice_alloc
       0.53%  gnome-shell      libgirepository-1.0.so.1.0.0      [.] g_base_info_unref
       0.53%  gnome-shell      ld-2.28.so                        [.] _dl_find_dso_for_object
       0.49%  kswapd0          [kernel.kallsyms]                 [k] vma_interval_tree_iter_next
       0.48%  gnome-shell      libpthread-2.28.so                [.] pthread_getspecific 0.47% gnome-shell libgirepository-1.0.so.1.0.0 [.] 0x0000000000013b1d 0.45% gnome-shell libglib-2.0.so.0.5600.4 [.] g_slice_free1 0.45% gnome-shell libgobject-2.0.so.0.5600.4 [.] g_type_check_instance_is_fundamentally_a 0.44% gnome-shell libc-2.28.so [.] malloc 0.41% swapper [kernel.kallsyms] [k] apic_timer_interrupt 0.40% gnome-shell ld-2.28.so [.] _dl_lookup_symbol_x 0.39% kswapd0 [kernel.kallsyms] [k] raw_callee_save___pv_queued_spin_unlock

추가 리소스

  • perf-report(1) 도움말 페이지

22장. perf를 사용하여 uprobes 생성

22.1. perf를 사용하여 함수 수준에서 uprobes 생성

perf 도구를 사용하여 프로세스 또는 애플리케이션의 임의의 시점에서 동적 추적 포인트를 생성할 수 있습니다. 그런 다음 이러한 추적점은 프로세스 또는 애플리케이션 동작을 더 잘 이해하기 위해 perf statperf 레코드와 같은 다른 perf 툴과 함께 사용할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  1. 프로세스 또는 애플리케이션 내에서 관심 있는 위치에서 모니터링에 관심이 있는 프로세스 또는 애플리케이션에 uprobe를 생성합니다.

    # perf probe -x /path/to/executable -a function
    Added new event:
      probe_executable:function   (on function in /path/to/executable)
    
    You can now use it in all perf tools, such as:
    
            perf record -e probe_executable:function -aR sleep 1

22.2. perf를 사용하여 함수 내에서 줄에 uprobes 생성

그런 다음 이러한 추적점은 프로세스 또는 애플리케이션 동작을 더 잘 이해하기 위해 perf statperf 레코드와 같은 다른 perf 툴과 함께 사용할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.
  • 실행 파일의 디버깅 기호를 가져옵니다.Gets the debugging symbols for your executable:

    # objdump -t ./your_executable | head
    참고

    이렇게 하려면 실행 파일의 debuginfo 패키지를 설치하거나, 실행 파일이 로컬에서 개발한 애플리케이션인 경우, 디버깅 정보를 사용하여 애플리케이션을 컴파일해야 하며 GCC의 -g 옵션을 사용해야 합니다.

절차

  1. uprobe를 배치할 수 있는 함수 행을 확인합니다.

    $ perf probe -x ./your_executable -L main

    이 명령의 출력은 다음과 유사합니다.

    <main@/home/user/my_executable:0>
                  0  int main(int argc, const char **argv)
                  1  {
                            int err;
                            const char *cmd;
                            char sbuf[STRERR_BUFSIZE];
    
                            /* libsubcmd init */
                  7         exec_cmd_init("perf", PREFIX, PERF_EXEC_PATH, EXEC_PATH_ENVIRONMENT);
                  8         pager_init(PERF_PAGER_ENVIRONMENT);
  2. 원하는 함수 행에 대한 uprobe를 생성합니다.

    # perf probe -x ./my_executable main:8
    Added new event:
              probe_my_executable:main_L8   (on main:8 in /home/user/my_executable)
    
            You can now use it in all perf tools, such as:
    
                    perf record -e probe_my_executable:main_L8 -aR sleep 1

22.3. uprobes에서 기록된 데이터의 perf 스크립트 출력

uprobes를 사용하여 수집된 데이터를 분석하는 일반적인 방법은 perf script 명령을 사용하여 perf.data 파일을 읽고 기록된 워크로드의 세부 추적을 표시하는 것입니다.

perf 스크립트 예제 출력에서 다음을 수행합니다.

  • my_prog라는 프로그램에서 uprobe 함수에 추가됩니다.
  • a 는 uprobe에 추가된 함수 인수입니다. 또는 uprobe를 추가하는 코드 범위에 표시되는 임의의 변수가 될 수 있습니다.
# perf script
    my_prog  1367 [007] 10802159.906593: probe_my_prog:isprime: (400551) a=2
    my_prog  1367 [007] 10802159.906623: probe_my_prog:isprime: (400551) a=3
    my_prog  1367 [007] 10802159.906625: probe_my_prog:isprime: (400551) a=4
    my_prog  1367 [007] 10802159.906627: probe_my_prog:isprime: (400551) a=5
    my_prog  1367 [007] 10802159.906629: probe_my_prog:isprime: (400551) a=6
    my_prog  1367 [007] 10802159.906631: probe_my_prog:isprime: (400551) a=7
    my_prog  1367 [007] 10802159.906633: probe_my_prog:isprime: (400551) a=13
    my_prog  1367 [007] 10802159.906635: probe_my_prog:isprime: (400551) a=17
    my_prog  1367 [007] 10802159.906637: probe_my_prog:isprime: (400551) a=19

23장. perf mem를 사용하여 메모리 액세스 프로파일링

perf mem 명령을 사용하여 시스템의 메모리 액세스를 샘플링할 수 있습니다.

23.1. perf mem의 목적

perf 툴의 mem 하위 명령을 사용하면 메모리 액세스 샘플링(로드 및 저장소)을 사용할 수 있습니다. perf mem 명령은 메모리 대기 시간, 메모리 액세스 유형, 캐시 적중 및 누락을 유발하는 기능, 데이터 기호를 기록하여 이러한 히트 및 누락에 대한 메모리 위치를 제공합니다.

23.2. perf mem를 사용하여 샘플링 메모리 액세스

이 절차에서는 perf mem 명령을 사용하여 시스템에서 메모리 액세스를 샘플하는 방법을 설명합니다. 이 명령은 perf 레코드 및 perf 보고서와 동일한 옵션을 사용하며 mem 하위 명령에 독점적인 일부 옵션을 사용합니다. 기록된 데이터는 나중에 분석을 위해 현재 디렉터리에 있는 perf.data 파일에 저장됩니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  1. 메모리 액세스 샘플:

    # perf mem record -a sleep seconds

    이 예제에서는 sleep 명령으로 지정된 대로 모든 CPU에서 몇 동안 메모리에 액세스합니다. 메모리 액세스 데이터를 샘플하려는 명령에 대해 sleep 명령을 교체할 수 있습니다. 기본적으로 perf mem 는 메모리가 로드 및 저장소를 모두 샘플링합니다. t 옵션을 사용하여 하나의 메모리 작업만 선택하고 perf mem레코드 간에 "load" 또는 "store"를 지정할 수 있습니다. 로드의 경우 메모리 계층 수준, TLB 메모리 액세스, 버스 스노크 및 메모리 잠금에 대한 정보가 캡처됩니다.

  2. 분석을 위해 perf.data 파일을 엽니다.

    # perf mem report

    예제 명령을 사용한 경우 출력은 다음과 같습니다.

    Available samples
    35k cpu/mem-loads,ldlat=30/P
    54k cpu/mem-stores/P

    cpu/mem-loads,ldlat=30/P 행은 메모리 로드를 통해 수집된 데이터를 나타내며 cpu/mem-stores/P 행은 메모리 저장소를 통해 수집된 데이터를 나타냅니다. 관심 카테고리를 강조 표시하고 Enter 를 눌러 데이터를 확인합니다.

    Samples: 35K of event 'cpu/mem-loads,ldlat=30/P', Event count (approx.): 4067062
    Overhead       Samples  Local Weight  Memory access             Symbol                                                                 Shared Object                 Data Symbol                                                     Data Object                            Snoop         TLB access              Locked
       0.07%            29  98            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.06%            26  97            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.06%            25  96            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.06%             1  2325          Uncached or N/A hit       [k] pci_azx_readl                                                      [kernel.kallsyms]             [k] 0xffffb092c06e9084                                          [kernel.kallsyms]                      None          L1 or L2 hit            No
       0.06%             1  2247          Uncached or N/A hit       [k] pci_azx_readl                                                      [kernel.kallsyms]             [k] 0xffffb092c06e8164                                          [kernel.kallsyms]                      None          L1 or L2 hit            No
       0.05%             1  2166          L1 or L1 hit              [.] 0x00000000038140d6                                                 libxul.so                     [.] 0x00007ffd7b84b4a8                                          [stack]                                None          L1 or L2 hit            No
       0.05%             1  2117          Uncached or N/A hit       [k] check_for_unclaimed_mmio                                           [kernel.kallsyms]             [k] 0xffffb092c1842300                                          [kernel.kallsyms]                      None          L1 or L2 hit            No
       0.05%            22  95            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.05%             1  1898          L1 or L1 hit              [.] 0x0000000002a30e07                                                 libxul.so                     [.] 0x00007f610422e0e0                                          anon                                   None          L1 or L2 hit            No
       0.05%             1  1878          Uncached or N/A hit       [k] pci_azx_readl                                                      [kernel.kallsyms]             [k] 0xffffb092c06e8164                                          [kernel.kallsyms]                      None          L2 miss                 No
       0.04%            18  94            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.04%             1  1593          Local RAM or RAM hit      [.] 0x00000000026f907d                                                 libxul.so                     [.] 0x00007f3336d50a80                                          anon                                   Hit           L2 miss                 No
       0.03%             1  1399          L1 or L1 hit              [.] 0x00000000037cb5f1                                                 libxul.so                     [.] 0x00007fbe81ef5d78                                          libxul.so                              None          L1 or L2 hit            No
       0.03%             1  1229          LFB or LFB hit            [.] 0x0000000002962aad                                                 libxul.so                     [.] 0x00007fb6f1be2b28                                          anon                                   None          L2 miss                 No
       0.03%             1  1202          LFB or LFB hit            [.] __pthread_mutex_lock                                               libpthread-2.29.so            [.] 0x00007fb75583ef20                                          anon                                   None          L1 or L2 hit            No
       0.03%             1  1193          Uncached or N/A hit       [k] pci_azx_readl                                                      [kernel.kallsyms]             [k] 0xffffb092c06e9164                                          [kernel.kallsyms]                      None          L2 miss                 No
       0.03%             1  1191          L1 or L1 hit              [k] azx_get_delay_from_lpib                                            [kernel.kallsyms]             [k] 0xffffb092ca7efcf0                                          [kernel.kallsyms]                      None          L1 or L2 hit            No

    또는 데이터를 표시할 때 다양한 관심 측면을 조사하도록 결과를 정렬할 수 있습니다. 예를 들어, 메모리 로드를 통해 데이터를 샘플링 기간 동안 처리하는 오버헤드 순서의 내림차순으로 발생하는 메모리 액세스 유형별로 정렬하려면 다음을 수행합니다.

    # perf mem -t load report --sort=mem

    예를 들어 출력은 다음과 같습니다.

    Samples: 35K of event 'cpu/mem-loads,ldlat=30/P', Event count (approx.): 40670
    Overhead       Samples  Memory access
      31.53%          9725  LFB or LFB hit
      29.70%         12201  L1 or L1 hit
      23.03%          9725  L3 or L3 hit
      12.91%          2316  Local RAM or RAM hit
       2.37%           743  L2 or L2 hit
       0.34%             9  Uncached or N/A hit
       0.10%            69  I/O or N/A hit
       0.02%           825  L3 miss

추가 리소스

  • perf-mem(1) 도움말 페이지.

23.3. perf mem 보고서 출력 해석

수정자 없이 perf mem report 명령을 실행하여 표시되는 표는 여러 열로 데이터를 정렬합니다.

'Overhead' 열
이 특정 함수에서 수집된 전체 샘플의 백분율을 나타냅니다.
<Samples> 열
해당 행에 의해 계산된 샘플 수를 표시합니다.
<Local Weight> 열
프로세서 코어 사이클에서 액세스 대기 시간을 표시합니다.
'Memory Access' 열
발생한 메모리 액세스 유형을 표시합니다.
<Symbol> 열
함수 이름 또는 기호를 표시합니다.
'공유 오브젝트' 열
샘플이 들어오는 ELF 이미지의 이름을 표시합니다(샘플에서 가져온 샘플 [kernel.kallsyms] is used).
'Data Symbol' 열
행이 대상으로 한 메모리 위치의 주소를 표시합니다.
중요

일반적으로 액세스하는 메모리 또는 스택 메모리의 동적 할당으로 인해 'Data Symbol' 열에 원시 주소가 표시됩니다.

<Snoop> 열
버스 트랜잭션을 표시합니다.
'TLB 액세스' 열
TLB 메모리 액세스를 표시합니다.
<Locked> 열
함수가 잠겼거나 메모리가 잠겼는지 여부를 나타냅니다.

기본 모드에서 함수는 가장 높은 오버헤드가 먼저 표시된 순서를 사용하여 내림차순으로 정렬됩니다.

24장. 잘못된 공유 감지

잘못된 공유는 Symmetric Multi Processing(SMP) 시스템의 프로세서 코어가 다른 프로세서에서 사용 중인 동일한 캐시 라인의 데이터 항목을 수정하여 프로세서 간에 공유되지 않는 다른 데이터 항목에 액세스할 때 발생합니다.

이러한 초기 수정을 위해서는 캐시 라인을 사용하는 다른 프로세서가 해당 사본을 무효화하고 업데이트된 프로세서를 요청할 필요가 없으며 수정된 데이터 항목의 업데이트된 버전에 액세스할 필요가 없습니다.

perf c2c 명령을 사용하여 잘못된 공유를 탐지할 수 있습니다.

24.1. perf c2c의 목적

perf 툴의 c2c 하위 명령을 사용하면 C2C(공유 데이터 캐시) 분석을 활성화합니다. perf c2c 명령을 사용하여 캐시 라인 경합을 검사하여 true 및 false 공유를 모두 탐지할 수 있습니다.

캐시 라인 경합은 SMP(Symmetric Multi Processing) 시스템의 프로세서 코어가 다른 프로세서에서 사용 중인 동일한 캐시 라인의 데이터 항목을 수정할 때 발생합니다. 그런 다음 이 캐시 라인을 사용하는 다른 모든 프로세서는 사본을 무효화하고 업데이트된 프로세서를 요청해야 합니다. 이로 인해 성능이 저하될 수 있습니다.

perf c2c 명령은 다음 정보를 제공합니다.

  • 경합이 감지된 캐시 라인
  • 데이터 읽기 및 쓰기 프로세스
  • 경합을 유발하는 지침
  • 경합과 관련된 NUMA(Non-Uniform Memory Access) 노드

24.2. perf c2c를 사용하여 캐시 라인 경합 감지

perf c2c 명령을 사용하여 시스템의 캐시 라인 경합을 감지합니다.

perf c2c 명령은 c2c 하위 명령에만 사용할 수 있는 일부 옵션과 동일한 옵션을 지원합니다. 기록된 데이터는 나중에 분석을 위해 현재 디렉터리에 있는 perf.data 파일에 저장됩니다.

사전 요구 사항

  • perf 사용자 공간 도구가 설치됩니다. 자세한 내용은 perf 설치를 참조하십시오.

절차

  • perf c2c 를 사용하여 캐시 라인 경합을 감지합니다.

    # perf c2c record -a sleep seconds

    이 예제에서는 sleep 명령으로 지정된 시간 동안 모든 CPU에서 캐시 라인 경합 데이터를 샘플링하고 기록합니다. sleep 명령을 통해 캐시 라인 경합 데이터를 수집하려는 모든 명령으로 교체할 수 있습니다.

추가 리소스

  • perf-c2c(1) man page

24.3. perf c2c 레코드로 기록된 perf.data 파일 시각화

이 절차에서는 perf c2c 명령을 사용하여 기록된 perf.data 파일을 시각화하는 방법을 설명합니다.

사전 요구 사항

절차

  1. 추가 분석을 위해 perf.data 파일을 엽니다.

    # perf c2c report --stdio

    이 명령은 perf.data 파일을 터미널 내의 여러 그래프로 시각화합니다.

    =================================================
               Trace Event Information
    =================================================
     Total records                     :     329219
     Locked Load/Store Operations      :      14654
     Load Operations                   :      69679
     Loads - uncacheable               :          0
     Loads - IO                        :          0
     Loads - Miss                      :       3972
     Loads - no mapping                :          0
     Load Fill Buffer Hit              :      11958
     Load L1D hit                      :      17235
     Load L2D hit                      :         21
     Load LLC hit                      :      14219
     Load Local HITM                   :       3402
     Load Remote HITM                  :      12757
     Load Remote HIT                   :       5295
     Load Local DRAM                   :        976
     Load Remote DRAM                  :       3246
     Load MESI State Exclusive         :       4222
     Load MESI State Shared            :          0
     Load LLC Misses                   :      22274
     LLC Misses to Local DRAM          :        4.4%
     LLC Misses to Remote DRAM         :       14.6%
     LLC Misses to Remote cache (HIT)  :       23.8%
     LLC Misses to Remote cache (HITM) :       57.3%
     Store Operations                  :     259539
     Store - uncacheable               :          0
     Store - no mapping                :         11
     Store L1D Hit                     :     256696
     Store L1D Miss                    :       2832
     No Page Map Rejects               :       2376
     Unable to parse data source       :          1
    
    =================================================
       Global Shared Cache Line Event Information
    =================================================
     Total Shared Cache Lines          :         55
     Load HITs on shared lines         :      55454
     Fill Buffer Hits on shared lines  :      10635
     L1D hits on shared lines          :      16415
     L2D hits on shared lines          :          0
     LLC hits on shared lines          :       8501
     Locked Access on shared lines     :      14351
     Store HITs on shared lines        :     109953
     Store L1D hits on shared lines    :     109449
     Total Merged records              :     126112
    
    =================================================
                     c2c details
    =================================================
     Events                            : cpu/mem-loads,ldlat=30/P
    	                                    : cpu/mem-stores/P
     Cachelines sort on                : Remote HITMs
     Cacheline data groupping          : offset,pid,iaddr
    
    =================================================
    	   Shared Data Cache Line Table
    =================================================
    #
    #                              Total      Rmt  ----- LLC Load Hitm -----  ---- Store Reference ----  --- Load Dram ----      LLC    Total  ----- Core Load Hit -----  -- LLC Load Hit --
    # Index           Cacheline  records     Hitm    Total      Lcl      Rmt    Total    L1Hit   L1Miss       Lcl       Rmt  Ld Miss    Loads       FB       L1       L2       Llc       Rmt
    # .....  ..................  .......  .......  .......  .......  .......  .......  .......  .......  ........  ........  .......  .......  .......  .......  .......  ........  ........
    #
          0            0x602180   149904   77.09%    12103     2269     9834   109504   109036      468       727      2657    13747    40400     5355    16154        0      2875       529
          1            0x602100    12128   22.20%     3951     1119     2832        0        0        0        65       200     3749    12128     5096      108        0      2056       652
          2  0xffff883ffb6a7e80      260    0.09%       15        3       12      161      161        0         1         1       15       99       25       50        0         6         1
          3  0xffffffff81aec000      157    0.07%        9        0        9        1        0        1         0         7       20      156       50       59        0        27         4
          4  0xffffffff81e3f540      179    0.06%        9        1        8      117       97       20         0        10       25       62       11        1        0        24         7
    
    =================================================
          Shared Cache Line Distribution Pareto
    =================================================
    #
    #        ----- HITM -----  -- Store Refs --        Data address                               ---------- cycles ----------       cpu                                     Shared
    #   Num      Rmt      Lcl   L1 Hit  L1 Miss              Offset      Pid        Code address  rmt hitm  lcl hitm      load       cnt               Symbol                Object                  Source:Line  Node{cpu list}
    # .....  .......  .......  .......  .......  ..................  .......  ..................  ........  ........  ........  ........  ...................  ....................  ...........................  ....
    #
      -------------------------------------------------------------
          0     9834     2269   109036      468            0x602180
      -------------------------------------------------------------
              65.51%   55.88%   75.20%    0.00%                 0x0    14604            0x400b4f     27161     26039     26017         9  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:144   0{0-1,4}  1{24-25,120}  2{48,54}  3{169}
    	   0.41%    0.35%    0.00%    0.00%                 0x0    14604            0x400b56     18088     12601     26671         9  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:145   0{0-1,4}  1{24-25,120}  2{48,54}  3{169}
    	   0.00%    0.00%   24.80%  100.00%                 0x0    14604            0x400b61         0         0         0         9  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:145   0{0-1,4}  1{24-25,120}  2{48,54}  3{169}
    	   7.50%    9.92%    0.00%    0.00%                0x20    14604            0x400ba7      2470      1729      1897         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:154   1{122}  2{144}
    	  17.61%   20.89%    0.00%    0.00%                0x28    14604            0x400bc1      2294      1575      1649         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:158   2{53}  3{170}
    	   8.97%   12.96%    0.00%    0.00%                0x30    14604            0x400bdb      2325      1897      1828         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:162   0{96}  3{171}
    
      -------------------------------------------------------------
          1     2832     1119        0        0            0x602100
      -------------------------------------------------------------
    	  29.13%   36.19%    0.00%    0.00%                0x20    14604            0x400bb3      1964      1230      1788         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:155   1{122}  2{144}
    	  43.68%   34.41%    0.00%    0.00%                0x28    14604            0x400bcd      2274      1566      1793         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:159   2{53}  3{170}
    	  27.19%   29.40%    0.00%    0.00%                0x30    14604            0x400be7      2045      1247      2011         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:163   0{96}  3{171}

24.4. perf c2c 보고서 출력의 해석

perf c2c 보고서를 실행하여 표시되는 시각화 --stdio 명령은 데이터를 여러 테이블로 정렬합니다.

추적 이벤트 정보
이 표는 모든 로드 및 저장소 샘플에 대한 높은 수준의 요약을 제공하며, 이는 perf c2c record 명령으로 수집됩니다.
글로벌 공유 캐시 라인 이벤트 정보
이 테이블은 공유 캐시 라인에 대한 통계를 제공합니다.
c2c 세부 정보
이 표는 샘플된 이벤트 및 시각화에서 perf c2c 보고서 데이터를 구성하는 방법에 대한 정보를 제공합니다.
공유 데이터 캐시 라인 테이블
이 표는 잘못된 공유가 감지되고 기본적으로 캐시 라인별로 감지된 원격 Hitm 의 양으로 내림차순으로 정렬된 hottest 캐시 행에 대한 한 줄 요약을 제공합니다.
공유 캐시 라인 배포 Pareto

이 표는 경합이 발생하는 각 캐시 라인에 대한 다양한 정보를 제공합니다.

  • 캐시 줄은 NUM 열에서 번호가 매겨지며 0 부터 시작합니다.
  • 각 캐시 라인의 가상 주소는 데이터 주소 Offset 열에 포함되어 있으며 그 다음에 다른 액세스가 발생한 캐시 라인의 오프셋이 포함됩니다.
  • Pid 열에는 프로세스 ID가 포함됩니다.
  • Code Address 열에는 명령 포인터 코드 주소가 포함되어 있습니다.
  • 사이클 레이블 아래의 열에는 평균 부하 대기 시간이 표시됩니다.
  • cpu cnt 열에는 제공된 CPU 샘플 수(즉, 지정된 위치에서 인덱싱된 데이터를 기다리는 CPU 수)가 표시됩니다.
  • Symbol 열에 함수 이름 또는 기호가 표시됩니다.
  • Shared Object 열에는 샘플이 들어오는 ELF 이미지의 이름이 표시됩니다(이름 [kernel.kallsyms]은 커널에서 가져올 때 사용됩니다).
  • Source:Line 열에는 소스 파일 및 행 번호가 표시됩니다.
  • Node{cpu list} 열에는 각 노드에 대해 제공된 특정 CPU 샘플이 표시됩니다.

24.5. perf c2c로 잘못된 공유 탐지

이 절차에서는 perf c2c 명령을 사용하여 잘못된 공유를 감지하는 방법을 설명합니다.

사전 요구 사항

절차

  1. 추가 분석을 위해 perf.data 파일을 엽니다.

    # perf c2c report --stdio

    그러면 터미널에서 perf.data 파일이 열립니다.

  2. "Trace Event Information" 표에서 NFD Mises to Remote Cache (HITM)에 대한 값이 포함된 행을 찾습니다.

    NFD Mises to Remote Cache (HITM) 행의 값 열에 있는 백분율은 수정된 캐시 줄의 NUMA 노드에서 발생했으며 키 표시기 거짓 공유가 발생했음을 나타내는 <.> 누락의 백분율을 나타냅니다.

    =================================================
                Trace Event Information
    =================================================
      Total records                     :     329219
      Locked Load/Store Operations      :      14654
      Load Operations                   :      69679
      Loads - uncacheable               :          0
      Loads - IO                        :          0
      Loads - Miss                      :       3972
      Loads - no mapping                :          0
      Load Fill Buffer Hit              :      11958
      Load L1D hit                      :      17235
      Load L2D hit                      :         21
      Load LLC hit                      :      14219
      Load Local HITM                   :       3402
      Load Remote HITM                  :      12757
      Load Remote HIT                   :       5295
      Load Local DRAM                   :        976
      Load Remote DRAM                  :       3246
      Load MESI State Exclusive         :       4222
      Load MESI State Shared            :          0
      Load LLC Misses                   :      22274
      LLC Misses to Local DRAM          :        4.4%
      LLC Misses to Remote DRAM         :       14.6%
      LLC Misses to Remote cache (HIT)  :       23.8%
      LLC Misses to Remote cache (HITM) : 57.3%
      Store Operations                  :     259539
      Store - uncacheable               :          0
      Store - no mapping                :         11
      Store L1D Hit                     :     256696
      Store L1D Miss                    :       2832
      No Page Map Rejects               :       2376
      Unable to parse data source       :          1
  3. 공유 데이터 캐시 라인 테이블의 LLC Load Hitm 필드의 Rmt 열을 검사합니다.

      =================================================
                 Shared Data Cache Line Table
      =================================================
      #
      #                              Total      Rmt  ----- LLC Load Hitm -----  ---- Store Reference ----  --- Load Dram ----      LLC    Total  ----- Core Load Hit -----  -- LLC Load Hit --
      # Index           Cacheline  records     Hitm    Total      Lcl      Rmt    Total    L1Hit   L1Miss       Lcl       Rmt  Ld Miss    Loads       FB       L1       L2       Llc       Rmt
      # .....  ..................  .......  .......  .......  .......  .......  .......  .......  .......  ........  ........  .......  .......  .......  .......  .......  ........  ........
      #
            0            0x602180   149904   77.09%    12103     2269     9834   109504   109036      468       727      2657    13747    40400     5355    16154        0      2875       529
            1            0x602100    12128   22.20%     3951     1119     2832        0        0        0        65       200     3749    12128     5096      108        0      2056       652
            2  0xffff883ffb6a7e80      260    0.09%       15        3       12      161      161        0         1         1       15       99       25       50        0         6         1
            3  0xffffffff81aec000      157    0.07%        9        0        9        1        0        1         0         7       20      156       50       59        0        27         4
            4  0xffffffff81e3f540      179    0.06%        9        1        8      117       97       20         0        10       25       62       11        1        0        24         7

    이 테이블은 캐시 줄당 감지된 원격 Hitm 의 양으로 내림차순으로 정렬됩니다. NFD Load Hit m 섹션의 Rmt 열에 있는 높은 수는 false 공유를 나타내며 잘못된 공유 활동을 디버깅하는 데 발생한 캐시 라인을 추가로 검사해야 합니다.

25장. fireamegraphs 시작하기

시스템 관리자는 사파 그래프를 사용하여 perf 도구로 기록된 시스템 성능 데이터의 시각화를 생성할 수 있습니다. 소프트웨어 개발자는 fireame graphs 를 사용하여 perf 도구로 기록된 애플리케이션 성능 데이터의 시각화를 생성할 수 있습니다.

샘플링 스택 추적은 perf 툴을 사용하여 CPU 성능을 프로파일링하는 일반적인 기술입니다. 유감스럽게도, perf 를 사용한 스택 추적의 결과는 분석하는 데 매우 상세하고 인건비 집약적일 수 있습니다. Flaamegraphs 는 핫 코드 경로를 더 빠르고 쉽게 식별할 수 있도록 perf 로 기록된 데이터에서 생성되는 시각화입니다.

25.1. fireamegraphs 설치

flamegraphs 사용을 시작하려면 필요한 패키지를 설치하십시오.

절차

  • fiream egraphs 패키지를 설치합니다.

    # dnf install js-d3-flame-graph

25.2. 전체 시스템에 불amegraphs 생성

이 절차에서는 fireame graphs 를 사용하여 전체 시스템에 대해 기록된 성능 데이터를 시각화하는 방법을 설명합니다.

사전 요구 사항

절차

  • 데이터를 기록하고 시각화를 생성합니다.

    # perf script flamegraph -a -F 99 sleep 60

    이 명령은 sleep 명령을 사용하여 설명하는 것처럼 전체 시스템에 대해 성능 데이터를 샘플링하고 기록한 다음, 현재 활성 디렉터리에 저장될 시각화를 구성했습니다. 이 명령은 기본적으로 호출 그래프 데이터를 샘플링하고 perf 툴과 동일한 인수를 사용합니다. 이 경우 다음과 같습니다.

    -a
    전체 시스템에 대한 데이터를 기록하도록 설정합니다.
    -F
    초당 샘플링 빈도를 설정하려면 다음을 수행합니다.

검증 단계

  • 분석을 위해 생성된 시각화를 확인합니다.

    # xdg-open flamegraph.html

    이 명령은 기본 브라우저에서 시각화를 엽니다.

    flamegraph allcpus

25.3. 특정 프로세스에 대한 불amegraphs 생성

flamegraphs 를 사용하여 실행 중인 특정 프로세스에 대해 기록된 성능 데이터를 시각화할 수 있습니다.

사전 요구 사항

절차

  • 데이터를 기록하고 시각화를 생성합니다.

    # perf script flamegraph -a -F 99 -p ID1,ID2 sleep 60

    이 명령은 sleep 명령을 사용하여 설명하는 대로 프로세스 ID1 및 ID2로 프로세스 ID1ID2 를 사용하여 프로세스의 성능 데이터를 기록한 다음 현재 활성 디렉터리에 저장될 시각화를 구성하며, 현재 활성 디렉터리에 저장된 시각화를 coname graph.html 로 구성합니다. 이 명령은 기본적으로 호출 그래프 데이터를 샘플링하고 perf 툴과 동일한 인수를 사용합니다. 이 경우 다음과 같습니다.

    -a
    전체 시스템에 대한 데이터를 기록하도록 설정합니다.
    -F
    초당 샘플링 빈도를 설정하려면 다음을 수행합니다.
    -p
    특정 프로세스 ID를 샘플로 지정하고 데이터를 기록하려면 다음을 수행합니다.

검증 단계

  • 분석을 위해 생성된 시각화를 확인합니다.

    # xdg-open flamegraph.html

    이 명령은 기본 브라우저에서 시각화를 엽니다.

    flamegraph

25.4. 불amegraphs 해석

플로브그의 각 박스는 스택의 다른 기능을 나타냅니다. y축은 각 스택의 가장 높은 박스가 있는 스택의 깊이를 보여줍니다. 각 스택은 실제로 on-CPU이고 그 아래의 모든 것이 ancestry인 함수입니다. X축은 샘플 호출-그래픽 데이터의 채우기를 표시합니다.

지정된 행에 스택의 자식은 x 축을 따라 각 함수의 내림차순으로 가져온 샘플 수에 따라 표시됩니다. x축은 통과 시간을 나타내지 않습니다. 개별 상자가 더 넓어지면 데이터가 샘플링되는 시점에 온-CPU 또는 온-CPU ancestry의 일부가되었습니다.

절차

  • 이전에 표시되지 않을 수 있는 함수 이름을 표시하고, 그 지정된 위치에서 스택을 확대하기 위해 플로브리 내의 상자에서 데이터 클릭을 추가로 조사합니다.

    zoomed in flamegraph

  • fireamegraph의 기본 보기로 돌아가려면 확대/축소 재설정 을 클릭합니다.
중요

사용자 공간 함수를 나타내는 박스는 함수의 바이너리가 제거되었기 때문에 플로 에서 알 수 없는 것으로 표시될 수 있습니다. 실행 파일의 debuginfo 패키지를 설치하거나 로컬에서 개발한 애플리케이션인 경우 디버깅 정보를 사용하여 애플리케이션을 컴파일해야 합니다. GCC에서 -g 옵션을 사용하여 이러한 상황에서 함수 이름 또는 기호를 표시합니다.

flamegraph

26장. perf 순환 버퍼를 사용하여 성능 병목 현상을 위한 프로세스 모니터링

시스템에서 실행되는 애플리케이션 일부 또는 특정 프로세스의 성능 병목 현상을 모니터링하기 위해 perf 툴을 사용하여 이벤트별 데이터 스냅샷을 사용하는 원형 버퍼를 생성할 수 있습니다. 이러한 경우, perf 는 지정된 이벤트가 감지된 경우에만 이후 분석을 위해 perf.data 파일에 데이터를 씁니다.

26.1. perf를 사용하여 순환 버퍼 및 이벤트별 스냅샷

프로세스 또는 perf 의 적용에서 성능 문제를 조사할 때 특정 관심 발생 시 몇 시간 전의 데이터를 기록하는 것이 저렴하거나 적절하지 않을 수 있습니다. 이러한 경우, perf 레코드 를 사용하여 특정 이벤트 후 스냅샷을 가져오는 사용자 지정 순환 버퍼를 생성할 수 있습니다.

--overwrite 옵션을 사용하면 perf 레코드 가 모든 데이터를 덮어쓸 수 있는 순환 버퍼에 저장합니다. 버퍼가 가득 차면 perf 레코드 가 가장 오래된 레코드를 자동으로 덮어쓰므로 perf.data 파일에 기록되지 않습니다.

--overwrite--switch-output-event 옵션을 함께 사용하면 --switch-output-event 트리거 이벤트를 탐지할 때까지 데이터를 기록하고 덤프하는 순환 버퍼를 구성합니다. 사용자에 대한 관심 있는 항목이 발생했으며 순환 버퍼의 데이터를 perf.data 파일에 기록하기 위해 perf 레코드에 대한 트리거 이벤트 신호입니다. 이렇게 하면 관심 있는 특정 데이터를 수집하지만 perf.data 파일에 원하지 않는 데이터를 작성하지 않고 실행 중인 perf 프로세스 오버헤드를 동시에 줄일 수 있습니다.

26.2. perf circular buffers를 사용하여 성능 병목 현상을 모니터링하기 위해 특정 데이터를 수집합니다.

perf 도구를 사용하면 관심 있는 데이터만 수집하기 위해 지정하는 이벤트에 의해 트리거되는 순환 버퍼를 생성할 수 있습니다. 이벤트별 데이터를 수집하는 순환 버퍼를 생성하려면 perf--overwrite--switch-output-event 옵션을 사용합니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.
  • 프로세스 또는 애플리케이션 내 관심 위치에서 모니터링에 관심이 있는 프로세스 또는 애플리케이션에 uprobe를 배치했습니다.

    # perf probe -x /path/to/executable -a function
    Added new event:
      probe_executable:function   (on function in /path/to/executable)
    
    You can now use it in all perf tools, such as:
    
            perf record -e probe_executable:function -aR sleep 1

절차

  • uprobe를 트리거 이벤트로 사용하여 원형 버퍼를 생성합니다.

    # perf record --overwrite -e cycles --switch-output-event probe_executable:function ./executable
    [ perf record: dump data: Woken up 1 times ]
    [ perf record: Dump perf.data.2021021012231959 ]
    [ perf record: dump data: Woken up 1 times ]
    [ perf record: Dump perf.data.2021021012232008 ]
    ^C[ perf record: dump data: Woken up 1 times ]
    [ perf record: Dump perf.data.2021021012232082 ]
    [ perf record: Captured and wrote 5.621 MB perf.data.<timestamp> ]

    이 예제에서는 실행 파일을 시작하고 -e 옵션 뒤에 지정된 cpu 사이클을 수집합니다. perf 가 uprobe를 탐지할 때까지 --switch-output-event 옵션 뒤에 지정된 트리거 이벤트입니다. 이 시점에서 perf 는 순환 버퍼에 있는 모든 데이터의 스냅샷을 사용하여 타임스탬프로 식별되는 고유한 perf.data 파일에 저장합니다. 이 예제에서는 총 2개의 스냅샷을 생성했으며 마지막 perf.data 파일은 Ctrl+c 를 눌러 강제 실행되었습니다.

27장. perf를 중지하거나 다시 시작하지 않고 실행 중인 perf 수집기에서 추적 지점 추가 및 제거

제어 파이프 인터페이스를 사용하여 실행 중인 perf 수집기에서 다른 추적 포인트를 활성화 및 비활성화함으로써 perf 를 중지하거나 재시작하지 않고도 수집하는 데이터를 동적으로 조정할 수 있습니다. 이렇게 하면 중지 또는 다시 시작 프로세스 중에 기록 된 성능 데이터가 손실되지 않습니다.

27.1. perf를 중지하거나 다시 시작하지 않고 실행 중인 perf 수집기에 추적 지점 추가

제어 파이프 인터페이스를 사용하여 실행 중인 perf 수집기에 추적 포인트를 추가하여 perf 를 중지하고 성능 데이터를 손실하지 않고도 기록 중인 데이터를 조정합니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  1. 제어 파이프 인터페이스를 구성합니다.

    # mkfifo control ack perf.pipe
  2. 관심 있는 컨트롤 파일 설정 및 이벤트를 사용하여 perf 레코드 를 실행합니다.

    # perf record --control=fifo:control,ack -D -1 --no-buffering -e 'sched:*' -o - > perf.pipe

    이 예제에서 -e 옵션 뒤에 'sched:*' 를 선언하면 스케줄러 이벤트가 포함된f 레코드 가 시작됩니다.

  3. 두 번째 터미널에서 제어 파이프의 읽기 측면을 시작합니다.

    # cat perf.pipe | perf --no-pager script -i -

    제어 파이프의 읽기 측면을 시작하면 첫 번째 터미널에서 다음 메시지가 트리거됩니다.

    Events disabled
  4. 세 번째 터미널에서 제어 파일을 사용하여 추적 지점을 활성화합니다.

    # echo 'enable sched:sched_process_fork' > control

    이 명령은 perf 를 트리거하여 선언된 이벤트에 대해 제어 파일의 현재 이벤트 목록을 스캔합니다. 이벤트가 있으면 tracepoint가 활성화되어 첫 번째 터미널에 다음 메시지가 표시됩니다.

    event sched:sched_process_fork enabled

    추적 지점이 활성화되면 두 번째 터미널은 추적 지점을 감지하는 perf 의 출력을 표시합니다.

    bash 33349 [034] 149587.674295: sched:sched_process_fork: comm=bash pid=33349 child_comm=bash child_pid=34056

27.2. perf를 중지하거나 다시 시작하지 않고 실행 중인 perf 수집기에서 추적 지점 제거

컨트롤 파이프 인터페이스를 사용하여 실행 중인 perf 수집기에서 추적 지점을 제거하여 모음별을 중지하고 성능 데이터를 손실하지 않고도 수집 중인 데이터 범위를 줄입니다.

사전 요구 사항

절차

  • 추적 지점을 제거합니다.

    # echo 'disable sched:sched_process_fork' > control
    참고

    이 예제에서는 이전에 스케줄러 이벤트를 제어 파일에 로드했으며 tracepoint sched_process_fork를 활성화했다고 가정합니다.

    이 명령은 perf 를 트리거하여 선언된 이벤트에 대해 제어 파일의 현재 이벤트 목록을 스캔합니다. 이벤트가 있는 경우 추적 지점이 비활성화되어 있으며 컨트롤 파이프를 구성하는 데 사용되는 터미널에 다음 메시지가 표시됩니다.

    event sched:sched_process_fork disabled

28장. numastat로 메모리 할당 프로파일링

numastat 툴을 사용하면 시스템의 메모리 할당에 대한 통계를 표시할 수 있습니다.

numastat 툴은 각 NUMA 노드의 데이터를 별도로 표시합니다. 이 정보를 사용하여 시스템의 메모리 성능 또는 시스템상의 다양한 메모리 정책의 효과를 조사할 수 있습니다.

28.1. 기본 numastat 통계

기본적으로 numastat 툴은 각 NUMA 노드의 이러한 데이터 카테고리에 대한 통계를 표시합니다.

numa_hit
이 노드에 성공적으로 할당된 페이지 수입니다.
numa_miss
예상 노드의 메모리가 부족하기 때문에 이 노드에 할당된 페이지 수입니다. 각 numa_miss 이벤트에는 다른 노드에 해당 numa_foreign 이벤트가 있습니다.
numa_foreign
이 노드의 원래는 다른 노드에 할당된 페이지 수입니다. 각 numa_foreign 이벤트에는 다른 노드에서 해당 numa_miss 이벤트가 있습니다.
interleave_hit
이 노드에 성공적으로 할당된 중간 정책 페이지 수입니다.
local_node
이 노드의 프로세스에 의해 이 노드에 성공적으로 할당된 페이지 수입니다.
other_node
다른 노드의 프로세스에 의해 이 노드에 할당된 페이지 수입니다.
참고

numa_hit 값과 낮은 numa_miss 값( other과 동일)은 최적의 성능을 나타냅니다.

28.2. numastat로 메모리 할당 보기

numastat 툴을 사용하여 시스템의 메모리 할당을 볼 수 있습니다.

사전 요구 사항

  • numactl 패키지를 설치합니다.

    # dnf install numactl

절차

  • 시스템의 메모리 할당을 확인합니다.

    $ numastat
                                 node0         node1
    numa_hit                  76557759      92126519
    numa_miss                 30772308      30827638
    numa_foreign              30827638      30772308
    interleave_hit              106507        103832
    local_node                76502227      92086995
    other_node                30827840      30867162

추가 리소스

  • numastat(8) 도움말 페이지

29장. CPU 사용률을 최적화하도록 운영 체제 구성

워크로드 전체의 CPU 사용률을 최적화하도록 운영 체제를 구성할 수 있습니다.

29.1. 프로세서 문제를 모니터링 및 진단하기 위한 툴

다음은 Red Hat Enterprise Linux 9에서 프로세서 관련 성능 문제를 모니터링하고 진단할 수 있는 툴입니다.

  • turbostat 툴은 관리자가 과도한 전원 사용과 같은 서버에서 예기치 않은 동작을 식별할 수 있도록 카운터 결과를 출력하고, 과도한 절전 상태를 입력하지 못하거나 시스템 관리 인터럽트(SMI)가 불필요하게 생성됩니다.
  • numactl 유틸리티는 프로세서 및 메모리 선호도를 관리하는 다양한 옵션을 제공합니다. numactl 패키지에는 커널에서 지원하는 NUMA 정책에 간단한 프로그래밍 인터페이스를 제공하는 libnuma 라이브러리가 포함되어 있으며 numactl 애플리케이션보다 더 세분화된 튜닝에 사용할 수 있습니다.
  • numastat 툴은 운영 체제 및 프로세스의 각 NUMAA 노드 메모리 통계를 표시하고, 프로세스 메모리가 시스템 전체에 분산되어 있는지 또는 특정 노드에 중앙 집중화되는지 관리자에게 표시합니다. 이 툴은 numactl 패키지에서 제공합니다.
  • numad 는 자동 NUMA 선호도 관리 데몬입니다. NUMA 리소스 할당 및 관리를 동적으로 개선하기 위해 시스템 내에서 NUMA 토폴로지 및 리소스 사용량을 모니터링합니다.
  • /proc/interrupts 파일은 인터럽트 요청(IRQ) 번호, 시스템의 각 프로세서가 처리하는 유사한 인터럽트 요청 수, 전송된 인터럽트 유형, 나열된 인터럽트 요청에 응답하는 쉼표로 구분된 장치 목록을 표시합니다.
  • pqos 유틸리티는 intel-cmt-cat 패키지에서 사용할 수 있습니다. 최근 Intel 프로세서에서 CPU 캐시 및 메모리 대역폭을 모니터링합니다. 다음을 모니터링합니다.

    • 언어별 지침(IPC)입니다.
    • 마지막 수준 캐시 MiSSES의 수입니다.
    • 지정된 CPU에서 프로그램이 실행되는 킬로바이트 크기(kilobytes)입니다.
    • 로컬 메모리(MBL)의 대역폭입니다.
    • 원격 메모리(MBR)의 대역폭입니다.
  • x86_energy_perf_policy 툴을 통해 관리자는 성능 및 에너지 효율성의 상대적 중요성을 정의할 수 있습니다. 그런 다음 이 정보를 사용하여 성능과 전력 효율성 사이에서 거래되는 옵션을 선택할 때 이러한 기능을 지원하는 프로세서에 영향을 미칠 수 있습니다.
  • taskset 툴은 util-linux 패키지에서 제공합니다. 관리자는 이를 통해 실행 중인 프로세스의 프로세서 선호도를 검색하고 설정하거나 지정된 프로세서 선호도로 프로세스를 시작할 수 있습니다.

추가 리소스

  • turbostat(8), numactl(8), numastat(8), numa(7), numad(8), pqos(8), x86_energy_perf_policy(8)taskset(1) 매뉴얼 페이지

29.2. 시스템 토폴로지 유형

최신 컴퓨팅에서는 대부분의 최신 시스템에 여러 프로세서가 있으므로 CPU에 대한 아이디어가 오를 수 있습니다. 시스템의 토폴로지는 이러한 프로세서가 서로 연결되고 다른 시스템 리소스에 연결하는 방식입니다. 이는 시스템 및 애플리케이션 성능과 시스템 튜닝 고려 사항에 영향을 미칠 수 있습니다.

다음은 최신 컴퓨팅에 사용되는 두 가지 기본 토폴로지 유형입니다.

대칭 MP(Multi-Processor) 토폴로지
NetNamespace 토폴로지를 사용하면 모든 프로세서가 동일한 시간 내에 메모리에 액세스할 수 있습니다. 그러나 공유 및 동일한 메모리 액세스가 본질적으로 모든 CPU에서 직렬화된 메모리 액세스를 강제 적용하기 때문에 ETL 시스템 확장 제약 조건이 일반적으로 예기치 않은 것으로 표시됩니다. 이러한 이유로 사실상 모든 최신 서버 시스템은 NUMA 시스템입니다.
NUMA(Non-Uniform Memory Access) 토폴로지

NUMA 토폴로지는 weekly 토폴로지보다 최근에 개발되었습니다. NUMA 시스템에서는 여러 개의 프로세서가 소켓에 물리적으로 그룹화됩니다. 각 소켓에는 해당 메모리에 대한 로컬 액세스 권한이 있는 전용 메모리 및 프로세서 영역이 있으며 이러한 영역은 노드라고 합니다. 동일한 노드의 프로세서는 해당 노드의 메모리 뱅크에 빠르게 액세스할 수 있으며 노드에 없는 메모리 은행에 대한 액세스 속도가 느려집니다.

따라서 로컬이 아닌 메모리에 액세스할 때 성능이 저하됩니다. 따라서 NUMA 토폴로지가 있는 시스템에서 성능에 민감한 애플리케이션은 애플리케이션을 실행하는 프로세서와 동일한 노드에 있는 메모리에 액세스해야 하며 가능한 경우 원격 메모리에 액세스하지 않아야 합니다.

성능에 민감한 다중 스레드 애플리케이션은 특정 프로세서가 아닌 특정 NUMA 노드에서 실행되도록 구성된 이점을 얻을 수 있습니다. 이것이 적합한지 여부는 시스템 및 애플리케이션의 요구 사항에 따라 달라집니다. 여러 애플리케이션 스레드가 동일한 캐시된 데이터에 액세스하는 경우 동일한 프로세서에서 실행되도록 해당 스레드를 구성하는 것이 적합할 수 있습니다. 그러나 서로 다른 데이터를 액세스 및 캐시하는 여러 스레드가 동일한 프로세서에서 실행되는 경우 각 스레드는 이전 스레드에서 액세스한 캐시된 데이터를 제거할 수 있습니다.However, if multiple threads that access and cache different data execute on the same processor, each thread may remove cached data accessed by a previous thread. 즉, 각 스레드가 캐시를 허용하여 메모리에서 데이터를 가져와 캐시에서 교체하는 실행 시간을 소비합니다. perf 툴을 사용하여 과도한 캐시 누락 수를 확인합니다.

29.2.1. 시스템 토폴로지 표시

시스템의 토폴로지를 이해하는 데 도움이 되는 여러 명령이 있습니다. 다음 절차에서는 시스템 토폴로지를 결정하는 방법을 설명합니다.

절차

  • 시스템 토폴로지 개요를 표시하려면 다음을 수행합니다.

    $ numactl --hardware
    available: 4 nodes (0-3)
    node 0 cpus: 0 4 8 12 16 20 24 28 32 36
    node 0 size: 65415 MB
    node 0 free: 43971 MB
    [...]
  • CPU 아키텍처 정보(예: CPU, 스레드, 코어, 소켓, NUMA 노드 수)를 수집하려면 다음을 수행합니다.

    $ lscpu
    Architecture:          x86_64
    CPU op-mode(s):        32-bit, 64-bit
    Byte Order:            Little Endian
    CPU(s):                40
    On-line CPU(s) list:   0-39
    Thread(s) per core:    1
    Core(s) per socket:    10
    Socket(s):             4
    NUMA node(s):          4
    Vendor ID:             GenuineIntel
    CPU family:            6
    Model:                 47
    Model name:            Intel(R) Xeon(R) CPU E7- 4870  @ 2.40GHz
    Stepping:              2
    CPU MHz:               2394.204
    BogoMIPS:              4787.85
    Virtualization:        VT-x
    L1d cache:             32K
    L1i cache:             32K
    L2 cache:              256K
    L3 cache:              30720K
    NUMA node0 CPU(s):     0,4,8,12,16,20,24,28,32,36
    NUMA node1 CPU(s):     2,6,10,14,18,22,26,30,34,38
    NUMA node2 CPU(s):     1,5,9,13,17,21,25,29,33,37
    NUMA node3 CPU(s):     3,7,11,15,19,23,27,31,35,39
  • 시스템의 그래픽 표시를 보려면 다음을 수행합니다.

    # dnf install hwloc-gui
    # lstopo

    그림 29.1. lstopo 출력

    lstopo
  • 자세한 symbols 출력을 보려면 다음을 수행합니다.

    # dnf install hwloc
    # lstopo-no-graphics
    Machine (15GB)
      Package L#0 + L3 L#0 (8192KB)
        L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
            PU L#0 (P#0)
            PU L#1 (P#4)
           HostBridge L#0
        PCI 8086:5917
            GPU L#0 "renderD128"
            GPU L#1 "controlD64"
            GPU L#2 "card0"
        PCIBridge
            PCI 8086:24fd
              Net L#3 "wlp61s0"
        PCIBridge
            PCI 8086:f1a6
        PCI 8086:15d7
            Net L#4 "enp0s31f6"

추가 리소스

  • numactl(8), lscpu(1), lstopo(1) 매뉴얼 페이지

29.3. 커널 틱 시간 구성

기본적으로 Red Hat Enterprise Linux 9는 유휴 CPU를 중단하지 않는 틱리스 커널을 사용하여 전력 사용량을 줄이고 새 프로세서가 수면 상태를 활용할 수 있도록 합니다.

Red Hat Enterprise Linux 9는 또한 고성능 컴퓨팅 또는 실시간 컴퓨팅과 같은 대기 시간에 민감한 워크로드에 유용한 동적 틱리스 옵션을 제공합니다. 기본적으로 동적 틱리스 옵션은 비활성화되어 있습니다. cpu-partitioning TuneD 프로필을 사용하여 isolated_cores 로 지정된 코어의 동적 틱리스 옵션을 활성화하는 것이 좋습니다.

이 절차에서는 동적 틱리스 동작을 수동으로 활성화하는 방법을 설명합니다.

절차

  1. 특정 코어에서 동적 틱리스 동작을 활성화하려면 nohz_full 매개변수를 사용하여 커널 명령줄에 코어를 지정합니다. 16개의 코어 시스템에서 nohz_full=1-15 커널 옵션을 활성화합니다.

    # grubby --update-kernel=ALL --args="nohz_full=1-15"

    이를 통해 코어 1 에서 15 까지 동적 틱 수없는 동작을 가능하게하고 모든 시간 유지를 지정하지 않은 코어 (코어 0)로 이동합니다.

  2. 시스템이 부팅될 때 rcu 스레드를 대기 시간이 아닌 코어로 수동으로 이동합니다. 이 경우 코어 0:

    # for i in `pgrep rcu[^c]` ; do taskset -pc 0 $i ; done
  3. 선택 사항: 커널 명령줄에서 isolcpus 매개변수를 사용하여 특정 코어를 사용자 공간 작업으로부터 분리합니다.
  4. 선택 사항: 커널의 write-back bdi-flush 스레드의 CPU 선호도를 하우스키핑 코어로 설정합니다.

    echo 1 > /sys/bus/workqueue/devices/writeback/cpumask

검증 단계

  • 시스템이 재부팅되면 dynticks 가 활성화되었는지 확인합니다.

    # journalctl -xe | grep dynticks
    Mar 15 18:34:54 rhel-server kernel: NO_HZ: Full dynticks CPUs: 1-15.
  • 동적 틱 없는 구성이 제대로 작동하는지 확인합니다.

    # perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 sleep 3

    이 명령은 CPU 1을 유휴 상태로 지정하는 동안 CPU 1이 3초 동안 켜지도록 하는 동안 CPU의 틱을 측정합니다.

  • 기본 커널 타이머 설정은 일반 CPU에서 약 3100개의 틱을 보여줍니다.

    # perf stat -C 0 -e irq_vectors:local_timer_entry taskset -c 0 sleep 3
    
     Performance counter stats for 'CPU(s) 0':
    
                 3,107      irq_vectors:local_timer_entry
    
           3.001342790 seconds time elapsed
  • 동적 틱리스 커널이 구성된 경우, 약 4개의 틱을 볼 수 있습니다.

    # perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 sleep 3
    
     Performance counter stats for 'CPU(s) 1':
    
                     4      irq_vectors:local_timer_entry
    
           3.001544078 seconds time elapsed

29.4. 인터럽트 요청 개요

인터럽트 요청 또는 IRQ는 하드웨어에서 프로세서로 전송되는 즉각적인 주의를 위한 신호입니다. 시스템의 각 장치에는 고유한 인터럽트를 보낼 수 있는 IRQ 번호가 하나 이상 할당됩니다. 인터럽트가 활성화되면 인터럽트 요청을 수신하는 프로세서는 인터럽트 요청을 처리하기 위해 현재 애플리케이션 스레드의 실행을 즉시 일시 중지합니다.

인터럽트가 정상적인 작동을 중단하므로 인터럽트 비율이 심각하게 시스템 성능이 저하될 수 있습니다. 인터럽트 선호도를 설정하거나 일괄 처리에서 여러 우선 순위 인터럽트를 전송하여 인터럽트에서 걸리는 시간을 줄일 수 있습니다(마운트 인터럽트 수 참조).

인터럽트 요청에는 인터럽트 요청을 처리하는 프로세서를 정의하는 smp_affinity 속성 smp_affinity이 있습니다. 애플리케이션 성능을 개선하기 위해 인터럽트 선호도 및 프로세스 선호도를 동일한 프로세서 또는 동일한 코어의 프로세서에 할당합니다. 이렇게 하면 지정된 인터럽트 및 애플리케이션 스레드가 캐시 라인을 공유할 수 있습니다.

인터럽트 steering을 지원하는 시스템에서는 인터럽트 요청의 smp_affinity 속성을 수정하여 하드웨어가 설정되므로 특정 프로세서를 통한 중단을 위한 결정이 커널에서 개입하지 않고 하드웨어 수준에서 이루어집니다.

29.4.1. 인터럽트 수동 밸런싱

BIOS가 NUMA 토폴로지를 내보내는 경우 irqbalance 서비스는 하드웨어 요청 서비스에 로컬인 노드의 인터럽트 요청을 자동으로 제공할 수 있습니다.

절차

  1. 구성할 인터럽트 요청에 해당하는 장치를 확인합니다.
  2. 플랫폼의 하드웨어 사양을 찾으십시오. 시스템의 칩셋이 인터럽트 배포를 지원하는지 확인합니다.

    1. 이 경우 다음 단계에 설명된 대로 인터럽트 전달을 구성할 수 있습니다. 또한 칩셋에서 인터럽트의 균형을 조정하는 데 사용하는 알고리즘을 확인합니다. 일부 BIOS에는 인터럽트 전달을 구성하는 옵션이 있습니다.
    2. 그렇지 않은 경우 칩셋은 모든 인터럽트를 항상 하나의 정적 CPU로 라우팅합니다. 사용되는 CPU를 구성할 수 없습니다.
  3. 시스템에서 사용 중인 APIC(Advanced Programmable Interrupt Controller) 모드를 확인합니다.

    $ journalctl --dmesg | grep APIC

    여기,

    • 시스템에서 플랫 이외의 모드를 사용하는 경우 물리적 플랫 으로 APIC 라우팅 설정 과 유사한 행이 표시될 수 있습니다.
    • 이러한 메시지가 표시되지 않으면 시스템은 플랫 모드를 사용합니다.

      시스템이 x2apic 모드를 사용하는 경우 부트 로더 설정의 커널 명령줄에 nox2apic 옵션을 추가하여 이를 비활성화할 수 있습니다.

      플랫(물리적 플랫 모드)만 인터럽트를 여러 CPU에 배포할 수 있도록 지원합니다. 이 모드는 CPU가 8 개까지 있는 시스템에만 사용할 수 있습니다.

  4. smp_affinity mask 를 계산합니다. smp_affinity mask 를 계산하는 방법에 대한 자세한 내용은 smp_affinity mask 설정을 참조하십시오.

추가 리소스

  • journalctl(1)taskset(1) 도움말 페이지

29.4.2. smp_affinity mask 설정

smp_affinity 값은 시스템의 모든 프로세서를 나타내는 16진수 비트 마스크로 저장됩니다. 각 비트는 다른 CPU를 구성합니다. 가장 작은 비트는 CPU 0입니다.

mask의 기본값은 f 이며, 이는 시스템의 모든 프로세서에서 인터럽트 요청을 처리할 수 있음을 의미합니다. 이 값을 1로 설정하면 프로세서 0만 인터럽트를 처리할 수 있습니다.

절차

  1. 바이너리에서 인터럽트를 처리하는 CPU의 값 1을 사용합니다. 예를 들어 인터럽트를 처리하기 위해 CPU 0 및 CPU 7을 설정하려면 0000000010000001 을 바이너리 코드로 사용합니다.

    표 29.1. CPU용 바이너리 비트

    CPU

    15

    14

    13

    12

    11

    10

    9

    8

    7

    6

    5

    4

    3

    2

    1

    0

    바이너리

    0

    0

    0

    0

    0

    0

    0

    0

    1

    0

    0

    0

    0

    0

    0

    1

  2. 바이너리 코드를 16진수로 변환합니다.

    예를 들어 Python을 사용하여 바이너리 코드를 변환하려면 다음을 수행합니다.

    >>> hex(int('0000000010000001', 2))
    
    '0x81'

    32개 이상의 프로세서가 있는 시스템에서는 개별 32비트 그룹의 smp_affinity 값을 줄여야 합니다. 예를 들어 64 프로세서 시스템의 첫 번째 32 프로세서만 인터럽트 요청을 서비스하려면 0xffffffffffffffffffffffffffffffffffffffffffffffffffff,00000000 을 사용합니다.

  3. 특정 인터럽트 요청의 인터럽트 선호도 값은 연결된 /proc/irq/irq_number/smp_affinity 파일에 저장됩니다. 이 파일에서 smp_affinity 마스크를 설정합니다.

    # echo mask > /proc/irq/irq_number/smp_affinity

추가 리소스

  • journalctl(1), irqbalance(1)taskset(1) 매뉴얼 페이지

30장. 스케줄링 정책 튜닝

Red Hat Enterprise Linux에서 가장 작은 프로세스 실행 단위를 스레드라고 합니다. 시스템 스케줄러는 스레드를 실행하는 프로세서와 스레드가 실행되는 기간을 결정합니다. 그러나 스케줄러의 주요 문제는 시스템을 계속 사용하는 것이기 때문에 애플리케이션 성능에 가장 적합한 스레드를 예약하지 않을 수 있습니다.

예를 들어 NUMA 시스템의 애플리케이션이 노드 B의 프로세서를 사용할 수 있게 되면 노드 A에서 실행되고 있다고 가정합니다. 노드 B에서 프로세서를 사용하도록 유지하기 위해 스케줄러는 애플리케이션의 스레드 중 하나를 Node B로 이동합니다. 그러나 애플리케이션 스레드는 여전히 Node A의 메모리에 액세스해야 합니다. 그러나 스레드가 현재 노드 B에서 실행되고 있는 스레드가 더 이상 스레드에서 실행되고 있지 않기 때문에 이 메모리는 더 이상 액세스할 수 없습니다. 따라서 노드 A에서 프로세서를 사용할 수 있을 때까지 대기한 다음 로컬 메모리 액세스 권한이 있는 원래 노드에서 스레드를 실행하는 데 걸리는 것보다 노드 B에서 실행을 완료하는 데 시간이 더 오래 걸릴 수 있습니다.

30.1. 스케줄링 정책의 범주

성능에 민감한 애플리케이션은 종종 설계자 또는 관리자가 스레드가 실행되는 위치를 결정하는 데 도움이 됩니다. Linux 스케줄러는 스레드가 실행되는 위치와 기간을 결정하는 여러 스케줄링 정책을 구현합니다.

다음은 스케줄링 정책의 두 가지 주요 범주입니다.

일반 정책
일반 스레드는 일반적인 우선 순위의 작업에 사용됩니다.
실시간 정책

실시간 정책은 중단 없이 완료해야 하는 시간에 민감한 작업에 사용됩니다. 실시간 스레드는 시간 분할의 영향을 받지 않습니다. 즉, 스레드는 차단, 종료, 자발적으로 산출되거나 더 높은 우선순위 스레드에 의해 선점될 때까지 실행됩니다.

가장 낮은 우선 순위 실시간 스레드는 일반 정책이 있는 스레드보다 먼저 예약됩니다. 자세한 내용은 nfsnobody _RR 를 사용한 Static 우선순위 스케줄링 을 참조하십시오.

추가 리소스

  • sched -02- , sched_setaffinity(2), sched_getaffinity(2), sched_setscheduler(2)sched_getscheduler(2) 도움말 페이지

30.2. nfsnobody_dpdk를 사용한 정적 우선 순위 예약

static 우선순위 예약이라고도 하는 NetNamespace _ databind 는 각 스레드에 대해 고정된 우선 순위를 정의하는 실시간 정책입니다. 관리자는 이 정책을 통해 이벤트 응답 시간을 개선하고 대기 시간을 줄일 수 있습니다. 시간에 민감한 작업의 장기적인 기간 동안 이 정책을 실행하지 않는 것이 좋습니다.

NetNamespace _ ECDSA가 사용 중인 경우 스케줄러는 우선 순위로 모든 DASD _ ECDSA 스레드 목록을 스캔하고 실행할 준비가 된 가장 높은 우선 순위 스레드를 예약합니다. jenkinsfile _ databind 스레드의 우선순위 수준은 1 에서 99까지의 모든 정수일 수 있으며 99 는 가장 높은 우선 순위로 취급됩니다. Red Hat은 대기 시간 문제를 식별할 때만 더 낮은 번호로 시작하고 우선 순위를 높이는 것이 좋습니다.

주의

실시간 스레드는 시간 분할에 적용되지 않으므로 Red Hat은 우선 순위를 99로 설정하는 것을 권장하지 않습니다. 이렇게 하면 프로세스가 마이그레이션 및 워치독 스레드와 동일한 우선 순위 수준으로 유지됩니다. 스레드가 계산 루프에 들어가면 이러한 스레드가 차단되면 실행할 수 없습니다. 단일 프로세서가 있는 시스템은 결국 이러한 상황에서 중단될 것입니다.

관리자는 realtime 애플리케이션 프로그래머가 프로세서를 모국화하는 실시간 작업을 시작하는 것을 방지하기 위해 NetNamespace_ ptp 대역폭을 제한할 수 있습니다.

다음은 이 정책에서 사용되는 몇 가지 매개 변수입니다.

/proc/sys/kernel/sched_rt_period_us
이 매개 변수는 프로세서 대역폭의 100 %로 간주되는 시간 기간을 마이크로초 단위로 정의합니다. 기본값은 1000000 databinds 또는 1초입니다.
/proc/sys/kernel/sched_rt_runtime_us
이 매개 변수는 실시간 스레드를 실행하는 데 사용되는 시간 기간을 마이크로초 단위로 정의합니다. 기본값은 95% 0000 databinds 또는 0.95초입니다.

30.3. DASD_RR을 사용한 라운드 로빈 우선순위 스케줄링

Net Namespace_RR 은 cryptsetup _databind 의 라운드 로빈 변형입니다. 이 정책은 여러 스레드를 동일한 우선 순위 수준에서 실행해야 하는 경우에 유용합니다.

Net Namespace_databind마찬가지로, cryptsetup_RR 은 각 스레드에 대해 고정된 우선 순위를 정의하는 실시간 정책입니다. 스케줄러는 우선 순위에 따라 모든 DASD_RR 스레드 목록을 스캔하고 실행할 준비가 된 가장 높은 우선 순위 스레드를 예약합니다. 그러나 precedence 동일한 우선 순위가 같은 스레드는 특정 시간 슬라이스 내에서 라운드 로빈 스타일로 예약됩니다.

/proc/sys/kernel/sched_rr_timeslice_ms 파일에서 sched_rr_timeslice_ms 커널 매개 변수를 사용하여 이 시간 슬라이스의 값을 밀리초 단위로 설정할 수 있습니다. 가장 작은 값은 1밀리초 입니다.

30.4. nfsnobody_OTHER를 사용한 일반 스케줄링

Net Namespace_OTHER 는 Red Hat Enterprise Linux 9의 기본 스케줄링 정책입니다. 이 정책은 CFS(Completely Fair Scheduler)를 사용하여 이 정책으로 예약된 모든 스레드에 대한 공정한 프로세서 액세스를 허용합니다. 이 정책은 시간이 지남에 따라 스레드를 보다 효율적으로 예약할 수 있으므로 많은 수의 스레드가 있거나 데이터 처리량이 우선 순위인 경우 가장 유용합니다.

이 정책이 사용 중인 경우 스케줄러는 각 프로세스 스레드의 선호도 값에 따라 부분적으로 동적 우선 순위 목록을 생성합니다. 관리자는 프로세스의 niceness 값을 변경할 수 있지만 스케줄러의 동적 우선 순위 목록을 직접 변경할 수는 없습니다.

30.5. 스케줄러 정책 설정

chrt 명령줄 툴을 사용하여 스케줄러 정책 및 우선 순위를 확인하고 조정합니다. 원하는 속성을 사용하여 새 프로세스를 시작하거나 실행 중인 프로세스의 속성을 변경할 수 있습니다. 런타임 시 정책을 설정하는 데 사용할 수도 있습니다.

절차

  1. 활성 프로세스의 PID(프로세스 ID)를 확인합니다.

    # ps

    ps 명령과 함께 --pid 또는 -p 옵션을 사용하여 특정 PID의 세부 정보를 확인합니다.

  2. 특정 프로세스의 스케줄링 정책, PID 및 우선 순위를 확인합니다.

    # chrt -p 468
    pid 468's current scheduling policy: SCHED_FIFO
    pid 468's current scheduling priority: 85
    
    # chrt -p 476
    pid 476's current scheduling policy: SCHED_OTHER
    pid 476's current scheduling priority: 0

    여기서 468476 은 프로세스의 PID입니다.

  3. 프로세스의 스케줄링 정책을 설정합니다.

    1. 예를 들어 PID 1000 인 프로세스를 우선 순위 50 개로 설정하려면 다음을 수행합니다.

      # chrt -f -p 50 1000
    2. 예를 들어 PID 1000 이 있는 프로세스를 priority _OTHER 로 설정하고 우선 순위가 0 으로 설정하려면 다음을 실행합니다.

      # chrt -o -p 0 1000
    3. 예를 들어 PID 1000 인 프로세스를 priority _RR 로 설정하고 우선 순위 10:

      # chrt -r -p 10 1000
    4. 특정 정책 및 우선 순위로 새 애플리케이션을 시작하려면 애플리케이션 이름을 지정합니다.

      # chrt -f 36 /bin/my-app

30.6. chrt 명령의 정책 옵션

chrt 명령을 사용하면 프로세스의 스케줄링 정책을 보고 설정할 수 있습니다.

다음 표에서는 프로세스의 스케줄링 정책을 설정하는 데 사용할 수 있는 적절한 정책 옵션을 설명합니다.

표 30.1. chrt 명령의 정책 옵션

짧은 옵션긴 옵션설명

-f

--fifo

schedule을 nfsnobody _databind로설정

-o

--other

schedule을 NetNamespace _OTHER로 설정

-r

--rr

schedule을 DASD _RR로 설정

30.7. 부팅 프로세스 중 서비스 우선 순위 변경

systemd 서비스를 사용하면 부팅 프로세스 중에 시작된 서비스에 대한 실시간 우선 순위를 설정할 수 있습니다. 단위 구성 지시문 은 부팅 프로세스 중에 서비스의 우선 순위를 변경하는 데 사용됩니다.

부팅 프로세스 우선 순위 변경은 service 섹션에서 다음 지시문을 사용하여 수행됩니다.

CPUSchedulingPolicy=
실행된 프로세스에 대한 CPU 스케줄링 정책을 설정합니다. 다른,fiforr 정책을 설정하는 데 사용됩니다.
CPUSchedulingPriority=
실행된 프로세스의 CPU 스케줄링 우선 순위를 설정합니다. 사용 가능한 우선 순위 범위는 선택한 CPU 스케줄링 정책에 따라 다릅니다. 실시간 스케줄링 정책의 경우 1 (최저 우선 순위)과 99 (최고 우선 순위) 사이의 정수를 사용할 수 있습니다.

다음 절차에서는 mcelog 서비스를 사용하여 부팅 프로세스 중에 서비스의 우선 순위를 변경하는 방법을 설명합니다.

사전 요구 사항

  1. TuneD 패키지를 설치합니다.

    # dnf install tuned
  2. TuneD 서비스를 활성화하고 시작합니다.

    # systemctl enable --now tuned

절차

  1. 실행 중인 스레드의 스케줄링 우선 순위를 확인합니다.

    # tuna --show_threads
                          thread       ctxt_switches
        pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
      1      OTHER     0     0xff      3181          292         systemd
      2      OTHER     0     0xff       254            0        kthreadd
      3      OTHER     0     0xff         2            0          rcu_gp
      4      OTHER     0     0xff         2            0      rcu_par_gp
      6      OTHER     0        0         9            0 kworker/0:0H-kblockd
      7      OTHER     0     0xff      1301            1 kworker/u16:0-events_unbound
      8      OTHER     0     0xff         2            0    mm_percpu_wq
      9      OTHER     0        0       266            0     ksoftirqd/0
    [...]
  2. 보조 mcelog 서비스 구성 디렉터리 파일을 생성하고 이 파일에 정책 이름과 우선 순위를 삽입합니다.

    # cat << EOF > /etc/systemd/system/mcelog.service.d/priority.conf
    
    [Service]
    CPUSchedulingPolicy=fifo
    CPUSchedulingPriority=20
    EOF
  3. systemd 스크립트 구성을 다시 로드합니다.

    # systemctl daemon-reload
  4. mcelog 서비스를 다시 시작하십시오.

    # systemctl restart mcelog

검증 단계

  • systemd 문제로 설정된 mcelog 우선 순위를 표시합니다.

    # tuna -t mcelog -P
    thread       ctxt_switches
      pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
    826     FIFO    20  0,1,2,3        13            0          mcelog

추가 리소스

30.8. 우선순위 맵

우선순위는 특정 커널 기능 전용인 그룹으로 정의됩니다. 실시간 스케줄링 정책의 경우 1 (최저 우선 순위)과 99 (최고 우선 순위) 사이의 정수를 사용할 수 있습니다.

다음 표에서는 프로세스의 스케줄링 정책을 설정하는 동안 사용할 수 있는 우선순위 범위를 설명합니다.

표 30.2. 우선순위 범위에 대한 설명

우선 순위스레드설명

1

낮은 우선 순위 커널 스레드

일반적으로 이 우선순위는 deadline _OTHER 위에 있어야 하는 작업에 대해 예약되어 있습니다.

2 - 49

사용 가능

일반적인 애플리케이션 우선 순위에 사용되는 범위입니다.

50

기본 hard-IRQ 값

 

51 - 98

높은 우선 순위 스레드

주기적으로 실행되고 빠른 응답 시간이 있어야 하는 스레드에 이 범위를 사용합니다. 인터럽트를 시작할 때 CPU 바인딩 스레드에 이 범위를 사용하지 마십시오.

99

워치독 및 마이그레이션

가장 높은 우선순위로 실행해야 하는 시스템 스레드입니다.

30.9. tuned cpu-partitioning 프로필

대기 시간에 민감한 워크로드에 맞게 Red Hat Enterprise Linux 9를 튜닝하려면 cpu-partitioning TuneD 프로필을 사용하는 것이 좋습니다.

Red Hat Enterprise Linux 9 이전에는 대기 시간이 짧은 Red Hat 문서에서는 대기 시간이 짧은 튜닝을 수행하는 데 필요한 수많은 낮은 수준의 단계를 설명했습니다. Red Hat Enterprise Linux 9에서는 cpu-partitioning TuneD 프로필을 사용하여 대기 시간이 짧은 튜닝을 보다 효율적으로 수행할 수 있습니다. 이 프로필은 대기 시간이 짧은 개별 애플리케이션의 요구 사항에 따라 쉽게 사용자 지정할 수 있습니다.

다음 그림은 cpu-partitioning 프로필을 사용하는 방법을 보여줍니다. 이 예에서는 CPU 및 노드 레이아웃을 사용합니다.

그림 30.1. figure cpu-partitioning

CPU 파티션

다음 구성 옵션을 사용하여 /etc/tuned/cpu-partitioning-ECDHEs.conf 파일에서 cpu-partitioning 프로필을 구성할 수 있습니다.

로드 밸런싱이 있는 격리된 CPU

cpu-partitioning figure에서 4에서 23으로 번호가 매겨진 블록은 기본 분리된 CPU입니다. 커널 스케줄러의 프로세스 부하 분산이 이러한 CPU에서 활성화됩니다. 커널 스케줄러 부하 분산이 필요한 여러 스레드가 있는 대기 시간이 짧은 프로세스를 위해 설계되었습니다.

kernel 스케줄러 로드 밸런싱을 사용할 CPU를 나열하는 isolated_cores= cpu-list 옵션을 사용하여 /etc/tuned/cpu-partitions.conf 파일에서 cpu-partitioning 프로필을 구성할 수 있습니다.

분리된 CPU 목록은 쉼표로 구분하거나 dash(예: )를 사용하여 범위를 지정할 수 있습니다. 이 옵션은 필수입니다. 이 목록에서 누락된 CPU는 자동으로 하우스키핑 CPU로 간주됩니다.

로드 밸런싱이 없는 격리된 CPU

cpu-partitioning 그림에서 번호가 지정된 블록 2와 3은 추가 커널 스케줄러 프로세스 부하 분산을 제공하지 않는 격리된 CPU입니다.

커널 스케줄러 로드 밸런싱을 사용하지 않는 CPU를 나열하는 no_balance_cores= cpu-list 옵션을 사용하여 /etc/tuned/cpu-partitions.conf 파일에서 cpu-partitioning 프로필을 구성할 수 있습니다.

no_balance_cores 옵션을 지정하는 것은 선택 사항이지만 이 목록의 모든 CPU는 isolated_cores 목록에 나열된 CPU의 하위 집합이어야 합니다.

이러한 CPU를 사용하는 애플리케이션 스레드를 각 CPU에 개별적으로 고정해야 합니다.

하우스키핑 CPU
cpu-partitioning-postgresqls.conf 파일에서 분리된 CPU는 자동으로 하우스키핑 CPU로 간주됩니다. 하우스키핑 CPU에서 모든 서비스, 데몬, 사용자 프로세스, 이동 가능한 커널 스레드, 인터럽트 처리기, 커널 타이머를 실행할 수 있습니다.

추가 리소스

  • tuned-profiles-cpu-partitioning(7) man page

30.10. 대기 시간이 짧은 튜닝을 위해 TuneD cpu-partitioning 프로파일 사용

이 프로세스에서는 TuneD의 cpu-partitioning 프로필을 사용하여 대기 시간이 짧은 시스템을 조정하는 방법을 설명합니다. cpu-partitioningcpu-partitioning 수치에 언급된 CPU 레이아웃을 사용할 수 있는 대기 시간이 짧은 애플리케이션의 예를 사용합니다.

이 경우 애플리케이션은 다음을 사용합니다.

  • 네트워크에서 데이터를 읽는 하나의 전용 리더 스레드가 CPU 2에 고정되어 있습니다.
  • 이 네트워크 데이터를 처리하는 많은 수의 스레드가 CPU 4-23에 고정되어 있습니다.
  • 처리된 데이터를 네트워크에 쓰는 전용 작성기 스레드는 CPU 3에 고정되어 있습니다.

사전 요구 사항

  • dnf install tuned-profiles- cpu-partitioning 명령을 root로 사용하여 cpu-partitioning TuneD 프로필 을 설치했습니다.

절차

  1. /etc/tuned/cpu-partitioning-ECDHEs.conf 파일을 편집하고 다음 정보를 추가합니다.

    # All isolated CPUs:
    isolated_cores=2-23
    # Isolated CPUs without the kernel’s scheduler load balancing:
    no_balance_cores=2,3
  2. cpu-partitioning TuneD 프로필을 설정합니다.

    # tuned-adm profile cpu-partitioning
  3. reboot

    재부팅 후 cpu-partitioning figure의 격리에 따라 대기 시간이 짧아지도록 시스템이 조정됩니다. 애플리케이션은 taskset을 사용하여 reader 및 writer 스레드를 2 및 3에 고정하고 CPU 4-23의 나머지 애플리케이션 스레드를 CPU 2 및 3에 고정할 수 있습니다.

추가 리소스

  • tuned-profiles-cpu-partitioning(7) man page

30.11. cpu-partitioning TuneD 프로파일 사용자 정의

TuneD 프로필을 확장하여 추가 튜닝을 변경할 수 있습니다.

예를 들어 cpu-partitioning 프로필은 CPU가 cstate=1 을 사용하도록 설정합니다. cpu-partitioning 프로필을 사용하지만 CPU cstate를 cstate1에서 cstate0으로 추가로 변경하려면 다음 절차에서는 cpu-partitioning 프로필을 상속하고 C state-0을 설정하는 my_profile 이라는 새 TuneD 프로필을 설명합니다.

절차

  1. /etc/tuned/my_profile 디렉토리를 만듭니다.

    # mkdir /etc/tuned/my_profile
  2. 이 디렉터리에 tuned.conf 파일을 생성하고 다음 콘텐츠를 추가합니다.

    # vi /etc/tuned/my_profile/tuned.conf
    [main]
    summary=Customized tuning on top of cpu-partitioning
    include=cpu-partitioning
    [cpu]
    force_latency=cstate.id:0|1
  3. 새 프로필을 사용합니다.

    # tuned-adm profile my_profile
참고

공유 예에서는 재부팅이 필요하지 않습니다. 그러나 my_profile 프로필의 변경 사항을 적용하려면 재부팅을 수행한 다음 시스템을 재부팅합니다.

추가 리소스

  • tuned-profiles-cpu-partitioning(7) man page

31장. 네트워크 성능 튜닝

네트워크 설정 튜닝은 복잡한 프로세스이며 고려해야 할 여러 가지 요소가 있습니다. 예를 들어 여기에는 CPU-메모리 아키텍처, CPU 코어 양 등이 포함됩니다. Red Hat Enterprise Linux는 대부분의 시나리오에 최적화된 기본 설정을 사용합니다. 그러나 특정 경우에는 처리량이나 대기 시간을 늘리거나 패킷 드롭과 같은 문제를 해결하기 위해 네트워크 설정을 튜닝해야 할 수 있습니다.

31.1. 네트워크 어댑터 설정 조정

40Gbps 이상의 고속 네트워크에서 네트워크 어댑터 관련 커널 설정의 특정 기본 값은 패킷 감소 및 성능 저하의 원인이 될 수 있습니다. 이러한 설정을 튜닝하면 이러한 문제가 발생하지 않을 수 있습니다.

31.1.1. nmcli를 사용하여 높은 패킷 드롭 속도를 줄이기 위해 링 버퍼 크기를 늘리십시오.

패킷 드롭 비율로 인해 애플리케이션이 데이터, 시간 초과 또는 기타 문제가 발생하는 경우 이더넷 장치의 링 버퍼 크기를 늘립니다.

수신 링 버퍼는 장치 드라이버와 NIC(네트워크 인터페이스 컨트롤러) 간에 공유됩니다. 카드는 전송(TX) 및 수신(RX) 링 버퍼를 할당합니다. 이름에서 알 수 있듯이 링 버퍼는 오버플로가 기존 데이터를 덮어쓰는 순환 버퍼입니다. NIC에서 커널로 데이터를 이동하는 방법은 두 가지입니다. 하드웨어 인터럽트 및 소프트웨어 인터럽트(예: system-IRQ)라고도 하는 소프트웨어 인터럽트도 있습니다.

커널은 장치 드라이버가 이를 처리할 수 있을 때까지 RX 링 버퍼를 사용하여 들어오는 패킷을 저장합니다. 장치 드라이버는 일반적으로 SoftIRQs를 사용하여 RX 링을 드레이닝하여 들어오는 패킷을 sk_buff 또는 skb 라는 커널 데이터 구조에 배치하여 커널과 관련 소켓을 소유하는 애플리케이션까지 이동합니다.

커널은 TX 링 버퍼를 사용하여 네트워크로 전송해야 하는 발신 패킷을 보관합니다. 이러한 링 버퍼는 스택의 맨 아래에 있으며 패킷 드롭이 발생할 수 있는 중요한 지점이며, 이로 인해 네트워크 성능에 부정적인 영향을 미칩니다.

절차

  1. 인터페이스의 패킷 삭제 통계를 표시합니다.

    # ethtool -S enp1s0
        ...
        rx_queue_0_drops: 97326
        rx_queue_1_drops: 63783
        ...

    명령 출력은 네트워크 카드 및 드라이버에 따라 다릅니다.

    삭제 또는 드롭 카운터의 높은 값은 사용 가능한 버퍼가 패킷을 처리할 수 있는 속도보다 빠르게 채워지는 것을 나타냅니다. 링 버퍼를 늘리면 이러한 손실을 피할 수 있습니다.

  2. 최대 링 버퍼 크기를 표시합니다.

    # ethtool -g enp1s0
     Ring parameters for enp1s0:
     Pre-set maximums:
     RX:             4096
     RX Mini:        0
     RX Jumbo:       16320
     TX:             4096
     Current hardware settings:
     RX:             255
     RX Mini:        0
     RX Jumbo:       0
     TX:             255

    Pre-set maximums 섹션의 값이 현재 하드웨어 설정 섹션에서보다 높은 경우 다음 단계에서 설정을 변경할 수 있습니다.

  3. 인터페이스를 사용하는 NetworkManager 연결 프로필을 식별합니다.

    # nmcli connection show
    NAME                UUID                                  TYPE      DEVICE
    Example-Connection  a5eb6490-cc20-3668-81f8-0314a27f3f75  ethernet  enp1s0
  4. 연결 프로필을 업데이트하고 링 버퍼를 늘립니다.

    • RX 링 버퍼를 늘리려면 다음을 입력하십시오.

      # nmcli connection modify Example-Connection ethtool.ring-rx 4096
    • TX 링 버퍼를 늘리려면 다음을 입력하십시오.

      # nmcli connection modify Example-Connection ethtool.ring-tx 4096
  5. NetworkManager 연결을 다시 로드합니다.

    # nmcli connection up Example-Connection
    중요

    NIC가 사용하는 드라이버에 따라 링 버퍼를 변경하면 네트워크 연결이 곧 중단될 수 있습니다.

31.1.2. 패킷이 손실되지 않도록 네트워크 장치 백로그 큐 조정

네트워크 카드가 패킷을 수신하고 커널 프로토콜 스택이 처리되기 전에 커널은 이러한 패킷을 백로그 큐에 저장합니다. 커널은 각 CPU 코어에 대해 별도의 대기열을 유지 관리합니다.

코어의 백로그 큐가 가득 차면 커널은 netif_receive_skb() 커널 함수가 이 큐에 할당하는 추가 수신 패킷을 모두 삭제합니다. 서버에 10Gbps 또는 더 빠른 네트워크 어댑터 또는 여러 개의 1Gbps 어댑터가 포함된 경우 이 문제를 방지하려면 백로그 큐 크기를 조정합니다.

사전 요구 사항

  • 10Gbps 이상 또는 여러 개의 1Gbps 네트워크 어댑터

절차

  1. 백로그 큐가 필요한지 여부를 확인하고 카운터를 /proc/net/softnet_stat 파일에 표시합니다.

    # awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t
    221951548  0      0  0  0  0  0  0  0  0  0  0  0
    192058677  18862  0  0  0  0  0  0  0  0  0  0  1
    455324886  0      0  0  0  0  0  0  0  0  0  0  2
    ...

    awk 명령은 /proc/net/softnet_stat 의 값을 16진수에서 10진수 형식으로 변환하고 테이블 형식으로 표시합니다. 각 행은 코어 0으로 시작하는 CPU 코어를 나타냅니다.

    관련 열은 다음과 같습니다.

    • 첫 번째 열: 수신된 총 프레임 수
    • 두 번째 열: 전체 백로그 큐로 인해 삭제된 프레임 수
    • 마지막 열: CPU 코어 수
  2. /proc/net/softnet_stat 파일의 두 번째 열에 있는 값이 시간에 따라 증가하면 백로그 대기열의 크기를 늘립니다.

    1. 현재 백로그 큐 크기를 표시합니다.

      # sysctl net.core.netdev_max_backlog
      net.core.netdev_max_backlog = 1000
    2. 다음 콘텐츠를 사용하여 /etc/sysctl.d/10-netdev_max_backlog.conf 파일을 만듭니다.

      net.core.netdev_max_backlog = 2000

      net.core.netdev_max_backlog 매개변수를 현재 값의 double로 설정합니다.

    3. /etc/sysctl.d/10-netdev_max_backlog.conf 파일에서 설정을 로드합니다.

      # sysctl -p /etc/sysctl.d/10-netdev_max_backlog.conf

검증

  • /proc/net/softnet_stat 파일에서 두 번째 열을 모니터링합니다.

    # awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t

    값이 여전히 증가하면 net.core.netdev_max_backlog 값을 다시 두 배로 늘립니다. 패킷 드롭 카운터가 더 이상 증가하지 않을 때까지 이 프로세스를 반복합니다.

31.1.3. 전송 오류 수를 줄이기 위해 NIC의 전송 대기열 길이 늘리기

커널은 패킷을 전송하기 전에 전송 대기열에 저장합니다. 기본 길이(1000 패킷)는 일반적으로 10Gbps에 충분하며 40Gbps 네트워크에도 적합합니다. 그러나 더 빠른 네트워크에서 또는 어댑터에서 전송 오류가 증가하는 경우 큐 길이를 늘립니다.

절차

  1. 현재 전송 대기열 길이를 표시합니다.

    # ip -s link show enp1s0
    2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    ...

    이 예에서 enp1s0 인터페이스의 전송 대기열 길이(qlen)는 1000 입니다.

  2. 네트워크 인터페이스의 소프트웨어 전송 큐의 드롭된 패킷 카운터를 모니터링합니다.

    # tc -s qdisc show dev enp1s0
    qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
     Sent 16889923 bytes 426862765 pkt (dropped 191980, overlimits 0 requeues 2)
    ...
  3. 전송 오류 수가 높거나 증가하는 경우 더 높은 전송 대기열 길이를 설정합니다.

    1. 이 인터페이스를 사용하는 NetworkManager 연결 프로필을 식별합니다.

      # nmcli connection show
      NAME                UUID                                  TYPE      DEVICE
      Example-Connection  a5eb6490-cc20-3668-81f8-0314a27f3f75  ethernet  enp1s0
    2. 연결 프로필을 업데이트하고 전송 큐 길이를 늘립니다.

      # nmcli connection modify Example-Connection link.tx-queue-length 2000

      현재 값의 큐 길이를 double로 설정합니다.

    3. 변경 사항을 적용합니다.

      # nmcli connection up Example-Connection

검증

  1. 전송 대기열 길이를 표시합니다.

    # ip -s link show enp1s0
    2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 2000
    ...
  2. 삭제된 패킷 카운터를 모니터링합니다.

    # tc -s qdisc show dev enp1s0

    삭제된 카운터가 계속 증가하면 전송 대기열 길이를 다시 두 배로 늘립니다. 카운터가 더 이상 증가하지 않을 때까지 이 프로세스를 반복합니다.

31.2. IRQ 밸런싱 튜닝

멀티 코어 호스트에서는 Red Hat Enterprise Linux가 인터럽트를 CPU 코어 간에 분산하도록 인터럽트 대기열(IRQ)의 균형을 조정할 수 있으므로 성능을 향상시킬 수 있습니다.

31.2.1. 처리기 중단 및 중단

NIC(네트워크 인터페이스 컨트롤러)가 들어오는 데이터를 수신하면 DMA(직접 메모리 액세스)를 사용하여 데이터를 커널 버퍼에 복사합니다. 그런 다음 NIC는 하드 인터럽트를 트리거하여 커널에 이 데이터에 대해 알립니다. 이러한 인터럽트는 다른 작업이 이미 중단되고 처리기가 중단될 수 없으므로 최소한의 작업을 수행하는 인터럽트 처리기에 의해 처리됩니다. 특히 커널 잠금을 사용하는 경우 CPU 사용량 측면에서 하드 인터럽트는 비용이 많이 들 수 있습니다.

그런 다음 하드 인터럽트 처리기는 대부분의 패킷 수신을 소프트웨어 인터럽트 요청(SoftIRQ) 프로세스에 남겨 둡니다. 커널은 이러한 프로세스를 보다 공정하게 예약할 수 있습니다.

예 31.1. 하드웨어 인터럽트 표시

커널은 인터럽트 카운터를 /proc/interrupts 파일에 저장합니다. enp1s0 과 같은 특정 NIC의 카운터를 표시하려면 다음을 입력합니다.

# egrep "CPU|enp1s0" /proc/interrupts
         CPU0     CPU1     CPU2    CPU3    CPU4   CPU5
 105:  141606        0        0       0       0      0  IR-PCI-MSI-edge      enp1s0-rx-0
 106:       0   141091        0       0       0      0  IR-PCI-MSI-edge      enp1s0-rx-1
 107:       2        0   163785       0       0      0  IR-PCI-MSI-edge      enp1s0-rx-2
 108:       3        0        0  194370       0      0  IR-PCI-MSI-edge      enp1s0-rx-3
 109:       0        0        0       0       0      0  IR-PCI-MSI-edge      enp1s0-tx

각 큐는 할당된 첫 번째 열에서 인터럽트 벡터를 갖습니다. 커널은 시스템이 부팅되거나 사용자가 NIC 드라이버 모듈을 로드할 때 이러한 벡터를 초기화합니다. 각 수신(RX) 및 전송(TX) 큐에는 인터럽트가 발생하는 NIC 또는 큐를 알리는 고유한 벡터가 할당됩니다. 열은 모든 CPU 코어에 대해 들어오는 인터럽트 수를 나타냅니다.

31.2.2. 소프트웨어 중단 요청

소프트웨어 인터럽트 요청(SoftIRQ)은 네트워크 어댑터의 수신 링 버퍼를 지웁니다. 커널은 다른 작업이 중단되지 않을 때 한 번에 실행되도록 IRQIRQ 루틴을 예약합니다. Red Hat Enterprise Linux에서 ksoftirqd/cpu-number 라는 프로세스는 이러한 루틴을 실행하고 드라이버별 코드 함수를 호출합니다.

각 CPU 코어에 대한 IRQIRQ 카운터를 모니터링하려면 다음을 입력합니다.

# watch -n1 'egrep "CPU|NET_RX|NET_TX" /proc/softirqs'
                    CPU0       CPU1	  CPU2       CPU3	CPU4	   CPU5       CPU6	 CPU7
      NET_TX:	   49672      52610	 28175      97288      12633	  19843      18746     220689
      NET_RX:         96       1615        789         46         31	   1735       1315     470798

명령은 출력을 동적으로 업데이트합니다. Ctrl+C 눌러 출력을 중단합니다.

31.2.3. NAPI 폴링

새로운 API(NAPI)는 들어오는 네트워크 패킷의 효율성을 개선하기 위해 장치 드라이버 패킷 처리 프레임워크를 확장한 것입니다. 일반적으로 커널 공간에서 사용자 공간으로 컨텍스트를 전환하고 다시 중단할 수 없기 때문에 하드 인터럽트는 비용이 많이 듭니다. 인터럽트 병합을 사용하더라도 인터럽트 처리기는 CPU 코어를 완전히 독점합니다. NAPI를 사용하면 드라이버는 수신된 모든 패킷에 대해 커널에서 하드 인터렉션하는 대신 폴링 모드를 사용할 수 있습니다.

일반 작업에서는 커널이 초기 하드 인터럽트를 실행한 다음 NAPI 루틴을 사용하여 네트워크 카드를 폴링하는 소프트 인터럽트 요청(SoftIRQ) 핸들러가 있습니다. IRQIRQ가 CPU 코어를 독점화하는 것을 방지하기 위해 폴링 루틴은 IRQIRQ가 사용할 수 있는 CPU 시간을 결정하는 예산이 있습니다. IRQIRQ 폴링 루틴이 완료되면 커널은 루틴을 종료하고 나중에 다시 실행되도록 예약하여 네트워크 카드에서 패킷을 수신하는 프로세스를 반복합니다.

31.2.4. irqbalance 서비스

NUMA(Non-Uniform Memory Access) 아키텍처가 있고 사용하지 않는 시스템에서 irqbalance 서비스는 시스템 조건에 따라 CPU 코어 간에 인터럽트의 균형을 효과적으로 조정합니다. irqbalance 서비스는 백그라운드에서 실행되며 10초마다 CPU 부하를 모니터링합니다. CPU 부하가 너무 높은 경우 서비스는 다른 CPU 코어로 인터럽트를 이동합니다. 결과적으로 시스템은 제대로 작동하고 부하를 더 효율적으로 처리합니다.

irqbalance 가 실행되지 않으면 일반적으로 CPU 코어 0은 대부분의 인터럽트를 처리합니다. 중간 부하에도 이 CPU 코어는 시스템의 모든 하드웨어의 워크로드를 처리하려고 할 수 있습니다. 결과적으로 인터럽트 또는 인터럽트 기반 작업이 누락되거나 지연될 수 있습니다. 이로 인해 네트워크 및 스토리지 성능, 패킷 손실 및 기타 문제가 발생할 수 있습니다.

중요

irqbalance 를 비활성화하면 네트워크 처리량에 부정적인 영향을 미칠 수 있습니다.

단일 CPU 코어만 있는 시스템에서 irqbalance 서비스는 이점을 제공하지 않고 자체적으로 종료됩니다.

기본적으로 irqbalance 서비스는 Red Hat Enterprise Linux에서 활성화되어 실행됩니다. 서비스를 비활성화한 경우 서비스를 다시 활성화하려면 다음을 입력합니다.

# systemctl enable --now irqbalance

31.2.5. CPU에서 실행할 수 있는 시간 늘리기

CloudEventIRQ가 충분히 오래 실행되지 않으면 들어오는 데이터의 속도가 버퍼를 충분히 빠르게 드레이닝하는 커널의 기능을 초과할 수 있습니다. 결과적으로 NIC(네트워크 인터페이스 컨트롤러) 버퍼 오버플로 및 패킷이 손실됩니다.

softirqd 프로세스에서 하나의 NAPI 폴링 주기의 인터페이스에서 모든 패킷을 검색할 수 없는 경우, IRQIRQ에 CPU 시간이 충분하지 않음을 나타냅니다. 이는 빠른 NIC가 있는 호스트의 경우(예: 10Gbps 및 더 빠릅니다)일 수 있습니다. net.core.netdev_budgetnet.core.netdev_budget_usecs 커널 매개변수 값을 늘리면 폴링 주기에서 패킷 수와 패킷 수를 제어할 수 있습니다.

절차

  1. net.core.netdev_budget 매개변수 튜닝이 필요한지 여부를 확인하려면 /proc/net/softnet_stat 파일에 카운터를 표시합니다.

    # awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t
    221951548  0  0      0  0  0  0  0  0  0  0  0  0
    192058677  0  20380  0  0  0  0  0  0  0  0  0  1
    455324886  0  0      0  0  0  0  0  0  0  0  0  2
    ...

    awk 명령은 /proc/net/softnet_stat 의 값을 16진수에서 10진수 형식으로 변환하고 테이블 형식으로 표시합니다. 각 행은 코어 0으로 시작하는 CPU 코어를 나타냅니다.

    관련 열은 다음과 같습니다.

    • 첫 번째 열: 수신된 총 프레임 수입니다.
    • 세 번째 열: 하나의 NAPI 폴링 주기의 인터페이스에서 모든 패킷을 검색할 수 없는 softirqd 프로세스 수입니다.
    • 마지막 열: CPU 코어 번호입니다.
  2. /proc/net/softnet_stat 파일의 세 번째 열에 있는 카운터가 시간에 따라 증가하면 시스템을 조정합니다.

    1. net.core.netdev_budget_usecsnet.core.netdev_budget 매개변수의 현재 값을 표시합니다.

      # sysctl net.core.netdev_budget_usecs net.core.netdev_budget
      net.core.netdev_budget_usecs = 2000
      net.core.netdev_budget = 300

      이러한 설정을 통해 softirqd 프로세스는 하나의 폴링 주기로 NIC에서 최대 300개의 메시지를 처리할 수 있는 최대 2000마이크로초를 갖습니다. 폴링은 어떤 조건이 먼저 충족되는지에 따라 종료됩니다.

    2. 다음 콘텐츠를 사용하여 /etc/sysctl.d/10-netdev_budget.conf 파일을 만듭니다.

      net.core.netdev_budget = 600
      net.core.netdev_budget_usecs = 4000

      매개변수를 현재 값의 double로 설정합니다.

    3. /etc/sysctl.d/10-netdev_budget.conf 파일에서 설정을 로드합니다.

      # sysctl -p /etc/sysctl.d/10-netdev_budget.conf

검증

  • /proc/net/softnet_stat 파일에서 세 번째 열을 모니터링합니다.

    # awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t

    값이 여전히 증가하는 경우 net.core.netdev_budget_usecsnet.core.netdev_budget 를 더 높은 값으로 설정합니다. 카운터가 더 이상 증가하지 않을 때까지 이 프로세스를 반복합니다.

31.3. 네트워크 대기 시간 개선

CPU 전원 관리 기능은 시간에 민감한 애플리케이션 처리에서 원치 않는 지연을 유발할 수 있습니다. 이러한 전원 관리 기능 중 일부 또는 모두를 비활성화하여 네트워크 대기 시간을 개선할 수 있습니다.

예를 들어 서버가 로드가 많은 것보다 유휴 상태일 때 대기 시간이 길면 CPU 전원 관리 설정이 대기 시간에 영향을 미칠 수 있습니다.

중요

CPU 전원 관리 기능을 비활성화하면 정전 및 전력 소비가 증가할 수 있습니다.

31.3.1. CPU 전원 상태가 네트워크 대기 시간에 미치는 영향

CPU의 소비 상태(C-states)는 컴퓨터의 전력 소비를 최적화하고 감소시킵니다. C-state는 C0부터 번호가 매겨집니다. C0에서 프로세서는 완전히 전원을 공급하고 실행됩니다. C1에서 프로세서는 완전히 전원을 공급하지만 실행하지 않습니다. C-state의 수가 많을수록 CPU가 꺼지는 구성 요소가 많을 수 있습니다.

CPU 코어가 유휴 상태가 될 때마다 기본 제공 전원 절약 논리 단계 in 및 다양한 프로세서 구성 요소를 꺼서 현재 C 상태에서 더 높은 상태로 코어를 이동하려고 합니다. CPU 코어가 데이터를 처리해야 하는 경우 RHEL(Red Hat Enterprise Linux)은 프로세서에 인터럽트를 보내 코어를 해제하고 C-state를 C0으로 다시 설정합니다.

깊은 C-state를 C0으로 다시 이동시키는 것은 프로세서의 다양한 구성 요소로 전원을 다시 켜기 때문에 시간이 걸립니다. 멀티 코어 시스템에서는 많은 코어가 동시에 유휴 상태이므로 더 깊은 C 상태가 될 수도 있습니다. RHEL이 동시에 문제를 해결하려고 하면 모든 코어에서 깊은 C-state를 반환하는 동안 커널에서 다수의 II(Inter-Processor Interrupts)를 생성할 수 있습니다. 인터럽트를 처리하는 동안 필요한 잠금으로 인해 시스템은 모든 인터럽트를 처리하는 동안 잠시 중단될 수 있습니다. 이로 인해 이벤트에 대한 애플리케이션 응답이 크게 지연될 수 있습니다.

예 31.2. 코어당 C 상태 표시

PowerTOP 애플리케이션의 Idle STAts 페이지에 CPU 코어가 각 C-state에 소요되는 시간을 표시합니다.

           Pkg(HW)  |            Core(HW) |            CPU(OS) 0   CPU(OS) 4
                    |                     | C0 active   2.5%        2.2%
                    |                     | POLL        0.0%    0.0 ms  0.0%    0.1 ms
                    |                     | C1          0.1%    0.2 ms  0.0%    0.1 ms
C2 (pc2)   63.7%    |                     |
C3 (pc3)    0.0%    | C3 (cc3)    0.1%    | C3          0.1%    0.1 ms  0.1%    0.1 ms
C6 (pc6)    0.0%    | C6 (cc6)    8.3%    | C6          5.2%    0.6 ms  6.0%    0.6 ms
C7 (pc7)    0.0%    | C7 (cc7)   76.6%    | C7s         0.0%    0.0 ms  0.0%    0.0 ms
C8 (pc8)    0.0%    |                     | C8          6.3%    0.9 ms  5.8%    0.8 ms
C9 (pc9)    0.0%    |                     | C9          0.4%    3.7 ms  2.2%    2.2 ms
C10 (pc10)  0.0%    |                     |
                    |                     | C10        80.8%    3.7 ms 79.4%    4.4 ms
                    |                     | C1E         0.1%    0.1 ms  0.1%    0.1 ms
...

31.3.2. EFI 펌웨어의 C 상태 설정

EFI 펌웨어가 있는 대부분의 시스템에서 개별 사용 상태(C-states)를 활성화 및 비활성화할 수 있습니다. 그러나 RHEL (Red Hat Enterprise Linux)에서 유휴 드라이버는 커널이 펌웨어의 설정을 사용하는지 여부를 결정합니다.

  • intel_idle: Intel CPU가 있는 호스트의 기본 드라이버이며 EFI 펌웨어의 C-state 설정을 무시합니다.
  • acpi_idle: RHEL은 Intel 이외의 공급 업체의 CPU가 있는 호스트에서 이 드라이버를 사용하고 intel_idle 이 비활성화된 경우 사용합니다. 기본적으로 acpi_idle 드라이버는 EFI 펌웨어의 C-state 설정을 사용합니다.

추가 리소스

  • /usr/share/doc/kernel-doc- <version> /Documentation/admin-guide/pm/cpuidle.rst - kernel-doc 패키지에서 제공

31.3.3. 사용자 정의 TuneD 프로필을 사용하여 C-state 비활성화

TuneD 서비스는 커널의PMQOS(Power Management Quality of Service) 인터페이스를 사용하여 소비 상태(C-states) 잠금을 설정합니다. 커널 유휴 드라이버는 이 인터페이스와 통신하여 C-state를 동적으로 제한할 수 있습니다. 따라서 관리자는 커널 명령줄 매개변수를 사용하여 최대 C-state 값을 하드 코딩해야 합니다.

사전 요구 사항

  • tuned 패키지가 설치되어 있습니다.
  • tuned 서비스가 활성화되어 실행되고 있습니다.

절차

  1. 활성 프로필을 표시합니다.

    # tuned-adm active
    Current active profile: network-latency
  2. 사용자 정의 TuneD 프로파일의 디렉터리를 생성합니다.

    # mkdir /etc/tuned/network-latency-custom/
  3. 다음 콘텐츠를 사용하여 /etc/tuned/network-latency-custom/tuned.conf 파일을 만듭니다.

    [main]
    include=network-latency
    
    [cpu]
    force_latency=cstate.id:1|2

    이 사용자 정의 프로필은 network-latency 프로필의 모든 설정을 상속합니다. force_latency TuneD 매개변수는 대기 시간을 microseconds(microseconds)로 지정합니다. C 상태 대기 시간이 지정된 값보다 크면 Red Hat Enterprise Linux의 유휴 상태로 인해 CPU가 더 높은 C 상태로 이동하지 않습니다. force_latency=cstate.id:1|2 로 TuneD는 먼저 /sys/devices/system/cpu_<number>_/cpuidle/state_<cstate.id>_/ 디렉터리가 존재하는지 확인합니다. 이 경우 TuneD는 이 디렉터리의 대기 시간 파일에서 대기 시간 값을 읽습니다. 디렉터리가 존재하지 않는 경우 TuneD는 2마이크로초를 폴백 값으로 사용합니다.

  4. network-latency-custom 프로필을 활성화합니다.

    # tuned-adm profile network-latency-custom

31.3.4. 커널 명령줄 옵션을 사용하여 C-state 비활성화

processor.max_cstateintel_idle.max_cstat 커널 명령줄 매개변수는 최대 소비 상태(C-state) CPU 코어를 구성할 수 있습니다. 예를 들어, 매개변수를 1 로 설정하면 CPU가 C1 미만의 C-state를 요청하지 않습니다.

이 방법을 사용하여 호스트의 애플리케이션 대기 시간이 C-states의 영향을 받는지 테스트합니다. 특정 상태를 하드 코딩하지 않으려면 더 동적 솔루션을 사용하는 것이 좋습니다. 사용자 정의 TuneD 프로필을 사용하여 C-state 비활성화를 참조하십시오.

사전 요구 사항

  • tuned 서비스가 C-state 설정을 업데이트하지 않도록 실행 중이거나 구성되지 않았습니다.

절차

  1. 시스템에서 사용하는 유휴 드라이버를 표시합니다.

    # cat /sys/devices/system/cpu/cpuidle/current_driver
    intel_idle
  2. 호스트에서 intel_idle 드라이버를 사용하는 경우 intel_idle.max_cstate 커널 매개변수를 설정하여 CPU 코어가 사용할 수 있는 가장 높은 C-state를 정의합니다.

    # grubby --update-kernel=ALL --args="intel_idle.max_cstate=0"

    intel_idle.max_cstate=0 을 설정하면 intel_idle 드라이버가 비활성화됩니다. 결과적으로 커널은 EFI 펌웨어에 설정된 C-state 값을 사용하는 acpi_idle 드라이버를 사용합니다. 이러한 이유로 processor.max_cstate 를 설정하여 이러한 C-state 설정을 재정의합니다.

  3. CPU 공급 업체와 독립적으로 모든 호스트에서 CPU 코어에서 사용할 수 있어야 하는 가장 높은 C-state를 설정합니다.

    # grubby --update-kernel=ALL --args="processor.max_cstate=0"
    중요

    intel_idle.max_cstate=0 외에 processor.max_cstate=0 을 설정하면 acpi_idle 드라이버가 processor.max_cstate 값을 재정의하고 1 로 설정합니다. 결과적으로 processor.max_cstate=0 intel_idle.max_cstate=0 인 경우 커널이 사용할 가장 높은 C 상태는 C0이 아닙니다.

  4. 변경 사항을 적용하려면 호스트를 다시 시작하십시오.

    # reboot

검증

  1. 최대 C-state를 표시합니다.

    # cat /sys/module/processor/parameters/max_cstate
    1
  2. 호스트에서 intel_idle 드라이버를 사용하는 경우 최대 C-state를 표시합니다.

    # cat /sys/module/intel_idle/parameters/max_cstate
    0

추가 리소스

31.4. 연속된 대량의 데이터 스트림의 처리량 향상

IEEE 802.3 표준에 따르면 VLAN(Virtual Local Area Network) 태그가 없는 기본 이더넷 프레임은 최대 크기가 1518바이트입니다. 이러한 각 프레임에는 18바이트 헤더가 포함되어 있으며 페이로드에 1500바이트를 남습니다. 결과적으로, 서버가 네트워크를 통해 전송되는 모든 1500바이트의 데이터에 대해 18바이트(1.2%) 이더넷 프레임 헤더도 오버헤드로 전송됩니다. 계층 3 및 4 프로토콜의 헤더는 패킷당 오버헤드를 더 높입니다.

네트워크의 호스트가 다수의 대용량 파일을 호스팅하는 백업 서버 또는 파일 서버와 같이 연속되는 여러 데이터 스트림을 보내는 경우 점보 프레임을 사용하여 오버헤드를 저장하는 것이 좋습니다. 점보 프레임은 1500바이트의 표준 이더넷 페이로드 크기보다 더 큰 최대 전송 단위(MTU)를 갖는 비표준 프레임입니다. 예를 들어 최대 허용되는 MTU가 9000바이트 페이로드로 점보 프레임을 구성하면 각 프레임의 오버헤드가 0.2%로 줄어듭니다.

네트워크 및 서비스에 따라 네트워크의 특정 부분에서만 점보 프레임(예: 클러스터의 스토리지 백엔드)을 활성화하는 것이 유용할 수 있습니다. 이렇게 하면 패킷 조각화가 방지됩니다.

31.4.1. 점보 프레임을 구성하기 전에 고려 사항

네트워크의 하드웨어, 애플리케이션 및 서비스에 따라 점보 프레임이 다른 영향을 미칠 수 있습니다. 점보 프레임이 시나리오의 이점을 제공하는지 여부를 신중하게 결정합니다.

사전 요구 사항

전송 경로의 모든 네트워크 장치는 점보 프레임을 지원해야 하며 동일한 최대 전송 단위(MTU) 크기를 사용해야 합니다. 반대로, 다음과 같은 문제에 직면할 수 있습니다:

  • 패킷을 삭제했습니다.
  • 조각화된 패킷으로 인해 대기 시간이 길어집니다.
  • 조각화로 인한 패킷 손실 위험 증가 예를 들어 라우터가 하나의 9000바이트 프레임을 6개의 1500바이트 프레임으로 분할하고 1500바이트 프레임 중 하나가 손실되면 전체 프레임이 손실됩니다.

다음 다이어그램에서 세 개의 서브넷에 있는 모든 호스트는 네트워크 A의 호스트가 네트워크 C의 호스트에 패킷을 보내는 경우 동일한 MTU를 사용해야 합니다.

네트워크 다이어그램 MTU

점보 프레임의 이점

  • 처리량이 높아짐: 각 프레임에는 프로토콜 오버헤드가 고정된 동안 더 많은 사용자 데이터가 포함됩니다.
  • CPU 사용률 감소: 점보 프레임으로 인해 인터럽트가 감소하므로 CPU 사이클이 절약됩니다.

점보 프레임의 단점

  • 대기 시간이 길음: 더 큰 프레임은 이어지는 패킷을 지연시킵니다.
  • 메모리 버퍼 사용량 증가: 더 큰 프레임은 버퍼 큐 메모리를 더 빠르게 채울 수 있습니다.

31.4.2. 기존 NetworkManager 연결 프로필에서 MTU 구성

네트워크에서 기본값과 다른 최대 전송 단위(MTU)가 필요한 경우 해당 NetworkManager 연결 프로필에서 이 설정을 구성할 수 있습니다.

점보 프레임은 1500에서 9000 바이트 사이의 페이로드가 있는 네트워크 패킷입니다. 동일한 브로드캐스트 도메인의 모든 장치는 이러한 프레임을 지원해야 합니다.

사전 요구 사항

  • 브로드캐스트 도메인의 모든 장치는 동일한 MTU를 사용합니다.
  • 네트워크의 MTU를 알고 있습니다.
  • Vivergent MTU를 사용하여 네트워크의 연결 프로필을 이미 구성하셨습니다.

절차

  1. 선택 사항: 현재 MTU를 표시합니다.

    # ip link show
    ...
    3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff
    ...
  2. 선택 사항: NetworkManager 연결 프로필을 표시합니다.

    # nmcli connection show
    NAME     UUID                                  TYPE      DEVICE
    Example  f2f33f29-bb5c-3a07-9069-be72eaec3ecf  ethernet  enp1s0
    ...
  3. 다양한 MTU를 사용하여 네트워크에 대한 연결을 관리하는 프로필의 MTU를 설정합니다.

    # nmcli connection modify Example mtu 9000
  4. 연결을 다시 활성화합니다.

    # nmcli connection up Example

검증

  1. MTU 설정을 표시합니다.

    # ip link show
    ...
    3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff
    ...
  2. 전송 경로의 호스트가 패킷 조각이 없는지 확인합니다.

    • 수신자 측에서 커널의 IP reassembly 통계를 표시합니다.

      # nstat -az IpReasm*
      #kernel
      IpReasmTimeout 0 0.0
      IpReasmReqds 0 0.0
      IpReasmOKs 0 0.0
      IpReasmFails 0 0.0

      카운터가 0 을 반환하면 패킷이 다시 조립되지 않았습니다.

    • 발신자 측에서 prohibit-fragmentation-bit로 ICMP 요청을 전송합니다.

      # ping -c1 -Mdo -s 8972 destination_host

      명령이 성공하면 패킷이 조각화되지 않았습니다.

      다음과 같이 패킷 크기 옵션 값을 계산합니다. MTU 크기 - 8바이트 ICMP 헤더 - 20바이트 IPv4 헤더 = 패킷 크기

31.5. 높은 처리량을 위해 TCP 연결 튜닝

Red Hat Enterprise Linux의 TCP 관련 설정을 조정하여 처리량을 늘리거나, 대기 시간을 줄이거나, 패킷 손실과 같은 문제를 방지합니다.

31.5.1. iperf3을 사용하여 TCP 처리량 테스트

iperf3 유틸리티는 두 호스트 간의 네트워크 처리량 테스트를 수행할 수 있는 서버와 클라이언트 모드를 제공합니다.

참고

애플리케이션 처리량은 애플리케이션에서 사용하는 버퍼 크기와 같은 여러 요인에 따라 달라집니다. 따라서 iperf3 과 같은 테스트 유틸리티로 측정한 결과는 프로덕션 워크로드에 있는 서버의 애플리케이션과 크게 다를 수 있습니다.

사전 요구 사항

  • iperf3 패키지는 클라이언트와 서버 모두에 설치됩니다.
  • 두 호스트의 다른 서비스가 테스트 결과에 상당한 영향을 미치는 네트워크 트래픽을 유발하지 않습니다.
  • 40Gbps 및 더 빠른 연결의 경우 네트워크 카드는 가속 Receive Flow hering (ARFS)을 지원하며 인터페이스에서 기능이 활성화됩니다.

절차

  1. 선택 사항: 서버와 클라이언트 모두에서 NIC(네트워크 인터페이스 컨트롤러)의 최대 네트워크 속도를 표시합니다.

    # ethtool enp1s0 | grep "Speed"
       Speed: 100000Mb/s
  2. 서버에서 다음을 수행합니다.

    1. firewalld 서비스에서 기본 iperf3 TCP 포트 5201을 임시로 엽니다.

      # firewall-cmd --add-port=5201/tcp
      # firewall-cmd --reload
    2. 서버 모드에서 iperf3 을 시작합니다.

      # iperf3 --server

      이제 서비스가 들어오는 클라이언트 연결을 대기 중입니다.

  3. 클라이언트에서 다음을 수행합니다.

    1. 처리량 측정을 시작합니다.

      # iperf3 --time 60 --zerocopy --client 192.0.2.1
      • --time <seconds > : 클라이언트가 전송을 중지할 때의 시간을 초 단위로 정의합니다.

        이 매개변수를 작업할 것으로 예상되는 값으로 설정하고 이후 측정에서 늘릴 수 있습니다. 서버가 전송 경로의 장치보다 빠른 속도로 패킷을 전송하거나 클라이언트가 처리할 수 있는 경우 패킷을 삭제할 수 있습니다.

      • --zerocopy: write() 시스템 호출을 사용하는 대신 0 복사 메서드를 활성화합니다. 복사 가능 애플리케이션을 시뮬레이션하거나 단일 스트림에서 40Gbps에 도달하려는 경우에만 이 옵션이 필요합니다.
      • --client <server >: 클라이언트 모드를 활성화하고 iperf3 서버를 실행하는 서버의 IP 주소 또는 이름을 설정합니다.
  4. iperf3 가 테스트를 완료할 때까지 기다립니다. 서버와 클라이언트 모두 1초마다 통계를 표시하고 마지막에 요약을 표시합니다. 예를 들어 다음은 클라이언트에 표시되는 요약입니다.

    [ ID] Interval         Transfer    Bitrate         Retr
    [  5] 0.00-60.00  sec  101 GBytes   14.4 Gbits/sec   0   sender
    [  5] 0.00-60.04  sec  101 GBytes   14.4 Gbits/sec       receiver

    이 예에서 평균 비트레이트는 14.4 Gbps였습니다.

  5. 서버에서 다음을 수행합니다.

    1. Ctrl+C 눌러 iperf3 서버를 중지합니다.
    2. firewalld 에서 TCP 포트 5201을 닫습니다.

      # firewall-cmd --remove-port=5201/tcp
      # firewall-cmd --reload

추가 리소스

  • iperf3(1) 매뉴얼 페이지

31.5.2. 시스템 전체 TCP 소켓 버퍼 설정

소켓 버퍼는 커널이 수신하거나 전송해야 하는 데이터를 임시로 저장합니다.

  • 읽기 소켓 버퍼에는 커널이 수신했지만 애플리케이션은 아직 읽지 않은 패킷이 있습니다.
  • 쓰기 소켓 버퍼에는 애플리케이션이 버퍼에 기록되었지만 커널이 IP 스택 및 네트워크 드라이버에 아직 전달되지 않은 패킷이 있습니다.

TCP 패킷이 너무 커서 버퍼 크기 또는 패킷이 너무 빠른 속도로 전송되거나 수신되는 경우 커널은 버퍼에서 데이터를 제거할 때까지 새로 들어오는 TCP 패킷을 삭제합니다. 이 경우 소켓 버퍼를 늘리면 패킷 손실을 방지할 수 있습니다.

net.ipv4.tcp_rmem (read) 및 net.ipv4.tcp_wmem (write) 소켓 버퍼 커널 설정에는 세 가지 값이 포함됩니다.

net.ipv4.tcp_rmem = 4096  131072  6291456
net.ipv4.tcp_wmem = 4096  16384   4194304

표시된 값은 바이트 단위이며 Red Hat Enterprise Linux는 다음과 같은 방식으로 사용합니다.

  • 첫 번째 값은 최소 버퍼 크기입니다. 새 소켓에는 크기가 더 작을 수 없습니다.
  • 두 번째 값은 기본 버퍼 크기입니다. 애플리케이션에서 버퍼 크기를 설정하지 않으면 기본값입니다.
  • 세 번째 값은 자동으로 튜닝된 버퍼의 최대 크기입니다. 애플리케이션에서 SO_SNDBUF 소켓 옵션과 함께 setsockopt() 함수를 사용하면 이 최대 버퍼 크기가 비활성화됩니다.

net.ipv4.tcp_rmemnet.ipv4.tcp_wmem 매개변수는 IPv4 및 IPv6 프로토콜 모두에 대해 소켓 크기를 설정합니다.

31.5.3. 시스템 전체 TCP 소켓 버퍼 증가

시스템 전체 TCP 소켓 버퍼는 커널이 수신하거나 전송해야 하는 데이터를 임시로 저장합니다. net.ipv4.tcp_rmem (read) 및 net.ipv4.tcp_wmem (write) 소켓 버퍼 커널 설정에는 각각 최소, default, maximum 값의 세 가지 설정이 포함되어 있습니다.

중요

버퍼 크기를 너무 크게 설정하면 메모리가 소모됩니다. 각 소켓은 애플리케이션에서 요청하는 크기로 설정할 수 있으며 커널은 이 값을 두 배로 늘립니다. 예를 들어 애플리케이션이 256KiB 소켓 버퍼 크기를 요청하고 1만 개의 소켓을 여는 경우 시스템은 최대 512GB RAM(512 KiB x 1 million)을 잠재적 소켓 버퍼 공간에만 사용할 수 있습니다.

또한 최대 버퍼 크기에 너무 큰 값은 대기 시간을 늘릴 수 있습니다.

사전 요구 사항

  • TCP 패킷 삭제 속도가 크게 발생했습니다.

절차

  1. 연결 대기 시간을 확인합니다. 예를 들어 클라이언트에서 서버로 ping하여 평균 Round Trip Time(RTT)를 측정합니다.

    # ping -c 10 server.example.com
    ...
    --- server.example.com ping statistics ---
    10 packets transmitted, 10 received, 0% packet loss, time 9014ms
    rtt min/avg/max/mdev = 117.208/117.056/119.333/0.616 ms

    이 예에서 대기 시간은 117ms입니다.

  2. 튜닝하려는 트래픽에 대해 다음 공식을 사용하여 BMC(Delay Product)를 계산합니다.

    connection speed in bytes * latency in ms = BDP in bytes

    예를 들어 117ms 대기 시간이 있는 10Gbps 연결에 대한 BDP를 계산하려면 다음을 수행합니다.

    (10 * 1000 * 1000 * 1000 / 8) * 117 = 10683760 bytes
  3. 요구 사항에 따라 /etc/sysctl.d/10-tcp-socket-buffers.conf 파일을 만들고 최대 읽기 또는 쓰기 버퍼 크기를 설정합니다.

    net.ipv4.tcp_rmem = 4096 262144 21367520
    net.ipv4.tcp_wmem = 4096 24576 21367520

    값을 바이트 단위로 지정합니다. 환경에 최적화된 값을 식별하려고 할 때 다음 규칙을 사용합니다.

    • 기본 버퍼 크기(초 값): 이 값을 약간만 늘리거나 524288 (512 KiB)으로 설정합니다. 너무 높은 기본 버퍼 크기는 버퍼가 충돌하여 결과적으로 대기 시간이 급증할 수 있습니다.
    • 최대 버퍼 크기(세번째 값): BDP의 곱셈에 두 번이면 충분한 경우가 많습니다.
  4. /etc/sysctl.d/10-tcp-socket-buffers.conf 파일에서 설정을 로드합니다.

    # sysctl -p /etc/sysctl.d/10-tcp-socket-buffers.conf
  5. 더 큰 소켓 버퍼 크기를 사용하도록 애플리케이션을 구성합니다. net.ipv4.tcp_rmemnet.ipv4.tcp_wmem 매개변수의 세 번째 값은 애플리케이션에서 setsockopt() 함수에서 요청할 수 있는 최대 버퍼 크기를 정의합니다.

    자세한 내용은 애플리케이션 프로그래밍 언어 설명서를 참조하십시오. 애플리케이션 개발자가 아닌 경우 개발자에게 문의하십시오.

  6. net.ipv4.tcp_rmem 또는 net.ipv4.tcp_wmem 매개변수에서 두 번째 값을 변경한 경우 애플리케이션을 다시 시작하여 새 TCP 버퍼 크기를 사용합니다.

    세 번째 값만 변경한 경우 자동 조정이 이러한 설정을 동적으로 적용하므로 애플리케이션을 다시 시작할 필요가 없습니다.

검증

  1. 선택 사항: iperf3을 사용하여 TCP 처리량을 테스트합니다.
  2. 패킷이 삭제될 때 사용한 것과 동일한 방법을 사용하여 패킷을 모니터링합니다.

    패킷이 계속 발생하지만 더 낮은 속도로 패킷이 발생하면 버퍼 크기를 더 늘립니다.

추가 리소스

31.5.4. TCP 창 확장

Red Hat Enterprise Linux에서 기본적으로 활성화되어 있는 TCP 창 확장 기능은 처리량을 크게 개선하는 TCP 프로토콜의 확장입니다.

예를 들어 1.5ms Round Trip Time(RTT)와 1Gbps 연결의 경우:

  • TCP Window Scaling을 사용하면 약 630Mbps가 실용적입니다.
  • TCP Window Scaling을 비활성화하면 처리량이 380Mbps로 줄어듭니다.

TCP가 제공하는 기능 중 하나는 흐름 제어입니다. 흐름 제어를 사용하면 수신자가 수신할 수 있는 만큼의 데이터를 보낼 수 있지만 더 이상 보낼 수 없습니다. 이를 위해 수신자는 발신자가 전송할 수 있는 데이터 양인 값을 알립니다.

TCP는 원래 최대 64KiB의 창 크기를 지원되지만, 높은 bandwidth Delay 제품(BDP)에서 이 값은 발신자가 한 번에 64KiB 이상을 보낼 수 없기 때문에 제한이 됩니다. 고속 연결은 한 번에 64KiB 이상의 데이터를 전송할 수 있습니다. 예를 들어 시스템 간에 1ms의 대기 시간이 있는 10Gbps 링크에는 지정된 시간에 전송 중 1MiB 이상의 데이터가 있을 수 있습니다. 호스트가 64KiB만 전송하는 경우 비효율적이며 다른 호스트에서 64KiB를 수신할 때까지 일시 중지합니다.

이러한 병목 현상을 제거하기 위해 TCP 창 확장 확장 기능을 사용하면 TCP 창 값을 요약하여 64KiB 이상으로 창 크기를 늘릴 수 있습니다. 예를 들어 65535 의 가장 큰 창 값이 7자리를 왼쪽으로 이동했기 때문에 창 크기가 거의 8MiB가 됩니다. 이렇게 하면 주어진 시간에 훨씬 더 많은 데이터를 전송할 수 있습니다.

TCP 창 확장은 모든 TCP 연결을 여는 3방향 TCP 핸드셰이크 중에 협상됩니다. 발신자와 수신자 모두 기능이 작동하려면 TCP 창 스케일링을 지원해야 합니다. 둘 중 하나 또는 둘 다 핸드셰이크에서 창 스케일링 기능을 광고하지 않으면 연결은 원래 16 비트 TCP 창 크기를 사용하는 것으로 되돌아갑니다.

기본적으로 TCP 창 확장이 Red Hat Enterprise Linux에서 활성화됩니다.

# sysctl net.ipv4.tcp_window_scaling
net.ipv4.tcp_window_scaling = 1

서버에서 TCP 창 스케일링이 비활성화된 경우(0) 설정한 것과 동일한 방식으로 설정을 되돌립니다.

31.5.5. TCP SACK에서 패킷 드롭 속도를 줄이는 방법

RHEL(Red Hat Enterprise Linux)에서 기본적으로 사용하도록 설정된 TCP 선택 승인(TCP SACK) 기능은 TCP 프로토콜의 향상된 기능이며 TCP 연결의 효율성을 높입니다.

TCP 전송에서 수신자는 수신되는 모든 패킷에 대해 ACK 패킷을 발신자에게 보냅니다. 예를 들어 클라이언트는 TCP 패킷 1-10을 서버로 전송하지만 패킷 번호 5 및 6은 손실됩니다. TCP SACK가 없으면 서버는 패킷 7-10을 삭제하고 클라이언트가 손실 시점에서 모든 패킷을 다시 전송해야 합니다. 이는 비효율적입니다. 두 호스트에서 TCP SACK를 활성화한 상태에서 클라이언트는 손실된 패킷 5와 6만 다시 전송해야 합니다.

중요

TCP SACK를 비활성화하면 성능이 저하되고 TCP 연결의 수신자 측에서 더 높은 패킷 드롭 속도가 발생합니다.

기본적으로 RHEL에서는 TCP SACK가 활성화됩니다. 확인하려면 다음을 수행하십시오.

# sysctl net.ipv4.tcp_sack
1

서버에서 TCP SACK (0)이 비활성화 된 경우 설정과 동일한 방식으로 설정을 되돌립니다.

31.6. UDP 연결 튜닝

UDP 트래픽 처리량을 개선하기 위해 Red Hat Enterprise Linux 튜닝을 시작하기 전에 실질적인 기대치를 갖는 것이 중요합니다. UDP는 간단한 프로토콜입니다. TCP와 비교하여 UDP에는 흐름 제어, 정체 제어 및 데이터 신뢰성과 같은 기능이 포함되어 있지 않습니다. 이로 인해 네트워크 인터페이스 컨트롤러(NIC)의 최대 속도와 가까운 처리량 속도를 사용하여 UDP를 통해 안정적으로 통신할 수 있습니다.

31.6.1. 패킷 삭제 탐지

커널에서 패킷을 삭제할 수 있는 네트워크 스택에는 여러 수준이 있습니다. Red Hat Enterprise Linux는 이러한 수준의 통계를 표시하는 다양한 유틸리티를 제공합니다. 잠재적인 문제를 식별하기 위해 사용합니다.

매우 적은 비율의 삭제된 패킷을 무시할 수 있습니다. 그러나 상당한 비율이 발생하는 경우 튜닝 조치를 고려하십시오.

참고

네트워킹 스택이 들어오는 트래픽을 처리할 수 없는 경우 커널은 네트워크 패킷을 삭제합니다.

절차

  1. NIC(네트워크 인터페이스 컨트롤러)가 패킷을 삭제하는지 여부를 확인합니다.

    1. NIC 및 드라이버별 통계를 표시합니다.

      # ethtool -S enp1s0
      NIC statistics:
           ...
           rx_queue_0_drops: 17657
           ...

      통계 이름 및 사용 가능한 경우 NIC와 드라이버에 따라 다릅니다.

    2. 인터페이스 통계를 표시합니다.

      # ip -s link show enp1s0
      2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
          link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff
          RX:   bytes  packets errors dropped  missed   mcast_
          84697611107 56866482      0   10904       0       0
          TX:   bytes  packets errors dropped carrier collsns_
           5540028184  3722234      0       0       0       0

      RX 는 수신된 패킷의 통계와 전송된 패킷의 TX 를 나타냅니다.

  2. 소켓 버퍼가 너무 느리거나 애플리케이션 처리 속도가 느리기 때문에 UDP 프로토콜 특정 패킷을 식별합니다.

    # nstat -az UdpSndbufErrors UdpRcvbufErrors
    #kernel
    UdpSndbufErrors           4    0.0
    UdpRcvbufErrors    45716659    0.0

    출력의 두 번째 열에는 카운터가 나열됩니다.

31.6.2. iperf3을 사용하여 UDP 처리량 테스트

iperf3 유틸리티는 두 호스트 간의 네트워크 처리량 테스트를 수행할 수 있는 서버와 클라이언트 모드를 제공합니다.

참고

애플리케이션 처리량은 애플리케이션에서 사용하는 버퍼 크기와 같은 여러 요인에 따라 달라집니다. 따라서 iperf3 과 같은 테스트 유틸리티로 측정한 결과는 프로덕션 워크로드에 있는 서버의 애플리케이션과 크게 다를 수 있습니다.

사전 요구 사항

  • iperf3 패키지는 클라이언트와 서버 모두에 설치됩니다.
  • 두 호스트의 다른 서비스가 테스트 결과에 상당한 영향을 미치는 네트워크 트래픽을 유발하지 않습니다.
  • 선택 사항: 서버와 클라이언트 모두에서 최대 UDP 소켓 크기를 늘렸습니다. 자세한 내용은 시스템 전체 UDP 소켓 버퍼 증가를 참조하십시오.

절차

  1. 선택 사항: 서버와 클라이언트 모두에서 NIC(네트워크 인터페이스 컨트롤러)의 최대 네트워크 속도를 표시합니다.

    # ethtool enp1s0 | grep "Speed"
       Speed: 10000Mb/s
  2. 서버에서 다음을 수행합니다.

    1. 최대 UDP 소켓 읽기 버퍼 크기를 표시하고 다음 값을 기록해 둡니다.

      # sysctl net.core.rmem_max
      net.core.rmem_max = 16777216

      표시된 값은 바이트 단위입니다.

    2. firewalld 서비스에서 기본 iperf3 포트 5201을 임시로 엽니다.

      # firewall-cmd --add-port=5201/tcp --add-port=5201/udp
      # firewall-cmd --reload

      iperf3 는 서버에서 TCP 소켓만 엽니다. 클라이언트가 UDP를 사용하려는 경우 먼저 이 TCP 포트에 연결한 다음 서버는 UDP 트래픽 처리량 테스트를 수행하기 위해 동일한 포트 번호에서 UDP 소켓을 엽니다. 따라서 로컬 방화벽에서 TCP 및 UDP 프로토콜 모두에 대해 포트 5201을 열어야 합니다.

    3. 서버 모드에서 iperf3 을 시작합니다.

      # iperf3 --server

      이제 서비스는 들어오는 클라이언트 연결을 기다립니다.

  3. 클라이언트에서 다음을 수행합니다.

    1. 클라이언트가 서버에 연결하는 데 사용할 인터페이스의 최대 전송 단위(MTU)를 표시하고 값을 기록해 둡니다.

      # ip link show enp1s0
      2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
      ...
    2. 최대 UDP 소켓 쓰기 버퍼 크기를 표시하고 값을 기록해 둡니다.

      # sysctl net.core.wmem_max
      net.core.wmem_max = 16777216

      표시된 값은 바이트 단위입니다.

    3. 처리량 측정을 시작합니다.

      # iperf3 --udp --time 60 --window 16777216 --length 1472 --bitrate 2G --client 192.0.2.1
      • -- UDP: 테스트에 UDP 프로토콜을 사용합니다.
      • --time <seconds > : 클라이언트가 전송을 중지할 때의 시간을 초 단위로 정의합니다.
      • --window & lt;size > : UDP 소켓 버퍼 크기를 설정합니다. 이상적으로 크기는 클라이언트와 서버 모두에서 동일합니다. 다른 경우 이 매개 변수를 서버의 net.core.wmem_max 또는 net.core.rmem_max 보다 작은 값으로 설정합니다.
      • --length <size > : 읽고 쓸 버퍼의 길이를 설정합니다. 이 옵션을 조각화되지 않은 가장 큰 페이로드로 설정합니다. MTU - IP 헤더 (20 IPv6의 경우 40바이트) - 8바이트 UDP 헤더를 계산합니다.
      • --bit rate < rate> : 비트 비율을 초당 지정된 비트 값으로 제한합니다. 2G for 2Gbps와 같은 단위를 지정할 수 있습니다.

        이 매개변수를 작업할 것으로 예상되는 값으로 설정하고 이후 측정에서 늘릴 수 있습니다. 서버가 전송 경로의 장치보다 빠른 속도로 패킷을 전송하거나 클라이언트가 처리할 수 있는 경우 패킷을 삭제할 수 있습니다.

      • --client <server >: 클라이언트 모드를 활성화하고 iperf3 서버를 실행하는 서버의 IP 주소 또는 이름을 설정합니다.
  4. iperf3 가 테스트를 완료할 때까지 기다립니다. 서버와 클라이언트 모두 1초마다 통계를 표시하고 마지막에 요약을 표시합니다. 예를 들어 다음은 클라이언트에 표시되는 요약입니다.

    [ ID] Interval       Transfer      Bitrate         Jitter    Lost/Total Datagrams
    [ 5] 0.00-60.00 sec  14.0 GBytes   2.00 Gbits/sec  0.000 ms  0/10190216 (0%) sender
    [ 5] 0.00-60.04 sec  14.0 GBytes   2.00 Gbits/sec  0.002 ms  0/10190216 (0%) receiver

    이 예에서 평균 비트 속도는 2Gbps이고 패킷이 손실되지 않았습니다.

  5. 서버에서 다음을 수행합니다.

    1. Ctrl+C 눌러 iperf3 서버를 중지합니다.
    2. firewalld 에서 포트 5201을 닫습니다.

      # firewall-cmd --remove-port=5201/tcp --remove-port=5201/udp
      # firewall-cmd --reload

추가 리소스

  • iperf3(1) 매뉴얼 페이지

31.6.3. UDP 트래픽 처리량에 대한 MTU 크기의 영향

애플리케이션이 대규모 UDP 메시지 크기를 사용하는 경우 점보 프레임을 사용하면 처리량이 향상될 수 있습니다. IEEE 802.3 표준에 따르면 VLAN(Virtual Local Area Network) 태그가 없는 기본 이더넷 프레임은 최대 크기가 1518바이트입니다. 이러한 각 프레임에는 18바이트 헤더가 포함되어 있으며 페이로드에 1500바이트를 남습니다. 결과적으로, 모든 1500바이트의 데이터에 대해 서버가 네트워크를 통해 전송되는 경우 18바이트(1.2%)가 오버헤드입니다.

점보 프레임은 1500바이트의 표준 이더넷 페이로드 크기보다 더 큰 최대 전송 단위(MTU)를 갖는 비표준 프레임입니다. 예를 들어, 최대 허용된 MTU가 9000바이트 페이로드로 점보 ECDHEs를 구성하면 각 프레임의 오버헤드가 0.2%로 줄어듭니다.

중요

전송 경로 및 관련 브로드캐스트 도메인의 모든 네트워크 장치는 점보 프레임을 지원하고 동일한 MTU를 사용해야 합니다. 전송 경로에 MTU 설정이 일관되지 않기 때문에 패킷 조각화 및 재조정으로 인해 네트워크 처리량이 감소합니다.

연결 유형에 따라 특정 MTU 제한 사항이 있습니다.

  • 이더넷: MTU는 9000바이트로 제한됩니다.
  • 데이터그램 모드에서 IPoIB(InfiniBand) IP: MTU는 InfiniBand MTU보다 4바이트 미만으로 제한됩니다.
  • 메모리 내 네트워킹은 일반적으로 더 큰 MTU를 지원합니다. 자세한 내용은 해당 문서를 참조하십시오.

31.6.4. UDP 트래픽 처리량에 대한 CPU 속도 영향

대규모 전송에서 UDP 프로토콜은 TCP보다 효율이 떨어지며 주로 UDP에서 패킷 집계가 누락되어 있습니다. 기본적으로 GRO(Generic Receive Offload) 및 TSO(Transmit Segmentation Offload) 기능은 활성화되어 있지 않습니다. 결과적으로 CPU 빈도는 고속 링크에서 대규모 전송을 위해 UDP 처리량을 제한할 수 있습니다.

예를 들어, MTU(Maximum Transmission Unit) 및 대용량 소켓 버퍼가 있는 tuned 호스트에서 3GbE CPU는 완전한 속도로 UDP 트래픽을 전송하거나 수신하는 10GB NIC의 트래픽을 처리할 수 있습니다. 그러나 UDP 트래픽을 전송할 때 3개 미만의 CPU 속도당 약 2Gbps의 속도 손실이 발생할 것으로 예상할 수 있습니다. 또한 3Gbps의 CPU 속도가 10Gbps를 달성할 수 있는 경우 동일한 CPU는 40GB NIC에서 UDP 트래픽을 약 20-25Gbps로 제한합니다.

31.6.5. 시스템 전체 UDP 소켓 버퍼 증가

소켓 버퍼는 커널이 수신하거나 전송해야 하는 데이터를 임시로 저장합니다.

  • 읽기 소켓 버퍼에는 커널이 수신했지만 애플리케이션은 아직 읽지 않은 패킷이 있습니다.
  • 쓰기 소켓 버퍼에는 애플리케이션이 버퍼에 기록되었지만 커널이 IP 스택 및 네트워크 드라이버에 아직 전달되지 않은 패킷이 있습니다.

UDP 패킷이 너무 커서 버퍼 크기 또는 패킷이 너무 빠른 속도로 전송되거나 수신되는 경우 커널은 버퍼에서 데이터를 제거할 때까지 새로 들어오는 UDP 패킷을 삭제합니다. 이 경우 소켓 버퍼를 늘리면 패킷 손실을 방지할 수 있습니다.

중요

버퍼 크기를 너무 크게 설정하면 메모리가 소모됩니다. 각 소켓은 애플리케이션에서 요청하는 크기로 설정할 수 있으며 커널은 이 값을 두 배로 늘립니다. 예를 들어 애플리케이션이 256KiB 소켓 버퍼 크기를 요청하고 1만 개의 소켓을 여는 경우 시스템은 잠재적인 소켓 버퍼 공간에만 512GB RAM(512 KiB x 1 million)이 필요합니다.

사전 요구 사항

  • UDP 패킷 삭제 속도가 크게 발생했습니다.

절차

  1. 요구 사항에 따라 /etc/sysctl.d/10-udp-socket-buffers.conf 파일을 만들고 최대 읽기 또는 쓰기 버퍼 크기를 설정합니다.

    net.core.rmem_max = 16777216
    net.core.wmem_max = 16777216

    값을 바이트 단위로 지정합니다. 이 예제의 값은 버퍼의 최대 크기를 16MiB로 설정합니다. 두 매개변수의 기본값은 212992 바이트(208KiB)입니다.

  2. /etc/sysctl.d/10-udp-socket-buffers.conf 파일에서 설정을 로드합니다.

    # sysctl -p /etc/sysctl.d/10-udp-socket-buffers.conf
  3. 더 큰 소켓 버퍼 크기를 사용하도록 애플리케이션을 구성합니다.

    net.core.rmem_maxnet.core.wmem_max 매개 변수는 애플리케이션에서 setsockopt() 함수에서 요청할 수 있는 최대 버퍼 크기를 정의합니다. setsockopt() 함수를 사용하지 않도록 애플리케이션을 구성하는 경우 커널은 rmem_defaultwmem_default 매개 변수의 값을 사용합니다.

    자세한 내용은 애플리케이션 프로그래밍 언어 설명서를 참조하십시오. 애플리케이션 개발자가 아닌 경우 개발자에게 문의하십시오.

  4. 애플리케이션을 다시 시작하여 새로운 UDP 버퍼 크기를 사용합니다.

검증

  • 패킷이 삭제될 때 사용한 것과 동일한 방법을 사용하여 패킷 드롭 통계를 모니터링합니다.

    패킷이 계속 발생하지만 더 낮은 속도로 패킷이 발생하면 버퍼 크기를 더 늘립니다.

추가 리소스

31.7. 애플리케이션 읽기 소켓 버퍼 병목 현상 식별

TCP 애플리케이션에서 읽기 소켓 버퍼를 자주 지우지 않으면 성능이 저하될 수 있으며 패킷이 손실될 수 있습니다. Red Hat Enterprise Linux는 이러한 문제를 식별할 수 있는 다양한 유틸리티를 제공합니다.

31.7.1. 수신 버퍼 충돌 및 정리 확인

수신 대기열의 데이터가 수신 버퍼 크기를 초과하면 TCP 스택은 소켓 버퍼에서 불필요한 메타데이터를 제거하여 일부 공간을 확보하려고 합니다. 이 단계를 collapsing이라고 합니다.

충돌 시 추가 트래픽을 위한 충분한 공간을 확보하지 못하는 경우 커널은 도달되는 새 데이터를 정리합니다. 즉, 커널은 메모리에서 데이터를 제거하고 패킷이 손실됩니다.

충돌 및 정리 작업을 방지하려면 서버에서 TCP 버퍼 충돌 및 정리가 발생하는지 여부를 모니터링하고, 이 경우 TCP 버퍼를 튜닝합니다.

절차

  1. nstat 유틸리티를 사용하여 TcpExtTCPRcvCollapsedTcpExtRcvPruned 카운터를 쿼리합니다.

    # nstat -az TcpExtTCPRcvCollapsed TcpExtRcvPruned
    #kernel
    TcpExtRcvPruned            0         0.0
    TcpExtTCPRcvCollapsed      612859    0.0
  2. 잠시 기다렸다가 nstat 명령을 다시 실행합니다.

    # nstat -az TcpExtTCPRcvCollapsed TcpExtRcvPruned
    #kernel
    TcpExtRcvPruned            0         0.0
    TcpExtTCPRcvCollapsed      620358    0.0
  3. 카운터 값이 첫 번째 실행에 비해 증가한 경우 튜닝이 필요합니다.

    • 애플리케이션에서 setsockopt(SO_RCVBUF) 호출을 사용하는 경우 해당 호출을 제거하는 것이 좋습니다. 이 호출을 사용하면 애플리케이션은 호출에 지정된 수신 버퍼 크기만 사용하고 소켓의 크기를 자동으로 조정하는 기능을 끕니다.
    • 애플리케이션에서 setsockopt(SO_RCVBUF) 호출을 사용하지 않는 경우 TCP 읽기 소켓 버퍼의 기본값 및 최대 값을 조정합니다.
  4. 수신 백로그 큐 표시(recv-Q):

    # ss -nti
    State   Recv-Q   Send-Q   Local Address:Port   Peer Address:Port   Process
    ESTAB   0        0        192.0.2.1:443        192.0.2.125:41574
          :7,7 ... lastrcv:543 ...
    ESTAB   78       0        192.0.2.1:443        192.0.2.56:42612
          :7,7 ... lastrcv:658 ...
    ESTAB   88       0        192.0.2.1:443        192.0.2.97:40313
          :7,7 ... lastrcv:5764 ...
    ...
  5. ss -nt 명령을 여러 번 실행하고 각 실행 사이의 대기 시간을 몇 초 동안 실행합니다.

    출력에 Recv-Q 열에서 높은 값의 경우만 나열되는 경우 애플리케이션은 두 개의 수신 작업 사이에 있었습니다. 그러나 Recv-Q 의 값이 일정하게 유지되지만 lastrcv 가 지속적으로 증가하거나 Recv-Q 가 지속적으로 증가하는 경우 다음 문제 중 하나가 원인일 수 있습니다.

    • 애플리케이션은 소켓 버퍼를 충분히 자주 확인하지 않습니다. 이 문제를 해결하는 방법에 대한 자세한 내용은 애플리케이션 벤더에 문의하십시오.
    • 애플리케이션에 CPU 시간이 충분하지 않습니다. 이 문제를 추가로 디버깅하려면 다음을 수행합니다.

      1. 애플리케이션이 실행하는 CPU 코어를 표시합니다.

        # ps -eo pid,tid,psr,pcpu,stat,wchan:20,comm
            PID     TID PSR %CPU STAT WCHAN                COMMAND
        ...
          44594   44594   5  0.0 Ss   do_select            httpd
          44595   44595   3  0.0 S    skb_wait_for_more_pa httpd
          44596   44596   5  0.0 Sl   pipe_read            httpd
          44597   44597   5  0.0 Sl   pipe_read            httpd
          44602   44602   5  0.0 Sl   pipe_read            httpd
        ...

        PSR 열에는 프로세스가 현재 할당된 CPU 코어가 표시됩니다.

      2. 동일한 코어에서 실행 중인 다른 프로세스를 식별하고 다른 코어에 할당하는 것이 좋습니다.

31.8. 많은 수의 수신 요청을 사용하여 애플리케이션 튜닝

웹 서버와 같이 들어오는 많은 요청을 처리하는 애플리케이션을 실행하는 경우 성능을 최적화하기 위해 Red Hat Enterprise Linux를 조정해야 할 수 있습니다.

31.8.1. 많은 TCP 연결 시도를 처리하기 위해 TCP 수신 백로그 튜닝

애플리케이션이 LISTEN 상태에서 TCP 소켓을 열 때 커널은 이 소켓이 처리할 수 있는 승인된 클라이언트 연결 수를 제한합니다. 클라이언트가 처리할 수 있는 것보다 더 많은 연결을 설정하려고 하면 새 연결이 손실되거나 커널이 클라이언트에 SYN 쿠키를 보냅니다.

시스템이 정상적인 워크로드 상태에 있고 적법한 클라이언트의 연결이 너무 많으면 커널에서 SYN 쿠키를 전송하도록 하려면 RHEL(Red Hat Enterprise Linux)을 조정하여 이를 방지합니다.

사전 요구 사항

  • RHEL 로그에서 SYN 플러싱 가능 포트 < ip_address > : <port_number > 오류 메시지의 Systemd 저널.
  • 연결 시도 횟수는 유효한 소스에서 생성되며 공격에 의한 것이 아닙니다.

절차

  1. 튜닝이 필요한지 여부를 확인하려면 영향을 받는 포트의 통계를 표시합니다.

    # ss -ntl '( sport = :443 )'
    State    Recv-Q   Send-Q   Local Address:Port   Peer Address:Port  Process
    LISTEN   650      500      192.0.2.1:443        0.0.0.0:*

    백로그(Recv-Q)의 현재 연결 수가 소켓 백로그(Send-Q)보다 큰 경우 수신 백로그는 여전히 충분하지 않고 튜닝이 필요합니다.

  2. 선택 사항: 현재 TCP 수신 백로그 제한을 표시합니다.

    # sysctl net.core.somaxconn
    net.core.somaxconn = 4096
  3. /etc/sysctl.d/10-socket-backlog-limit.conf 파일을 만들고 더 큰 수신 백로그 제한을 설정합니다.

    net.core.somaxconn = 8192

    애플리케이션은 net.core.somaxconn 커널 매개변수에 지정된 것보다 큰 수신 백로그를 요청할 수 있지만 커널은 애플리케이션을 이 매개변수에 설정한 번호로 제한할 수 있습니다.

  4. /etc/sysctl.d/10-socket-backlog-limit.conf 파일에서 설정을 로드합니다.

    # sysctl -p /etc/sysctl.d/10-socket-backlog-limit.conf
  5. 새 listen backlog 제한을 사용하도록 애플리케이션을 재구성합니다.

    • 애플리케이션에서 제한에 대한 config 옵션을 제공하는 경우 이를 업데이트합니다. 예를 들어 Apache HTTP 서버는 이 서비스에 대한 listen backlog 제한을 설정하는 ListenBacklog 구성 옵션을 제공합니다.
    • 제한을 구성할 수 없는 경우 애플리케이션을 다시 컴파일합니다.
  6. 애플리케이션을 다시 시작합니다.

검증

  1. 포트 < port_number> 오류 메시지에서 가능한 SYN 플러딩이 발생할 수 있는지 Systemd 저널을 모니터링합니다.
  2. 백로그에서 현재 연결 수를 모니터링하고 소켓 백로그와 비교합니다.

    # ss -ntl '( sport = :443 )'
    State    Recv-Q   Send-Q   Local Address:Port   Peer Address:Port  Process
    LISTEN   0        500      192.0.2.1:443        0.0.0.0:*

    백로그(Recv-Q)의 현재 연결 수가 소켓 백로그(Send-Q)보다 크면 수신 백로그가 충분히 크지 않고 추가 튜닝이 필요합니다.

31.9. 수신 대기 대기열 잠금 경합 방지

큐 잠금 경합으로 인해 패킷이 감소하고 CPU 사용량이 증가할 수 있으므로 대기 시간이 길어집니다. 애플리케이션을 조정하고 패킷 라이틀링을 사용하여 수신(RX) 및 전송(TX) 대기열에서 대기열 잠금 경합을 방지할 수 있습니다.

31.9.1. RX 대기열 잠금 방지: SO_REUSEPORT 및 SO_REUSEPORT_BPF 소켓 옵션

멀티 코어 시스템에서는 애플리케이션이 SO_REUSEPORT 또는 SO_REUSEPORT_BPF 소켓 옵션을 사용하여 포트를 여는 경우 다중 스레드 네트워크 서버 애플리케이션의 성능을 향상시킬 수 있습니다. 애플리케이션에서 이러한 소켓 옵션 중 하나를 사용하지 않는 경우 모든 스레드는 들어오는 트래픽을 수신하기 위해 단일 소켓을 공유해야 합니다. 단일 소켓 원인을 사용하여 다음을 수행합니다.

  • 수신 버퍼의 상당한 경합으로 인해 패킷이 감소하고 CPU 사용량이 증가할 수 있습니다.
  • CPU 사용량이 크게 증가
  • 패킷이 삭제될 수 있습니다.
잠금 경합

SO_REUSEPORT 또는 SO_REUSEPORT_BPF 소켓 옵션을 사용하면 한 호스트의 여러 소켓이 동일한 포트에 바인딩될 수 있습니다.

so reuseport

Red Hat Enterprise Linux는 커널 소스에서 SO_REUSEPORT 소켓 옵션을 사용하는 방법에 대한 코드 예제를 제공합니다. 코드 예제에 액세스하려면 다음을 수행합니다.

  1. rhel-9-for-x86_64-baseos-debug-rpms 리포지토리를 활성화합니다.

    # subscription-manager repos --enable rhel-9-for-x86_64-baseos-debug-rpms
  2. kernel-debuginfo-common-x86_64 패키지를 설치합니다.

    # dnf install kernel-debuginfo-common-x86_64
  3. 코드 예제는 이제 /usr/src/debug/kernel- <version> /linux-<version>/tools/testing/selftests/net/reuseport_bpf_cpu.c 파일에서 사용할 수 있습니다.

추가 리소스

  • socketECDHE 매뉴얼 페이지
  • /usr/src/debug/kernel- <version> /linux-<version>/tools/testing/selftests/net/reuseport_bpf_cpu.c

31.9.2. TX 대기열 잠금 경합 방지: 패킷 작동 전송

여러 큐를 지원하는 NIC(네트워크 인터페이스 컨트롤러)가 있는 호스트에서 송신된 네트워크 패킷 처리(XPS)는 여러 큐 간에 발신 네트워크 패킷을 배포합니다. 이를 통해 여러 CPU가 발신 네트워크 트래픽을 처리하고 대기열 잠금 경합 전송을 방지할 수 있으므로 패킷이 삭제됩니다.

ixgbe,i40emlx5 와 같은 특정 드라이버는 XPS를 자동으로 구성합니다. 드라이버가 이 기능을 지원하는지 확인하려면 NIC 드라이버 설명서를 참조하십시오. NIC 드라이버의 설명서를 참조하여 드라이버가 이 기능을 지원하는지 확인합니다. 드라이버가 XPS 자동 튜닝을 지원하지 않는 경우 CPU 코어를 전송 대기열에 수동으로 할당할 수 있습니다.

참고

Red Hat Enterprise Linux는 CPU 코어에 전송 대기열을 영구적으로 할당할 수 있는 옵션을 제공하지 않습니다. 스크립트에서 명령을 사용하고 시스템이 부팅될 때 실행합니다.

사전 요구 사항

  • NIC는 여러 큐를 지원합니다.
  • numactl 패키지가 설치되어 있어야 합니다.

절차

  1. 사용 가능한 대기열 수를 표시합니다.

    # ethtool -l enp1s0
    Channel parameters for enp1s0:
    Pre-set maximums:
    RX:		0
    TX:		0
    Other:		0
    Combined:	4
    Current hardware settings:
    RX:		0
    TX:		0
    Other:		0
    Combined:	1

    Pre-set maximums 섹션에는 총 대기열 수와 현재 수신, 전송, 기타 또는 결합된 대기열에 할당된 대기열 수가 설정되어 있습니다.

  2. 선택 사항: 특정 채널에서 대기열이 필요한 경우 적절하게 할당합니다. 예를 들어 4개의 대기열을 Combined 채널에 할당하려면 다음을 입력합니다.

    # ethtool -L enp1s0 combined 4
  3. NIC가 할당된 NUMA(Non-Uniform Memory Access) 노드에 표시합니다.

    # cat /sys/class/net/enp1s0/device/numa_node
    0

    파일을 찾을 수 없거나 명령이 -1 을 반환하는 경우 호스트는 NUMA 시스템이 아닙니다.

  4. 호스트가 NUMA 시스템인 경우 어떤 CPU가 어떤 NUMA 노드에 할당되는지 표시합니다.

    # lscpu | grep NUMA
    NUMA node(s):       2
    NUMA node0 CPU(s):  0-3
    NUMA node1 CPU(s):  4-7
  5. 위의 예에서 NIC에는 4개의 대기열이 있으며 NIC는 NUMA 노드 0에 할당됩니다. 이 노드는 CPU 코어 0-3을 사용합니다. 결과적으로 각 전송 큐를 0-3에서 CPU 코어 중 하나에 매핑합니다.

    # echo 1 > /sys/class/net/enp1s0/queues/tx-0/xps_cpus
    # echo 2 > /sys/class/net/enp1s0/queues/tx-1/xps_cpus
    # echo 4 > /sys/class/net/enp1s0/queues/tx-2/xps_cpus
    # echo 8 > /sys/class/net/enp1s0/queues/tx-3/xps_cpus

    CPU 코어 수와 전송(TX) 대기열 수가 동일한 경우 1에서 1개의 매핑을 사용하여 TX 대기열의 경합을 방지합니다. 그렇지 않으면 동일한 TX 큐에 여러 CPU를 매핑하면 서로 다른 CPU에 대한 전송 작업으로 인해 TX 대기열 잠금 경합이 발생하고 전송 처리량에 부정적인 영향을 미칩니다.

    CPU의 코어 번호가 포함된 비트맵을 큐에 전달해야 합니다. 다음 명령을 사용하여 비트맵을 계산합니다.

    # printf %x $((1 << <core_number> ))

검증

  1. 트래픽을 전송하는 서비스의 프로세스 ID(PID)를 식별합니다.

    # pidof <process_name>
    12345 98765
  2. XPS를 사용하는 코어에 PID를 고정합니다.

    # numactl -C 0-3 12345 98765
  3. 프로세스에서 트래픽을 보내는 동안 requeues 카운터를 모니터링합니다.

    # tc -s qdisc
    qdisc fq_codel 0: dev enp10s0u1 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
     Sent 125728849 bytes 1067587 pkt (dropped 0, overlimits 0 requeues 30)
     backlog 0b 0p requeues 30
     ...

    Requeue s 카운터가 더 이상 상당한 속도로 증가하지 않으면 TX 대기열 잠금 경합이 더 이상 발생하지 않습니다.

추가 리소스

  • /usr/share/doc/kernel-doc-_<version>/Documentation/networking/scaling.rst

31.9.3. UDP 트래픽이 높은 서버에서 Generic Receive Offload 기능 비활성화

고속 UDP 대량 전송을 사용하는 애플리케이션은 UDP 소켓에서 UDP GRO(Generic Receive Offload)를 활성화하고 사용해야 합니다. 그러나 다음 조건이 적용되는 경우 GRO를 비활성화하여 처리량을 늘릴 수 있습니다.

  • 애플리케이션이 GRO를 지원하지 않으며 기능을 추가할 수 없습니다.
  • TCP 처리량은 중요하지 않습니다.

    주의

    GRO를 비활성화하면 TCP 트래픽의 수신 처리량이 크게 저하됩니다. 따라서 TCP 성능이 관련된 호스트에서 GRO를 비활성화하지 마십시오.

사전 요구 사항

  • 호스트는 주로 UDP 트래픽을 처리합니다.
  • 애플리케이션에서 GRO를 사용하지 않습니다.
  • 호스트는 VXLAN과 같은 UDP 터널 프로토콜을 사용하지 않습니다.
  • 호스트에서 VM(가상 머신) 또는 컨테이너를 실행하지 않습니다.

절차

  1. 선택 사항: NetworkManager 연결 프로필을 표시합니다.

    # nmcli connection show
    NAME     UUID                                  TYPE      DEVICE
    example  f2f33f29-bb5c-3a07-9069-be72eaec3ecf  ethernet  enp1s0
  2. 연결 프로필에서 GRO 지원을 비활성화합니다.

    # nmcli connection modify example ethtool.feature-gro off
  3. 연결 프로필을 다시 활성화합니다.

    # nmcli connection up example

검증

  1. GRO가 비활성화되어 있는지 확인합니다.

    # ethtool -k enp1s0 | grep generic-receive-offload
    generic-receive-offload: off
  2. 서버의 처리량을 모니터링합니다. 설정이 호스트의 다른 애플리케이션에 부정적인 영향을 미치는 경우 NetworkManager 프로필에서 GRO를 다시 활성화합니다.

31.10. 장치 드라이버 및 NIC 튜닝

RHEL에서 kernel 모듈은 NIC(네트워크 인터페이스 컨트롤러)의 드라이버를 제공합니다. 이 모듈은 매개변수를 지원하여 장치 드라이버 및 NIC를 튜닝하고 최적화합니다. 예를 들어 드라이버가 수신 인터럽트 생성 지연을 지원하는 경우 수신 설명자가 부족하지 않도록 해당 매개변수의 값을 줄일 수 있습니다.

참고

모든 모듈이 사용자 지정 매개변수를 지원하는 것은 아니며 기능이 하드웨어와 드라이버 및 펌웨어 버전에 따라 달라집니다.

31.10.1. 사용자 정의 NIC 드라이버 매개변수 구성

많은 커널 모듈에서는 드라이버 및 NIC(네트워크 인터페이스 컨트롤러)를 튜닝하는 매개 변수 설정을 지원합니다. 하드웨어 및 드라이버에 따라 설정을 사용자 지정할 수 있습니다.

중요

커널 모듈에서 매개변수를 설정하면 RHEL은 이 드라이버를 사용하는 모든 장치에 이러한 설정을 적용합니다.

사전 요구 사항

  • 호스트에 NIC가 설치되어 있습니다.
  • NIC에 드라이버를 제공하는 커널 모듈은 필요한 튜닝 기능을 지원합니다.
  • 로컬에 로그인했거나 매개 변수를 변경하려는 드라이버를 사용하는 것과 다른 네트워크 인터페이스를 사용합니다.

절차

  1. 드라이버를 식별합니다.

    # ethtool -i enp0s31f6
    driver: e1000e
    version: ...
    firmware-version: ...
    ...

    특정 기능에는 특정 드라이버 및 펌웨어 버전이 필요할 수 있습니다.

  2. 커널 모듈의 사용 가능한 매개변수를 표시합니다.

    # modinfo -p e1000e
    ...
    SmartPowerDownEnable:Enable PHY smart power down (array of int)
    parm:RxIntDelay:Receive Interrupt Delay (array of int)

    매개변수에 대한 자세한 내용은 커널 모듈 설명서를 참조하십시오. RHEL의 모듈에 대해서는 kernel-doc 패키지에서 제공하는 /usr/share/doc/kernel-doc- <version> /Documentation/networking/device_drivers/ 디렉터리의 문서를 참조하십시오.

  3. /etc/modprobe.d/nic-parameters.conf 파일을 생성하고 모듈에 대한 매개변수를 지정합니다.

    options <module_name> <parameter1>=<value> <parameter2>=<value>

    예를 들어 포트 전원 절약 메커니즘을 활성화하고 수신 인터럽트 생성을 4 단위로 설정하려면 다음을 입력합니다.

    options e1000e SmartPowerDownEnable=1 RxIntDelay=4
  4. 모듈을 언로드합니다.

    # modprobe -r e1000e
    주의

    활성 네트워크 인터페이스에서 사용하는 모듈을 언로드하면 즉시 연결을 종료하고 서버에서 자신을 잠글 수 있습니다.

  5. 모듈을 로드합니다.

    # modprobe e1000e
  6. 네트워크 연결을 다시 활성화합니다.

    # nmcli connection up <profile_name>

검증

  1. 커널 메시지를 표시합니다.

    # dmesg
    ...
    [35309.225765] e1000e 0000:00:1f.6: Transmit Interrupt Delay set to 16
    [35309.225769] e1000e 0000:00:1f.6: PHY Smart Power Down Enabled
    ...

    일부 모듈 로그 매개변수 설정은 커널 링 버퍼에 대한 것은 아닙니다.

  2. 특정 커널 모듈은 /sys/module/ <driver> /parameters/ 디렉터리의 각 모듈 매개변수에 대한 파일을 생성합니다. 이러한 각 파일에는 이 매개변수의 현재 값이 포함되어 있습니다. 이 파일을 표시하여 설정을 확인할 수 있습니다.

    # cat /sys/module/<driver_name>/parameters/<parameter_name>

31.11. 네트워크 어댑터 오프로드 설정 구성

CPU 부하를 줄이기 위해 특정 네트워크 어댑터는 네트워크 처리 부하를 NIC(네트워크 인터페이스 컨트롤러)로 이동하는 오프로드 기능을 사용합니다. 예를 들어 ESP(Security Payload) 오프로드를 캡슐화하면 NIC에서 ESP 작업을 수행하여 IPsec 연결을 가속화하고 CPU 로드를 줄입니다.

기본적으로 Red Hat Enterprise Linux의 대부분의 오프로드 기능이 활성화됩니다. 다음 경우에만 비활성화합니다.

  • 문제 해결을 위해 오프로드 기능을 일시적으로 비활성화합니다.
  • 특정 기능이 호스트에 부정적인 영향을 미칠 때 오프로드 기능을 영구적으로 비활성화합니다.

네트워크 드라이버에서 성능 관련 오프로드 기능이 기본적으로 활성화되어 있지 않으면 수동으로 활성화할 수 있습니다.

31.11.1. 일시적으로 오프로드 기능 설정

오프로드 기능이 문제를 유발하거나 호스트의 성능을 저하시킬 것으로 예상되는 경우 현재 상태에 따라 일시적으로 활성화 또는 비활성화하여 원인을 축소할 수 있습니다.

일시적으로 오프로드 기능을 활성화하거나 비활성화하는 경우 다음 재부팅 시 이전 값으로 돌아갑니다.

사전 요구 사항

  • 네트워크 카드는 오프로드 기능을 지원합니다.

절차

  1. 인터페이스의 사용 가능한 오프로드 기능과 해당 현재 상태를 표시합니다.

    # ethtool -k enp1s0
    ...
    esp-hw-offload: on
    ntuple-filters: off
    rx-vlan-filter: off [fixed]
    ...

    출력은 하드웨어의 기능과 해당 드라이버의 기능에 따라 달라집니다. [fixed] 로 플래그가 지정된 기능 상태를 변경할 수 없습니다.

  2. 오프로드 기능을 일시적으로 비활성화합니다.

    # ethtool -K <interface> <feature> [on|off]
    • 예를 들어 enp10s0u1 인터페이스에서 IPsec ESP(Security Payload) 오프로드를 일시적으로 비활성화하려면 다음을 입력합니다.

      # ethtool -K enp10s0u1 esp-hw-offload off
    • 예를 들어 enp10s0u1 인터페이스에서 가속 Receive Flow hering (aRFS) 필터링을 일시적으로 활성화하려면 다음을 입력합니다.

      # ethtool -K enp10s0u1 ntuple-filters on

검증

  1. 오프로드 기능 상태를 표시합니다.

    # ethtool -k enp1s0
    ...
    esp-hw-offload: off
    ntuple-filters: on
    ...
  2. 오프로드 기능을 변경하기 전에 발생한 문제가 여전히 존재하는지 테스트합니다.

    • 특정 오프로드 기능을 변경한 후 문제가 더 이상 존재하지 않는 경우:

      1. Red Hat 지원에 문의하여 문제를 보고합니다.
      2. 수정 사항이 제공될 때까지 오프로드 기능을 영구적으로 설정하는 것이 좋습니다.
    • 특정 오프로드 기능을 비활성화한 후에도 문제가 계속 발생하는 경우:

      1. ethtool -K < interface > < feature > [on|off] 명령을 사용하여 설정을 이전 상태로 재설정합니다.
      2. 다른 오프로드 기능을 활성화하거나 비활성화하여 문제를 좁힐 수 있습니다.

추가 리소스

  • ethtool(8) 도움말 페이지

31.11.2. 영구적으로 오프로드 기능 설정

호스트의 성능을 제한하는 특정 오프로드 기능을 확인한 경우 현재 상태에 따라 호스트의 성능을 영구적으로 활성화하거나 비활성화할 수 있습니다.

오프로드 기능을 영구적으로 활성화하거나 비활성화하는 경우 NetworkManager는 재부팅 후에도 기능에 여전히 이 상태가 있는지 확인합니다.

사전 요구 사항

  • 특정 오프로드 기능을 확인하여 호스트의 성능을 제한합니다.

절차

  1. 오프로드 기능의 상태를 변경할 네트워크 인터페이스를 사용하는 연결 프로필을 식별합니다.

    # nmcli connection show
    NAME     UUID                                  TYPE      DEVICE
    Example  a5eb6490-cc20-3668-81f8-0314a27f3f75  ethernet  enp1ss0
    ...
  2. 오프로드 기능 상태를 영구적으로 변경합니다.

    # nmcli connection modify <connection_name> <feature> [on|off]
    • 예를 들어 Example 연결 프로필에서 IPsec ESP(Security Payload) 오프로드를 영구적으로 비활성화하려면 다음을 입력합니다.

      # nmcli connection modify Example ethtool.feature-esp-hw-offload off
    • 예를 들어 예제 연결 프로필에서 빠른 수신 흐름 hpering (aRFS) 필터링을 영구적으로 활성화하려면 다음을 입력합니다.

      # nmcli connection modify Example ethtool.feature-ntuple on
  3. 연결 프로필을 다시 활성화합니다.

    # nmcli connection up Example

검증

  • 오프로드 기능의 출력 상태를 표시합니다.

    # ethtool -k enp1s0
    ...
    esp-hw-offload: off
    ntuple-filters: on
    ...

추가 리소스

  • nm-settings-nmcli(5) 도움말 페이지

31.12. 인터럽트 병합 설정 튜닝

인터럽트 병합은 네트워크 카드로 생성되는 인터럽트 수를 줄이기 위한 메커니즘입니다. 일반적으로 인터럽트가 줄어들면 네트워크의 대기 시간과 전체 성능이 향상될 수 있습니다.

인터럽트 병합 설정을 튜닝하려면 다음을 제어하는 매개변수를 조정해야 합니다.

  • 단일 인터럽트로 결합된 패킷 수입니다.
  • 인터럽트를 생성하기 전에 지연입니다.
중요

최적의 병합 설정은 사용 중인 특정 네트워크 조건 및 하드웨어에 따라 다릅니다. 따라서 환경 및 요구 사항에 가장 적합한 설정을 찾으려면 몇 가지 시도가 필요할 수 있습니다.

31.12.1. 대기 시간 또는 처리량에 민감한 서비스에 대해 RHEL 최적화

병합 튜닝의 목표는 지정된 워크로드에 필요한 인터럽트 수를 최소화하는 것입니다. 처리량이 높은 상황에서 목표는 높은 데이터 속도를 유지하면서 최대한 적은 인터럽트를 보유하는 것입니다. 대기 시간이 짧은 경우 더 많은 인터럽트를 사용하여 트래픽을 빠르게 처리할 수 있습니다.

네트워크 카드의 설정을 조정하여 단일 인터럽트로 결합된 패킷 수를 늘리거나 줄일 수 있습니다. 결과적으로 트래픽에 대한 처리량 또는 대기 시간을 개선할 수 있습니다.

절차

  1. 병목 현상이 발생하는 네트워크 인터페이스를 식별합니다.

    # ethtool -S enp1s0
    NIC statistics:
         rx_packets: 1234
         tx_packets: 5678
         rx_bytes: 12345678
         tx_bytes: 87654321
         rx_errors: 0
         tx_errors: 0
         rx_missed: 0
         tx_dropped: 0
         coalesced_pkts: 0
         coalesced_events: 0
         coalesced_aborts: 0

    이름에 "drop", "discard" 또는 "error"가 포함된 패킷 카운터를 식별합니다. 이러한 특정 통계는 NIC 병합으로 인해 발생할 수 있는 NIC(네트워크 인터페이스 카드) 패킷 버퍼의 실제 패킷 손실을 측정합니다.

  2. 이전 단계에서 식별한 패킷 카운터의 값을 모니터링합니다.

    네트워크를 네트워크의 예상 값과 비교하여 특정 인터페이스에 병목 현상이 발생하는지 확인합니다. 네트워크 병목 현상의 일반적인 신호에는 다음이 포함되지만 이에 국한되지는 않습니다.

    • 네트워크 인터페이스에서 많은 오류
    • 높은 패킷 손실
    • 네트워크 인터페이스를 많이 사용

      참고

      다른 중요한 요인은 네트워크 병목 현상을 식별할 때 CPU 사용량, 메모리 사용량, 디스크 I/O와 같은 요인입니다.

  3. 현재 coalescence 설정을 확인합니다.

    # ethtool enp1s0
    Settings for enp1s0:
            Supported ports: [ TP ]
            Supported link modes:   10baseT/Half 10baseT/Full
                                    100baseT/Half 100baseT/Full
                                    1000baseT/Full
            Supported pause frame use: No
            Supports auto-negotiation: Yes
            Advertised link modes:  10baseT/Half 10baseT/Full
                                    100baseT/Half 100baseT/Full
                                    1000baseT/Full
            Advertised pause frame use: No
            Advertised auto-negotiation: Yes
            Speed: 1000Mb/s
            Duplex: Full
            Port: Twisted Pair
            PHYAD: 0
            Transceiver: internal
            Auto-negotiation: on
            MDI-X: Unknown
            Supports Wake-on: g
            Wake-on: g
            Current message level: 0x00000033 (51)
                                   drv probe link
            Link detected: yes

    이 출력에서 speed 및 Duplex 필드를 모니터링합니다. 이러한 필드에는 네트워크 인터페이스 작업과 예상되는 값으로 실행 중인지에 대한 정보가 표시됩니다.

  4. 현재 인터럽트 병합 설정을 확인합니다.

    # ethtool -c enp1s0
    Coalesce parameters for enp1s0:
            Adaptive RX: off
            Adaptive TX: off
            RX usecs: 100
            RX frames: 8
            RX usecs irq: 100
            RX frames irq: 8
            TX usecs: 100
            TX frames: 8
            TX usecs irq: 100
            TX frames irq: 8
    • usecs 값은 인터럽트를 생성하기 전에 수신자 또는 송신기가 대기하는 마이크로초 수를 나타냅니다.
    • 프레임 값은 인터럽트를 생성하기 전에 수신기 또는 송신기가 대기하는 프레임 수를 나타냅니다.
    • irq 값은 네트워크 인터페이스가 이미 인터럽트를 처리하는 경우 인터럽트를 구성하는 데 사용됩니다.

      참고

      일부 네트워크 인터페이스 카드가 예제 출력에서 모든 값을 보고하고 변경하는 것은 아닙니다.

    • Adaptive RX/TX 값은 인터럽트 병합 설정을 동적으로 조정하는 조정 인터럽트 결합 메커니즘을 나타냅니다. 패킷 조건에 따라 NIC 드라이버는 Adaptive RX/TX 가 활성화될 때 값을 자동으로 계산합니다(단, NIC 드라이버마다 알고리즘이 다릅니다).
  5. 필요에 따라 병합 설정을 수정합니다. 예를 들어 다음과 같습니다.

    • ethtool.coalesce-adaptive-rx 가 비활성화되어 있지만 RX 패킷의 인터럽트를 100마이크로초로 생성하기 전에 ethtool.coalesce-rx-usecs 를 구성하여 지연을 설정합니다.

      # nmcli connection modify enp1s0 ethtool.coalesce-rx-usecs 100
    • ethtool.coalesce-adaptive-rx 를 활성화하면 ethtool.coalesce-rx-usecs 가 기본값으로 설정됩니다.

      # nmcli connection modify enp1s0 ethtool.coalesce-adaptive-rx on

      Red Hat은 Adaptive-RX 설정을 다음과 같이 수정할 것을 권장합니다.

      • 낮은 대기 시간 (sub-50us)에 관련된 사용자는 Adaptive-RX 를 활성화해서는 안 됩니다.
      • 처리량에 관련된 사용자는 잠재적으로 Adaptive-RX 를 손상 없이 활성화할 수 있습니다. 사용자가 조정 인터럽트 병합 메커니즘을 사용하지 않으려면 100us와 같은 큰 값을 사용하거나 250us를 ethtool.coalesce-rx-usecs 로 설정할 수 있습니다.
      • 요구 사항에 대해 확실하지 않은 사용자는 문제가 발생할 때까지 이 설정을 수정하지 않아야 합니다.
  6. 연결을 다시 활성화합니다.

    # nmcli connection up enp1s0

검증 단계

  • 네트워크 성능을 모니터링하고 삭제된 패킷을 확인합니다.

    # ethtool -S enp1s0
    NIC statistics:
         rx_packets: 1234
         tx_packets: 5678
         rx_bytes: 12345678
         tx_bytes: 87654321
         rx_errors: 0
         tx_errors: 0
         rx_missed: 0
         tx_dropped: 0
         coalesced_pkts: 12
         coalesced_events: 34
         coalesced_aborts: 56
    ...

    rx_errors,rx_dropped,tx_errors, tx_dropped 필드의 값은 0이거나 (네트워크 트래픽 및 시스템 리소스에 따라 최대 수백 개까지) 있어야 합니다. 이 필드의 높은 값은 네트워크 문제를 나타냅니다. 카운터의 이름이 다를 수 있습니다. 이름에 "drop", "discard" 또는 "error"가 포함된 패킷 카운터를 면밀히 모니터링합니다.

    rx_packets,tx_packets,rx_bytestx_bytes 의 값은 시간이 지남에 따라 증가해야 합니다. 값이 증가하지 않으면 네트워크 문제가 발생할 수 있습니다. 패킷 카운터는 NIC 드라이버에 따라 이름이 다를 수 있습니다.

    중요

    사용 중인 NIC 및 드라이버에 따라 ethtool 명령 출력이 다를 수 있습니다.

    대기 시간이 매우 짧은 사용자는 모니터링 목적으로 애플리케이션 수준 메트릭 또는 커널 패킷 시간 스탬프 API를 사용할 수 있습니다.

31.13. TCP 타임스탬프의 이점

TCP Timestamps는 TCP 헤더와 TCP 프로토콜 확장에서 선택적 정보입니다. 기본적으로 TCP Timestamps는 Red Hat Enterprise Linux에서 활성화되며 커널은 TCP Timestamps를 사용하여 TCP 연결에서 RT(Round Trip Time)를 더 잘 추정합니다. 이렇게 하면 더 정확한 TCP 창 및 버퍼 계산이 생성됩니다.

또한 TCP Timestamps는 세그먼트의 수명과 순서를 결정하고 래핑된 시퀀스 번호로부터 보호하는 대체 방법을 제공합니다. TCP 패킷 헤더는 32비트 필드에서 시퀀스 번호를 기록합니다. 10Gbps 연결에서 이 필드의 값은 1.7초 후에 래핑할 수 있습니다. TCP 타임스탬프가 없으면 수신자는 래핑된 시퀀스 번호가 있는 세그먼트가 새 세그먼트인지 이전 복제인지 여부를 확인할 수 없었습니다. 그러나 TCP Timestamps를 사용하면 수신자가 세그먼트를 수신하거나 삭제하도록 올바른 선택을 할 수 있습니다. 따라서 빠른 네트워크 인터페이스가 있는 시스템에서 TCP Timestamps를 활성화하는 것이 중요합니다.

net.ipv4.tcp_timestamps 커널 매개변수는 다음 값 중 하나를 가질 수 있습니다.

  • 0: TCP 타임 스탬프가 비활성화되어 있습니다.
  • 1: TCP 타임스탬프가 활성화되어 있습니다(기본값).
  • 2: TCP 타임 스탬프는 사용할 수 있지만 임의의 오프셋은 없습니다.

    중요

    각 연결에 대해 임의의 오프셋이 없으면 대략 호스트의 가동 시간 및 지문을 확인하고 이러한 정보를 공격에 사용할 수 있습니다.

기본적으로 TCP Timestamps는 Red Hat Enterprise Linux에서 활성화되며 현재 시간만 저장하는 대신 각 연결에 임의의 오프셋을 사용합니다.

# sysctl net.ipv4.tcp_timestamps
net.ipv4.tcp_timestamps = 1

net.ipv4.tcp_timestamps 매개변수에 기본값(1)과 다른 값이 있는 경우 설정한 것과 동일한 방식으로 설정을 되돌립니다.

31.14. 이더넷 네트워크의 흐름 제어

이더넷 링크에서 네트워크 인터페이스와 스위치 포트 간 연속 데이터 전송은 전체 버퍼 용량을 유발할 수 있습니다. 전체 버퍼 용량은 네트워크 혼잡을 초래합니다. 이 경우, 발신자가 수신기의 처리 용량보다 높은 속도로 데이터를 전송할 때, 스위치 포트인 링크의 다른 쪽 끝에 있는 네트워크 인터페이스의 낮은 데이터 처리 용량으로 인해 패킷 손실이 발생할 수 있습니다.

흐름 제어 메커니즘은 각 발신자와 수신자가 서로 다른 이더넷 링크의 데이터 전송을 관리하고 이를 수신합니다. 패킷 손실을 방지하기 위해 이더넷 흐름 제어 메커니즘은 패킷 전송을 일시적으로 일시 중단하여 스위치 포트에서 더 높은 전송 속도를 관리합니다. 라우터는 일시 정지 프레임을 스위치 포트 이상으로 전달하지 않습니다.

수신(RX) 버퍼가 가득 차면 수신자는 일시 정지 프레임을 송신기로 보냅니다. 그런 다음 송신기는 짧은 하위 초 기간 동안 데이터 전송을 중지하고 이 일시 중지 기간 동안 들어오는 데이터를 버퍼 수신을 계속합니다. 이 기간은 수신자가 인터페이스 버퍼를 비우고 버퍼 오버플로를 방지할 수 있는 충분한 시간을 제공합니다.

참고

이더넷 링크의 양쪽 끝은 다른 쪽 끝에 정지 프레임을 보낼 수 있습니다. 네트워크 인터페이스의 수신 버퍼가 가득 차면 네트워크 인터페이스는 일시 정지 프레임을 스위치 포트로 보냅니다. 마찬가지로 스위치 포트의 수신 버퍼가 가득 차면 스위치 포트는 일시 정지 프레임을 네트워크 인터페이스로 보냅니다.

기본적으로 Red Hat Enterprise Linux의 대부분의 네트워크 드라이버에는 일시 정지 프레임 지원이 활성화됩니다. 네트워크 인터페이스의 현재 설정을 표시하려면 다음을 입력합니다.

# ethtool --show-pause enp1s0
Pause parameters for enp1s0:
...
RX:     on
TX:     on
...

전환 벤더에 대해 확인하여 스위치가 일시 정지 프레임을 지원하는지 확인합니다.

32장. I/O 및 파일 시스템 성능에 영향을 미치는 요소

스토리지 및 파일 시스템 성능에 적합한 설정은 스토리지 목적에 따라 크게 달라집니다.

I/O 및 파일 시스템 성능은 다음 요인의 영향을 받을 수 있습니다.

  • 데이터 쓰기 또는 읽기 패턴
  • 순차 또는 임의의
  • 버퍼링 또는 직접 IO
  • 데이터 기본 기하 도형과 정렬
  • 블록 크기
  • 파일 시스템 크기
  • 저널 크기 및 위치
  • 액세스 시간 기록
  • 데이터 신뢰성 보장
  • 데이터 가져오기 전
  • 디스크 공간 사전 할당
  • 파일 조각화
  • 리소스 경합

32.1. I/O 및 파일 시스템 문제를 모니터링 및 진단하기 위한 툴

Red Hat Enterprise Linux 9에서 시스템 성능을 모니터링하고 I/O, 파일 시스템 및 해당 구성과 관련된 성능 문제를 진단하는 데 사용할 수 있는 툴은 다음과 같습니다.

  • vmstat 툴은 전체 시스템의 프로세스, 메모리, 페이징, 블록 I/O, 인터럽트, CPU 활동에 대해 보고합니다. 관리자는 I/O 하위 시스템이 성능 문제를 담당하는지 여부를 결정하는 데 도움이 될 수 있습니다. vmstat 를 사용한 분석을 통해 I/O 하위 시스템이 성능 감소를 담당하는 것으로 표시되면 관리자는 iostat 툴을 사용하여 관련 I/O 장치를 결정할 수 있습니다.
  • iostat 는 시스템의 I/O 장치 로드에 대해 보고합니다. NetNamespace 패키지에서 제공합니다.
  • blktrace 는 I/O 하위 시스템에서 시간을 소비하는 방법에 대한 자세한 정보를 제공합니다. companion 유틸리티 blkparseblktrace 에서 원시 출력을 읽고 blktrace 에서 기록한 입력 및 출력 작업에 대한 사람이 읽을 수 있는 요약을 생성합니다.
  • BTT blktrace 출력을 분석하고 데이터가 I/O 스택의 각 영역에 보내는 시간을 표시하므로 I/O 하위 시스템에서 병목 현상을 쉽게 찾을 수 있습니다. 이 유틸리티는 blktrace 패키지의 일부로 제공됩니다. blktrace 메커니즘에서 추적하고 btt 에서 분석한 중요한 이벤트 중 일부는 다음과 같습니다.

    • I/O 이벤트 대기열(Q)
    • I/O를 드라이버 이벤트 (D)로 디스패치
    • I/O 이벤트 완료 (C)
  • iowatcher 는 시간 경과에 따른 그래프 I/O에 blktrace 출력을 사용할 수 있습니다. 디스크 I/O의 논리 블록 주소(LBA), 초당 메가바이트당 처리량, 초당 검색 수 및 초당 I/O 작업 수에 중점을 둡니다. 이렇게 하면 장치의 1초 단위 제한에 도달할 때를 식별하는 데 도움이 될 수 있습니다.
  • BCC(BPF Compiler Collection)는eBPF(extended Berkeley Packet Filter) 프로그램을 쉽게 생성할 수 있는 라이브러리입니다. eBPF 프로그램은 디스크 I/O, TCP 연결 및 프로세스 생성과 같은 이벤트에서 트리거됩니다. BCC 툴은 /usr/share/bcc/tools/ 디렉터리에 설치됩니다. 다음 bcc-tools 는 성능을 분석하는 데 도움이 됩니다.

    • interactivelatency 는 히스토그램의 블록 장치 I/O(디스크 I/O)의 대기 시간을 요약합니다. 이를 통해 장치 캐시 히트 및 캐시 누락에 대한 두 가지 모드를 포함하여 배포를 연구할 수 있으며 대기 시간이 초과됩니다.
    • biosnoop 는 발행 프로세스 ID 및 I/O 대기 시간과 함께 각 I/O 이벤트를 표시하는 기본 블록 I/O 추적 툴입니다. 이 도구를 사용하면 디스크 I/O 성능 문제를 조사할 수 있습니다.
    • biotop 는 커널의 블록 i/o 작업에 사용됩니다.
    • 파일life 툴은 stat() syscall을 추적합니다.
    • 더 낮은 파일 추적 속도가 동기 파일 읽기 및 쓰기 속도가 느립니다.
    • Filetop 는 프로세스별로 파일 읽기 및 쓰기를 표시합니다.
    • ext4slower,nfs slower 는 특정 임계값보다 느린 파일 시스템 작업을 표시하는 툴이며 기본값은 10ms 입니다.

      자세한 내용은 Analyzing system performance with BPF Compiler Collection 을 참조하십시오.

  • bpftace 는 성능 문제를 분석하는 데 사용되는 eBPF 의 추적 언어입니다. 또한 시스템 관찰에 대해 BCC와 같은 추적 유틸리티를 제공합니다. 이 유틸리티는 I/O 성능 문제를 조사하는 데 유용합니다.
  • 다음 SystemTap 스크립트는 스토리지 또는 파일 시스템 성능 문제를 진단하는 데 유용할 수 있습니다.

    • disktop.stp: 5초마다 디스크를 읽거나 쓰는 상태를 확인하고 해당 기간 동안 상위 10개 항목을 출력합니다.
    • iotime.stp: 읽기 및 쓰기 작업에 소요된 시간과 읽기 및 쓰기 바이트 수를 출력합니다.
    • traceio.stp: 관찰된 누적 I/O 트래픽에 따라 상위 10개의 실행 파일을 1초마다 인쇄합니다.
    • traceio2.stp: 지정된 장치에 대한 읽기 및 쓰기가 발생할 때 실행 가능 이름 및 프로세스 식별자를 인쇄합니다.
    • Inodewatch.stp: 지정된 메이저 또는 마이너 장치의 지정된 inode에 읽기 또는 쓰기가 발생할 때마다 실행 가능한 이름 및 프로세스 식별자를 출력합니다.
    • inodewatch2.stp: 지정된 메이저 또는 마이너 장치의 지정된 inode에서 속성이 변경될 때마다 실행 가능한 이름, 프로세스 식별자 및 속성을 인쇄합니다.

추가 리소스

32.2. 파일 시스템 포맷에 사용 가능한 튜닝 옵션

장치를 포맷한 후에는 일부 파일 시스템 구성 결정을 변경할 수 없습니다.

다음은 스토리지 장치를 포맷하기 전에 사용할 수 있는 옵션입니다.

크기
워크로드에 맞게 적절하게 크기 조정된 파일 시스템을 생성합니다. 크기가 작은 파일 시스템은 파일 시스템 점검을 위해 시간과 메모리를 더 적게 필요로 합니다. 그러나 파일 시스템이 너무 작으면 성능이 높은 조각화로 인해 발생합니다.
블록 크기

블록은 파일 시스템의 작업 단위입니다. 블록 크기는 단일 블록에 저장할 수 있는 데이터의 양을 결정하므로 한 번에 쓰거나 읽는 최소 데이터 양을 결정합니다.

기본 블록 크기는 대부분의 사용 사례에 적합합니다. 그러나 파일 시스템은 블록 크기 또는 여러 블록의 크기가 일반적으로 한 번에 읽거나 쓰는 데이터의 양과 동일하거나 약간 큰 경우 데이터를 더 효율적으로 수행하고 저장합니다. 작은 파일은 여전히 전체 블록을 사용합니다. 파일을 여러 블록에 분산할 수 있지만 이로 인해 추가 런타임 오버헤드가 발생할 수 있습니다.

또한 일부 파일 시스템은 특정 블록 수로 제한되며, 이로 인해 파일 시스템의 최대 크기가 제한됩니다. 블록 크기는 mkfs 명령으로 장치를 포맷할 때 파일 시스템 옵션의 일부로 지정됩니다. 블록 크기를 지정하는 매개변수는 파일 시스템에 따라 다릅니다.

기하메트리

파일 시스템의 Geometry는 파일 시스템 전체에서 데이터의 분산과 관련이 있습니다. 시스템에서 RAID와 같이 스트라이핑된 스토리지를 사용하는 경우 장치를 포맷할 때 데이터와 메타데이터를 기본 스토리지 기하메리와 정렬하여 성능을 향상시킬 수 있습니다.

많은 장치는 장치가 특정 파일 시스템으로 포맷될 때 자동으로 설정되는 권장 geometry를 내보냅니다. 장치가 이러한 권장 사항을 내보내지 않거나 권장 설정을 변경하려면 mkfs 명령을 사용하여 장치를 포맷할 때 geometry를 수동으로 지정해야 합니다.

파일 시스템을 지정하는 매개 변수는 파일 시스템에 따라 다릅니다.

외부 저널
저널링 파일 시스템은 작업이 실행되기 전에 저널 파일에서 쓰기 작업 중에 수행할 변경 사항을 문서화합니다. 이렇게 하면 시스템 충돌 또는 정전 시 스토리지 장치가 손상될 가능성이 줄어들고 복구 프로세스가 빨라집니다.
참고

Red Hat은 외부 저널 옵션을 사용하지 않는 것이 좋습니다.

메타데이터 사용량이 많은 워크로드에는 저널에 대한 매우 빈번한 업데이트가 포함됩니다. 더 큰 저널은 메모리를 더 사용하지만 쓰기 작업 빈도를 줄입니다. 또한 기본 스토리지보다 빠르고 빠른 전용 스토리지에 저널을 배치하여 메타데이터 집약적인 워크로드로 장치의 검색 시간을 개선할 수 있습니다.

주의

외부 저널이 신뢰할 수 있는지 확인합니다. 외부 저널 장치를 손실하면 파일 시스템이 손상됩니다. 외부 저널은 형식으로 생성해야 하며 마운트 시 저널 장치를 지정해야 합니다.

추가 리소스

32.3. 파일 시스템 마운트에 사용 가능한 튜닝 옵션

다음은 대부분의 파일 시스템에서 사용 가능한 옵션입니다. 장치가 마운트될 때 지정할 수 있습니다.

액세스 시간

파일을 읽을 때마다 해당 메타데이터는 액세스가 발생한 시점(시간)으로 업데이트됩니다. 여기에는 추가 쓰기 I/O가 포함됩니다. relatime 은 대부분의 파일 시스템에 대한 기본 atime 설정입니다.

그러나 이 메타데이터를 업데이트하는 데 시간이 소요되며 정확한 액세스 시간 데이터가 필요하지 않은 경우 noatime 마운트 옵션으로 파일 시스템을 마운트할 수 있습니다. 이 명령은 파일을 읽을 때 메타데이터 업데이트를 비활성화합니다. 또한 디렉터리를 읽을 때 메타데이터 업데이트를 비활성화하는 nodiratime 동작을 활성화합니다.

참고

no atime 마운트 옵션을 사용하여 일정 시간 업데이트를 비활성화하면 백업 프로그램(예: 백업 프로그램)에 의존하는 애플리케이션이 중단될 수 있습니다.

read-ahead

미리 필요한 데이터를 미리 가져와서 페이지 캐시에 로드할 수 있는 파일 액세스 권한의 속도가 빨라지므로 디스크에 있는 것보다 더 빠르게 검색할 수 있습니다. read-ahead 값이 클수록 시스템이 데이터를 미리 가져옵니다.

Red Hat Enterprise Linux는 파일 시스템에 대해 감지한 내용에 따라 적절한 읽기-부트 값을 설정하려고 합니다. 그러나 정확한 탐지가 항상 가능한 것은 아닙니다. 예를 들어 스토리지 배열이 시스템에 단일 LUN으로 자신을 표시하는 경우 시스템은 단일 LUN을 감지하고 배열에 대한 적절한 읽기-마이마 값을 설정하지 않습니다.

순차적 I/O 스트리밍이 많은 워크로드에서는 종종 읽기/출력의 높은 읽기 값의 이점을 얻을 수 있습니다. Red Hat Enterprise Linux와 함께 제공되는 스토리지 관련 tuned 프로필은 LVM 스트라이핑을 사용하는 것처럼 미리 읽기 값을 높일 수 있지만 이러한 조정이 모든 워크로드에 대해 항상 충분하지는 않습니다.

추가 리소스

  • mount(8), xfs(5)ext4(5) 매뉴얼 페이지

32.4. 사용되지 않는 블록 삭제 유형

파일 시스템에서 사용하지 않는 블록을 정기적으로 삭제하는 것은 솔리드 스테이트 디스크와 씬 프로비저닝된 스토리지에 권장되는 방법입니다.

다음은 사용되지 않는 블록을 삭제하는 두 가지 방법입니다.

배치 삭제
이러한 유형의 삭제는 fstrim 명령의 일부입니다. 관리자가 지정한 조건과 일치하는 파일 시스템에서 사용되지 않은 모든 블록을 삭제합니다. Red Hat Enterprise Linux 9는 물리적 삭제 작업을 지원하는 XFS 및 ext4 형식의 장치에서 배치 삭제 기능을 지원합니다.
온라인 삭제

이 유형의 삭제 작업은 discard 옵션을 사용하여 마운트 시 구성되며 사용자 개입 없이 실시간으로 실행됩니다. 그러나 에서 무료로 전환되는 블록만 삭제합니다. Red Hat Enterprise Linux 9는 XFS 및 ext4 형식의 장치에서 온라인 삭제 기능을 지원합니다.

Red Hat은 성능을 유지하기 위해 온라인 삭제가 필요한 경우 또는 배치 삭제가 시스템 워크로드에 적합하지 않은 경우를 제외하고 배치 삭제를 권장합니다.

사전 할당은 해당 공간에 데이터를 쓰지 않고 파일에 디스크 공간이 할당되어 있음을 나타냅니다. 이는 데이터 조각화 및 읽기 성능이 저하되는 데 유용할 수 있습니다. Red Hat Enterprise Linux 9는 XFS, ext4 및 GFS2 파일 시스템의 사전 할당 공간을 지원합니다. 애플리케이션은 fallocate(2) glibc 호출을 사용하여 공간을 미리 배치하면 이점을 얻을 수 있습니다.

추가 리소스

  • mount(8)fallocate(2) 매뉴얼 페이지

32.5. 솔리드 스테이트 디스크 튜닝 고려 사항

SSD(솔리드 스테이트 디스크)는 영구 데이터를 저장하기 위해 회전하는 마운드 플래터 대신 NAND Flash chip을 사용합니다. SSD는 전체 논리 블록 주소 범위에서 데이터에 대한 일정한 액세스 시간을 제공하며 회전하는 상대와 같은 비용을 측정할 수 없습니다. 1GB의 스토리지 공간당 비용이 많이 들고 스토리지 밀도가 줄어들지만, memory보다 대기 시간이 단축되고 처리량이 향상됩니다.

SSD에서 사용된 블록이 디스크의 용량에 접근하므로 일반적으로 성능이 저하됩니다. 성능 저하 수준은 벤더에 따라 달라지지만 모든 장치는 이러한 성능 저하를 경험할 수 있습니다. 삭제 동작을 활성화하면 이러한 성능 저하를 완화하는 데 도움이 될 수 있습니다. 자세한 내용은 사용되지 않는 블록 삭제 유형을 참조하십시오.

기본 I/O 스케줄러 및 가상 메모리 옵션은 SSD와 함께 사용하기에 적합합니다. SSD 성능에 영향을 줄 수 있는 설정을 구성할 때 다음 요소를 고려하십시오.

I/O 스케줄러

모든 I/O 스케줄러는 대부분의 SSD에서 제대로 작동할 것으로 예상됩니다. 그러나 다른 스토리지 유형과 마찬가지로 Red Hat은 지정된 워크로드에 대한 최적의 구성을 확인하기 위해 벤치마킹을 권장합니다. SSD를 사용하는 경우 Red Hat은 특정 워크로드 벤치마킹을 위해서만 I/O 스케줄러 변경을 권장합니다. I/O 스케줄러 간에 전환하는 방법에 대한 지침은 /usr/share/doc/kernel-version/Documentation/block/sched.txt 파일을 참조하십시오.

단일 대기열 HBA의 경우 기본 I/O 스케줄러는 데드라인 입니다. 다중 대기열 HBA의 경우 기본 I/O 스케줄러는 none 입니다. I/O 스케줄러를 설정하는 방법에 대한 자세한 내용은 디스크 스케줄러 설정을 참조하십시오.

가상 메모리
I/O 스케줄러와 마찬가지로 VM(가상 메모리) 하위 시스템에는 특별한 튜닝이 필요하지 않습니다. SSD의 I/O의 빠른 특성을 고려할 때 vm_dirty_backfield_ratiovm_dirty_ratio 설정을 끄면 일반적으로 디스크의 다른 작업 대기 시간에 부정적인 영향을 미치지 않습니다. 그러나 이러한 튜닝은 전체 I/O를 더 많이 생성할 수 있으므로 일반적으로 워크로드별 테스트 없이 권장되지 않습니다.
swap
SSD도 스왑 장치로 사용할 수 있으며 좋은 페이지 아웃 및 페이지인 성능을 생성할 수 있습니다.

32.6. 일반 블록 장치 튜닝 매개변수

여기에 나열된 일반 튜닝 매개변수는 /sys/block/sdX/queue/ 디렉터리에서 사용할 수 있습니다.

다음 나열된 튜닝 매개변수는 I/O 스케줄러 튜닝과 다르며 모든 I/O 스케줄러에 적용할 수 있습니다.

add_random
일부 I/O 이벤트는 /dev/random 의 엔트로피 풀에 기여합니다. 이러한 기여의 오버헤드가 측정 가능한 경우 이 매개변수를 0 으로 설정할 수 있습니다.
iostats

기본적으로 iostats 는 활성화되어 있으며 기본값은 1 입니다. iostats 값을 0 으로 설정하면 장치에 대한 I/O 통계 수집이 비활성화되어 I/O 경로에 적은 오버헤드가 제거됩니다. iostats0 으로 설정하면 특정 NVMe 솔리드 스테이트 스토리지 장치와 같은 매우 고성능 장치의 성능이 약간 향상될 수 있습니다. 벤더가 지정된 스토리지 모델에 달리 지정하지 않는 한 iostats 를 활성화 상태로 두는 것이 좋습니다.

iostats 를 비활성화하면 장치에 대한 I/O 통계가 더 이상 /proc/diskstats 파일에 존재하지 않습니다. /sys/diskstats 파일의 내용은 sar 또는 iostats 와 같은 I/O 툴 모니터링을 위한 I/O 정보의 소스입니다. 따라서 장치에 대한 iostats 매개변수를 비활성화하면 장치가 더 이상 I/O 모니터링 툴 출력에 표시되지 않습니다.

max_sectors_kb

I/O 요청의 최대 크기를 킬로바이트로 지정합니다. 기본값은 512 KB입니다. 이 매개 변수의 최소 값은 스토리지 장치의 논리 블록 크기에 따라 결정됩니다. 이 매개변수의 최대값은 max_hw_sectors_kb 의 값으로 결정됩니다.

Red Hat은 max_sectors_kb 가 항상 최적의 I/O 크기의 여러 개이며 내부 클리어 블록 크기가 클 것을 권장합니다. 스토리지 장치에 의해 0이거나 지정되지 않은 경우 매개 변수에 logical_block_size 값을 사용합니다.

nomerges
대부분의 워크로드는 요청 병합을 통해 이점을 얻을 수 있습니다. 그러나 병합을 비활성화하면 디버깅에 유용할 수 있습니다. 기본적으로 nomerges 매개변수는 0 으로 설정되어 병합이 가능합니다. 간단한 일회성 병합을 비활성화하려면 nomerges1 로 설정합니다. 모든 유형의 병합을 비활성화하려면 nomerges2 로 설정합니다.
nr_requests
대기 중인 I/O의 허용된 최대 수입니다. 현재 I/O 스케줄러가 none 이면 이 수를 줄일 수 있습니다. 그렇지 않으면 수를 늘리거나 줄일 수 있습니다.
optimal_io_size
일부 스토리지 장치는 이 매개변수를 통해 최적의 I/O 크기를 보고합니다. 이 값이 보고되면 Red Hat은 가능한 경우 최적의 I/O 크기와 일치하는 I/O와 관련된 I/O를 실행하는 것이 좋습니다.
read_ahead_kb

연속 읽기 작업 중에 운영 체제가 미리 읽을 수 있는 최대 킬로바이트 수를 정의합니다. 결과적으로 다음 순차 읽기의 커널 페이지 캐시에 필요한 정보가 이미 있으므로 읽기 I/O 성능이 향상됩니다.

장치 매퍼는 종종 상위 read_ahead_kb 값의 이점을 얻습니다. 각 장치를 매핑할 수 있는 128 KB는 좋은 시작점이지만, 디스크의 queue의 max_sectors_kb 값을 요청하도록 read_ahead_kb 값을 늘리면 대용량 파일을 순차적으로 읽을 수 있는 애플리케이션 환경에서 성능이 향상될 수 있습니다.

rotational
일부 솔리드 스테이트 디스크는 솔리드 스테이트 상태를 올바르게 공개하지 않으며 기존 교체 디스크로 마운트됩니다. 스케줄러에서 불필요한 검색 논리를 비활성화하려면 rotation 값을 0 으로 수동으로 설정합니다.
rq_affinity
rq_affinity 의 기본값은 1 입니다. 실행된 CPU 코어의 동일한 CPU 그룹에 있는 하나의 CPU 코어에서 I/O 작업을 완료합니다. I/O 요청을 발급한 프로세서에서만 완료를 수행하려면 rq_affinity2 로 설정합니다. 언급된 두 가지 능력을 비활성화하려면 0 으로 설정하십시오.
scheduler
특정 스토리지 장치에 대한 스케줄러 또는 스케줄러 기본 순서를 설정하려면 /sys/block/devname/queue/scheduler 파일을 편집합니다. 여기서 devname 은 구성하려는 장치의 이름입니다.

33장. systemd를 사용하여 애플리케이션에서 사용하는 리소스 관리

RHEL 9에서는 cgroup 계층 구조의 시스템을 systemd 단위 트리에 바인딩하여 리소스 관리 설정을 프로세스 수준에서 애플리케이션 수준으로 이동합니다. 따라서 systemctl 명령을 사용하거나 systemd 장치 파일을 수정하여 시스템 리소스를 관리할 수 있습니다.

이를 위해 systemd 는 단위 파일에서 또는 systemctl 명령을 통해 직접 다양한 구성 옵션을 사용합니다. 그런 다음 systemdcgroup네임스페이스 와 같은 Linux 커널 시스템 호출 및 기능을 사용하여 해당 옵션을 특정 프로세스 그룹에 적용합니다.

참고

다음 도움말 페이지에서 systemd 에 대한 전체 설정 옵션 세트를 검토할 수 있습니다.

  • systemd.resource-control(5)
  • systemd.exec(5)

33.1. 리소스 관리에서 systemd의 역할

systemd 의 핵심 기능은 서비스 관리 및 감독입니다. systemd 시스템 및 서비스 관리자:

  • 부팅 프로세스 중에 관리 서비스가 적시에 올바른 순서로 시작되는지 확인합니다.
  • 관리 서비스가 원활하게 실행되도록 기본 하드웨어 플랫폼을 최적으로 사용할 수 있습니다.
  • 리소스 관리 정책을 정의하는 기능을 제공합니다.
  • 서비스 성능을 향상시킬 수 있는 다양한 옵션을 조정하는 기능을 제공합니다.
중요

일반적으로 Red Hat은 systemd 를 사용하여 시스템 리소스 사용을 제어하는 것이 좋습니다. 특수한 경우에만 cgroup 가상 파일 시스템을 수동으로 구성해야 합니다. 예를 들어 cgroup-v2 계층 구조에는 동일하지 않은 cgroup-v1 컨트롤러를 사용해야 합니다.

33.2. 시스템 소스의 배포 모델

시스템 리소스의 배포를 수정하려면 다음 배포 모델 중 하나 이상을 적용할 수 있습니다.

weights

모든 하위 그룹의 가중치를 추가하고 각 하위 그룹에 합계와 일치하는 분수를 지정하여 리소스를 배포할 수 있습니다.

예를 들어 cgroup이 10개의 경우 각각 값 100의 가중치가 있으면 합계는 1000입니다. 각 cgroup은 리소스 1/10을 수신합니다.

weight는 일반적으로 상태 비저장 리소스를 배포하는 데 사용됩니다. 예를 들어 CPUWeight= 옵션은 이 리소스 배포 모델의 구현입니다.

제한

cgroup은 구성된 리소스 양까지 사용할 수 있습니다. 하위 그룹 제한의 합계는 상위 cgroup의 제한을 초과할 수 있습니다. 따라서 이 모델에서 리소스를 과다 할당할 수 있습니다.

예를 들어 MemoryMax= 옵션은 이 리소스 배포 모델의 구현입니다.

보호

cgroup에 대해 보호된 리소스 양을 설정할 수 있습니다. 리소스 사용량이 보호 경계 아래에 있는 경우 커널은 동일한 리소스에 대해 경쟁하는 다른 cgroups에 우선하여 이 cgroup에 영향을 미치지 않습니다. 오버 커밋도 가능합니다.

예를 들어 MemoryLow= 옵션은 이 리소스 배포 모델의 구현입니다.

할당
무한한 리소스의 절대 할당에 대한 배타적 할당입니다. 오버 커밋이 불가능합니다. Linux의 이러한 리소스 유형의 예로는 실시간 예산이 있습니다.
단위 파일 옵션

리소스 제어 구성 설정입니다.

예를 들어 CPUAccounting= 또는 CPUQuota= 와 같은 옵션을 사용하여 CPU 리소스를 구성할 수 있습니다. 마찬가지로 AllowedMemoryNodes=IOAccounting= 와 같은 옵션을 사용하여 메모리 또는 I/O 리소스를 구성할 수 있습니다.

33.3. systemd를 사용하여 시스템 리소스 할당

절차

서비스의 단위 파일 옵션의 필요한 값을 변경하려면 단위 파일에서 값을 조정하거나 systemctl 명령을 사용하면 됩니다.

  1. 선택한 서비스에 대해 할당된 값을 확인합니다.

    # systemctl show --property <unit file option> <service name>
  2. CPU 시간 할당 정책 옵션의 필요한 값을 설정합니다.

    # systemctl set-property <service name> <unit file option>=<value>

검증 단계

  • 선택한 서비스에 대해 새로 할당된 값을 확인합니다.

    # systemctl show --property <unit file option> <service name>

추가 리소스

  • systemd.resource-control(5)systemd.exec(5) 도움말 페이지

33.4. cgroups의 systemd 계층 구조 개요

백엔드에서 systemd 시스템 및 서비스 관리자는 슬라이스, 범위서비스 단위를 사용하여 제어 그룹의 프로세스를 구성하고 구성합니다. 사용자 지정 유닛 파일을 생성하거나 systemctl 명령을 사용하여 이 계층을 추가로 수정할 수 있습니다. 또한 systemd/sys/fs/cgroup/ 디렉터리에 중요한 커널 리소스 컨트롤러에 대한 계층을 자동으로 마운트합니다.

리소스 제어의 경우 다음 세 가지 systemd 장치 유형을 사용할 수 있습니다.

Service

systemd 가 장치 구성 파일에 따라 시작된 프로세스 또는 프로세스 그룹입니다.

서비스는 지정된 프로세스를 캡슐화하여 하나의 세트로 시작 및 중지할 수 있습니다. 서비스의 이름은 다음과 같이 지정됩니다.

<name>.service
범위

외부에서 생성된 프로세스 그룹입니다. 범위는 fork() 함수를 통해 임의의 프로세스에서 시작 및 중지된 프로세스를 캡슐화한 다음 런타임 시 systemd 에 의해 등록됩니다. 예를 들어 사용자 세션, 컨테이너 및 가상 머신은 범위로 처리됩니다. 범위는 다음과 같이 이름이 지정됩니다.

<name>.scope
slice

계층적으로 구성된 단위 그룹입니다. 슬라이스는 범위가 배치되는 계층 구조를 구성합니다.

실제 프로세스는 범위 또는 서비스에 포함됩니다. 슬라이스 단위의 모든 이름은 계층 구조의 위치 경로에 해당합니다.

대시(-) 문자는 -.slice 루트 슬라이스에서 슬라이스에 대한 경로 구성 요소의 구분 기호 역할을 합니다. 다음 예에서:

<parent-name>.slice

parent-name.slice-.slice 루트 슬라이스의 하위 디렉터리인 parent.slice.slice입니다. parent-name.slice 에는 parent-name-name2.slice 라는 고유한 하위 디렉터리가 있을 수 있습니다.

서비스, 범위, 슬라이스 단위는 제어 그룹 계층 구조의 개체에 직접 매핑됩니다. 이러한 장치가 활성화되면 직접 매핑하여 장치 이름에서 구축된 그룹 경로를 제어합니다.

다음은 제어 그룹 계층 구조의 축약된 예입니다.

Control group /:
-.slice
├─user.slice
│ ├─user-42.slice
│ │ ├─session-c1.scope
│ │ │ ├─ 967 gdm-session-worker [pam/gdm-launch-environment]
│ │ │ ├─1035 /usr/libexec/gdm-x-session gnome-session --autostart /usr/share/gdm/greeter/autostart
│ │ │ ├─1054 /usr/libexec/Xorg vt1 -displayfd 3 -auth /run/user/42/gdm/Xauthority -background none -noreset -keeptty -verbose 3
│ │ │ ├─1212 /usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart
│ │ │ ├─1369 /usr/bin/gnome-shell
│ │ │ ├─1732 ibus-daemon --xim --panel disable
│ │ │ ├─1752 /usr/libexec/ibus-dconf
│ │ │ ├─1762 /usr/libexec/ibus-x11 --kill-daemon
│ │ │ ├─1912 /usr/libexec/gsd-xsettings
│ │ │ ├─1917 /usr/libexec/gsd-a11y-settings
│ │ │ ├─1920 /usr/libexec/gsd-clipboard
…​
├─init.scope
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
└─system.slice
  ├─rngd.service
  │ └─800 /sbin/rngd -f
  ├─systemd-udevd.service
  │ └─659 /usr/lib/systemd/systemd-udevd
  ├─chronyd.service
  │ └─823 /usr/sbin/chronyd
  ├─auditd.service
  │ ├─761 /sbin/auditd
  │ └─763 /usr/sbin/sedispatch
  ├─accounts-daemon.service
  │ └─876 /usr/libexec/accounts-daemon
  ├─example.service
  │ ├─ 929 /bin/bash /home/jdoe/example.sh
  │ └─4902 sleep 1
  …​

위의 예제에서는 서비스 및 범위에 프로세스가 포함되어 있지 않은 슬라이스에 배치되어 있음을 보여줍니다.

추가 리소스

33.5. systemd 단위 나열

systemd 시스템 및 서비스 관리자를 사용하여 유닛을 나열합니다.

절차

  • systemctl 유틸리티를 사용하여 시스템의 활성 단위를 모두 나열합니다. 터미널은 다음 예와 유사한 출력을 반환합니다.

    # systemctl
    UNIT                                                LOAD   ACTIVE SUB       DESCRIPTION
    …​
    init.scope                                          loaded active running   System and Service Manager
    session-2.scope                                     loaded active running   Session 2 of user jdoe
    abrt-ccpp.service                                   loaded active exited    Install ABRT coredump hook
    abrt-oops.service                                   loaded active running   ABRT kernel log watcher
    abrt-vmcore.service                                 loaded active exited    Harvest vmcores for ABRT
    abrt-xorg.service                                   loaded active running   ABRT Xorg log watcher
    …​
    -.slice                                             loaded active active    Root Slice
    machine.slice                                       loaded active active    Virtual Machine and Container Slice system-getty.slice                                                                       loaded active active    system-getty.slice
    system-lvm2\x2dpvscan.slice                         loaded active active    system-lvm2\x2dpvscan.slice
    system-sshd\x2dkeygen.slice                         loaded active active    system-sshd\x2dkeygen.slice
    system-systemd\x2dhibernate\x2dresume.slice         loaded active active    system-systemd\x2dhibernate\x2dresume>
    system-user\x2druntime\x2ddir.slice                 loaded active active    system-user\x2druntime\x2ddir.slice
    system.slice                                        loaded active active    System Slice
    user-1000.slice                                     loaded active active    User Slice of UID 1000
    user-42.slice                                       loaded active active    User Slice of UID 42
    user.slice                                          loaded active active    User and Session Slice
    …​
    UNIT
    컨트롤 그룹 계층 구조의 단위 위치를 반영하는 단위의 이름입니다. 리소스 제어와 관련된 단위는 슬라이스, 범위서비스 입니다.
    LOAD
    단위 구성 파일이 올바르게 로드되었는지 여부를 나타냅니다. 단위 파일을 로드하지 못하는 경우 필드에 로드 되지 않고 상태 오류가 포함됩니다. 기타 단위 로드 상태는 stub,mergedmasked 입니다.
    활성 상태
    SUB 의 일반화인 고급 단위 활성화 상태입니다.
    SUB
    낮은 수준의 유닛 활성화 상태입니다. 가능한 값의 범위는 단위 유형에 따라 다릅니다.
    DESCRIPTION
    단위 콘텐츠 및 기능에 대한 설명입니다.
  • 활성 및 비활성 유닛을 모두 나열합니다.

    # systemctl --all
  • 출력 정보 양을 제한합니다.

    # systemctl --type service,masked

    --type 옵션에는 서비스슬라이스 와 같은 단위 유형 또는 로드 및 마스크 와 같은 단위 로드 상태 목록이 쉼표로 구분되어 있어야 합니다.

추가 리소스

33.6. systemd cgroups 계층 구조 보기

특정 cgroups 에서 실행되는 cgroup(컨트롤 그룹) 계층 및 프로세스를 표시합니다.

절차

  • systemd-cgls 명령을 사용하여 시스템의 전체 cgroups 계층을 표시합니다.

    # systemd-cgls
    Control group /:
    -.slice
    ├─user.slice
    │ ├─user-42.slice
    │ │ ├─session-c1.scope
    │ │ │ ├─ 965 gdm-session-worker [pam/gdm-launch-environment]
    │ │ │ ├─1040 /usr/libexec/gdm-x-session gnome-session --autostart /usr/share/gdm/greeter/autostart
    …​
    ├─init.scope
    │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
    └─system.slice
      …​
      ├─example.service
      │ ├─6882 /bin/bash /home/jdoe/example.sh
      │ └─6902 sleep 1
      ├─systemd-journald.service
        └─629 /usr/lib/systemd/systemd-journald
      …​

    예제 출력은 전체 cgroups 계층을 반환하며, 가장 높은 수준은 슬라이스 순으로 구성됩니다.

  • systemd-cgls <resource_controller> 명령을 사용하여 리소스 컨트롤러에서 필터링된 cgroups 계층을 표시합니다.

    # systemd-cgls memory
    Controller memory; Control group /:
    ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
    ├─user.slice
    │ ├─user-42.slice
    │ │ ├─session-c1.scope
    │ │ │ ├─ 965 gdm-session-worker [pam/gdm-launch-environment]
    …​
    └─system.slice
      |
      …​
      ├─chronyd.service
      │ └─844 /usr/sbin/chronyd
      ├─example.service
      │ ├─8914 /bin/bash /home/jdoe/example.sh
      │ └─8916 sleep 1
      …​

    예제 출력에는 선택한 컨트롤러와 상호 작용하는 서비스가 나열됩니다.

  • systemctl status <system_unit > 명령을 사용하여 cgroups 계층의 특정 단위 및 해당 부분에 대한 자세한 정보를 표시합니다.

    # systemctl status example.service
    ● example.service - My example service
       Loaded: loaded (/usr/lib/systemd/system/example.service; enabled; vendor preset: disabled)
       Active: active (running) since Tue 2019-04-16 12:12:39 CEST; 3s ago
     Main PID: 17737 (bash)
        Tasks: 2 (limit: 11522)
       Memory: 496.0K (limit: 1.5M)
       CGroup: /system.slice/example.service
               ├─17737 /bin/bash /home/jdoe/example.sh
               └─17743 sleep 1
    Apr 16 12:12:39 redhat systemd[1]: Started My example service.
    Apr 16 12:12:39 redhat bash[17737]: The current time is Tue Apr 16 12:12:39 CEST 2019
    Apr 16 12:12:40 redhat bash[17737]: The current time is Tue Apr 16 12:12:40 CEST 2019

추가 리소스

33.7. 프로세스 cgroups 보기

프로세스가 속한 제어 그룹 (cgroup)을 확인할 수 있습니다. 그런 다음 cgroup 을 확인하여 사용하는 컨트롤러 및 컨트롤러별 구성을 찾을 수 있습니다.

절차

  1. 프로세스가 속한 cgroup 을 보려면 # cat proc/<PID>/cgroup 명령을 실행합니다.

    # cat /proc/2467/cgroup
    0::/system.slice/example.service

    예제 출력은 관심 프로세스와 관련이 있습니다. 이 경우 PID 2467 에 의해 식별되는 프로세스이며 example.service 단위에 속합니다. 프로세스가 systemd 장치 파일 사양에 정의된 대로 올바른 제어 그룹에 배치되었는지 여부를 확인할 수 있습니다.

  2. cgroup에서 사용하는 컨트롤러 및 해당 구성 파일을 표시하려면 cgroup 디렉터리를 확인합니다.

    # cat /sys/fs/cgroup/system.slice/example.service/cgroup.controllers
    memory pids
    
    # ls /sys/fs/cgroup/system.slice/example.service/
    cgroup.controllers
    cgroup.events
    …​
    cpu.pressure
    cpu.stat
    io.pressure
    memory.current
    memory.events
    …​
    pids.current
    pids.events
    pids.max
참고

cgroup 의 버전 1 계층 구조에서는 컨트롤러별 모델을 사용합니다. 따라서 /proc/PID/cgroup 파일의 출력은 PID가 속한 각 컨트롤러 아래에 있는 cgroup 을 표시합니다. 해당 cgroup/sys/fs/cgroup/ <controller_name>/ 에서 확인할 수 있습니다.

추가 리소스

  • cgroups(7) 매뉴얼 페이지
  • 커널 리소스 컨트롤러란?
  • /usr/share/doc/kernel-doc-<kernel_version>/Documentation/admin-guide/cgroup-v2.rst 파일에 있는 문서( kernel-doc 패키지를 설치한 후)

33.8. 리소스 사용 모니터링

현재 실행 중인 제어 그룹(Groups)목록과 해당 리소스 사용을 실시간으로 확인합니다.

절차

  1. systemd-cgtop 명령을 사용하여 현재 실행 중인 cgroup 의 동적 계정을 표시합니다.

    # systemd-cgtop
    Control Group                            Tasks   %CPU   Memory  Input/s Output/s
    /                                          607   29.8     1.5G        -        -
    /system.slice                              125      -   428.7M        -        -
    /system.slice/ModemManager.service           3      -     8.6M        -        -
    /system.slice/NetworkManager.service         3      -    12.8M        -        -
    /system.slice/accounts-daemon.service        3      -     1.8M        -        -
    /system.slice/boot.mount                     -      -    48.0K        -        -
    /system.slice/chronyd.service                1      -     2.0M        -        -
    /system.slice/cockpit.socket                 -      -     1.3M        -        -
    /system.slice/colord.service                 3      -     3.5M        -        -
    /system.slice/crond.service                  1      -     1.8M        -        -
    /system.slice/cups.service                   1      -     3.1M        -        -
    /system.slice/dev-hugepages.mount            -      -   244.0K        -        -
    /system.slice/dev-mapper-rhel\x2dswap.swap   -      -   912.0K        -        -
    /system.slice/dev-mqueue.mount               -      -    48.0K        -        -
    /system.slice/example.service                2      -     2.0M        -        -
    /system.slice/firewalld.service              2      -    28.8M        -        -
    ...

    예제 출력에는 리소스 사용량(CPU, 메모리, 디스크 I/O 로드)으로 정렬된 현재 실행 중인 cgroup 이 표시됩니다. 목록은 기본적으로 1초마다 새로 고쳐집니다. 따라서 각 제어 그룹의 실제 리소스 사용에 대한 동적 통찰력을 제공합니다.

추가 리소스

  • systemd-cgtop(1) 매뉴얼 페이지

33.9. systemd 장치 파일을 사용하여 애플리케이션 제한 설정

systemd 서비스 관리자는 기존 또는 실행 중인 각 유닛을 감독하고 이를 위한 제어 그룹을 생성합니다. 유닛에는 /usr/lib/systemd/system/ 디렉터리에 구성 파일이 있습니다.

단위 파일을 다음과 같이 수동으로 수정할 수 있습니다.

  • 제한 설정.
  • 우선순위를 지정합니다.
  • 프로세스 그룹의 하드웨어 리소스에 대한 액세스를 제어합니다.

사전 요구 사항

  • 루트 권한이 있어야 합니다.

절차

  1. /usr/lib/systemd/system/example.service 파일을 편집하여 서비스의 메모리 사용량을 제한합니다.

    …​
    [Service]
    MemoryMax=1500K
    …​

    구성은 제어 그룹의 프로세스가 초과할 수 없는 최대 메모리를 제한합니다. example.service 서비스는 제한 사항이 있는 제어 그룹의 일부입니다. 접미사 K, M, G 또는 T를 사용하여 Kilobyte, Megabyte, 기가바이트 또는 Terabyte를 측정 단위로 식별할 수 있습니다.

  2. 모든 단위 구성 파일을 다시 로드합니다.

    # systemctl daemon-reload
  3. 서비스를 다시 시작하십시오.

    # systemctl restart example.service

검증

  1. 변경 사항이 적용되었는지 확인합니다.

    # cat /sys/fs/cgroup/system.slice/example.service/memory.max
    1536000

    예제 출력에서는 메모리 사용량이 약 1,500KB로 제한되었음을 보여줍니다.

추가 리소스

33.10. systemctl 명령을 사용하여 애플리케이션 제한 설정

CPU 선호도 설정은 특정 프로세스의 액세스를 일부 CPU로 제한하는 데 도움이 됩니다. 효과적으로 CPU 스케줄러는 프로세스의 유사성 마스크에 없는 CPU에서 실행되도록 프로세스를 예약하지 않습니다.

기본 CPU 선호도 마스크는 systemd 에서 관리하는 모든 서비스에 적용됩니다.

특정 systemd 서비스에 대한 CPU 선호도 마스크를 구성하기 위해 systemd 는 다음과 같이 CPUAffinity= 를 제공합니다.

  • 단위 파일 옵션.
  • /etc/systemd/system.conf 파일의 [Manager] 섹션에 있는 구성 옵션입니다.

CPUAffinity= 단위 파일 옵션은 유사성 마스크로 병합되어 사용되는 CPU 또는 CPU 범위 목록을 설정합니다.

절차

CPUAffinity 장치 파일 옵션을 사용하여 특정 systemd 서비스의 CPU 선호도 마스크를 설정하려면 다음을 수행합니다.

  1. 선택한 서비스에서 CPUAffinity 단위 파일 옵션 값을 확인합니다.

    $ systemctl show --property <CPU affinity configuration option> <service name>
  2. root 사용자로 선호도 마스크로 사용되는 CPU 범위에 대한 CPUAffinity 장치 파일 옵션의 필요한 값을 설정합니다.

    # systemctl set-property <service name> CPUAffinity=<value>
  3. 서비스를 다시 시작하여 변경 사항을 적용합니다.

    # systemctl restart <service name>

추가 리소스

  • systemd.resource-control(5), systemd.exec(5), cgroups(7) 도움말 페이지

33.11. 관리자 구성을 통해 글로벌 기본 CPU 선호도 설정

/etc/systemd/system.conf 파일의 CPUAffinity 옵션은 PID(프로세스 식별 번호) 1에 대한 선호도 마스크와 PID1에서 분기된 모든 프로세스를 정의합니다. 그런 다음 서비스별로 CPUAffinity 를 덮어쓸 수 있습니다.

/etc/systemd/system.conf 파일을 사용하여 모든 systemd 서비스의 기본 CPU 선호도 마스크를 설정하려면 다음을 수행합니다.

  1. /etc/systemd/system.conf 파일의 [Manager] 섹션에서 CPUAffinity= 옵션의 CPU 번호를 설정합니다.
  2. 편집한 파일을 저장하고 systemd 서비스를 다시 로드합니다.

    # systemctl daemon-reload
  3. 서버를 재부팅하여 변경 사항을 적용합니다.

추가 리소스

  • systemd.resource-control(5)systemd.exec(5) 도움말 페이지.

33.12. systemd를 사용하여 NUMA 정책 구성

NUMA(Non-Uniform Memory Access)는 컴퓨터 메모리 하위 시스템 설계로, 프로세서와 관련된 실제 메모리 위치에 따라 메모리 액세스 시간이 달라집니다.

CPU에 가까운 메모리는 다른 CPU (foreign memory)에 대해 로컬되거나 CPU 세트 간에 공유되는 메모리보다 대기 시간(로컬 메모리)이 더 적습니다.

Linux 커널 측면에서 NUMA 정책은 커널이 프로세스에 실제 메모리 페이지를 할당하는 위치(예: NUMA 노드)를 관리합니다.

systemd 는 서비스의 메모리 할당 정책을 제어하기 위해 장치 파일 옵션 NUMAPolicyNUMAMask 를 제공합니다.

절차

NUMAPolicy 단위 파일 옵션을 통해 NUMA 메모리 정책을 설정하려면 다음을 수행합니다.

  1. 선택한 서비스에서 NUMAPolicy 단위 파일 옵션 값을 확인합니다.

    $ systemctl show --property <NUMA policy configuration option> <service name>
  2. 루트로서 NUMAPolicy 단위 파일 옵션의 필수 정책 유형을 설정합니다.

    # systemctl set-property <service name> NUMAPolicy=<value>
  3. 서비스를 다시 시작하여 변경 사항을 적용합니다.

    # systemctl restart <service name>

[Manager] 구성 옵션을 사용하여 글로벌 NUMAPolicy 설정을 설정하려면 다음을 수행합니다.

  1. /etc/systemd/system.conf 파일에서 파일의 [Manager] 섹션에서 NUMAPolicy 옵션을 검색합니다.
  2. 정책 유형을 편집하고 파일을 저장합니다.
  3. systemd 구성을 다시 로드합니다.

    # systemd daemon-reload
  4. 서버를 재부팅합니다.
중요

엄격한 NUMA 정책을 구성할 때(예: 바인딩 )는 CPUAffinity= 단위 파일 옵션도 적절히 설정해야 합니다.

추가 리소스

33.13. systemd에 대한 NUMA 정책 구성 옵션

systemd 는 NUMA 정책을 구성하는 다음 옵션을 제공합니다.

NUMAPolicy

실행된 프로세스의 NUMA 메모리 정책을 제어합니다. 이러한 정책 유형을 사용할 수 있습니다.

  • default
  • preferred
  • bind
  • interleave
  • 로컬
NUMAMask

선택한 NUMA 정책과 연결된 NUMA 노드 목록을 제어합니다.

다음 정책에 대해 NUMAMask 옵션을 지정할 필요가 없습니다.

  • default
  • 로컬

기본 정책의 경우 목록은 단일 NUMA 노드만 지정합니다.

추가 리소스

  • systemd.resource-control(5), systemd.exec(5), set_mempolicy(2) 도움말 페이지

33.14. systemd-run 명령을 사용하여 일시적인 cgroups 생성

일시적인 cgroups 는 런타임 중 단위(서비스 또는 범위)에서 사용하는 리소스에 대한 제한을 설정합니다.

절차

  • 일시적인 제어 그룹을 생성하려면 다음 형식으로 systemd-run 명령을 사용합니다.

    # systemd-run --unit=<name> --slice=<name>.slice <command>

    이 명령은 일시적인 서비스 또는 범위 장치를 생성 및 시작하고 이러한 단위로 사용자 지정 명령을 실행합니다.

    • --unit=<name& gt; 옵션은 유닛 이름을 제공합니다. --unit 을 지정하지 않으면 이름이 자동으로 생성됩니다.
    • --slice=<name>.slice 옵션을 사용하면 서비스 또는 범위 단위를 지정된 슬라이스의 멤버로 만들 수 있습니다. < name>.slice 를 기존 슬라이스 이름(예: systemctl -t slice)의 이름으로 바꾸거나 고유한 이름을 전달하여 새 슬라이스를 생성합니다. 기본적으로 서비스 및 범위는 system.slice 의 멤버로 생성됩니다.
    • & lt;command >를 서비스 또는 범위 단위에 입력하려는 명령으로 바꿉니다.

      다음 메시지가 표시되어 서비스 또는 범위를 성공적으로 생성 및 시작했는지 확인합니다.

      # Running as unit <name>.service
  • 선택 사항: 프로세스가 완료된 후 런타임 정보를 수집하도록 장치를 실행합니다.

    # systemd-run --unit=<name> --slice=<name>.slice --remain-after-exit <command>

    명령은 일시적인 서비스 장치를 생성 및 시작하고 단위에서 사용자 지정 명령을 실행합니다. --remain-after-exit 옵션을 사용하면 프로세스가 완료된 후 서비스가 계속 실행되도록 합니다.

추가 리소스

33.15. 일시적인 제어 그룹 제거

systemd 시스템 및 서비스 관리자를 사용하여 더 이상 제한, 우선 순위 또는 프로세스 그룹의 하드웨어 리소스에 대한 액세스를 제어할 필요가 없는 경우cgroup(임시 제어 그룹)을 제거할 수 있습니다.

임시 cgroup 은 서비스 또는 범위 단위에 포함된 모든 프로세스가 완료되면 자동으로 릴리스됩니다.

절차

  • 모든 프로세스가 포함된 서비스 장치를 중지하려면 다음을 입력합니다.

    # systemctl stop <name>.service
  • 하나 이상의 단위 프로세스를 종료하려면 다음을 입력합니다.

    # systemctl kill <name>.service --kill-who=PID,…​ --signal=<signal>

    명령은 --kill-who 옵션을 사용하여 종료하려는 제어 그룹에서 프로세스를 선택합니다. 여러 프로세스를 동시에 종료하려면 쉼표로 구분된 PID 목록을 전달합니다. --signal 옵션은 지정된 프로세스에 보낼 POSIX 신호 유형을 결정합니다. 기본 신호는 SIGTERM 입니다.

추가 리소스

34장. 제어 그룹 이해

제어 그룹(cgroup) 커널 기능을 사용하면 애플리케이션의 리소스 사용량을 제어하여 보다 효율적으로 사용할 수 있습니다.

다음 작업에 cgroup 을 사용할 수 있습니다.

  • 시스템 리소스 할당에 대한 제한 설정.
  • 특정 프로세스에 대한 하드웨어 리소스 할당 우선 순위를 지정합니다.
  • 특정 프로세스에서 하드웨어 리소스를 가져오지 못하도록 격리합니다.

34.1. 제어 그룹 소개

제어 그룹 Linux 커널 기능을 사용하여 프로세스를 계층적으로 정렬된 그룹인 cgroup 으로 구성할 수 있습니다. /sys/fs/cgroup/ 디렉터리에 기본적으로 마운트된 cgroups 가상 파일 시스템에 구조를 제공하여 계층 구조(제어 그룹 트리)를 정의합니다.

systemd 서비스 관리자는 cgroup 을 사용하여 관리하는 모든 장치 및 서비스를 구성합니다. 수동으로 /sys/fs/cgroup/ 디렉터리에 하위 디렉터리를 생성하고 제거하여 cgroup 의 계층 구조를 관리할 수 있습니다.

그런 다음 커널의 리소스 컨트롤러는 해당 프로세스의 시스템 리소스를 제한, 우선 지정 또는 할당하여 cgroup 의 프로세스 동작을 수정합니다. 이러한 리소스에는 다음이 포함됩니다.

  • CPU 시간
  • 메모리
  • 네트워크 대역폭
  • 이러한 리소스의 조합

cgroup 의 주요 사용 사례는 시스템 프로세스를 집계하고 애플리케이션 및 사용자 간에 하드웨어 리소스를 분할하는 것입니다. 이를 통해 환경의 효율성, 안정성 및 보안을 강화할 수 있습니다.

제어 그룹 버전 1

제어 그룹 버전 1 (cgroups-v1)은 리소스별 컨트롤러 계층을 제공합니다. 즉, 각 리소스(예: CPU, 메모리 또는 I/O)에는 자체 제어 그룹 계층 구조가 있습니다. 하나의 컨트롤러에서 각각의 리소스를 관리할 때 다른 컨트롤러와 조정할 수 있는 방식으로 서로 다른 제어 그룹 계층 구조를 결합할 수 있습니다. 그러나 두 컨트롤러가 서로 다른 프로세스 계층에 속하는 경우 적절한 조정이 제한됩니다.

cgroups-v1 컨트롤러는 대규모 기간 동안 개발되었으며 그 결과 제어 파일의 동작 및 이름 지정은 균일하지 않습니다.

제어 그룹 버전 2

제어 그룹 버전 2 (cgroups-v2)는 모든 리소스 컨트롤러가 마운트된 단일 제어 그룹 계층 구조를 제공합니다.

제어 파일 동작 및 이름 지정은 다양한 컨트롤러에서 일관되게 지정됩니다.

중요

RHEL 9는 기본적으로 cgroups-v2 를 마운트 및 사용합니다.

추가 리소스

34.2. 커널 리소스 컨트롤러 소개

커널 리소스 컨트롤러를 사용하면 제어 그룹의 기능을 사용할 수 있습니다. RHEL 9는 제어 그룹 버전 1(cgroups-v1 ) 및 제어 그룹 버전 2(cgroups-v2 )에 대한 다양한 컨트롤러를 지원합니다.

제어 그룹 하위 시스템이라고도 하는 리소스 컨트롤러는 CPU 시간, 메모리, 네트워크 대역폭 또는 디스크 I/O와 같은 단일 리소스를 나타내는 커널 하위 시스템입니다. Linux 커널은 systemd 서비스 관리자가 자동으로 마운트하는 다양한 리소스 컨트롤러를 제공합니다. 현재 마운트된 리소스 컨트롤러 목록은 /proc/cgroups 파일에서 찾을 수 있습니다.

cgroups-v1 에서 사용 가능한 컨트롤러:

blkio
블록 장치에 대한 입력/출력 액세스 제한을 설정합니다.
cpu
제어 그룹의 작업에 대한 CFS(Completely Fair Scheduler)의 매개변수를 조정합니다. cpu 컨트롤러는 동일한 마운트에 cpuacct 컨트롤러와 함께 마운트됩니다.
cpuacct
제어 그룹의 작업에서 사용하는 CPU 리소스에 대한 자동 보고서를 생성합니다. cpuacct 컨트롤러는 동일한 마운트에 cpu 컨트롤러와 함께 마운트됩니다.
cpuset
CPU의 지정된 하위 집합에서만 실행되도록 제어 그룹 작업을 제한하고 지정된 메모리 노드에서만 메모리를 사용하도록 작업에 지시합니다.
devices
제어 그룹의 작업에 대한 장치에 대한 액세스를 제어합니다.
freezer
제어 그룹에서 작업을 일시 중지하거나 재개합니다.
memory
제어 그룹의 작업에서 메모리 사용량에 대한 제한을 설정하고 해당 작업에서 사용하는 메모리 리소스에 대한 자동 보고서를 생성합니다.
net_cls
Linux 트래픽 컨트롤러( tc 명령)를 활성화하여 특정 제어 그룹 작업에서 시작된 패킷을 식별하는 클래스 식별자(classid)가 있는 네트워크 패킷을 태그합니다. net_cls 의 하위 시스템인 net_filter (iptables)도 이 태그를 사용하여 이러한 패킷에 대한 작업을 수행할 수 있습니다. net_filter 는 Linux 방화벽에서 특정 제어 그룹 작업에서 시작된 패킷을 식별할 수 있는 방화벽 식별자(fwid)로 네트워크 소켓을 태그합니다( iptables 명령을 사용하여).
net_prio
네트워크 트래픽의 우선 순위를 설정합니다.
pids
제어 그룹에서 여러 프로세스 및 해당 하위 항목에 대한 제한을 설정합니다.
perf_event
perf 성능 모니터링 및 보고 유틸리티를 통한 모니터링을 위한 작업을 그룹화합니다.
rdma
제어 그룹의 Remote Direct Memory Access/InfiniBand 특정 리소스에 대한 제한을 설정합니다.
hugetlb
제어 그룹의 작업으로 큰 크기의 가상 메모리 페이지 사용을 제한하는 데 사용할 수 있습니다.

cgroups-v2 에서 사용 가능한 컨트롤러:

io
블록 장치에 대한 입력/출력 액세스 제한을 설정합니다.
memory
제어 그룹의 작업에서 메모리 사용량에 대한 제한을 설정하고 해당 작업에서 사용하는 메모리 리소스에 대한 자동 보고서를 생성합니다.
pids
제어 그룹에서 여러 프로세스 및 해당 하위 항목에 대한 제한을 설정합니다.
rdma
제어 그룹의 Remote Direct Memory Access/InfiniBand 특정 리소스에 대한 제한을 설정합니다.
cpu
제어 그룹의 작업에 대한 CFS(Completely Fair Scheduler) 매개변수를 조정하고 제어 그룹의 작업에서 사용하는 CPU 리소스에 대한 자동 보고서를 생성합니다.
cpuset
CPU의 지정된 하위 집합에서만 실행되도록 제어 그룹 작업을 제한하고 지정된 메모리 노드에서만 메모리를 사용하도록 작업에 지시합니다. 새 파티션 기능이 있는 코어 기능(cpus{,.effective}, mems{,.effective})만 지원합니다.
perf_event
perf 성능 모니터링 및 보고 유틸리티를 통한 모니터링을 위한 작업을 그룹화합니다. perf_event 는 v2 계층 구조에서 자동으로 활성화됩니다.
중요

리소스 컨트롤러는 cgroup-v1 계층 구조 또는 두 계층에서 동시에 사용할 수 없는 cgroups-v2 계층에서 사용할 수 있습니다.

추가 리소스

  • cgroups(7) 매뉴얼 페이지
  • /usr/share/doc/kernel-doc-<kernel_version>/Documentation/cgroups-v1/ 디렉토리( kernel-doc 패키지를 설치한 후).

34.3. 네임스페이스 소개

네임스페이스는 소프트웨어 오브젝트를 구성하고 식별하는 데 가장 중요한 방법 중 하나입니다.

네임스페이스는 글로벌 리소스(예: 마운트 지점, 네트워크 장치 또는 호스트 이름)를 추상화로 래핑하여 글로벌 리소스의 자체 격리된 인스턴스가 있는 네임스페이스 내의 프로세스에 나타납니다. 네임스페이스를 사용하는 가장 일반적인 기술 중 하나는 컨테이너입니다.

특정 글로벌 리소스에 대한 변경 사항은 해당 네임스페이스의 프로세스에만 표시되고 나머지 시스템 또는 기타 네임 스페이스에는 영향을 미치지 않습니다.

프로세스가 속한 네임스페이스를 검사하려면 /proc/<PID>/ns/ 디렉터리에서 심볼릭 링크를 확인할 수 있습니다.

표 34.1. 격리할 수 있는 지원되는 네임스페이스 및 리소스:

네임스페이스isolates

Mount

마운트 지점

UTS

호스트 이름 및 NIS 도메인 이름

IPC

System V IPC, POSIX 메시지 대기열

PID

프로세스 ID

네트워크

네트워크 장치, 스택, 포트 등

사용자

사용자 및 그룹 ID

제어 그룹

제어 그룹 루트 디렉터리

추가 리소스

35장. cgroup을 사용하여 cgroup 수동 관리

cgroup fs 가상 파일 시스템에 디렉터리를 생성하여 시스템의 cgroup 계층 구조를 관리할 수 있습니다. 파일 시스템은 기본적으로 /sys/fs/cgroup/ 디렉터리에 마운트되며 전용 제어 파일에 원하는 구성을 지정할 수 있습니다.

중요

일반적으로 Red Hat은 systemd 를 사용하여 시스템 리소스 사용을 제어하는 것이 좋습니다. 특수한 경우에만 cgroup 가상 파일 시스템을 수동으로 구성해야 합니다. 예를 들어 cgroup-v2 계층 구조에는 동일하지 않은 cgroup-v1 컨트롤러를 사용해야 합니다.

35.1. cgroup 생성 및 cgroups-v2 파일 시스템에서 컨트롤러 활성화

디렉터리를 생성하거나 제거하고cgroups가상 파일 시스템의 파일에 작성하여 제어 그룹 ( cgroups )을 관리할 수 있습니다. 파일 시스템은 기본적으로 /sys/fs/cgroup/ 디렉터리에 마운트됩니다. cgroups 컨트롤러의 설정을 사용하려면 하위 cgroup 에 대해 원하는 컨트롤러도 활성화해야 합니다. 루트 cgroup 은 기본적으로 하위 cgroup 에 대해 메모리pids 컨트롤러를 활성화했습니다. 따라서 Red Hat은 /sys/fs/cgroup/ root cgroup 에 두 개 이상의 하위 cgroup 을 생성하는 것이 좋습니다. 이렇게 하면 선택적으로 자식 cgroups 에서 메모리pids 컨트롤러를 제거하고 cgroup 파일의 조직적인 명확성을 개선할 수 있습니다.

사전 요구 사항

  • 루트 권한이 있어야 합니다.

절차

  1. /sys/fs/cgroup/Example/ 디렉터리를 생성합니다.

    # mkdir /sys/fs/cgroup/Example/

    /sys/fs/cgroup/Example/ 디렉터리는 하위 그룹을 정의합니다. /sys/fs/cgroup/Example/ 디렉토리를 생성하면 일부 cgroups-v2 인터페이스 파일이 디렉터리에 자동으로 생성됩니다. /sys/fs/cgroup/Example/ 디렉터리에는 메모리pids 컨트롤러의 컨트롤러별 파일도 포함되어 있습니다.

  2. 선택적으로 새로 생성된 하위 제어 그룹을 검사합니다.

    # ll /sys/fs/cgroup/Example/
    -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.controllers
    -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.events
    -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.freeze
    -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.procs
    …​
    -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.subtree_control
    -r—​r—​r--. 1 root root 0 Jun  1 10:33 memory.events.local
    -rw-r—​r--. 1 root root 0 Jun  1 10:33 memory.high
    -rw-r—​r--. 1 root root 0 Jun  1 10:33 memory.low
    …​
    -r—​r—​r--. 1 root root 0 Jun  1 10:33 pids.current
    -r—​r—​r--. 1 root root 0 Jun  1 10:33 pids.events
    -rw-r—​r--. 1 root root 0 Jun  1 10:33 pids.max

    예제 출력에서는 cgroup.procs 또는 cgroup.controllers 와 같은 일반적인 cgroup 제어 인터페이스 파일을 보여줍니다. 이러한 파일은 활성화된 컨트롤러에 관계없이 모든 제어 그룹에 공통입니다.

    memory.highpids.max 와 같은 파일은 루트 제어 그룹(/sys/fs/cgroup/)에 있는 메모리pids 컨트롤러와 관련되어 있으며 systemd 에 의해 기본적으로 활성화됩니다.

    기본적으로 새로 생성된 하위 그룹은 상위 cgroup 의 모든 설정을 상속합니다. 이 경우 root cgroup 에는 제한이 없습니다.

  3. /sys/fs/cgroup/cgroup.controllers 파일에서 원하는 컨트롤러를 사용할 수 있는지 확인합니다.

    # cat /sys/fs/cgroup/cgroup.controllers
    cpuset cpu io memory hugetlb pids rdma
  4. 원하는 컨트롤러를 활성화합니다. 이 예제에서는 cpucpuset 컨트롤러입니다.

    # echo "+cpu" >> /sys/fs/cgroup/cgroup.subtree_control
    # echo "+cpuset" >> /sys/fs/cgroup/cgroup.subtree_control

    이러한 명령을 사용하면 /sys/fs/cgroup/ root 제어 그룹의 즉시 하위 그룹에 대해 cpucpuset 컨트롤러가 활성화됩니다. 새로 생성된 Example 제어 그룹 포함. 하위 그룹은 프로세스를 지정하고 기준에 따라 각 프로세스에 제어 검사를 적용할 수 있는 곳입니다.

    사용자는 임의 수준에서 cgroup.subtree_control 파일의 내용을 읽고 즉시 하위 그룹에서 사용할 수 있는 컨트롤러를 확인할 수 있습니다.

    참고

    기본적으로 루트 제어 그룹의 /sys/fs/cgroup/cgroup.subtree_control 파일에는 메모리 및 pid 컨트롤러가 포함되어 있습니다.

  5. Example 제어 그룹의 하위 cgroup 에 대해 원하는 컨트롤러를 활성화합니다.

    # echo "+cpu +cpuset" >> /sys/fs/cgroup/Example/cgroup.subtree_control

    이 명령을 사용하면 즉시 하위 제어 그룹에 메모리 또는 pids 컨트롤러가 아닌 CPU 시간 분배를 규제하는 데 관련된 컨트롤러 있습니다.

  6. /sys/fs/cgroup/Example/tasks/ 디렉터리를 생성합니다.

    # mkdir /sys/fs/cgroup/Example/tasks/

    /sys/fs/cgroup/Example/tasks/ 디렉터리는 cpucpuset 컨트롤러와 관련된 파일이 있는 하위 그룹을 정의합니다. 이제 프로세스를 이 제어 그룹에 할당하고 프로세스에 cpucpuset 컨트롤러 옵션을 사용할 수 있습니다.

  7. 필요한 경우 하위 제어 그룹을 검사합니다.

    # ll /sys/fs/cgroup/Example/tasks
    -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.controllers
    -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.events
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.freeze
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.max.depth
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.max.descendants
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.procs
    -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.stat
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.subtree_control
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.threads
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.type
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.max
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.pressure
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus
    -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus.effective
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus.partition
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.mems
    -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpuset.mems.effective
    -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpu.stat
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.weight
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.weight.nice
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 io.pressure
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 memory.pressure
중요

cpu 컨트롤러는 관련 하위 제어 그룹에 단일 CPU의 시간 동안 경쟁하는 최소 2개의 프로세스가 있는 경우에만 활성화됩니다.

검증 단계

  • 선택 사항: 원하는 컨트롤러가 활성화된 새 cgroup 을 생성했는지 확인합니다.

    # cat /sys/fs/cgroup/Example/tasks/cgroup.controllers
    cpuset cpu

추가 리소스

35.2. CPU 가중치를 조정하여 애플리케이션의 CPU 시간 분배 제어

특정 cgroup 트리의 애플리케이션에 CPU 시간 배포를 규제하려면 cpu 컨트롤러의 관련 파일에 값을 할당해야 합니다.

사전 요구 사항

  • 루트 권한이 있어야 합니다.
  • CPU 시간 분배를 제어하려는 애플리케이션이 있습니다.
  • 다음 예제와 같이 /sys/fs/cgroup/ root 제어 그룹 내에 하위 제어 그룹 의 두 가지 수준 계층을 생성했습니다.

    …​
      ├── Example
      │   ├── g1
      │   ├── g2
      │   └── g3
    …​
  • cgroup 생성에 설명된 대로 상위 제어 그룹 및 하위 제어 그룹에서 cpu 컨트롤러를 활성화하여 cgroups-v2 파일 시스템에서 컨트롤러를 활성화합니다.

절차

  1. 제어 그룹 내에서 리소스 제한을 달성하도록 원하는 CPU 가중치를 구성합니다.

    # echo "150" > /sys/fs/cgroup/Example/g1/cpu.weight
    # echo "100" > /sys/fs/cgroup/Example/g2/cpu.weight
    # echo "50" > /sys/fs/cgroup/Example/g3/cpu.weight
  2. 애플리케이션의 PID를 g1,g2, g3 하위 그룹에 추가합니다.

    # echo "33373" > /sys/fs/cgroup/Example/g1/cgroup.procs
    # echo "33374" > /sys/fs/cgroup/Example/g2/cgroup.procs
    # echo "33377" > /sys/fs/cgroup/Example/g3/cgroup.procs

    예제 명령을 사용하면 원하는 애플리케이션이 Example/g*/ 하위 cgroup의 멤버가 되고 해당 cgroups의 구성에 따라 CPU 시간을 분산시킵니다.

    프로세스를 실행 중인 하위 cgroup(g1,g2,g3)의 가중치는 상위 cgroup 수준()으로 요약됩니다. 그런 다음 CPU 리소스는 각각의 가중치에 따라 비례분산됩니다.

    결과적으로 모든 프로세스가 동시에 실행될 때 커널은 각각의 cgroup의 cpu.weight 파일에 따라 비례 CPU 시간을 할당합니다.

    하위 cgroupcpu.weight fileCPU 시간 할당

    g1

    150

    ~50% (150/300)

    g2

    100

    ~33% (100/300)

    g3

    50

    ~16% (50/300)

    cpu.weight 컨트롤러 파일의 값은 백분율이 아닙니다.

    한 프로세스가 중지되어 실행 중인 프로세스가 없는 cgroup g2 를 그대로 두면 계산으로 cgroup g2g3 의 계정 가중치만 생략됩니다.

    하위 cgroupcpu.weight fileCPU 시간 할당

    g1

    150

    ~75% (150/200)

    g3

    50

    ~25% (50/200)

    중요

    하위 cgroup에 실행 중인 프로세스가 여러 개 있는 경우 해당 cgroup에 할당된 CPU 시간이 해당 cgroup의 멤버 프로세스에 동일하게 배포됩니다.

검증

  1. 애플리케이션이 지정된 제어 그룹에서 실행되는지 확인합니다.

    # cat /proc/33373/cgroup /proc/33374/cgroup /proc/33377/cgroup
    0::/Example/g1
    0::/Example/g2
    0::/Example/g3

    명령 출력에는 Example/g*/ 하위 cgroups에서 실행되는 지정된 애플리케이션의 프로세스가 표시됩니다.

  2. 스로틀된 애플리케이션의 현재 CPU 사용량을 검사합니다.

    # top
    top - 05:17:18 up 1 day, 18:25,  1 user,  load average: 3.03, 3.03, 3.00
    Tasks:  95 total,   4 running,  91 sleeping,   0 stopped,   0 zombie
    %Cpu(s): 18.1 us, 81.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  0.0 si,  0.0 st
    MiB Mem :   3737.0 total,   3233.7 free,    132.8 used,    370.5 buff/cache
    MiB Swap:   4060.0 total,   4060.0 free,      0.0 used.   3373.1 avail Mem
    
        PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
      33373 root      20   0   18720   1748   1460 R  49.5   0.0 415:05.87 sha1sum
      33374 root      20   0   18720   1756   1464 R  32.9   0.0 412:58.33 sha1sum
      33377 root      20   0   18720   1860   1568 R  16.3   0.0 411:03.12 sha1sum
        760 root      20   0  416620  28540  15296 S   0.3   0.7   0:10.23 tuned
          1 root      20   0  186328  14108   9484 S   0.0   0.4   0:02.00 systemd
          2 root      20   0       0      0      0 S   0.0   0.0   0:00.01 kthread
    ...
    참고

    더 명확한 설명을 위해 모든 예제 프로세스를 단일 CPU에서 실행하도록 강제했습니다. CPU weight는 여러 CPU에서 사용되는 경우에도 동일한 원칙을 적용합니다.

    PID 33373,PID 33374, PID 33377 의 CPU 리소스가 각 하위 cgroup에 할당한 가중치인 150, 100, 50을 기반으로 할당되었습니다. 가중치는 약 50%, 33%, 각 애플리케이션에 대한 CPU 시간이 16%에 해당합니다.

35.3. cgroups-v1 마운트

부팅 프로세스 중에 RHEL 9는 기본적으로 cgroup-v2 가상 파일 시스템을 마운트합니다. 애플리케이션의 리소스를 제한하면서 cgroup-v1 기능을 활용하려면 시스템을 수동으로 구성합니다.

참고

cgroup-v1cgroup-v2 는 모두 커널에서 완전히 활성화됩니다. 커널 보기에는 기본 제어 그룹 버전이 없으며 시작 시 마운트할 systemd 에 의해 결정됩니다.

사전 요구 사항

  • 루트 권한이 있어야 합니다.

절차

  1. 시스템 부팅 중에 systemd 시스템 및 서비스 관리자가 기본적으로 cgroup-v1 을 마운트하도록 시스템을 구성합니다.

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"

    그러면 현재 부팅 항목에 필요한 커널 명령줄 매개변수가 추가됩니다.

    모든 커널 부팅 항목에 동일한 매개변수를 추가하려면 다음을 수행합니다.

    # grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"
  2. 시스템을 재부팅하여 변경 사항을 적용합니다.

검증

  1. 필요한 경우 cgroups-v1 파일 시스템이 마운트되었는지 확인합니다.

    # mount -l | grep cgroup
    tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,size=4096k,nr_inodes=1024,mode=755,inode64)
    cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
    cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,perf_event)
    cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpu,cpuacct)
    cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,pids)
    cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpuset)
    cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,net_cls,net_prio)
    cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,hugetlb)
    cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,memory)
    cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,blkio)
    cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,devices)
    cgroup on /sys/fs/cgroup/misc type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,misc)
    cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,freezer)
    cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,rdma)

    다양한 cgroup-v1 컨트롤러에 해당하는 cgroups-v1 파일 시스템이 /sys/fs/cgroup/ 디렉터리에 성공적으로 마운트되었습니다.

  2. 선택적으로 /sys/fs/cgroup/ 디렉터리의 콘텐츠를 검사합니다.

    # ll /sys/fs/cgroup/
    dr-xr-xr-x. 10 root root  0 Mar 16 09:34 blkio
    lrwxrwxrwx.  1 root root 11 Mar 16 09:34 cpu → cpu,cpuacct
    lrwxrwxrwx.  1 root root 11 Mar 16 09:34 cpuacct → cpu,cpuacct
    dr-xr-xr-x. 10 root root  0 Mar 16 09:34 cpu,cpuacct
    dr-xr-xr-x.  2 root root  0 Mar 16 09:34 cpuset
    dr-xr-xr-x. 10 root root  0 Mar 16 09:34 devices
    dr-xr-xr-x.  2 root root  0 Mar 16 09:34 freezer
    dr-xr-xr-x.  2 root root  0 Mar 16 09:34 hugetlb
    dr-xr-xr-x. 10 root root  0 Mar 16 09:34 memory
    dr-xr-xr-x.  2 root root  0 Mar 16 09:34 misc
    lrwxrwxrwx.  1 root root 16 Mar 16 09:34 net_cls → net_cls,net_prio
    dr-xr-xr-x.  2 root root  0 Mar 16 09:34 net_cls,net_prio
    lrwxrwxrwx.  1 root root 16 Mar 16 09:34 net_prio → net_cls,net_prio
    dr-xr-xr-x.  2 root root  0 Mar 16 09:34 perf_event
    dr-xr-xr-x. 10 root root  0 Mar 16 09:34 pids
    dr-xr-xr-x.  2 root root  0 Mar 16 09:34 rdma
    dr-xr-xr-x. 11 root root  0 Mar 16 09:34 systemd

    /sys/fs/cgroup/ 디렉터리(기본적으로 루트 제어 그룹 라고도 함)에는 cpuset 와 같은 컨트롤러별 디렉터리가 포함되어 있습니다. 또한 systemd 와 관련된 일부 디렉터리도 있습니다.

35.4. cgroups-v1을 사용하여 애플리케이션에 CPU 제한 설정

제어 그룹 버전 1 (cgroups-v1)을 사용하여 애플리케이션에 대한 CPU 제한을 구성하려면 /sys/fs/ 가상 파일 시스템을 사용합니다.

사전 요구 사항

  • 루트 권한이 있어야 합니다.
  • CPU 사용량이 제한하려는 애플리케이션이 있습니다.
  • 시스템 부팅 중에 systemd 시스템 및 서비스 관리자가 기본적으로 cgroup-v1 을 마운트하도록 시스템을 구성하셨습니다.

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"

    그러면 현재 부팅 항목에 필요한 커널 명령줄 매개변수가 추가됩니다.

절차

  1. CPU 소비에서 제한하려는 애플리케이션의 PID(프로세스 ID)를 식별합니다.

    # top
    top - 11:34:09 up 11 min,  1 user,  load average: 0.51, 0.27, 0.22
    Tasks: 267 total,   3 running, 264 sleeping,   0 stopped,   0 zombie
    %Cpu(s): 49.0 us,  3.3 sy,  0.0 ni, 47.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.0 st
    MiB Mem :   1826.8 total,    303.4 free,   1046.8 used,    476.5 buff/cache
    MiB Swap:   1536.0 total,   1396.0 free,    140.0 used.    616.4 avail Mem
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     6955 root      20   0  228440   1752   1472 R  99.3   0.1   0:32.71 sha1sum
     5760 jdoe      20   0 3603868 205188  64196 S   3.7  11.0   0:17.19 gnome-shell
     6448 jdoe      20   0  743648  30640  19488 S   0.7   1.6   0:02.73 gnome-terminal-
        1 root      20   0  245300   6568   4116 S   0.3   0.4   0:01.87 systemd
      505 root      20   0       0      0      0 I   0.3   0.0   0:00.75 kworker/u4:4-events_unbound
    ...

    top 프로그램의 이 예제 출력에서는 PID 6955 가 있는 애플리케이션 sha1sum 이 많은 CPU 리소스를 사용한다는 것을 보여줍니다.

  2. cpu 리소스 컨트롤러 디렉터리에 하위 디렉터리를 생성합니다.

    # mkdir /sys/fs/cgroup/cpu/Example/

    이 디렉터리는 특정 프로세스를 배치하고 프로세스에 특정 CPU 제한을 적용할 수 있는 제어 그룹을 나타냅니다. 동시에 여러 cgroups-v1 인터페이스 파일과 cpu 컨트롤러별 파일이 디렉터리에 생성됩니다.

  3. 선택 사항: 새로 생성된 제어 그룹을 검사합니다.

    # ll /sys/fs/cgroup/cpu/Example/
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.clone_children
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.procs
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.stat
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_all
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_sys
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_user
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_sys
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_user
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_period_us
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_quota_us
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_period_us
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_runtime_us
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.shares
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpu.stat
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 notify_on_release
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 tasks

    이 예제 출력은 예제 제어 그룹의 프로세스에 대해 설정할 수 있는 특정 구성 및/또는 제한을 나타내는 cpuacct.usage,cpu.cfs._period_us 와 같은 파일을 보여줍니다. 각 파일 이름 앞에는 자신이 속한 제어 그룹 컨트롤러의 이름이 접두어 있습니다.

    기본적으로 새로 생성된 제어 그룹은 제한 없이 시스템의 전체 CPU 리소스에 대한 액세스를 상속합니다.

  4. 제어 그룹에 대한 CPU 제한을 구성합니다.

    # echo "1000000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us
    # echo "200000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us
    • cpu.cfs_period_us 파일은 CPU 리소스에 대한 제어 그룹의 액세스 권한이 얼마나 자주 할당되어야 하는지에 대해 여기서 "us")로 표시되는 시간(마이크로초) 기간을 나타냅니다. 상한은 1 000 마이크로초이며 더 낮은 제한은 1 000 마이크로초입니다.
    • cpu.cfs_quota_us 파일은 한 기간 동안 모든 프로세스를 전체적으로 실행할 수 있는( cpu.cfs_period_us) 동안 모든 프로세스를 전체적으로 실행할 수 있는 마이크로초의 총 시간을 나타냅니다. 단일 기간 동안 제어 그룹의 프로세스가 할당량에 의해 지정된 모든 시간을 사용하는 경우 나머지 기간 동안 제한되며 다음 기간까지 실행되지 않습니다. 낮은 제한은 1000 마이크로초입니다.

      위의 예제 명령은 예제 제어 그룹의 모든 프로세스가 1초( cpu.cfs_period_us로 정의됨)에서 0.2초 동안만 실행할 수 있도록 CPU 시간 제한을 설정합니다.

  5. 선택 사항: 제한 확인:

    # cat /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us
    1000000
    200000
  6. 애플리케이션의 PID를 Example 제어 그룹에 추가합니다.

    # echo "6955" > /sys/fs/cgroup/cpu/Example/cgroup.procs

    이 명령은 특정 애플리케이션이 Example 제어 그룹의 멤버가 되도록 하여 Example 제어 그룹에 구성된 CPU 제한을 초과하지 않습니다. PID는 시스템의 기존 프로세스를 나타냅니다. 여기서 PID 6955cpu 컨트롤러의 사용 사례를 설명하는 데 사용되는 sha1sum /dev/zero & amp; 를 처리하도록 할당되었습니다.

검증

  1. 애플리케이션이 지정된 제어 그룹에서 실행되는지 확인합니다.

    # cat /proc/6955/cgroup
    12:cpuset:/
    11:hugetlb:/
    10:net_cls,net_prio:/
    9:memory:/user.slice/user-1000.slice/user@1000.service
    8:devices:/user.slice
    7:blkio:/
    6:freezer:/
    5:rdma:/
    4:pids:/user.slice/user-1000.slice/user@1000.service
    3:perf_event:/
    2:cpu,cpuacct:/Example
    1:name=systemd:/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service

    이 예제 출력은 원하는 애플리케이션의 프로세스가 Example 제어 그룹에서 실행되므로 애플리케이션의 프로세스에 CPU 제한을 적용합니다.

  2. throttled 애플리케이션의 현재 CPU 사용량을 확인합니다.

    # top
    top - 12:28:42 up  1:06,  1 user,  load average: 1.02, 1.02, 1.00
    Tasks: 266 total,   6 running, 260 sleeping,   0 stopped,   0 zombie
    %Cpu(s): 11.0 us,  1.2 sy,  0.0 ni, 87.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.2 st
    MiB Mem :   1826.8 total,    287.1 free,   1054.4 used,    485.3 buff/cache
    MiB Swap:   1536.0 total,   1396.7 free,    139.2 used.    608.3 avail Mem
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     6955 root      20   0  228440   1752   1472 R  20.6   0.1  47:11.43 sha1sum
     5760 jdoe      20   0 3604956 208832  65316 R   2.3  11.2   0:43.50 gnome-shell
     6448 jdoe      20   0  743836  31736  19488 S   0.7   1.7   0:08.25 gnome-terminal-
      505 root      20   0       0      0      0 I   0.3   0.0   0:03.39 kworker/u4:4-events_unbound
     4217 root      20   0   74192   1612   1320 S   0.3   0.1   0:01.19 spice-vdagentd
    ...

    PID 6955 의 CPU 사용량이 99 %에서 20%로 감소했습니다.

참고

cpu.cfs_period_uscpu.cfs_quota_uscgroup-v2cpu.max 파일입니다. cpu.max 파일은 cpu 컨트롤러를 통해 사용할 수 있습니다.

추가 리소스

36장. BPF Compiler Collection을 사용하여 시스템 성능 분석

시스템 관리자는 BCC(BPF Compiler Collection) 라이브러리를 사용하여 Linux 운영 체제의 성능을 분석하고 정보를 수집하는 도구를 만들 수 있으며 다른 인터페이스를 통해 가져오기가 어려울 수 있습니다.

36.1. bcc-tools 패키지 설치

BCC(BPF Compiler Collection) 라이브러리도 종속성으로 설치하는 bcc-tools 패키지를 설치합니다.

절차

  1. bcc-tools 를 설치합니다.

    # dnf install bcc-tools

    BCC 툴은 /usr/share/bcc/tools/ 디렉터리에 설치됩니다.

  2. 필요한 경우 툴을 검사합니다.

    # ll /usr/share/bcc/tools/
    ...
    -rwxr-xr-x. 1 root root  4198 Dec 14 17:53 dcsnoop
    -rwxr-xr-x. 1 root root  3931 Dec 14 17:53 dcstat
    -rwxr-xr-x. 1 root root 20040 Dec 14 17:53 deadlock_detector
    -rw-r--r--. 1 root root  7105 Dec 14 17:53 deadlock_detector.c
    drwxr-xr-x. 3 root root  8192 Mar 11 10:28 doc
    -rwxr-xr-x. 1 root root  7588 Dec 14 17:53 execsnoop
    -rwxr-xr-x. 1 root root  6373 Dec 14 17:53 ext4dist
    -rwxr-xr-x. 1 root root 10401 Dec 14 17:53 ext4slower
    ...

    위의 목록에 있는 doc 디렉토리에는 각 툴에 대한 문서가 포함되어 있습니다.

36.2. 성능 분석에 선택된 bcc-tools 사용

BPF Compiler Collection(BCC) 라이브러리의 사전 생성된 특정 프로그램을 사용하여 이벤트별로 시스템 성능을 효율적이고 안전하게 분석합니다. BCC 라이브러리에서 미리 생성된 프로그램 세트는 추가 프로그램 생성의 예 역할을 할 수 있습니다.

사전 요구 사항

execsnoop를 사용하여 시스템 프로세스 검사

  1. 하나의 터미널에서 execsnoop 프로그램을 실행합니다.

    # /usr/share/bcc/tools/execsnoop
  2. 다른 터미널에서 다음을 실행합니다. 예를 들면 다음과 같습니다.

    $ ls /usr/share/bcc/tools/doc/

    위 명령은 ls 명령의 수명이 짧은 프로세스를 생성합니다.

  3. execsnoop 를 실행하는 터미널은 다음과 유사한 출력을 보여줍니다.

    PCOMM	PID    PPID   RET ARGS
    ls   	8382   8287     0 /usr/bin/ls --color=auto /usr/share/bcc/tools/doc/
    ...

    execsnoop 프로그램은 시스템 리소스를 사용하는 새 프로세스마다 출력의 행을 출력합니다. ls 와 같이 매우 빠르게 실행되는 프로그램 프로세스도 감지하며 대부분의 모니터링 툴은 등록하지 않습니다.

    execsnoop 출력에는 다음 필드가 표시됩니다.

    PCOMM
    상위 프로세스 이름입니다. (ls)
    PID
    프로세스 ID입니다. (8382)
    PPID
    상위 프로세스 ID입니다. (8287)
    RET
    프로그램 코드를 새 프로세스로 로드하는 exec() 시스템 호출(0)의 반환 값입니다.
    ARGS
    시작된 프로그램의 인수와 관련된 위치입니다.

execsnoop 에 대한 자세한 정보, 예제 및 옵션을 보려면 /usr/share/bcc/tools/doc/execsnoop_example.txt 파일을 참조하십시오.

exec() 에 대한 자세한 내용은 exec(3) 매뉴얼 페이지를 참조하십시오.

opennoop를 사용하여 명령에서 열리는 파일을 추적할 수 있습니다.

  1. 하나의 터미널에서 opensnoop 프로그램을 실행합니다.

    # /usr/share/bcc/tools/opensnoop -n uname

    위의 명령은 uname 명령 프로세스에서만 여는 파일의 출력을 출력합니다.

  2. 다른 터미널에서 다음을 입력합니다.

    $ uname

    위의 명령은 특정 파일을 열고 다음 단계에서 캡처됩니다.

  3. 실행 중인 터미널 은 다음과 유사한 출력을 보여줍니다.

    PID    COMM 	FD ERR PATH
    8596   uname 	3  0   /etc/ld.so.cache
    8596   uname 	3  0   /lib64/libc.so.6
    8596   uname 	3  0   /usr/lib/locale/locale-archive
    ...

    opensnoop 프로그램은 전체 시스템에서 open() 시스템 호출을 감시하고 uname 이 방식을 따라 열려고 시도하는 각 파일의 출력 라인을 출력합니다.

    opensnoop 출력에는 다음 필드가 표시됩니다.

    PID
    프로세스 ID입니다. (8596)
    COMM
    프로세스 이름입니다. (uname)
    FD
    파일 설명자 - open() 이 열려 있는 파일을 참조하기 위해 반환하는 값입니다. (3)
    ERR
    모든 오류.
    PATH
    open() 가 열려는 파일의 위치입니다.

    명령이 존재하지 않는 파일을 읽으려고 하면 FD 열은 -1 을 반환하고 ERR 열에는 관련 오류에 해당하는 값이 출력됩니다. 따라서 opensnoop 는 제대로 작동하지 않는 애플리케이션을 식별하는 데 도움이 될 수 있습니다.

opensnoop 에 대한 자세한 정보, 예제 및 옵션을 보려면 /usr/share/bcc/tools/doc/opensnoop_example.txt 파일을 참조하십시오.

open() 에 대한 자세한 내용은 open(2) 매뉴얼 페이지를 참조하십시오.

BIOStop를 사용하여 디스크의 I/O 작업 검사

  1. 하나의 터미널에서 BIOS 프로그램을 실행합니다.

    # /usr/share/bcc/tools/biotop 30

    명령을 사용하면 디스크에서 I/O 작업을 수행하는 최상위 프로세스를 모니터링할 수 있습니다. 인수를 사용하면 명령이 30초 요약을 생성합니다.

    참고

    인수를 제공하지 않으면 기본적으로 출력 화면이 1초마다 새로 고쳐집니다.

  2. 다른 터미널에서 다음을 입력합니다. 예를 들면 다음과 같습니다.

    # dd if=/dev/vda of=/dev/zero

    위의 명령은 로컬 하드 디스크 장치에서 콘텐츠를 읽고 출력을 /dev/zero 파일에 씁니다. 이 단계는 BIOS 를 설명하기 위해 특정 I/O 트래픽을 생성합니다.

  3. biotop 실행 중인 터미널은 다음과 유사한 출력을 보여줍니다.

    PID    COMM             D MAJ MIN DISK       I/O  Kbytes     AVGms
    9568   dd               R 252 0   vda      16294 14440636.0  3.69
    48     kswapd0          W 252 0   vda       1763 120696.0    1.65
    7571   gnome-shell      R 252 0   vda        834 83612.0     0.33
    1891   gnome-shell      R 252 0   vda       1379 19792.0     0.15
    7515   Xorg             R 252 0   vda        280  9940.0     0.28
    7579   llvmpipe-1       R 252 0   vda        228  6928.0     0.19
    9515   gnome-control-c  R 252 0   vda         62  6444.0     0.43
    8112   gnome-terminal-  R 252 0   vda         67  2572.0     1.54
    7807   gnome-software   R 252 0   vda         31  2336.0     0.73
    9578   awk              R 252 0   vda         17  2228.0     0.66
    7578   llvmpipe-0       R 252 0   vda        156  2204.0     0.07
    9581   pgrep            R 252 0   vda         58  1748.0     0.42
    7531   InputThread      R 252 0   vda         30  1200.0     0.48
    7504   gdbus            R 252 0   vda          3  1164.0     0.30
    1983   llvmpipe-1       R 252 0   vda         39   724.0     0.08
    1982   llvmpipe-0       R 252 0   vda         36   652.0     0.06
    ...

    biotop 출력에는 다음 필드가 표시됩니다.

    PID
    프로세스 ID입니다. (9568)
    COMM
    프로세스 이름입니다. (dd)
    DISK
    읽기 작업을 수행하는 디스크입니다. (vda)
    I/O
    수행된 읽기 작업 수입니다. (16294)
    kbytes
    읽기 작업에서 도달한 K바이트 수입니다. (14,440,636)
    AVGms
    평균 읽기 작업의 I/O 시간입니다. (3.69)

biotop 에 대한 자세한 정보, 예제 및 옵션을 보려면 /usr/share/bcc/tools/doc/biotop_example.txt 파일을 참조하십시오.

dd 에 대한 자세한 내용은 dd(1) 매뉴얼 페이지를 참조하십시오.

xfsslower를 사용하여 예기치 않게 느린 파일 시스템 작업 노출

  1. 하나의 터미널에서 xfsslower 프로그램을 실행합니다.

    # /usr/share/bcc/tools/xfsslower 1

    위의 명령은 XFS 파일 시스템이 읽기, 쓰기, 열기 또는 동기화(fsync) 작업을 수행하는 데 사용하는 시간을 측정합니다. 1 인수는 프로그램이 1ms보다 느린 작업만 표시하도록 합니다.

    참고

    인수가 제공되지 않으면 xfsslower 는 기본적으로 10ms보다 느린 작업을 표시합니다.

  2. 다른 터미널에서 다음을 입력합니다.

    $ vim text

    위의 명령은 ovs 편집기에 텍스트 파일을 생성하여 XFS 파일 시스템과의 특정 상호 작용을 시작합니다.

  3. xfsslower 를 실행하는 터미널은 이전 단계에서 파일을 저장할 때 유사한 것을 보여줍니다.

    TIME     COMM           PID    T BYTES   OFF_KB   LAT(ms) FILENAME
    13:07:14 b'bash'        4754   R 256     0           7.11 b'vim'
    13:07:14 b'vim'         4754   R 832     0           4.03 b'libgpm.so.2.1.0'
    13:07:14 b'vim'         4754   R 32      20          1.04 b'libgpm.so.2.1.0'
    13:07:14 b'vim'         4754   R 1982    0           2.30 b'vimrc'
    13:07:14 b'vim'         4754   R 1393    0           2.52 b'getscriptPlugin.vim'
    13:07:45 b'vim'         4754   S 0       0           6.71 b'text'
    13:07:45 b'pool'        2588   R 16      0           5.58 b'text'
    ...

    위의 각 줄은 파일 시스템에서 작업을 나타내며 특정 임계값보다 더 많은 시간이 걸렸습니다. xfsslower 는 예기치 않은 느린 작업을 수행할 수 있는 파일 시스템 문제를 노출하는 데 유용합니다.

    xfsslower 출력에는 다음 필드가 표시됩니다.

    COMM
    프로세스 이름입니다. (b'bash')
    T

    작업 유형입니다. (R)

    • Read
    • Write
    • Sync
    OFF_KB
    KB의 파일 오프셋입니다. (0)
    파일 이름
    읽기, 쓰기 또는 동기화되는 파일입니다.

xfsslower 에 대한 세부 정보, 예제 및 옵션을 보려면 /usr/share/bcc/tools/doc/xfsslower_example.txt 파일을 참조하십시오.

fsync 에 대한 자세한 내용은 fsync(2) 매뉴얼 페이지를 참조하십시오.

37장. 메모리 액세스를 최적화하도록 운영 체제 구성

RHEL에 포함된 툴을 사용하여 워크로드 전체에서 메모리 액세스를 최적화하도록 운영 체제를 구성할 수 있습니다.

37.1. 시스템 메모리 문제 모니터링 및 진단 툴

시스템 성능을 모니터링하고 시스템 메모리와 관련된 성능 문제를 진단하기 위해 Red Hat Enterprise Linux 9에서 다음 툴을 사용할 수 있습니다.

  • procps-ng 패키지에서 제공하는 vmstat 툴은 시스템 프로세스, 메모리, 페이징, 블록 I/O, 트랩, 디스크 및 CPU 활동에 대한 보고서를 표시합니다. 머신이 마지막으로 켜졌거나 이전 보고서 이후 이러한 이벤트의 평균에 대한 즉각적인 보고서를 제공합니다.
  • Valgrind 프레임워크는 사용자 공간 바이너리에 계측을 제공합니다. dnf install valgrind 명령을 사용하여 이 툴을 설치합니다. 여기에는 다음과 같은 프로그램 성능을 프로파일링하고 분석하는 데 사용할 수 있는 여러 도구가 포함되어 있습니다.

    • Memcheck 옵션은 기본 valgrind 툴입니다. 다음과 같이 탐지하고 진단하기 어려울 수 있는 여러 메모리 오류를 감지하고 보고합니다.

      • 발생하지 않아야 하는 메모리 액세스
      • 정의되지 않았거나 초기화되지 않은 값 사용
      • 힙 메모리가 잘못 해제되었습니다.
      • 포인터 중복
      • 메모리 누수

        참고

        Memcheck는 이러한 오류만 보고할 수 있으며 이러한 오류가 발생하지 않도록 방지할 수 없습니다. 그러나 memcheck 는 오류가 발생하기 직전에 오류 메시지를 기록합니다.

    • cachegrind 옵션은 시스템의 캐시 계층 및 분기 예측자와 애플리케이션 상호 작용을 시뮬레이션합니다. 애플리케이션 실행 기간에 대한 통계를 수집하고 콘솔에 요약을 출력합니다.
    • 이 옵션은 지정된 애플리케이션에서 사용하는 힙 공간을 측정합니다. 이 명령은 하우스키핑 및 정렬 목적으로 할당된 추가 공간과 유용한 공간을 모두 측정합니다.

추가 리소스

  • vmstat(8)valgrind(1) 매뉴얼 페이지
  • /usr/share/doc/valgrind-version/valgrind_ECDHE.pdf 파일

37.2. 시스템의 메모리 개요

Linux 커널은 시스템의 메모리 리소스(RAM)의 활용도를 극대화하도록 설계되었습니다. 이러한 설계 특성으로 인해 워크로드의 메모리 요구 사항에 따라 시스템 메모리의 일부가 워크로드를 대신하여 커널 내에서 사용되고 메모리의 일부는 사용 가능합니다. 이 여유 메모리는 특수 시스템 할당 및 낮은 우선 순위 또는 높은 우선 순위의 시스템 서비스를 위해 예약되어 있습니다.

나머지 시스템 메모리는 워크로드 자체 전용이며 다음 두 가지 범주로 나뉩니다.

파일 메모리

이 카테고리에 추가된 페이지는 영구 스토리지의 파일 부분을 나타냅니다. 페이지 캐시의 이러한 페이지는 애플리케이션의 주소 공간에 매핑하거나 매핑 해제할 수 있습니다. 애플리케이션을 사용하여 mmap 시스템 호출을 사용하여 파일을 주소 공간에 매핑하거나 버퍼링된 I/O 읽기 또는 쓰기 시스템 호출을 통해 파일에서 작업할 수 있습니다.

버퍼링된 I/O 시스템 호출과 페이지를 직접 매핑하는 애플리케이션도 매핑되지 않은 페이지를 다시 사용할 수 있습니다. 결과적으로 이러한 페이지는 특히 시스템이 메모리 집약적 작업을 실행하지 않는 경우 동일한 페이지 세트에서 과도한 I/O 작업을 다시 실행하지 않도록 커널에 의해 캐시에 저장됩니다.

익명 메모리
이 카테고리의 페이지는 동적으로 할당된 프로세스에 의해 사용되거나 영구 스토리지의 파일과 관련이 없습니다. 이 페이지 세트는 각 작업의 메모리 내 제어 구조를 백업합니다(예: 애플리케이션 스택 및 힙 영역).

그림 37.1. 메모리 사용 패턴

RHEL 메모리 사용량 패턴

37.3. 가상 메모리 매개변수

가상 메모리 매개변수는 /proc/sys/vm 디렉터리에 나열됩니다.

다음은 사용 가능한 가상 메모리 매개변수입니다.

vm.dirty_ratio
백분율 값입니다. 전체 시스템 메모리의 이 백분율이 수정되면 시스템은 pdflush 작업으로 디스크에 수정 사항을 쓰기 시작합니다. 기본값은 20% 입니다.
vm.dirty_background_ratio
백분율 값입니다. 전체 시스템 메모리의 이 백분율이 수정되면 시스템은 수정 사항을 백그라운드에서 디스크에 쓰기 시작합니다. 기본값은 10 %입니다.
vm.overcommit_memory

큰 메모리 요청이 허용되거나 거부되는지 여부를 결정하는 조건을 정의합니다. 기본값은 0 입니다.

기본적으로 커널은 가상 메모리 할당 요청이 현재 메모리 양(total + 스왑)에 맞는지 확인하고 대규모 요청만 거부합니다. 그렇지 않으면 가상 메모리 할당이 부여되며 이는 메모리 과다 할당을 허용합니다.

overcommit_memory 매개변수 값을 설정합니다.

  • 이 매개변수를 1 로 설정하면 커널은 메모리 과다 할당 처리를 수행하지 않습니다. 이렇게 하면 메모리 과부하가 증가하지만 메모리 집약적 작업의 성능이 향상됩니다.
  • 이 매개변수를 2 로 설정하면 커널은 사용 가능한 총 스왑 공간의 합계와 동일한 메모리 요청 및 overcommit_ratio 에 지정된 물리적 RAM의 백분율보다 큽니다. 이렇게 하면 메모리를 과다 할당할 위험이 줄어들지만 실제 메모리보다 큰 스왑 영역이 있는 시스템에만 권장됩니다.
vm.overcommit_ratio
overcommit_memory2 로 설정된 경우 고려되는 물리적 RAM의 백분율을 지정합니다. 기본값은 50 입니다.
vm.max_map_count
프로세스에서 사용할 수 있는 최대 메모리 맵 영역 수를 정의합니다. 기본값은 65530 입니다. 애플리케이션에 더 많은 메모리 맵 영역이 필요한 경우 이 값을 늘립니다.
vm.min_free_kbytes

사용 가능한 페이지 풀의 크기를 설정합니다. 또한 Linux 커널의 페이지 회수 알고리즘의 동작을 제어하는 min_page,low_page, high_page 임계값을 설정해야 합니다. 또한 시스템에서 무료로 사용할 수 있도록 최소 킬로바이트 수를 지정합니다. 이렇게 하면 낮은 각 메모리 영역에 대한 특정 값을 계산하며, 각 영역에는 크기에 비례하여 예약된 여러 페이지가 할당됩니다.

vm.min_free_kbytes 매개변수 값을 설정합니다.

  • 매개 변수 값을 늘리면 사용 가능한 메모리가 애플리케이션 작업 세트를 효과적으로 줄일 수 있습니다. 따라서 드라이버 버퍼를 원자성 컨텍스트에서 할당해야 하는 커널 중심 워크로드에만 사용할 수 있습니다.
  • 매개 변수 값을 줄이면 메모리가 시스템에서 많이 조정되는 경우 커널에서 시스템 요청을 처리할 수 없게 될 수 있습니다.

    주의

    극단적인 값은 시스템 성능에 영향을 미칠 수 있습니다. vm.min_free_kbytes 를 매우 낮은 값으로 설정하면 시스템이 메모리를 효과적으로 회수하지 못하여 시스템 충돌이 발생하고 인터럽트 또는 기타 커널 서비스를 서비스하지 못할 수 있습니다. 그러나 vm.min_free_kbytes 를 너무 높게 설정하면 시스템 회수 작업이 증가하여 직접 회수 상태가 false로 인한 할당 대기 시간이 발생합니다. 이로 인해 시스템이 메모리 부족 상태가 될 수 있습니다.

    vm.min_free_kbytes 매개변수는 min_pages 라는 페이지 회수 워터마크도 설정합니다. 이 워터마크는 페이지 회수 알고리즘을 관리하는 두 개의 다른 메모리 워터마크, low_pages, high_pages 를 결정할 때 요인으로 사용됩니다.

/proc/PID/oom_adj

시스템이 메모리가 부족하고 panic_on_oom 매개 변수가 0 으로 설정된 경우 oom_killer 함수가 시스템이 복구될 때까지 oom_score 가 가장 높은 프로세스부터 프로세스를 종료합니다.

oom_adj 매개변수는 프로세스의 oom_score 를 결정합니다. 이 매개변수는 프로세스 식별자별로 설정됩니다. -17 값은 해당 프로세스에 대한 oom_killer 를 비활성화합니다. 기타 유효한 값의 범위는 -16 에서 15 사이입니다.

참고

조정된 프로세스에서 생성한 프로세스는 해당 프로세스의 oom_score 를 상속합니다.

vm.swappiness

swappiness 값은 0 에서 200 사이이며 시스템이 익명 메모리 풀 또는 페이지 캐시 메모리 풀에서 메모리를 회수하는 정도를 제어합니다.

swappiness 매개변수 값을 설정합니다.

  • 값이 높으면 파일 매핑된 워크로드가 선호되고 덜 적극적으로 액세스되는 프로세스의 RAM에 매핑되지 않는 메모리를 교체합니다. 이는 스토리지의 파일에서 서비스 요청에 대한 I/O 대기 시간을 줄이기 위해 메모리에 상주하는 파일 서버 또는 스트리밍 애플리케이션에 유용합니다.
  • 낮은 값은 페이지 캐시(파일 매핑된 메모리)를 회수하는 동안 익명 매핑 기반 워크로드를 선호합니다. 이 설정은 파일 시스템 정보에 크게 의존하지 않는 애플리케이션에 유용하며, 지현성 및 숫자 분쇄 애플리케이션, QEMU와 같은 하드웨어 가상화 관리자 등 동적으로 할당된 개인 메모리와 개인 메모리를 많이 활용합니다.

    vm.swappiness 매개변수의 기본값은 60 입니다.

    주의

    vm.swappiness0 으로 설정하면 익명 메모리를 디스크로 스왑하지 않도록 적극적으로, 메모리 또는 I/O 집약적 워크로드에서 oom_killer 기능에 의해 프로세스가 종료될 위험이 높아집니다.

추가 리소스

37.4. 파일 시스템 매개변수

파일 시스템 매개변수는 /proc/sys/fs 디렉터리에 나열됩니다. 다음은 사용 가능한 파일 시스템 매개변수입니다.

aio-max-nr
모든 활성 비동기 입력/출력 컨텍스트에서 허용되는 최대 이벤트 수를 정의합니다. 기본값은 65536 이며 이 값을 수정해도 커널 데이터 구조를 사전 할당하거나 조정하지 않습니다.
file-max

전체 시스템에 대한 최대 파일 처리 수를 결정합니다. Red Hat Enterprise Linux 9의 기본값은 커널이 시작될 때 사용 가능한 메모리 페이지 중 8192 또는 10분의 1입니다.

이 값을 늘리면 사용 가능한 파일 처리 부족으로 인한 오류를 해결할 수 있습니다.

추가 리소스

  • sysctl(8) 도움말 페이지

37.5. 커널 매개변수

커널 매개 변수의 기본값은 /proc/sys/kernel/ 디렉터리에 있습니다. 이는 커널에서 제공하는 기본값 또는 sysctl 을 통해 사용자가 지정한 값입니다.

다음은 msg*shm* System V IPC(sysvipc) 시스템 호출에 대한 제한을 설정하는 데 사용되는 사용 가능한 커널 매개변수입니다.

msgmax
메시지 큐에서 단일 메시지의 최대 허용된 크기(바이트)를 정의합니다. 이 값은 큐 크기(msgmnb)를 초과해서는 안 됩니다. sysctl msgmax 명령을 사용하여 시스템의 현재 msgmax 값을 확인합니다.
msgmnb
단일 메시지 큐의 최대 크기(바이트)를 정의합니다. sysctl msgmnb 명령을 사용하여 시스템에서 현재 msgmnb 값을 확인합니다.
msgmni
최대 메시지 큐 식별자 수를 정의하므로 최대 대기열 수를 정의합니다. sysctl msgmni 명령을 사용하여 시스템에서 현재 msgmni 값을 확인합니다.
shmall
시스템에서 동시에 사용할 수 있는 공유 메모리 페이지의 총 양을 정의합니다. 예를 들어, 페이지는 AMD64 및 Intel 64 아키텍처의 4096 바이트입니다. sysctl shmall 명령을 사용하여 시스템의 현재 shmall 값을 확인합니다.
shmmax
커널에서 허용하는 단일 공유 메모리 세그먼트의 최대 크기(바이트)를 정의합니다. 이제 최대 1Gb의 공유 메모리 세그먼트가 커널에서 지원됩니다. sysctl shmmax 명령을 사용하여 시스템의 현재 shmmax 값을 확인합니다.
shmmni
시스템 전체 공유 메모리 세그먼트 수를 정의합니다. 기본값은 모든 시스템에서 4096 입니다.

추가 리소스

  • sysvipc(7)sysctl(8) 도움말 페이지

38장. 대규모 페이지 구성

물리적 메모리는 페이지라는 고정된 크기 청크로 관리됩니다. Red Hat Enterprise Linux 9에서 지원하는 x86_64 아키텍처에서 메모리 페이지의 기본 크기는 4KB 입니다. 이 기본 페이지 크기는 다양한 종류의 워크로드를 지원하는 Red Hat Enterprise Linux와 같은 범용 운영 체제에 적합한 것으로 입증되었습니다.

그러나 특정 애플리케이션에서는 특정 경우에 더 큰 페이지 크기를 사용할 때 이점을 얻을 수 있습니다. 예를 들어 수백 메가바이트 또는 수십 기가 바이트로 구성된 대규모 및 비교적 수정된 대규모 데이터 세트에서 작동하는 애플리케이션은 4KB 페이지를 사용할 때 성능 문제가 발생할 수 있습니다. 이러한 데이터 세트에는 많은 양의 4KB 페이지가 필요할 수 있으므로 운영 체제 및 CPU에 오버헤드가 발생할 수 있습니다.

이 섹션에서는 RHEL 9에서 사용할 수 있는 대규모 페이지 및 구성 방법에 대해 설명합니다.

38.1. 사용 가능한 대규모 페이지 기능

Red Hat Enterprise Linux 9를 사용하면 큰 데이터 세트와 함께 작동하는 애플리케이션에 대규모 페이지를 사용하고 이러한 애플리케이션의 성능을 개선할 수 있습니다.

다음은 RHEL 9에서 지원되는 대규모 페이지 방법입니다.

HugeTLB 페이지

HugeTLB 페이지는 정적 대규모 페이지라고도 합니다. HugeTLB 페이지를 예약하는 방법은 다음 두 가지가 있습니다.

  • 부팅 시: 메모리가 아직 크게 조각화되지 않았기 때문에 성공할 가능성이 높아집니다. 그러나 NUMA 시스템에서 페이지 수는 NUMA 노드 간에 자동으로 분할됩니다.

부팅 시 HugeTLB 페이지 동작에 영향을 미치는 매개변수에 대한 자세한 내용은 부팅 시 HugeTLB 페이지를 예약하는 방법 및 이러한 매개변수를 사용하여 부팅 시 HugeTLB 페이지를 구성하는 방법을 참조하십시오.

  • 런타임 시: NUMA 노드당 대규모 페이지를 예약할 수 있습니다. 부팅 프로세스에서 런타임 예약이 가능한 한 빨리 수행되면 메모리 조각화 가능성이 낮습니다.

런타임에 HugeTLB 페이지 동작에 영향을 미치는 매개변수에 대한 자세한 내용은 런타임에 HugeTLB 페이지를 예약하는 매개 변수 및 이러한 매개변수를 사용하여 런타임에 HugeTLB 페이지를 구성하는 방법을 참조하십시오.

THP(Transparent HugePages)

THP를 사용하면 커널이 프로세스에 대규모 페이지를 자동으로 할당하므로 정적 대규모 페이지를 수동으로 예약할 필요가 없습니다. 다음은 THP의 두 가지 작업 모드입니다.

  • 시스템 전체: 여기에서 커널은 대규모 페이지를 할당할 수 있을 때마다 프로세스에 대규모 페이지를 할당하려고 하며 프로세스는 많은 연속 가상 메모리 영역을 사용합니다.
  • 프로세스별: 여기에서 커널은 madvise() 시스템 호출을 사용하여 지정할 수 있는 개별 프로세스의 메모리 영역에만 대규모 페이지를 할당합니다.

    참고

    THP 기능은 2MB 페이지만 지원합니다.

부팅 시 HugeTLB 페이지 동작에 영향을 미치는 매개변수에 대한 자세한 내용은 투명한 hugepage 활성화 및 투명한 hugepages 비활성화를 참조하십시오.

38.2. 부팅 시 HugeTLB 페이지 예약 매개 변수

다음 매개변수를 사용하여 부팅 시 HugeTLB 페이지 동작에 영향을 미칩니다.

부팅 시 이러한 매개변수를 사용하여 HugeTLB 페이지를 구성하는 방법에 대한 자세한 내용은 부팅 시 HugeTLB 구성을 참조하십시오.

표 38.1. 부팅 시 HugeTLB 페이지를 구성하는 데 사용되는 매개변수

매개변수설명기본값

hugepages

부팅 시 커널에 구성된 영구 대규모 페이지 수를 정의합니다.

NUMA 시스템에서 이 매개변수가 정의된 대규모 페이지는 노드 간에 동일하게 나뉩니다.

/sys/devices/system/node/node_id/hugepages/hugepages/nr_hugepages 파일의 노드 값을 변경하여 런타임에 대규모 페이지를 할당할 수 있습니다.

기본값은 0입니다.

부팅 시 이 값을 업데이트하려면 /proc/sys/vm/nr_hugepages 파일에서 이 매개변수 값을 변경합니다.

hugepagesz

부팅 시 커널에 구성된 영구 대규모 페이지의 크기를 정의합니다.

유효한 값은 2MB1GB 입니다. 기본값은 2MB 입니다.

default_hugepagesz

부팅 시 커널에 구성된 영구 대규모 페이지의 기본 크기를 정의합니다.

유효한 값은 2MB1GB 입니다. 기본값은 2MB 입니다.

38.3. 부팅 시 HugeTLB 구성

HugeTLB 하위 시스템이 지원하는 페이지 크기는 아키텍처에 따라 다릅니다. x86_64 아키텍처는 2MB 의 대규모 페이지 및 1GB gigantic 페이지를 지원합니다.

다음 절차에서는 부팅 시 1GB 페이지를 예약하는 방법을 설명합니다.

절차

  1. 1GB 페이지에 HugeTLB 풀을 생성하려면 default_hugepagesz=1Ghugepagesz=1G 커널 옵션을 활성화합니다.

    # grubby --update-kernel=ALL --args="default_hugepagesz=1G hugepagesz=1G"
  2. /usr/lib/systemd/system/ 디렉터리에 hugetlb-gigantic-pages.service 라는 새 파일을 생성하고 다음 콘텐츠를 추가합니다.

    [Unit]
    Description=HugeTLB Gigantic Pages Reservation
    DefaultDependencies=no
    Before=dev-hugepages.mount
    ConditionPathExists=/sys/devices/system/node
    ConditionKernelCommandLine=hugepagesz=1G
    
    [Service]
    Type=oneshot
    RemainAfterExit=yes
    ExecStart=/usr/lib/systemd/hugetlb-reserve-pages.sh
    
    [Install]
    WantedBy=sysinit.target
  3. /usr/lib/systemd/ 디렉터리에 hugetlb-reserve-pages.sh 라는 새 파일을 생성하고 다음 콘텐츠를 추가합니다.

    다음 콘텐츠를 추가하는 동안 number_of_pages 를 예약하려는 1GB 페이지 수로 바꾸고 node 를 해당 페이지를 예약할 노드의 이름으로 바꿉니다.

    #!/bin/sh
    
    nodes_path=/sys/devices/system/node/
    if [ ! -d $nodes_path ]; then
        echo "ERROR: $nodes_path does not exist"
        exit 1
    fi
    
    reserve_pages()
    {
        echo $1 > $nodes_path/$2/hugepages/hugepages-1048576kB/nr_hugepages
    }
    
    reserve_pages number_of_pages node

    예를 들어 node1 에서 node0 1GB 페이지에 두 개의 1GB 페이지를 예약하려면 node0의 경우 number_of_pages 를 2로, node1 의 경우 1로 바꿉니다.

    reserve_pages 2 node0
    reserve_pages 1 node1
  4. 실행 가능한 스크립트를 생성합니다.

    # chmod +x /usr/lib/systemd/hugetlb-reserve-pages.sh
  5. 초기 부팅 예약을 활성화합니다.

    # systemctl enable hugetlb-gigantic-pages
참고
  • 언제든지 nr_hugepages 에 작성하여 런타임 시 더 많은 1GB 페이지를 예약할 수 있습니다. 그러나 메모리 조각화로 인한 실패를 방지하려면 부팅 프로세스 중에 초기에 1GB 페이지를 예약하십시오.
  • 정적 대규모 페이지를 예약하면 시스템에서 사용할 수 있는 메모리 양을 효과적으로 줄일 수 있으며 전체 메모리 용량을 제대로 사용하지 못하게 합니다. 예약된 대규모 페이지 풀은 적절하게 크기가 지정된 대규모 페이지를 활용하는 애플리케이션에 유용할 수 있지만, 결국 전체 시스템 성능에 부정적인 영향을 미칠 수 있습니다. 예약된 대규모 페이지 풀을 설정할 때 시스템이 전체 메모리 용량을 올바르게 활용할 수 있는지 확인합니다.

추가 리소스

  • systemd.service(5) man page
  • /usr/share/doc/kernel-doc-kernel_version/Documentation/vm/hugetlbpage.txt file

38.4. 런타임에 HugeTLB 페이지 예약 매개 변수

다음 매개변수를 사용하여 런타임 시 HugeTLB 페이지 동작에 영향을 미칩니다.

런타임 시 이러한 매개변수를 사용하여 HugeTLB 페이지를 구성하는 방법에 대한 자세한 내용은 런타임 시 HugeTLB 구성을 참조하십시오.

표 38.2. 런타임에 HugeTLB 페이지를 구성하는 데 사용되는 매개변수

매개변수설명파일 이름

nr_hugepages

지정된 NUMA 노드에 할당된 지정된 크기의 대규모 페이지 수를 정의합니다.

/sys/devices/system/node/node_id/hugepages/hugepages-size/nr_hugepages

nr_overcommit_hugepages

메모리 과다 할당을 통해 시스템에서 생성하고 사용할 수 있는 최대 대규모 페이지 수를 정의합니다.

이 파일에 0이 아닌 값을 작성하면 영구적인 대규모 페이지 풀이 소진되면 시스템이 커널의 일반 페이지 풀에서 대규모 페이지 수를 얻을 수 있음을 나타냅니다. 이 서한 대규모 페이지가 사용되지 않으면 해제되고 커널의 일반 페이지 풀로 돌아갑니다.

/proc/sys/vm/nr_overcommit_hugepages

38.5. 런타임에 HugeTLB 구성

다음 절차에서는 node220 2048 kB 대규모 페이지를 추가하는 방법을 설명합니다.

요구 사항에 따라 페이지를 예약하려면 교체합니다.

  • 20 예약하려는 대규모 페이지 수와 함께,
  • 2048KB 의 크기가 큰 페이지
  • 페이지를 예약하려는 노드가 있는 node2 입니다.

절차

  1. 메모리 통계를 표시합니다.

    # numastat -cm | egrep 'Node|Huge'
                     Node 0 Node 1 Node 2 Node 3  Total add
    AnonHugePages         0      2      0      8     10
    HugePages_Total       0      0      0      0      0
    HugePages_Free        0      0      0      0      0
    HugePages_Surp        0      0      0      0      0
  2. 지정된 크기의 대규모 페이지 수를 노드에 추가합니다.

    # echo 20 > /sys/devices/system/node/node2/hugepages/hugepages-2048kB/nr_hugepages

검증 단계

  • 대규모 페이지 수가 추가되었는지 확인합니다.

    # numastat -cm | egrep 'Node|Huge'
                     Node 0 Node 1 Node 2 Node 3  Total
    AnonHugePages         0      2      0      8     10
    HugePages_Total       0      0     40      0     40
    HugePages_Free        0      0     40      0     40
    HugePages_Surp        0      0      0      0      0

추가 리소스

  • numastat(8) 도움말 페이지

38.6. 투명한 hugepages 활성화

THP는 Red Hat Enterprise Linux 9에서 기본적으로 활성화되어 있습니다. 그러나 THP를 활성화하거나 비활성화할 수 있습니다.

다음 절차에서는 THP를 활성화하는 방법을 설명합니다.

절차

  1. THP의 현재 상태를 확인합니다.

    # cat /sys/kernel/mm/transparent_hugepage/enabled
  2. THP를 활성화합니다.

    # echo always > /sys/kernel/mm/transparent_hugepage/enabled
  3. 애플리케이션이 필요한 것보다 많은 메모리 리소스를 할당하지 못하도록 하려면 시스템 전체의 투명한 대규모 페이지를 비활성화하고 madvise 를 통해 명시적으로 요청하는 애플리케이션에 대해서만 활성화합니다.

    # echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
참고

경우에 따라 수명이 짧은 할당에 짧은 대기 시간을 제공하는 것이 수명이 긴 할당을 통해 최상의 성능을 달성하는 것보다 우선 순위가 높습니다. 이러한 경우 THP를 활성화한 상태로 두는 동안 직접 압축 기능을 비활성화할 수 있습니다.

직접 압축은 대규모 페이지 할당 중에 동기식 메모리 압축입니다. 직접 압축 기능을 비활성화하면 메모리 저장이 보장되지 않지만 자주 페이지 오류 발생 시 대기 시간이 증가할 위험이 증가할 수 있습니다. THP에서 워크로드가 상당한 이점을 얻을 경우 성능이 저하됩니다. 직접 압축 비활성화:

# echo madvise > /sys/kernel/mm/transparent_hugepage/defrag

추가 리소스

38.7. 투명한 hugepages 비활성화

THP는 Red Hat Enterprise Linux 9에서 기본적으로 활성화되어 있습니다. 그러나 THP를 활성화하거나 비활성화할 수 있습니다.

다음 절차에서는 THP를 비활성화하는 방법을 설명합니다.

절차

  1. THP의 현재 상태를 확인합니다.

    # cat /sys/kernel/mm/transparent_hugepage/enabled
  2. THP를 비활성화합니다.

    # echo never > /sys/kernel/mm/transparent_hugepage/enabled

38.8. 번역 조회 버퍼 크기에 대한 페이지 크기에 미치는 영향

페이지 테이블의 주소 매핑을 읽는 것은 시간이 오래 걸리므로 TLB(Transform Lookaside Buffer)라는 최근에 사용된 주소에 대한 캐시로 CPU가 빌드됩니다. 그러나 기본 TLB는 특정 수의 주소 매핑만 캐시할 수 있습니다.

요청된 주소 매핑이 TLB 누락이라는 TLB에 없는 경우 시스템은 여전히 페이지 테이블을 읽고 물리적 주소 매핑을 결정해야 합니다. 애플리케이션 메모리 요구 사항과 주소 매핑을 캐시하는 데 사용되는 페이지 크기 간의 관계로 인해 메모리 요구 사항이 큰 애플리케이션이 최소 메모리 요구 사항이 있는 애플리케이션보다 TLB에서 성능이 저하될 가능성이 높습니다. 따라서 가능한 경우 TLB 누락을 방지하는 것이 중요합니다.

HugeTLB 및 Transparent Huge Page 기능을 모두 사용하면 애플리케이션이 4KB 보다 큰 페이지를 사용할 수 있습니다. 이를 통해 TLB에 저장된 주소가 더 많은 메모리를 참조할 수 있으므로 TLB 누락이 줄어들고 애플리케이션 성능이 향상됩니다.

39장. SystemTap 시작하기

시스템 관리자는 SystemTap을 사용하여 실행 중인 Linux 시스템에서 버그 또는 성능 문제의 근본적인 원인을 확인할 수 있습니다.

애플리케이션 개발자는 SystemTap을 사용하여 Linux 시스템 내에서 애플리케이션이 작동하는 방식을 자세히 모니터링할 수 있습니다.

39.1. SystemTap의 목적

SystemTap은 운영 체제의 활동(특히 커널)을 자세히 연구하고 모니터링하는 데 사용할 수 있는 추적 및 프로빙 툴입니다. SystemTap은 netstat,ps,topiostat 와 같은 툴 출력과 유사한 정보를 제공합니다. 그러나 SystemTap은 수집된 정보에 대한 더 많은 필터링 및 분석 옵션을 제공합니다. SystemTap 스크립트에서 SystemTap이 수집하는 정보를 지정합니다.

SystemTap은 사용자에게 커널 활동을 추적하고 이 기능을 다음 두 가지 속성과 결합하는 인프라를 제공하여 기존 Linux 모니터링 툴 제품군을 보완하는 것을 목표로 합니다.

유연성
SystemTap 프레임워크를 사용하면 커널 공간에서 발생하는 다양한 커널 기능, 시스템 호출 및 기타 이벤트를 조사하고 모니터링하는 간단한 스크립트를 개발할 수 있습니다. 이 기능을 사용하면 SystemTap이 자체 커널 특정 포렌식 및 모니터링 툴을 개발할 수 있는 시스템이므로 툴이 많지 않습니다.
사용 편의성
SystemTap을 사용하면 커널을 다시 컴파일하거나 시스템을 재부팅하지 않고도 커널 활동을 모니터링할 수 있습니다.

39.2. SystemTap 설치

SystemTap 사용을 시작하려면 필요한 패키지를 설치합니다. 시스템에 여러 커널이 설치된 두 개 이상의 커널에서 SystemTap을 사용하려면 커널 버전에 필요한 커널 패키지를 설치합니다.

절차

  1. 필요한 SystemTap 패키지를 설치합니다.

    # dnf install systemtap
  2. 필요한 커널 패키지를 설치합니다.

    1. stap-prep 사용:

      # stap-prep
    2. stap-prep 이 작동하지 않는 경우 필요한 커널 패키지를 수동으로 설치합니다.

      # dnf install kernel-debuginfo-$(uname -r) kernel-debuginfo-common-$(uname -i)-$(uname -r) kernel-devel-$(uname -r)

      $(uname -i) 는 자동으로 시스템의 하드웨어 플랫폼으로 교체되고 $(uname -r) 은 실행 중인 커널 버전으로 자동 교체됩니다.

검증 단계

  • SystemTap으로 검색할 커널이 현재 사용 중인 경우 설치에 성공했는지 테스트합니다.

    # stap -v -e 'probe kernel.function("vfs_read") {printf("read performed\n"); exit()}'

    SystemTap 배포에 성공하면 다음과 유사한 출력이 생성됩니다.

    Pass 1: parsed user script and 45 library script(s) in 340usr/0sys/358real ms.
    Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s) in 290usr/260sys/568real ms.
    Pass 3: translated to C into "/tmp/stapiArgLX/stap_e5886fa50499994e6a87aacdc43cd392_399.c" in 490usr/430sys/938real ms.
    Pass 4: compiled C into "stap_e5886fa50499994e6a87aacdc43cd392_399.ko" in 3310usr/430sys/3714real ms.
    Pass 5: starting run. 1
    read performed 2
    Pass 5: run completed in 10usr/40sys/73real ms. 3

    출력의 마지막 세 줄( Pass 5로 시작)은 다음을 나타냅니다.

    1
    SystemTap에서 커널을 검색하고 계측을 실행하기 위한 계측을 성공적으로 생성했습니다.
    2
    SystemTap이 지정된 이벤트(이 경우 VFS 읽기)를 감지했습니다.
    3
    SystemTap은 유효한 처리기를 실행한 다음(인쇄된 텍스트를 입력한 다음 오류 없이 닫힙니다).

39.3. SystemTap을 실행할 수 있는 권한

SystemTap 스크립트를 실행하려면 상승된 시스템 권한이 필요하지만 경우에 따라 권한이 없는 사용자는 시스템에서 SystemTap 계측을 실행해야 할 수 있습니다.

사용자가 root 액세스 권한 없이 SystemTap을 실행할 수 있도록 하려면 다음 사용자 그룹에 사용자를 추가합니다.

stapdev

이 그룹의 멤버는 stap 을 사용하여 SystemTap 스크립트를 실행하거나 staprun 을 사용하여 SystemTap 계측 모듈을 실행할 수 있습니다.

stap 을 실행하려면 SystemTap 스크립트를 커널 모듈로 컴파일하고 커널에 로드해야 합니다. 이를 위해서는 stapdev 멤버에 부여된 시스템에 대한 승격된 권한이 필요합니다. 안타깝게도 이러한 권한은 stapdev 멤버에 대한 효과적인 root 액세스 권한도 부여합니다. 따라서 root 액세스 권한으로 신뢰할 수 있는 사용자에게 stapdev 그룹 멤버십만 부여합니다.

stapusr
이 그룹의 멤버는 staprun 만 사용하여 SystemTap 계측 모듈을 실행할 수 있습니다. 또한 /lib/modules/kernel_version/systemtap/ 디렉터리의 모듈만 실행할 수 있습니다. 이 디렉터리는 root 사용자만 소유해야 하며 root 사용자만 쓸 수 있어야 합니다.

39.4. SystemTap 스크립트 실행

표준 입력 또는 파일에서 SystemTap 스크립트를 실행할 수 있습니다.

SystemTap 설치와 함께 배포되는 샘플 스크립트는 /usr/share/systemtap/examples 디렉터리에서 확인할 수 있습니다.

사전 요구 사항

  1. SystemTap 및 관련 필수 커널 패키지는 Systemtap 설치에 설명된 대로 설치됩니다.
  2. 일반 사용자로 SystemTap 스크립트를 실행하려면 사용자를 SystemTap 그룹에 추가합니다.

    # usermod --append --groups
    stapdev,stapusr user-name

절차

  • SystemTap 스크립트를 실행합니다.

    • 표준 입력에서:

      # echo "probe timer.s(1) {exit()}" | stap -

      이 명령은 echo 가 표준 입력에 전달된 스크립트를 실행하도록 stap 에 지시합니다. stap 옵션을 추가하려면 - 문자 앞에 삽입합니다. 예를 들어 이 명령의 결과를 더 자세히 이해하기 위해 명령은 다음과 같습니다.

      # echo "probe timer.s(1) {exit()}" | stap -v -
    • 파일에서 다음을 수행합니다.

      # stap file_name

40장. SystemTap의 교차 복원

SystemTap 간 복원 모듈은 SystemTap이 완전히 배포되지 않은 다른 시스템에서 사용할 SystemTap 스크립트에서 SystemTap 계측 모듈을 생성하고 있습니다.

40.1. SystemTap 교차 복원

SystemTap 스크립트를 실행하면 커널 모듈이 해당 스크립트에서 빌드됩니다. 그런 다음 SystemTap은 모듈을 커널에 로드합니다.

일반적으로 SystemTap 스크립트는 SystemTap이 배포된 시스템에서만 실행할 수 있습니다. 10개의 시스템에서 SystemTap을 실행하려면 해당 모든 시스템에 SystemTap을 배포해야 합니다. 경우에 따라 이 방법이 불가능하거나 바람직하지 않을 수도 있습니다. 예를 들어 회사 정책은 컴파일러를 제공하거나 특정 머신에 대한 디버그 정보를 제공하는 패키지를 설치하지 못하도록 할 수 있으므로 SystemTap 배포가 금지될 수 있습니다.

이 문제를 해결하려면 교차 복원을 사용하십시오. 교차 복원은 한 시스템의 SystemTap 스크립트에서 다른 시스템에서 사용할 SystemTap 계측 모듈을 생성하는 프로세스입니다. 이 프로세스는 다음과 같은 이점을 제공합니다.

  • 다양한 시스템의 커널 정보 패키지는 단일 호스트 시스템에 설치할 수 있습니다.

    중요

    커널 패키징 버그로 인해 설치가 금지될 수 있습니다. 이러한 경우 호스트 시스템 및 대상 시스템의 kernel-debuginfokernel-devel 패키지가 일치해야 합니다. 버그가 발생하면 https://bugzilla.redhat.com/ 에서 버그를 보고합니다.

  • 대상 시스템은 생성된 SystemTap 계측 모듈인 systemtap-runtime 을 사용하기 위해 하나의 패키지만 설치해야 합니다.

    중요

    호스트 시스템은 구축된 조정 모듈이 작동하려면 아키텍처와 대상 시스템과 동일한 Linux 배포를 실행해야 합니다.

용어
조정 모듈
SystemTap 모듈은 SystemTap 스크립트로 빌드됩니다. SystemTap 모듈은 호스트 시스템에 빌드되며 대상 시스템의 대상 커널에 로드됩니다.
호스트 시스템
대상 시스템에 로드되도록 조정 모듈( SystemTap 스크립트에서)을 컴파일하는 시스템입니다.
대상 시스템
조정 모듈이 빌드되는 시스템 ( SystemTap 스크립트의)입니다.
대상 커널
대상 시스템의 커널입니다. 이 커널은 조정 모듈을 로드하고 실행하는 커널입니다.

40.2. SystemTap 간 복원 초기화

SystemTap 간 복원을 초기화하여 한 시스템에서 SystemTap 스크립트에서 SystemTap 계측 모듈을 빌드하고 SystemTap이 완전히 배포되지 않은 다른 시스템에서 사용합니다.

사전 요구 사항

  • SystemTap은 Systemtap 설치에 설명된 대로 호스트 시스템에 설치됩니다.
  • systemtap-runtime 패키지는 각 대상 시스템에 설치됩니다.

    # dnf install systemtap-runtime
  • 호스트 시스템과 대상 시스템은 모두 동일한 아키텍처입니다.
  • 호스트 시스템과 대상 시스템은 모두 동일한 Red Hat Enterprise Linux (예: Red Hat Enterprise Linux 9) 주요 버전을 실행하고 있습니다.
중요

커널 패키징 버그로 인해 여러 kernel-debuginfokernel-devel 패키지가 하나의 시스템에 설치되지 않을 수 있습니다. 이러한 경우 호스트 시스템 및 대상 시스템의 마이너 버전이 일치해야 합니다. 버그가 발생하면 https://bugzilla.redhat.com/ 에서 보고합니다.

절차

  1. 대상 시스템에서 실행 중인 커널 확인:

    $ uname -r

    대상 시스템에 대해 이 단계를 반복합니다.

  2. 호스트 시스템에서 Systemtap 설치에 설명된 방법으로 각 대상 시스템의 대상 커널 및 관련 패키지를 설치합니다.
  3. 호스트 시스템에서 조정 모듈을 빌드하고, 이 모듈을 에 복사하여 대상 시스템의 에서 이 모듈을 실행합니다.

    1. 원격 구현 사용:

      # stap --remote target_system script

      이 명령은 대상 시스템에서 지정된 스크립트를 원격으로 구현합니다. 이 작업이 성공하려면 호스트 시스템에서 대상 시스템에 대한 SSH 연결을 수행할 수 있는지 확인해야 합니다.

    2. 수동:

      1. 호스트 시스템에서 조정 모듈을 빌드합니다.

        # stap -r kernel_version script -m module_name -p 4

        여기서 kernel_version 은 1단계에서 결정된 대상 커널 버전을 나타냅니다. script 는 조정 모듈로 변환할 스크립트를 나타내며 module_name계측 모듈의 원하는 이름입니다. -p4 옵션은 SystemTap에 컴파일된 모듈을 로드하지 않고 실행하도록 지시합니다.

      2. 계측 모듈이 컴파일되면 대상 시스템에 복사하여 다음 명령을 사용하여 로드합니다.

        # staprun module_name.ko

41장. SystemTap을 사용하여 네트워크 활동 모니터링

systemtap-testsuite 패키지를 설치할 때 /usr/share/systemtap/testsuite/systemtap.examples/ 디렉터리에서 사용할 수 있는 유용한 SystemTap 스크립트를 사용하여 시스템의 네트워크 활동을 모니터링하고 조사할 수 있습니다.

41.1. SystemTap을 사용하여 네트워크 활동 프로파일링

nettop.stp 예제 SystemTap 스크립트를 사용하여 네트워크 활동을 프로파일링할 수 있습니다. 이 스크립트는 시스템에서 네트워크 트래픽을 생성하는 프로세스를 추적하고 각 프로세스에 대한 다음 정보를 제공합니다.

PID
나열된 프로세스의 ID입니다.
UID
사용자 ID. 사용자 ID가 0이면 root 사용자를 나타냅니다.
DEV
데이터를 보내거나 수신하는 데 사용되는 이더넷 장치(예: eth0, eth1)는 무엇입니까.
XMIT_PK
프로세스에서 전송한 패킷 수입니다.
RECV_PK
프로세스에서 수신한 패킷 수입니다.
XMIT_KB
프로세스에서 보낸 데이터 양(KB)입니다.
RECV_KB
서비스에서 수신한 데이터 양(KB)입니다.

사전 요구 사항

  • SystemTap 설치에 설명된 대로 SystemTap 설치했습니다.

절차

  • nettop.stp 스크립트를 실행합니다.

    # stap  --example nettop.stp

    nettop.stp 스크립트는 5초마다 네트워크 프로필 샘플링을 제공합니다.

    nettop.stp 스크립트의 출력은 다음과 유사합니다.

    [...]
      PID   UID DEV     XMIT_PK RECV_PK XMIT_KB RECV_KB COMMAND
        0     0 eth0          0       5       0       0 swapper
    11178     0 eth0          2       0       0       0 synergyc
      PID   UID DEV     XMIT_PK RECV_PK XMIT_KB RECV_KB COMMAND
     2886     4 eth0         79       0       5       0 cups-polld
    11362     0 eth0          0      61       0       5 firefox
        0     0 eth0          3      32       0       3 swapper
     2886     4 lo            4       4       0       0 cups-polld
    11178     0 eth0          3       0       0       0 synergyc
      PID   UID DEV     XMIT_PK RECV_PK XMIT_KB RECV_KB COMMAND
        0     0 eth0          0       6       0       0 swapper
     2886     4 lo            2       2       0       0 cups-polld
    11178     0 eth0          3       0       0       0 synergyc
     3611     0 eth0          0       1       0       0 Xorg
      PID   UID DEV     XMIT_PK RECV_PK XMIT_KB RECV_KB COMMAND
        0     0 eth0          3      42       0       2 swapper
    11178     0 eth0         43       1       3       0 synergyc
    11362     0 eth0          0       7       0       0 firefox
     3897     0 eth0          0       1       0       0 multiload-apple

41.2. SystemTap을 사용하여 네트워크 소켓 코드에서 호출되는 추적 함수

socket-trace.stp 예제 SystemTap 스크립트를 사용하여 커널의 net/socket.c 파일에서 호출되는 함수를 추적할 수 있습니다. 이렇게 하면 각 프로세스가 커널 수준에서 네트워크와 상호 작용하는 방법을 자세히 확인할 수 있습니다.

사전 요구 사항

  • SystemTap 설치에 설명된 대로 SystemTap 설치했습니다.

절차

  • socket-trace.stp 스크립트를 실행합니다.

    # stap  --example socket-trace.stp

    socket-trace.stp 스크립트 출력의 3초 반은 다음과 유사합니다.

    [...]
    0 Xorg(3611): -> sock_poll
    3 Xorg(3611): <- sock_poll
    0 Xorg(3611): -> sock_poll
    3 Xorg(3611): <- sock_poll
    0 gnome-terminal(11106): -> sock_poll
    5 gnome-terminal(11106): <- sock_poll
    0 scim-bridge(3883): -> sock_poll
    3 scim-bridge(3883): <- sock_poll
    0 scim-bridge(3883): -> sys_socketcall
    4 scim-bridge(3883):  -> sys_recv
    8 scim-bridge(3883):   -> sys_recvfrom
    12 scim-bridge(3883):-> sock_from_file
    16 scim-bridge(3883):<- sock_from_file
    20 scim-bridge(3883):-> sock_recvmsg
    24 scim-bridge(3883):<- sock_recvmsg
    28 scim-bridge(3883):   <- sys_recvfrom
    31 scim-bridge(3883):  <- sys_recv
    35 scim-bridge(3883): <- sys_socketcall
    [...]

41.3. SystemTap을 사용하여 네트워크 패킷 제거

Linux의 네트워크 스택은 다양한 이유로 패킷을 삭제할 수 있습니다. 일부 Linux 커널에는 패킷이 삭제되는 위치를 추적하는 tracepoint kernel.trace("kfree_skb") 가 포함됩니다.

dropwatch.stp SystemTap 스크립트는 kernel.trace("kfree_skb") 를 사용하여 패킷 삭제 추적을 수행합니다. 이 스크립트는 5초 간격마다 패킷을 삭제하는 위치를 요약합니다.

사전 요구 사항

  • SystemTap 설치에 설명된 대로 SystemTap 설치했습니다.

절차

  • dropwatch.stp 스크립트를 실행합니다.

    # stap  --example dropwatch.stp

    15초 동안 dropwatch.stp 스크립트를 실행하면 다음과 유사한 출력이 생성됩니다.

    Monitoring for dropped packets
    51 packets dropped at location 0xffffffff8024cd0f
    2 packets dropped at location 0xffffffff8044b472
    51 packets dropped at location 0xffffffff8024cd0f
    1 packets dropped at location 0xffffffff8044b472
    97 packets dropped at location 0xffffffff8024cd0f
    1 packets dropped at location 0xffffffff8044b472
    Stopping dropped packet monitor
    참고

    패킷 위치를 더 의미 있게 설정하려면 /boot/System.map-$(uname -r) 파일을 참조하십시오. 이 파일은 각 기능의 시작 주소를 나열하여 dropwatch.stp 스크립트 출력의 주소를 특정 함수 이름에 매핑할 수 있습니다. /boot/System.map-$(uname -r) 파일의 다음 스니펫에서 주소 0xffffffff8024cd0funix_stream_recvmsg 함수에 매핑되고 주소 0xffffff8044b472arp_rcv 함수에 매핑됩니다.

    [...]
    ffffffff8024c5cd T unlock_new_inode
    ffffffff8024c5da t unix_stream_sendmsg
    ffffffff8024c920 t unix_stream_recvmsg
    ffffffff8024cea1 t udp_v4_lookup_longway
    [...]
    ffffffff8044addc t arp_process
    ffffffff8044b360 t arp_rcv
    ffffffff8044b487 t parp_redo
    ffffffff8044b48c t arp_solicit
    [...]

42장. SystemTap을 사용하여 커널 활동 프로파일링

다음 스크립트로 함수 호출을 모니터링하여 커널 활동을 프로파일링할 수 있습니다.

42.1. SystemTap을 사용하여 함수 호출 계산

functioncallcount.stp SystemTap 스크립트를 사용하여 특정 커널 함수 호출을 계산할 수 있습니다. 이 스크립트를 사용하여 여러 커널 함수를 대상으로 할 수도 있습니다.

사전 요구 사항

절차

  • functioncallcount.stp 스크립트를 실행합니다.

    # stap --example functioncallcount.stp 'argument'

    이 스크립트는 대상 커널 함수를 인수로 사용합니다. 인수 와일드카드를 사용하여 일정 범위까지 여러 커널 함수를 대상으로 지정할 수 있습니다.

    스크립트의 출력은 알파벳순으로, 라는 함수의 이름과 샘플 시간 동안 호출된 횟수를 포함합니다.

    다음 예제를 고려하십시오.

    # stap -w -v --example functioncallcount.stp "*@mm*.c" -c /bin/true

    다음과 같습니다.

  • -w : 경고를 표시합니다.
  • -V: 시작 커널의 출력을 표시합니다.
  • -c 명령 : 명령을 실행하는 동안 함수 호출을 계산하도록 SystemTap을 Tells합니다(이 예제에서는 /bin/true ).

    출력은 다음과 유사해야 합니다.

    [...]
    __vma_link 97
    __vma_link_file 66
    __vma_link_list 97
    __vma_link_rb 97
    __xchg 103
    add_page_to_active_list 102
    add_page_to_inactive_list 19
    add_to_page_cache 19
    add_to_page_cache_lru 7
    all_vm_events 6
    alloc_pages_node 4630
    alloc_slabmgmt 67
    anon_vma_alloc 62
    anon_vma_free 62
    anon_vma_lock 66
    anon_vma_prepare 98
    anon_vma_unlink 97
    anon_vma_unlock 66
    arch_get_unmapped_area_topdown 94
    arch_get_unmapped_exec_area 3
    arch_unmap_area_topdown 97
    atomic_add 2
    atomic_add_negative 97
    atomic_dec_and_test 5153
    atomic_inc 470
    atomic_inc_and_test 1
    [...]

42.2. SystemTap을 사용하여 함수 호출 추적

para-callgraph.stp SystemTap 스크립트를 사용하여 함수 호출 및 함수 반환을 추적할 수 있습니다.

사전 요구 사항

절차

  • para-callgraph.stp 스크립트를 실행합니다.
# stap --example para-callgraph.stp 'argument1' 'argument2'

para-callgraph.stp 스크립트에는 두 가지 명령줄 인수가 사용됩니다.

  1. 추적하려는 항목/exit인 함수의 이름입니다.
  2. 스레드별로 추적을 활성화하거나 비활성화하는 선택적 트리거 기능입니다. 트리거 함수가 아직 종료되지 않은 한 각 스레드에서 추적은 계속됩니다.

다음 예제를 고려하십시오.

# stap -wv --example para-callgraph.stp 'kernel.function("*@fs/proc.c*")' 'kernel.function("vfs_read")' -c "cat /proc/sys/vm/* || true"

다음과 같습니다.

  • -w : 경고를 표시합니다.
  • -V: 시작 커널의 출력을 표시합니다.
  • -c 명령 : 명령을 실행하는 동안 함수 호출을 계산하도록 SystemTap을 Tells합니다(이 예제에서는 /bin/true ).

출력은 다음과 유사해야 합니다.

[...]
   267 gnome-terminal(2921): <-do_sync_read return=0xfffffffffffffff5
   269 gnome-terminal(2921):<-vfs_read return=0xfffffffffffffff5
     0 gnome-terminal(2921):->fput file=0xffff880111eebbc0
     2 gnome-terminal(2921):<-fput
     0 gnome-terminal(2921):->fget_light fd=0x3 fput_needed=0xffff88010544df54
     3 gnome-terminal(2921):<-fget_light return=0xffff8801116ce980
     0 gnome-terminal(2921):->vfs_read file=0xffff8801116ce980 buf=0xc86504 count=0x1000 pos=0xffff88010544df48
     4 gnome-terminal(2921): ->rw_verify_area read_write=0x0 file=0xffff8801116ce980 ppos=0xffff88010544df48 count=0x1000
     7 gnome-terminal(2921): <-rw_verify_area return=0x1000
    12 gnome-terminal(2921): ->do_sync_read filp=0xffff8801116ce980 buf=0xc86504 len=0x1000 ppos=0xffff88010544df48
    15 gnome-terminal(2921): <-do_sync_read return=0xfffffffffffffff5
    18 gnome-terminal(2921):<-vfs_read return=0xfffffffffffffff5
     0 gnome-terminal(2921):->fput file=0xffff8801116ce980

42.3. SystemTap을 사용하여 커널 및 사용자 공간에 소요된 시간 확인

thread-times.stp SystemTap 스크립트를 사용하여 지정된 스레드가 커널 또는 사용자 공간에 소비하는 시간을 확인할 수 있습니다.

사전 요구 사항

절차

  • thread-times.stp 스크립트를 실행합니다.

    # stap --example thread-times.stp

    이 스크립트는 샘플 중에 만든 총 CPU 틱 수와 함께 5초 동안 CPU 시간을 차지하는 상위 20개의 프로세스를 표시합니다. 이 스크립트의 출력에서는 각 프로세스가 사용된 CPU 시간 백분율과 커널 공간 또는 사용자 공간에 사용된 시간도 기록합니다.

    tid   %user %kernel (of 20002 ticks)
      0   0.00%  87.88%
    32169   5.24%   0.03%
    9815   3.33%   0.36%
    9859   0.95%   0.00%
    3611   0.56%   0.12%
    9861   0.62%   0.01%
    11106   0.37%   0.02%
    32167   0.08%   0.08%
    3897   0.01%   0.08%
    3800   0.03%   0.00%
    2886   0.02%   0.00%
    3243   0.00%   0.01%
    3862   0.01%   0.00%
    3782   0.00%   0.00%
    21767   0.00%   0.00%
    2522   0.00%   0.00%
    3883   0.00%   0.00%
    3775   0.00%   0.00%
    3943   0.00%   0.00%
    3873   0.00%   0.00%

42.4. SystemTap을 사용하여 폴링 애플리케이션 모니터링

timeout.stp SystemTap 스크립트를 사용하여 폴링 중인 애플리케이션을 식별하고 모니터링할 수 있습니다. 이렇게 하면 불필요한 폴링 또는 과도한 폴링을 추적할 수 있으므로 CPU 사용량 및 전력 절감 측면에서 개선할 수 있는 영역을 정확하게 파악할 수 있습니다.

사전 요구 사항

절차

  • timeout.stp 스크립트를 실행합니다.

    # stap --example timeout.stp

    이 스크립트는 각 애플리케이션에서 시간이 지남에 따라 다음 시스템 호출을 사용하는 횟수를 추적합니다.

  • 폴링
  • 선택
  • epoll
  • itimer
  • futex
  • nanosleep
  • 신호

이 예제 출력에서는 어떤 프로세스가 어떤 시스템 호출을 사용한지, 몇 번인지 확인할 수 있습니다.

uid |   poll  select   epoll  itimer   futex nanosle  signal| process
28937 | 148793       0       0    4727   37288       0       0| firefox
22945 |      0   56949       0       1       0       0       0| scim-bridge
  0 |      0       0       0   36414       0       0       0| swapper
4275 |  23140       0       0       1       0       0       0| mixer_applet2
4191 |      0   14405       0       0       0       0       0| scim-launcher
22941 |   7908       1       0      62       0       0       0| gnome-terminal
4261 |      0       0       0       2       0    7622       0| escd
3695 |      0       0       0       0       0    7622       0| gdm-binary
3483 |      0    7206       0       0       0       0       0| dhcdbd
4189 |   6916       0       0       2       0       0       0| scim-panel-gtk
1863 |   5767       0       0       0       0       0       0| iscsid

42.5. SystemTap을 사용하여 가장 자주 사용되는 시스템 호출 추적

topsys.stp SystemTap 스크립트를 사용하여 시스템에서 사용하는 상위 시스템 호출을 5초 간격으로 나열할 수 있습니다. 또한 해당 기간 동안 각 시스템 호출이 사용된 횟수도 나열합니다.

사전 요구 사항

절차

  • topsys.stp 스크립트를 실행합니다.

    # stap --example topsys.stp

    다음 예제를 고려하십시오.

    # stap -v --example topsys.stp

    여기서 -v는 시작 커널의 출력을 표시합니다.

    출력은 다음과 유사해야 합니다.

--------------------------------------------------------------
                  SYSCALL      COUNT
             gettimeofday       1857
                     read       1821
                    ioctl       1568
                     poll       1033
                    close        638
                     open        503
                   select        455
                    write        391
                   writev        335
                    futex        303
                  recvmsg        251
                   socket        137
            clock_gettime        124
           rt_sigprocmask        121
                   sendto        120
                setitimer        106
                     stat         90
                     time         81
                sigreturn         72
                    fstat         66
--------------------------------------------------------------

42.6. SystemTap을 사용하여 프로세스당 시스템 호출 볼륨 추적

syscalls_by_proc.stp SystemTap 스크립트를 사용하여 시스템 호출의 가장 많은 볼륨을 수행하는 프로세스를 확인할 수 있습니다. 가장 많은 시스템 호출을 수행하는 20개의 프로세스를 표시합니다.

사전 요구 사항

절차

  • syscalls_by_proc.stp 스크립트를 실행합니다.

    # stap --example syscalls_by_proc.stp

    syscalls_by_proc.stp 스크립트의 출력은 다음과 유사합니다.

    Collecting data... Type Ctrl-C to exit and display results
    #SysCalls  Process Name
    1577       multiload-apple
    692        synergyc
    408        pcscd
    376        mixer_applet2
    299        gnome-terminal
    293        Xorg
    206        scim-panel-gtk
    95         gnome-power-man
    90         artsd
    85         dhcdbd
    84         scim-bridge
    78         gnome-screensav
    66         scim-launcher
    [...]

43장. SystemTap을 사용하여 디스크 및 I/O 활동 모니터링

다음 스크립트를 사용하여 디스크 및 I/O 활동을 모니터링할 수 있습니다.

43.1. SystemTap을 사용하여 디스크 읽기/쓰기 트래픽 요약

disktop.stp SystemTap 스크립트를 사용하여 가장 중요한 디스크 읽기 및 쓰기를 수행하는 프로세스를 확인할 수 있습니다.

사전 요구 사항

절차

  • disktop.stp 스크립트를 실행합니다.

    # stap --example disktop.stp

    이 스크립트는 가장 많은 읽기 또는 디스크에 쓰는 상위 10개의 프로세스를 표시합니다.

    출력에는 나열된 프로세스당 다음 데이터가 포함됩니다.

    UID
    사용자 ID. 사용자 ID가 0 이면 root 사용자를 나타냅니다.
    PID
    나열된 프로세스의 ID입니다.
    PPID
    나열된 프로세스의 상위 프로세스의 프로세스 ID입니다.
    CMD
    나열된 프로세스의 이름입니다.
    장치
    나열된 프로세스가 또는 쓰기에서 읽고 있는 스토리지 장치는 무엇입니까.
    T
    나열된 프로세스에서 수행하는 작업 유형입니다. 여기서 W 는 쓰기를 참조하고 R 은 읽기를 나타냅니다.
    BYTES
    디스크에서 읽거나 쓰는 데이터 양입니다.

disktop.stp 스크립트의 출력은 다음과 유사합니다.

[...]
Mon Sep 29 03:38:28 2008 , Average:  19Kb/sec, Read: 7Kb, Write: 89Kb
UID      PID     PPID                       CMD   DEVICE    T    BYTES
0    26319    26294                   firefox     sda5    W        90229
0     2758     2757           pam_timestamp_c     sda5    R         8064
0     2885        1                     cupsd     sda5    W         1678
Mon Sep 29 03:38:38 2008 , Average:   1Kb/sec, Read: 7Kb, Write: 1Kb
UID      PID     PPID                       CMD   DEVICE    T    BYTES
0     2758     2757           pam_timestamp_c     sda5    R         8064
0     2885        1                     cupsd     sda5    W         1678

43.2. SystemTap을 사용하여 각 파일 읽기 또는 쓰기에 대한 I/O 시간 추적

iotime.stp SystemTap 스크립트를 사용하여 각 프로세스를 읽거나 파일에 쓰는 데 걸리는 시간을 모니터링할 수 있습니다. 이렇게 하면 시스템에서 로드하는 속도가 느린 파일을 결정하는 데 도움이 됩니다.

사전 요구 사항

절차

  • iotime.stp 스크립트를 실행합니다.

    # stap --example iotime.stp

    이 스크립트는 시스템 호출이 열리며, 닫히고, 에서 읽고, 파일에 쓸 때마다 추적합니다. 시스템 호출 액세스에 대한 각 파일에 대해 읽기 또는 쓰기가 완료되는 데 걸리는 마이크로초의 수를 계산하고 데이터 양을 바이트 단위로 계산합니다.

    출력에는 다음이 포함됩니다.

  • 타임스탬프(마이크로초)
  • 프로세스 ID 및 프로세스 이름
  • 액세스 또는 iotime 플래그
  • 액세스한 파일

    프로세스가 데이터를 읽거나 쓸 수 있는 경우 액세스 쌍과 iotime 행이 함께 표시되어야 합니다. 액세스 행은 지정된 프로세스가 파일에 액세스하기 시작한 시간을 나타냅니다. 액세스 행의 끝에는 읽거나 쓰거나 읽은 데이터 양이 표시됩니다. iotime 행에는 읽기 또는 쓰기를 수행하기 위해 프로세스가 걸리는 시간(마이크로초)이 표시됩니다.

iotime.stp 스크립트의 출력은 다음과 유사합니다.

[...]
825946 3364 (NetworkManager) access /sys/class/net/eth0/carrier read: 8190 write: 0
825955 3364 (NetworkManager) iotime /sys/class/net/eth0/carrier time: 9
[...]
117061 2460 (pcscd) access /dev/bus/usb/003/001 read: 43 write: 0
117065 2460 (pcscd) iotime /dev/bus/usb/003/001 time: 7
[...]
3973737 2886 (sendmail) access /proc/loadavg read: 4096 write: 0
3973744 2886 (sendmail) iotime /proc/loadavg time: 11
[...]

43.3. SystemTap을 사용하여 누적 I/O 추적

traceio.stp SystemTap 스크립트를 사용하여 시스템의 누적 I/O 양을 추적할 수 있습니다.

사전 요구 사항

절차

  • traceio.stp 스크립트를 실행합니다.

    # stap --example traceio.stp

    스크립트는 시간이 지남에 따라 I/O 트래픽을 생성하는 상위 10개의 실행 파일을 출력합니다. 또한 해당 실행 파일에서 수행한 I/O 읽기 및 쓰기의 누적 양을 추적합니다. 이 정보는 1초 간격으로 추적 및 출력되며 내림차순으로 표시됩니다.

    traceio.stp 스크립트의 출력은 다음과 유사합니다.

[...]
           Xorg r:   583401 KiB w:        0 KiB
       floaters r:       96 KiB w:     7130 KiB
multiload-apple r:      538 KiB w:      537 KiB
           sshd r:       71 KiB w:       72 KiB
pam_timestamp_c r:      138 KiB w:        0 KiB
        staprun r:       51 KiB w:       51 KiB
          snmpd r:       46 KiB w:        0 KiB
          pcscd r:       28 KiB w:        0 KiB
     irqbalance r:       27 KiB w:        4 KiB
          cupsd r:        4 KiB w:       18 KiB
           Xorg r:   588140 KiB w:        0 KiB
       floaters r:       97 KiB w:     7143 KiB
multiload-apple r:      543 KiB w:      542 KiB
           sshd r:       72 KiB w:       72 KiB
pam_timestamp_c r:      138 KiB w:        0 KiB
        staprun r:       51 KiB w:       51 KiB
          snmpd r:       46 KiB w:        0 KiB
          pcscd r:       28 KiB w:        0 KiB
     irqbalance r:       27 KiB w:        4 KiB
          cupsd r:        4 KiB w:       18 KiB

43.4. SystemTap을 사용하여 특정 장치에서 I/O 활동 모니터링

traceio2.stp SystemTap 스크립트를 사용하여 특정 장치의 I/O 활동을 모니터링할 수 있습니다.

사전 요구 사항

절차

  • traceio2.stp 스크립트를 실행합니다.
# stap --example traceio2.stp 'argument'

이 스크립트는 전체 장치 번호를 인수로 사용합니다. 이 번호를 찾으려면 다음을 사용합니다.

# stat -c "0x%D" directory

모니터링할 장치에 디렉터리 가 있습니다.

출력에는 다음이 포함됩니다.

  • 읽기 또는 쓰기를 수행하는 프로세스의 이름 및 ID
  • 수행 중인 함수(vfs_read 또는 vfs_write)
  • 커널 장치 번호

# stap traceio2.stp 0x805의 출력을 고려하십시오.

[...]
synergyc(3722) vfs_read 0x800005
synergyc(3722) vfs_read 0x800005
cupsd(2889) vfs_write 0x800005
cupsd(2889) vfs_write 0x800005
cupsd(2889) vfs_write 0x800005
[...]

43.5. SystemTap을 사용하여 파일 읽기 및 쓰기 모니터링

inodewatch.stp SystemTap 스크립트를 사용하여 실시간으로 파일에서 읽기 및 쓰기를 모니터링할 수 있습니다.

사전 요구 사항

절차

  • inodewatch.stp 스크립트를 실행합니다.
# stap --example inodewatch.stp 'argument1' 'argument2' 'argument3'

inodewatch.stp 스크립트는 세 가지 명령줄 인수를 사용합니다.

  1. 파일의 주요 장치 번호입니다.
  2. 파일의 마이너 장치 번호입니다.
  3. 파일의 inode 번호입니다.

이 번호는 다음을 사용하여 얻을 수 있습니다.

# stat -c '%D %i' filename

여기서 filename 은 절대 경로입니다.

다음 예제를 고려하십시오.

# stat -c '%D %i' /etc/crontab

출력은 다음과 같아야 합니다.

805 1078319

다음과 같습니다.

  • 805 는 기본 16 (hexadecimal) 장치 번호입니다. 마지막 두 자리는 마이너 장치 번호이고 나머지 숫자는 메이저 번호입니다.
  • 1078319 는 inode 번호입니다.

/etc/crontab 모니터링을 시작하려면 다음을 실행합니다.

# stap inodewatch.stp 0x8 0x05 1078319

처음 두 인수에서는 base-16 숫자에 0x 접두사를 사용해야 합니다.

출력에는 다음이 포함됩니다.

  • 읽기 또는 쓰기를 수행하는 프로세스의 이름 및 ID
  • 수행 중인 함수(vfs_read 또는 vfs_write)
  • 커널 장치 번호

이 예제의 출력은 다음과 같아야 합니다.

cat(16437) vfs_read 0x800005/1078319
cat(16437) vfs_read 0x800005/1078319

법적 공지

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.