검색

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

download PDF
Red Hat Enterprise Linux 8

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

Red Hat Customer Content Services

초록

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

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

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

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

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

1장. 성능 모니터링 옵션 개요

다음은 Red Hat Enterprise Linux 8에서 사용할 수 있는 몇 가지 성능 모니터링 및 구성 툴입니다.

  • PCP(Performance Co-Pilot)는 시스템 수준의 성능 측정을 모니터링, 시각화, 저장 및 분석하는 데 사용됩니다. 실시간 데이터의 모니터링 및 관리, 기록 데이터의 로깅 및 검색을 가능하게 합니다.
  • Red Hat Enterprise Linux 8은 명령줄에서 사용할 수 있는 여러 도구를 제공하여 시스템 외부 실행 수준 5 를 모니터링합니다. 다음은 기본 제공되는 명령줄 도구입니다.

    • topprocps-ng 패키지에서 제공합니다. 실행 중인 시스템에서 프로세스의 동적 보기를 제공합니다. 시스템 요약 및 Linux 커널에서 현재 관리 중인 작업 목록을 포함하여 다양한 정보를 표시합니다.
    • PSprocps-ng 패키지에서 제공합니다. 활성 프로세스로 이루어진 일부 그룹의 스냅샷을 캡처합니다. 기본적으로 검사된 그룹은 현재 사용자가 소유한 프로세스와 ps 명령이 실행되는 터미널과 연결된 프로세스로 제한됩니다.
    • 가상 메모리 통계(vmstat)는 procps-ng 패키지에서 제공합니다. 시스템 프로세스, 메모리, 페이징, 블록 입력/출력, 인터럽트 및 CPU 활동의 즉시 보고를 제공합니다.
    • 시스템 활동 리포터(sar)는 sysstat 패키지에서 제공합니다. 현재까지 발생한 시스템 활동에 대한 정보를 수집 및 보고합니다.
  • perf 는 하드웨어 성능 카운터 및 커널 추적 지점을 사용하여 시스템에서 다른 명령 및 애플리케이션의 영향을 추적합니다.
  • BCC -tools 는 BCC(BPF Compiler Collection)에 사용됩니다. 커널 활동을 모니터링하는 100개가 넘는 eBPF 스크립트를 제공합니다. 이 툴 각각에 대한 자세한 내용은 사용 방법 및 수행하는 기능에 대해 설명하는 도움말 페이지를 참조하십시오.
  • turbostatkernel-tools 패키지에서 제공합니다. Intel 64 프로세서에서 프로세서 토폴로지, 빈도, 유휴 전원 상태 통계, 온도 및 전력 사용량에 대해 보고합니다.
  • iostatsysstat 패키지에서 제공합니다. 시스템 IO 장치 로드를 모니터링하고 보고하여 관리자가 물리적 디스크 간 IO 로드의 균형을 조정하는 방법을 결정할 수 있습니다.
  • irqbalance 는 시스템 성능을 향상시키기 위해 프로세서 간에 하드웨어 인터럽트를 배포합니다.
  • SS 는 소켓에 대한 통계 정보를 인쇄하여 관리자가 시간 경과에 따른 장치 성능을 평가할 수 있습니다. Red Hat Enterprise Linux 8에서는 netstat 를 통해 ss 를 사용하는 것이 좋습니다.
  • numastatnumactl 패키지에서 제공합니다. 기본적으로 numastat 는 노드별 NUMA가 커널 메모리 할당기의 누락 시스템 통계를 표시합니다. 최적의 성능은 높은 numa_hit 값과 낮은 numa_miss 값으로 표시됩니다.
  • numad 는 자동 NUMA 선호도 관리 데몬입니다. NUMA 리소스 할당, 관리 및 시스템 성능을 동적으로 개선하는 시스템 내의 NUMA 토폴로지 및 리소스 사용량을 모니터링합니다.
  • SystemTap 은 운영 체제 활동, 특히 커널 활동을 모니터링 및 분석합니다.
  • Valgrind 는 실행에 따른 기존 애플리케이션 코드를 계측하고 이를 실행하면서 온도 CPU에서 애플리케이션을 실행하여 애플리케이션을 분석합니다. 그런 다음 애플리케이션 실행과 관련된 각 프로세스를 사용자 지정 파일, 파일 설명자 또는 네트워크 소켓에 명확하게 식별하는 주석이 인쇄됩니다. 또한 메모리 누수를 찾는 데 유용합니다.
  • pqosintel-cmt-cat 패키지에서 제공합니다. 최신 Intel 프로세서에서 CPU 캐시 및 메모리 대역폭을 모니터링 및 제어합니다.

추가 리소스

2장. TuneD 시작하기

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

2.1. TuneD의 목적

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

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

  • 높은 처리량
  • 짧은 대기 시간
  • 절전

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

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

2.2. tuned 프로필

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

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

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

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

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

tuned.conf 파일에는 [main] 섹션 1개와 플러그인 인스턴스를 구성하는 다른 섹션이 포함될 수 있습니다. 그러나 모든 섹션은 선택 사항입니다.

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

추가 리소스

  • tuned.conf(5) 도움말 페이지.

2.3. 기본 TuneD 프로필

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

환경기본 프로필목적

계산 노드

throughput-performance

최상의 처리량 성능

가상 머신

virtual-guest

최고의 성능. 최상의 성능에 관심이 없는 경우 balanced 또는 powersave 프로필로 변경할 수 있습니다.

기타 케이스

균형 조정

균형 있는 성능 및 전력 소비

추가 리소스

  • tuned.conf(5) 도움말 페이지.

2.4. 병합 TuneD 프로필

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

충돌이 있는 경우 마지막 지정된 프로필의 설정이 우선합니다.

예 2.1. 가상 게스트의 전력 소비가 적습니다.

다음 예제에서는 최상의 성능을 위해 가상 시스템에서 실행되도록 시스템을 최적화하고 낮은 전력 소비를 위해 동시에 튜닝하는 반면, 낮은 전력 소비는 우선 순위입니다.

# tuned-adm profile virtual-guest powersave
주의

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

추가 리소스

*tuned-adm man 페이지. * tuned.conf(5) 도움말 페이지.

2.5. TuneD 프로필의 위치

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

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

추가 리소스

  • tuned.conf(5) 도움말 페이지.

2.6. RHEL로 배포된 조정된 프로필

다음은 Red Hat Enterprise Linux에서 TuneD 를 사용하여 설치되는 프로필 목록입니다.

참고

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

균형 조정

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

이는 energy_performance_preference 특성을 일반 에너지 설정으로 변경합니다. 또한 scaling_governor 정책 특성을 일반 또는 절전 CPU governor로 변경합니다.

powersave

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

이는 energy_performance_preference 특성을 절전 또는 전원 에너지 설정으로 변경합니다. 또한 scaling_governor 정책 속성을 ondemand 또는 powersave CPU governor로 변경합니다.

참고

특정 경우에는 powersave 프로필에 비해 balanced 프로필이 더 효율적입니다.

지정된 양의 작업을 수행해야 합니다(예: 트랜스코딩해야 하는 동영상 파일). 작업을 신속하게 완료하면 시스템이 유휴 상태가 되기 때문에 트랜스코딩이 전체 전원에서 수행되면 시스템이 유휴 상태가 되고 매우 효율적인 절전 모드로 자동으로 스테이징될 수 있습니다. 반면 스로틀드 시스템으로 파일을 트랜스코딩하는 경우 시스템은 트랜스코딩 중에 전력을 적게 소비하지만 프로세스가 더 오래 걸리고 전반적으로 소비되는 에너지는 더 높을 수 있습니다.

따라서 balanced 프로필은 일반적으로 더 나은 옵션일 수 있습니다.

throughput-performance

높은 처리량에 최적화된 서버 프로필. 절전 메커니즘을 비활성화하고 디스크 및 네트워크 IO의 처리량 성능을 개선하는 sysctl 설정을 활성화합니다. CPU governor가 performance로 설정되어 있습니다.

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

accelerator-performance
accelerator-performance 프로필에는 throughput -performance 프로필과 동일한 튜닝이 포함되어 있습니다. 또한 대기 시간이 100us 미만이 되도록 CPU가 낮은 C 상태로 잠깁니다. 따라서 GPU와 같은 특정 액셀러레이터의 성능이 향상됩니다.
latency-performance

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

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

network-latency

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

energy_performance_ preference 및 scaling_governor 특성을 성능 프로필로 변경하는 latency- performance 프로필을 상속받습니다.

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

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

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

virtual-guest

다른 작업 중에 가상 메모리 스왑을 줄이고 디스크 읽기 값을 늘리는 throughput-performance 프로필을 기반으로 Red Hat Enterprise Linux 8 가상 시스템 및 VMWare 게스트용으로 설계된 프로필입니다. 디스크 장벽을 비활성화하지 않습니다.

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

virtual-host

다른 작업에서 가상 메모리 스왑성을 줄이고 디스크 읽기 헤드 값을 높이며 더티 페이지 나중 쓰기백 값을 활성화하는 throughput-performance 프로필을 기반으로 가상 호스트를 위해 설계된 프로필입니다.

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

Oracle
Oracle 데이터베이스에 최적화된 프로필은 처리량-성능 프로필을 기반으로 로드됩니다. 또한 투명한 대규모 페이지를 비활성화하고 다른 성능 관련 커널 매개 변수를 수정합니다. 이 프로필은 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

2.7. tuned cpu-partitioning 프로파일

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

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

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

그림 2.1. 그림 cpu-partitioning

CPU 파티션

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

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

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

isolated_cores=cpu-list 옵션을 사용하여 /etc/tuned/cpu-partitioning-variables.conf 파일에서 cpu- partitioning 프로필을 구성할 수 있습니다. 이 옵션은 커널 스케줄러 로드 밸런싱을 사용할 CPU를 격리합니다.

분리된 CPU 목록은 쉼표로 구분되거나 3-5 와 같은 대시를 사용하여 범위를 지정할 수 있습니다. 이 옵션은 필수입니다. 이 목록에서 누락된 CPU는 자동으로 하우스키핑 CPU로 간주됩니다.

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

cpu-partitioning 그림의 경우 번호가 매겨진 2 및 3 블록은 추가 커널 스케줄러 프로세스 로드 밸런싱을 제공하지 않는 분리된 CPU입니다.

no_balance_cores=cpu-list 옵션을 사용하여 /etc/tuned/cpu-partitioning-variables.conf 파일에서 cpu- partitioning 프로필을 구성할 수 있습니다. 이 옵션은 커널 스케줄러 부하 분산을 사용하지 않는 CPU를 격리하도록 나열합니다.

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

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

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

추가 리소스

  • tuned-profiles-cpu-partitioning(7) 도움말 페이지

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

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

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

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

사전 요구 사항

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

절차

  1. /etc/tuned/cpu-partitioning-variables.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. 재부팅

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

추가 리소스

  • tuned-profiles-cpu-partitioning(7) 도움말 페이지

2.9. cpu-partitioning TuneD 프로필 사용자 정의

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

예를 들어 cpu-partitioning 프로필은 CPU를 cstate=1 으로 설정합니다. cpu-partitioning 프로필을 사용하지만 CPU 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) 도움말 페이지

2.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 패키지에서 제공합니다.

2.11. TuneD의 정적 및 동적 튜닝

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

정적 튜닝
주로 사전 정의된 sysctlsysfs 설정 적용 및 ethtool 과 같은 여러 구성 도구의 한 가지 스냅샷 활성화로 구성됩니다.
동적 튜닝

시스템 가동 시간 전체에서 다양한 시스템 구성 요소를 사용하는 방법을 살펴봅니다. tuned는 모니터링 정보를 기반으로 시스템 설정을 동적으로 조정합니다.

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

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

현재 구현된 동적 튜닝 알고리즘은 성능과 절전의 균형을 맞추기 때문에 성능 프로필에서 비활성화됩니다. TuneD 프로필에서 개별 플러그인에 대한 동적 튜닝을 활성화하거나 비활성화할 수 있습니다.

예 2.2. 워크스테이션에서 정적 및 동적 튜닝

일반적인 사무실 워크스테이션에서 이더넷 네트워크 인터페이스는 대부분의 시간이 비활성 상태입니다. 몇 개의 이메일만 들어오거나 일부 웹 페이지를 로드할 수 있습니다.

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

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

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

2.12. tuned no-daemon 모드

상주 메모리가 필요하지 않은 경우 TuneDno-daemon 모드에서 실행할 수 있습니다. 이 모드에서 TuneD 는 설정을 적용하고 종료합니다.

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

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

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

daemon = 0

2.13. TuneD 설치 및 활성화

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

절차

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

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

    # systemctl enable --now tuned
  3. 선택적으로 실시간 시스템에 TuneD 프로필을 설치합니다.

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

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

    설치합니다.

    # yum 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.

2.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) 도움말 페이지.

2.15. TuneD 프로필 설정

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

사전 요구 사항

절차

  1. 선택적으로 TuneD 가 시스템에 가장 적합한 프로파일을 권장하도록 할 수 있습니다.

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

    # tuned-adm profile selected-profile

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

    # tuned-adm profile selected-profile1 selected-profile2

    예 2.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) 도움말 페이지

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

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

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

참고

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

2.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 업스트림 리포지토리에서 사용 가능한 다양한 방법에 대한 설명을 찾을 수 있습니다.

2.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"

2.17. TuneD 비활성화

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

절차

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

    # tuned-adm off

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

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

    # systemctl disable --now tuned

추가 리소스

  • tuned-adm(8) 도움말 페이지

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

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

사전 요구 사항

3.1. tuned 프로필

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

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

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

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

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

tuned.conf 파일에는 [main] 섹션 1개와 플러그인 인스턴스를 구성하는 다른 섹션이 포함될 수 있습니다. 그러나 모든 섹션은 선택 사항입니다.

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

추가 리소스

  • tuned.conf(5) 도움말 페이지.

3.2. 기본 TuneD 프로필

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

환경기본 프로필목적

계산 노드

throughput-performance

최상의 처리량 성능

가상 머신

virtual-guest

최고의 성능. 최상의 성능에 관심이 없는 경우 balanced 또는 powersave 프로필로 변경할 수 있습니다.

기타 케이스

균형 조정

균형 있는 성능 및 전력 소비

추가 리소스

  • tuned.conf(5) 도움말 페이지.

3.3. 병합 TuneD 프로필

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

충돌이 있는 경우 마지막 지정된 프로필의 설정이 우선합니다.

예 3.1. 가상 게스트의 전력 소비가 적습니다.

다음 예제에서는 최상의 성능을 위해 가상 시스템에서 실행되도록 시스템을 최적화하고 낮은 전력 소비를 위해 동시에 튜닝하는 반면, 낮은 전력 소비는 우선 순위입니다.

# tuned-adm profile virtual-guest powersave
주의

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

추가 리소스

*tuned-adm man 페이지. * tuned.conf(5) 도움말 페이지.

3.4. TuneD 프로필의 위치

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

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

추가 리소스

  • tuned.conf(5) 도움말 페이지.

3.5. TuneD 프로필 간 상속

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

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

[main]
include=parent

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

일부 매개 변수만 조정하면 / usr/lib/tuned/의 사전 설치된 프로필을 기반으로 /etc /tuned/ 디렉토리에 고유한 하위 프로필을 만들 수 있습니다.

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

예 3.2. 균형에 따른 절전 프로파일

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

[main]
include=balanced

[scsi_host]
alpm=min_power

추가 리소스

  • tuned.conf(5) 도움말 페이지

3.6. TuneD의 정적 및 동적 튜닝

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

정적 튜닝
주로 사전 정의된 sysctlsysfs 설정 적용 및 ethtool 과 같은 여러 구성 도구의 한 가지 스냅샷 활성화로 구성됩니다.
동적 튜닝

시스템 가동 시간 전체에서 다양한 시스템 구성 요소를 사용하는 방법을 살펴봅니다. tuned는 모니터링 정보를 기반으로 시스템 설정을 동적으로 조정합니다.

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

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

현재 구현된 동적 튜닝 알고리즘은 성능과 절전의 균형을 맞추기 때문에 성능 프로필에서 비활성화됩니다. TuneD 프로필에서 개별 플러그인에 대한 동적 튜닝을 활성화하거나 비활성화할 수 있습니다.

예 3.3. 워크스테이션에서 정적 및 동적 튜닝

일반적인 사무실 워크스테이션에서 이더넷 네트워크 인터페이스는 대부분의 시간이 비활성 상태입니다. 몇 개의 이메일만 들어오거나 일부 웹 페이지를 로드할 수 있습니다.

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

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

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

3.7. tuned 플러그인

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

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

모니터링 플러그인

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

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

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

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

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

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

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

예 3.4. 플러그인과 블록 장치 일치

다음 예는 as sda 또는 sdb 와 같이 sd 로 시작하는 모든 블록 장치와 일치하며 해당 장치에서 장벽을 비활성화하지 않습니다.

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

다음 예제는 모든 블록 장치와 일치합니다. 단,da 1sda2:

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

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

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

짧은 플러그인 구문

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

[TYPE]
devices=DEVICES

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

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

[disk]
devices=sdb*
disable_barriers=false
프로필의 플러그인 정의 충돌

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

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

참고

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

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

추가 리소스

  • tuned.conf(5) 도움말 페이지

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

모니터링 플러그인

현재 다음과 같은 모니터링 플러그인이 구현됩니다.

disk
장치 및 측정 간격당 디스크 부하(IO 작업 수) 확보.
net
네트워크 카드 및 측정 간격별로 네트워크 부하(전송된 패킷 수) 가져오기.
load
CPU당 CPU 부하 확보 및 측정 간격.
튜닝 플러그인

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

cpu

CPU governor를 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(전면 버스) 속도를 동적으로 설정합니다.

이 기능은 일부 넷북에서 확인할 수 있으며 ASUS Super Hybrid Engine (SHE)이라고도 합니다.

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

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

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

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

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

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

usb

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

0 은 autosuspend가 비활성화되었음을 의미합니다.

vm

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

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

  • "항상"
  • "안함"
  • "madvise"
audio

오디오 코덱의 자동 일시 중지 타임아웃을 timeout 옵션에 지정된 값으로 설정합니다.

현재 snd_hda_intelsnd_ac97_codec codec가 지원됩니다. 값 0 은 autosuspend가 비활성화되었음을 의미합니다. 부울 옵션 reset _controller를 true 로 설정하여 컨트롤러 재설정 을 적용할 수도 있습니다.

disk

디스크 프레임을 확대 옵션에서 지정한 값으로 설정합니다.

또한 다음과 같은 설정도 설정됩니다.

  • apm 옵션에 지정된 값으로의 APM
  • scheduler _quantum 옵션으로 지정한 값에 대한 스케줄러 쿼터
  • 스핀 다운 옵션으로 지정된 값에 대한 디스크 회전 시간 초과
  • disk readahead 매개변수에 지정된 값의 readahead
  • 현재 디스크 읽기 묶음에서 readahead_multiply 옵션에 지정된 상수를 곱한 값

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

scsi_host

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

ALPM(Aggressive Link Power Management)을 ALPM 옵션으로 지정한 값으로 설정합니다.

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

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

중요

script 플러그인은 주로 이전 릴리스와의 호환성을 위해 제공됩니다. 필요한 기능을 다루는 경우 다른 TuneD 플러그인을 사용하는 것이 좋습니다.

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

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

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

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

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

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

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

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

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

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

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

video

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

절전 수준은 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

예 3.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 이외의 시스템에서만 작동합니다.

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

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

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

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

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

3.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 옵션은 .로 구분된 여러 정규식이 지원됩니다. \; 은 문자 그대로 사용됩니다.

예 3.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 파일에 직접 씁니다.

예 3.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 는 우선 순위 및 스케줄링 정책을 결정합니다.

예 3.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 이벤트가 모니터링되지 않고 작동합니다. 이에 대한 단점은 프로세스 및 스레드 튜닝이 프로필 애플리케이션에서만 수행된다는 것입니다.

예 3.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 옵션으로 지정된 위치 외부에 기록되지 않습니다.

예 3.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는 논리 '또는' 연산자를 나타냅니다.

예 3.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

    예 3.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 값을 씁니다.

3.10. TuneD 프로필의 변수

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

TuneD 변수를 사용하면 TuneD 프로필에서 필요한 입력 양이 줄어듭니다.

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

[variables]

variable_name=value

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

${variable_name}

예 3.16. 변수를 사용하여 CPU 코어 격리

다음 예에서 ${isolated_cores} 변수는 1,2 로 확장되므로 커널 은 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-variables.conf 파일에 추가하면 커널이 isolcpus=1,2 옵션으로 부팅됩니다.

추가 리소스

  • tuned.conf(5) 도움말 페이지

3.11. TuneD 프로필의 기본 제공 함수

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

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

  • TuneD 변수와 함께 다양한 기본 제공 함수 사용
  • Python에서 사용자 지정 함수를 만들고 플러그인 형식의 TuneD 에 추가합니다.

함수를 호출하려면 다음 구문을 사용하십시오.

${f:function_name:argument_1:argument_2}

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

${i:PROFILE_DIR}

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

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

[variables]
non_isolated_cores=0,3-5

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

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

추가 리소스

  • tuned.conf(5) 도움말 페이지

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

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

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

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

  • 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 의 형식으로 CPU 목록을 1-3,5 형식으로 팩합니다.

3.13. 새 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) 도움말 페이지

3.14. 기존 TuneD 프로필 수정

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

사전 요구 사항

절차

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

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

    [main]
    include=parent-profile

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

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

    예 3.18. throughput-performance 프로필에서 스왑성 감소

    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) 도움말 페이지

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

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

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

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

사전 요구 사항

  • TuneD 서비스가 설치되고 활성화됩니다. 자세한 내용은 TuneD 설치 및 사용을 참조하십시오.

절차

  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(World Wide Name) 또는 일련 번호로 식별된 모든 값을 반환합니다. WWN을 사용하는 것이 바람직하지만 WWN은 지정된 장치에 항상 사용 가능한 것은 아니며 예제 명령에서 반환된 값은 장치 시스템 고유 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 를 선택한 식별자 값으로 바꿉니다(예: 0x5002538d0000).

        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/장치/queue/scheduler 파일의 내용을 읽습니다.

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

    파일 이름에서 device 를 exampledc의 블록 장치 이름으로 바꿉니다.

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

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

tuna 툴을 사용하여 스케줄러 튜닝 가능 항목을 조정하고, 스레드 우선 순위, IRQ 핸들러를 조정하고, CPU 코어와 소켓을 격리합니다. tuna는 튜닝 작업 수행의 복잡성을 줄입니다.

tuna 툴은 다음 작업을 수행합니다.

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

4.1. tuna 툴 설치

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

절차

  • tuna 툴을 설치합니다.

    # yum install tuna

검증

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

    # tuna -h

추가 리소스

  • tuna(8) 도움말 페이지

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

이 절차에서는 tuna CLI( 명령줄 인터페이스) 툴을 사용하여 시스템 상태를 확인하는 방법을 설명합니다.

사전 요구 사항

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

절차

  • 현재 정책 및 우선 순위를 보려면 다음을 수행합니다.

    # tuna --show_threads
                thread
    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 --threads=pid_or_cmd_list --show_threads

    pid_or_cmd_list 인수는 쉼표로 구분된 PID 또는 명령 이름 패턴 목록입니다.

  • tuna CLI 를 사용하여 CPU를 조정하려면 tuna 툴을 사용하여 CPU 튜닝 을 참조하십시오.
  • tuna 툴을 사용하여 IRQ를 조정하려면 tuna 도구를 사용하여 IRQ 튜닝을 참조하십시오.
  • 변경된 구성을 저장하려면 다음을 수행합니다.

    # tuna --save=filename

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

추가 리소스

  • tuna(8) 도움말 페이지

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

tuna 툴 명령은 개별 CPU를 대상으로 할 수 있습니다.

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

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

다음 절차에서는 tuna CLI를 사용하여 CPU를 튜닝하는 방법을 설명합니다.

사전 요구 사항

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

절차

  • 명령의 영향을 받을 CPU 목록을 지정하려면 다음을 수행합니다.

    # tuna --cpus=cpu_list [command]

    cpu_list 인수는 쉼표로 구분된 CPU 번호 목록입니다. 예를 들면 --cpus=0,2 입니다. CPU 목록도 범위 내에 지정할 수 있습니다(예: --cpus="1-3", CPUs 1, 2, 3를 선택하는).

    현재 cpu_list 에 특정 CPU를 추가하려면 예를 들어 --cpus=+0 을 사용합니다.

    [command]를 --isolate 으로 바꿉니다.

  • CPU를 격리하려면 다음을 수행합니다.

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

    # tuna --cpus=cpu_list --include
  • 4개 이상의 프로세서가 있는 시스템을 사용하려면 모든 ssh 스레드가 CPU 01 에서 실행되도록 하는 방법과 CPU 23 의 모든 http 스레드를 표시하는 방법은 다음과 같습니다.

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

    이 명령은 다음 작업을 순차적으로 수행합니다.

    1. CPU 01 을 선택합니다.
    2. ssh 로 시작하는 모든 스레드를 선택합니다.
    3. 선택한 스레드를 선택한 CPU로 이동합니다. tuna는 ssh 로 시작하는 스레드의 선호도 마스크를 적절한 CPU에 설정합니다. CPU는 0과 1 로, 16진수 마스크에서 0 x3으로, 또는 11으로 바이너리로 나타낼 수 있습니다.
    4. CPU 목록을 23 으로 재설정합니다.
    5. http 로 시작하는 모든 스레드를 선택합니다.
    6. 선택한 스레드를 지정된 CPU로 이동합니다. tuna는 http 로 시작하는 스레드의 선호도 마스크를 지정된 CPU로 설정합니다. CPU는 23, 16진수 마스크에서 0xC로, 또는 1100으로 바이너리로 나타낼 수 있습니다.

검증

  • 현재 구성을 표시하고 변경 사항이 예상대로 수행되었는지 확인합니다.

    # tuna --threads=gnome-sc\* --show_threads \
    --cpus=0 --move --show_threads --cpus=1 \
    --move --show_threads --cpus=+0 --move --show_threads
    
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0      0,1     33997           58 gnome-screensav
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0        0     33997           58 gnome-screensav
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0        1     33997           58 gnome-screensav
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0      0,1     33997           58 gnome-screensav

    이 명령은 다음 작업을 순차적으로 수행합니다.

    1. gnome-sc 스레드로 시작하는 모든 스레드를 선택합니다.
    2. 사용자가 선호도 마스크 및 RT 우선 순위를 확인할 수 있도록 선택한 스레드를 표시합니다.
    3. CPU 0 을 선택합니다.
    4. gnome-sc 스레드를 지정된 CPU, CPU 0 으로 이동합니다.
    5. 는 이동 결과를 표시합니다.
    6. CPU 목록을 CPU 1 로 재설정합니다.
    7. gnome-sc 스레드를 지정된 CPU, CPU 1 로 이동합니다.
    8. 이동 결과를 표시합니다.
    9. CPU 목록에 CPU 0 을 추가합니다.
    10. gnome-sc 스레드를 지정된 CPU, CPU 01 로 이동합니다.
    11. 이동 결과를 표시합니다.

추가 리소스

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

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

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

이 절차에서는 tuna 도구를 사용하여 IRQ를 조정하는 방법을 설명합니다.

사전 요구 사항

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

절차

  • 현재 IRQ 및 해당 유사성을 보려면 다음을 수행합니다.

    # tuna --show_irqs
    # users            affinity
    0 timer                   0
    1 i8042                   0
    7 parport0                0
  • 명령의 영향을 받을 IRQ 목록을 지정하려면 다음을 수행합니다.

    # tuna --irqs=irq_list [command]

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

    [command]를 --spread 로 바꿉니다.

  • 인터럽트를 지정된 CPU로 이동하려면 다음을 수행합니다.

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

    128 을 irq_list 인수로 바꾸고 3 을 cpu_list 인수로 바꿉니다.

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

검증

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

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

추가 리소스

  • /procs/interrupts 파일
  • tuna(8) 도움말 페이지

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

시스템 관리자는 Ansible Automation Platform 제어 노드에서 메트릭 RHEL 시스템 역할을 사용하여 시스템의 성능을 모니터링할 수 있습니다.

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

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

5.1.1. RHEL 8에서 제어 노드 준비

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

사전 요구 사항

  • RHEL 8.6 이상이 설치되어 있어야 합니다. RHEL 설치에 대한 자세한 내용은 설치 미디어에서 RHEL 상호 작용 설치를 참조하십시오.

    참고

    RHEL 8.5 및 이전 버전에서 Ansible 패키지는 Ansible Core 대신 Ansible Engine을 통해 제공되었으며 다른 수준의 지원이 제공되었습니다. 패키지가 RHEL 8.6 이상의 Ansible 자동화 콘텐츠와 호환되지 않을 수 있으므로 Ansible Engine을 사용하지 마십시오. 자세한 내용은 RHEL 9 및 RHEL 8.6 이상 AppStream 리포지토리에 포함된 Ansible Core 패키지에 대한 지원 범위를 참조하십시오.

  • 시스템이 고객 포털에 등록되어 있습니다.
  • 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]# yum 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/ 디렉터리에 컬렉션을 설치합니다.

다음 단계

5.1.2. 관리형 노드 준비

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

사전 요구 사항

  • 제어 노드를 준비합니다. 자세한 내용은 RHEL 8에서 제어 노드 준비를 참조하십시오.
  • 제어 노드에서 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 all -m command -a whoami
    BECOME password: <password>
    managed-node-01.example.com | CHANGED | rc=0 >>
    root
    ...

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

추가 리소스

5.2. 메트릭 RHEL 시스템 역할 소개

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

추가 리소스

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

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

다음 절차에서는 지표 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/ 디렉터리

5.4. RHEL 시스템 역할을 지표로 사용하여 자체적으로 모니터링할 개별 시스템 설정

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

사전 요구 사항

절차

  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/ 디렉터리

5.5. RHEL 시스템 역할을 지표로 사용하여 로컬 시스템을 사용하여 중앙에 있는 시스템을 모니터링

다음 절차에서는 메트릭 시스템 역할을 사용하여 시스템 플릿을 중앙에서 모니터링하면서 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/ 디렉터리

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

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

검증

  • the 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/ 디렉터리

5.7. RHEL 시스템 역할을 메트릭 을 사용하여 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 명령을 사용하여mssql(SQL 서버 PMDA 에이전트)이 로드되고 실행 중인지 확인합니다.

    # 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

추가 리소스

6장. PCP 설정

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

6.1. PCP 개요

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

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

PCP의 특징:

  • 복잡한 시스템의 중앙 집중식 분석 중에 유용한 경량 분산 아키텍처.
  • 실시간 데이터의 모니터링 및 관리를 가능하게 합니다.
  • 기록 데이터를 로깅 및 검색할 수 있습니다.

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

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

6.2. PCP 설치 및 활성화

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

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

절차

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

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

추가 리소스

6.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 도구를 사용하여 데이터를 분석합니다.

추가 리소스

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

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

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

pmcd
PMCD(성능 지표 수집기 데몬).
pmie
성능 지표 추론 엔진.
pmlogger
성능 지표 로거.
pmproxy
실시간 및 기록 성능 지표 프록시, 시계열 쿼리 및 REST API 서비스.

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

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

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

pcp-atop
성능 관점에서 가장 중요한 하드웨어 리소스의 시스템 수준 표시. CPU, 메모리, 디스크 및 네트워크.
pcp-atopsar
다양한 시스템 리소스 활용도에 대한 시스템 수준 활동 보고서를 생성합니다. 이 보고서는 pmlogger 또는 pcp-atop-w 옵션을 사용하여 이전에 기록된 원시 로그 파일에서 생성됩니다.
pcp-dmcache
장치 IOP, 캐시 및 메타데이터 장치 사용률과 같은 구성된 장치 매퍼 캐시 대상에 대한 정보와 각 캐시 장치의 읽기 및 쓰기에 대한 적중률 및 누락 비율 정보가 표시됩니다.
pcp-dstat
한 번에 하나의 시스템의 지표를 표시합니다. 여러 시스템의 지표를 표시하려면 --host 옵션을 사용합니다.
pcp-free
시스템의 사용 가능한 메모리와 사용 중인 메모리에 대해 보고합니다.
pcp-htop
top 명령과 유사하게 명령줄 인수와 함께 시스템에서 실행되는 모든 프로세스를 표시하지만 마우스를 사용하여 수직 및 수평으로 스크롤할 수 있습니다. 또한 트리 형식으로 프로세스를 보고 여러 프로세스에 대해 한 번에 선택하고 실행할 수 있습니다.
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-Pilot 기능을 통해 사용할 수 있는 성능 지표 값을 나타냅니다.
pmdumptext
실시간 또는 Performance Co-Pilot 아카이브에서 수집된 성능 지표 값을 출력합니다.

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

pmclient
PMAPI(성능 지표 애플리케이션 프로그래밍 인터페이스)를 사용하여 고급 시스템 성능 지표를 표시합니다.
pmdbg
사용 가능한 Performance Co-Pilot 디버그 제어 플래그 및 해당 값을 표시합니다.
pmerr
사용 가능한 Performance Co-Pilot 오류 코드 및 해당 오류 메시지를 표시합니다.

6.5. PCP 배포 아키텍처

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

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

참고

PCP 버전 5.3.0은 Red Hat Enterprise Linux 8.4 및 이전 Red Hat Enterprise Linux 8 마이너 버전에서 사용할 수 없으므로 localhost 및 pmlogger 팜 아키텍처를 사용하는 것이 좋습니다.

5.3.0 이전의 PCP 버전의 pmproxy에서 알려진 메모리 누수에 대한 자세한 내용은 PCP의 pmproxy에서 메모리 누수를 참조하십시오.

localhost

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

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

분산

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

그림 6.1. 분산된 로깅

분산된 로깅
중앙 집중식 로깅 - pmlogger 팜

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

그림 6.2. 중앙 집중식 로깅 - pmlogger 팜

중앙 집중식 로깅 - pmlogger 팜
페더레이션 - 여러 pmlogger 팜

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

그림 6.3. 페더레이션 - 여러 pmlogger 팜

페더레이션 - 여러 pmlogger 팜
참고

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

추가 리소스

6.7. 크기 조정 요소

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

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

추가 리소스

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

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

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

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

pmproxy 서비스는 기록된 지표를 pmlogger 에서 Redis 인스턴스로 보냅니다. 다음은 /etc/pcp/pmproxy/pmproxy.conf 구성 파일에서 보존 설정을 지정하는 데 사용할 수 있는 두 가지 옵션입니다.

  • stream.expire 는 오래된 지표를 제거해야 하는 경우의 기간을 지정합니다. 이 값은 지정된 시간(초) 내에 업데이트되지 않은 지표입니다.
  • stream.maxlen 은 호스트당 하나의 지표에 대한 최대 지표 값 수를 지정합니다. 이 설정은 로깅 간격으로 분할된 보존 시간이어야 합니다(예: 14일 보존 및 60일 로깅 간격(60*60*24*14/60)

추가 리소스

  • pmproxy(1), pmlogger(1)sysctl(8) 도움말 페이지

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

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

로깅 간격은 10초이고 원격 노드의 proc 지표는 포함되지 않으며, 메모리 값은RSS(Resident Set Size) 값을 참조합니다.

표 6.2. 10초 로깅 간격에 대한 자세한 사용 통계
호스트 수1050

PCP 아카이브 스토리지(1일당 스토리지)

91 MB

522MB

pmlogger 메모리

160MB

580MB

Day당 pmlogger 네트워크(In)

2MB

9MB

pmproxy 메모리

1.4GB

6.3GB

일당 Redis 메모리

2.6GB

12GB

표 6.3. 60초 로깅 간격을 위해 모니터링된 호스트에 따라 사용된 리소스
호스트 수1050100

PCP 아카이브 스토리지(1일당 스토리지)

20MB

120MB

271MB

pmlogger 메모리

104MB

524MB

1049MB

Day당 pmlogger 네트워크(In)

0.38 MB

1.75MB

3.48MB

pmproxy 메모리

2.67GB

5.5GB

9GB

일당 Redis 메모리

0.54GB

2.65GB

5.3GB

참고

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

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

다음은 3개의 중앙 로깅( pmlogger 팜) 설정으로 구성된 페더레이션 팜으로 알려진 페더레이션 설정에서 관찰되었으며, 각 pmlogger 팜은 100대의 원격 호스트를 모니터링했으며, 이 설정은 총 300개의 호스트입니다.

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

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

표 6.4. 60초 로깅 간격 동안 페더레이션 호스트에 따라 사용된 리소스
PCP 아카이브 스토리지(1일당 스토리지)pmlogger 메모리날짜당 네트워크 (In/Out)pmproxy 메모리일당 Redis 메모리

277MB

1058MB

15.6 MB / 12.3 MB

6-8GB

5.5GB

여기에서 모든 값은 호스트당입니다. 네트워크 대역폭은 Redis 클러스터의 노드 간 통신 때문에 더 높습니다.

6.11. 메모리 사용량이 많은 문제 해결

다음 시나리오는 메모리 사용량이 높을 수 있습니다.

  • pmproxy 프로세스는 새로운 PCP 아카이브를 처리하는데 사용되며, Redis 요청 및 응답을 처리하는 예비 CPU 사이클이 없습니다.
  • Redis 노드 또는 클러스터는 과부하되어 입력되는 요청을 제때 처리할 수 없습니다.

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

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

사전 요구 사항

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

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

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

절차

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

    $ 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

    이 열에는 진행 중 요청 수가 표시됩니다. 즉, 대기 또는 전송되었음을 의미하며 지금까지 응답이 수신되지 않았습니다.

    높은 숫자는 다음 조건 중 하나를 나타냅니다.

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

    Redis 노드에서 오랜 시간 동안 100% CPU를 사용하고 있는 경우 성능이 더 뛰어난 호스트로 이동하거나 클러스터형 Redis setup을 대신 사용하십시오.

  • 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이지만 대규모 pmlogger 팜을 사용하여 빌드할 수 있으며 이는 확장성을 제한하고 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 지표를 참조하십시오.

추가 리소스

7장. pmlogger를 사용하여 성능 데이터 로깅

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

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

  • 시스템에서 선택한 메트릭의 아카이브된 로그를 생성합니다.
  • 시스템에 기록되는 메트릭과 빈도를 지정합니다.

7.1. pmlogconf를 사용하여 pmlogger 구성 파일 수정

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

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

사전 요구 사항

절차

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

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

추가 리소스

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

추가 리소스

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

추가 리소스

7.4. 메트릭 컬렉션을 위한 클라이언트 시스템 설정

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

사전 요구 사항

절차

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

    # yum 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))

추가 리소스

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

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

사전 요구 사항

절차

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

    # yum 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.13,192.168.4.14192.168.4.62 를 클라이언트 IP 주소로 바꿉니다.

    참고

    Red Hat Enterpirse Linux 8.0에서 8.1 및 8.2는 제어 파일의 원격 호스트에 대해 다음 형식을 사용합니다. PCP_LOG_DIR/pmlogger/host_name.

  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/ 디렉토리의 아카이브 파일을 추가 분석 및 그래프 작성에 사용할 수 있습니다.

추가 리소스

7.6. systemd 단위 및 pmlogger

pmlogger 서비스를 여러 원격 호스트에서 지표를 수집하는 단일 호스트가 있는 단일 호스트 모니터링 자체 또는 pmlogger 로 배포할 때 자동으로 배포되는 몇 가지 관련 systemd 서비스 및 타이머 장치가 있습니다. 이러한 서비스 및 타이머는 일상적인 검사를 제공하여 pmlogger 인스턴스가 실행 중인지 확인하고 누락된 인스턴스를 다시 시작한 다음 파일 압축과 같은 아카이브 관리를 수행합니다.

pmlogger 에서 일반적으로 배포한 검사 및 하우스키핑 서비스는 다음과 같습니다.

pmlogger_daily.service
기본적으로 자정 직후에 매일 실행되어 하나 이상의 PCP 아카이브 세트를 집계, 압축 및 순환합니다. 또한 culls는 제한보다 오래된 아카이브(기본적으로 2주)입니다. pmlogger_daily.timer 유닛에 의해 트리거되었으며 pmlogger.service 장치에서 필요합니다.
pmlogger_check
반 시간 동안은 pmlogger 인스턴스가 실행 중인지 확인합니다. 누락된 인스턴스를 재시작하고 필요한 압축 작업을 수행합니다. pmlogger_check.timer 유닛에 의해 트리거되었으며 pmlogger.service 유닛에 필요합니다.
pmlogger_farm_check
구성된 모든 pmlogger 인스턴스의 상태를 확인합니다. 누락된 인스턴스를 다시 시작합니다. 기본이 아닌 모든 인스턴스를 pmlogger_farm 서비스로 마이그레이션합니다. pmlogger_farm_check.timer 에서는 pmlogger_farm.service 장치에서 자체적으로 필요한 pmlogger_farm.service 유닛에 의해 트리거됩니다.

이러한 서비스는 일련의 긍정적인 종속 항목을 통해 관리되므로 기본 pmlogger 인스턴스를 활성화할 때 모두 활성화됩니다. pmlogger_daily.service 는 기본적으로 비활성화되어 있지만 pmlogger_daily.timerpmlogger.service 와의 종속성을 통해 활성 상태입니다. pmlogger_daily.service 가 실행되는 것을 트리거합니다.

pmlogger_daily 는 병합하기 전에 자동으로 아카이브 다시 쓰기를 위해 pmlogrewrite 와 통합되어 있습니다. 이를 통해 변경 프로덕션 환경 및 PMDAs의 메타데이터 일관성을 유지할 수 있습니다. 예를 들어, 로깅 간격 동안 모니터링되는 호스트에서 pmcd 가 업데이트되면 호스트의 일부 지표에 대한 의미 체계가 업데이트될 수 있으므로 해당 호스트에서 이전에 기록된 아카이브와 호환되지 않는 새 아카이브가 생성됩니다. 자세한 내용은 pmlogrewrite(1) 매뉴얼 페이지를 참조하십시오.

pmlogger에서 트리거한 systemd 서비스 관리

pmlogger 인스턴스에서 수집한 데이터에 대한 자동화된 사용자 지정 아카이브 관리 시스템을 생성할 수 있습니다. 이 작업은 제어 파일을 사용하여 수행됩니다. 이러한 제어 파일은 다음과 같습니다.

  • 기본 pmlogger 인스턴스의 경우:

    • etc/pcp/pmlogger/control
    • /etc/pcp/pmlogger/control.d/local
  • 원격 호스트의 경우:

    • /etc/pcp/pmlogger/control.d/remote

      remote 를 원하는 파일 이름으로 교체합니다.

      참고
      기본 pmlogger 인스턴스는 연결된 pmcd 와 동일한 호스트에서 실행되어야 합니다. 기본 인스턴스가 필요하지 않으며 하나의 중앙 호스트에서 원격 호스트에서 실행 중인 pmcd 인스턴스에 연결된 여러 pmlogger 인스턴스에서 데이터를 수집하는 경우 구성에 필요하지 않을 수 있습니다.

파일에는 로깅할 각 호스트에 대해 하나의 행이 포함되어야 합니다. 자동으로 생성되는 기본 로거 인스턴스의 기본 형식은 다음과 유사합니다.

# === LOGGER CONTROL SPECIFICATIONS ===
#
#Host   	 P?  S?    directory   		 args

# local primary logger
LOCALHOSTNAME    y   n    PCP_ARCHIVE_DIR/LOCALHOSTNAME    -r -T24h10m -c config.default -v 100Mb

필드는 다음과 같습니다.

호스트
기록할 호스트의 이름
P?
"Primary"입니다. 이 필드는 호스트가 기본 로거 인스턴스인지 y, n 인지 여부를 나타냅니다. 구성의 모든 파일에 대해 하나의 기본 로거만 있을 수 있으며 연결된 pmcd 와 동일한 호스트에서 실행되어야 합니다.
S?
예를 들면 "Socks"입니다. 이 필드는 이 로거 인스턴스에서 방화벽, y 또는 not, n 을 통해 pmcd 에 연결하는 데 Cryostat 프로토콜을 사용해야 하는지 여부를 나타냅니다.
디렉터리
이 행과 연결된 모든 아카이브는 이 디렉터리에 생성됩니다.
args

인수는 pmlogger 에 전달됩니다.

args 필드의 기본값은 다음과 같습니다.

-r
아카이브 크기 및 증가 속도를 보고합니다.
T24h10m
매일 로깅을 종료할 시기를 지정합니다. 일반적으로 pmlogger_daily.service 가 실행되는 시간입니다. 기본값 24h10m 은 로깅이 시작된 후 24 시간 및 10 분 후에 종료되어야 함을 나타냅니다.
-c config.default
사용할 구성 파일을 지정합니다. 이는 기본적으로 기록할 메트릭을 정의합니다.
-v 100Mb
한 데이터 볼륨이 채워지고 다른 데이터 볼륨이 생성되는 크기를 지정합니다. 새 아카이브로 전환하면 이전에 기록된 파일이 pmlogger_daily 또는 pmlogger_check 에 의해 압축됩니다.

추가 리소스

  • pmlogger(1) 도움말 페이지
  • pmlogger_daily(1) 매뉴얼 페이지
  • pmlogger_check(1) 매뉴얼 페이지
  • pmlogger.control(5) 도움말 페이지
  • pmlogrewrite(1) 매뉴얼 페이지

7.7. pmrep를 사용하여 PCP 로그 아카이브 재생

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

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

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

사전 요구 사항

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

    # yum 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 아카이브가 포함된 파일 이름으로 바꿉니다.

추가 리소스

8장. Performance Co-Pilot을 통한 성능 모니터링

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

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

8.1. pmda-postfix를 사용하여 postfix 모니터링

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

사전 요구 사항

절차

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

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

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

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

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

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

    # systemctl enable postfix rsyslog
    # systemctl restart postfix rsyslog
  3. pmda-postfix 가 필요한 로그 파일에 액세스할 수 있도록 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-postfix 작업을 확인합니다.

    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

추가 리소스

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

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

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

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

사전 요구 사항

절차

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

    # pmchart

    그림 8.1. PCP Charts 애플리케이션

    pmchart 시작

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

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

    다음은 PCP Charts 애플리케이션에 생성된 뷰를 기록하거나 이미지를 가져오는 옵션입니다.

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

    PCP Charts 애플리케이션 보기 구성 파일의 다음 예제에서는 지정된 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"

추가 리소스

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

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

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

사전 요구 사항

  • Microsoft SQL Server for Red Hat Enterprise Linux를 설치하고 SQL 서버에 '신뢰할 수 있는' 연결을 구축했습니다.
  • Red Hat Enterprise Linux용 SQL Server용 Microsoft ODBC 드라이버를 설치했습니다.

절차

  1. PCP를 설치합니다.

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

    # yum install gcc-c++ python3-devel unixODBC-devel
    
    # yum install python3-pyodbc
  3. mssql 에이전트를 설치합니다.

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

      # yum 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 명령을 사용하여mssql(SQL 서버 PMDA)이 로드되고 실행 중인지 확인합니다.

    $ 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 Charts 애플리케이션을 사용하여 시각적으로 PCP 로그 아카이브 추적을 참조하십시오.

추가 리소스

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

XFS PMDA는 pcp 패키지의 일부로 제공되며 설치 중에 기본적으로 활성화됩니다. PCP(Performance Co-Pilot)에서 XFS 파일 시스템의 성능 지표 데이터를 수집하는 데 사용됩니다.

PCP를 사용하여 XFS 파일 시스템의 성능을 분석할 수 있습니다.

9.1. 수동으로 XFS PMDA 설치

XFS PMDA가 pcp 구성 출력에 나열되지 않은 경우 수동으로 PMDA 에이전트를 설치합니다.

이 절차에서는 PMDA 에이전트를 수동으로 설치하는 방법을 설명합니다.

사전 요구 사항

절차

  1. xfs 디렉터리로 이동합니다.

    # cd /var/lib/pcp/pmdas/xfs/
  2. XFS PMDA를 수동으로 설치합니다.

    xfs]# ./Install
    
    You will need to choose an appropriate configuration for install of
    the “xfs” Performance Metrics Domain Agent (PMDA).
    
      collector     collect performance statistics on this system
      monitor       allow this system to monitor local and/or remote systems
      both          collector and monitor configuration for this system
    
    Please enter c(ollector) or m(onitor) or (both) [b]
    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 xfs metrics have appeared ... 149 metrics and 149 values
  3. 컬렉터에 c, monitor에 대해 m 또는 둘 다에 대해 c를 입력하여 원하는 PMDA 역할을 선택합니다. PMDA 설치 스크립트에서 다음 PMDA 역할 중 하나를 지정하라는 메시지를 표시합니다.

    • 수집기 역할을 사용하면 현재 시스템에 대한 성능 지표를 수집할 수 있습니다.
    • 모니터 역할을 사용하면 시스템에서 로컬 시스템, 원격 시스템 또는 둘 다를 모니터링할 수 있습니다.

      기본 옵션은 수집기모니터 이며, 대부분의 시나리오에서 XFS PMDA가 올바르게 작동할 수 있습니다.

검증

  • pmcd 프로세스가 호스트에서 실행 중이며 XFS PMDA가 구성에서 enabled로 나열되는지 확인합니다.

    # 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

추가 리소스

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

추가 리소스

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

추가 리소스

9.4. XFS용 PCP 지표 그룹

다음 표에서는 XFS에 사용할 수 있는 PCP 지표 그룹을 설명합니다.

표 9.1. XFS의 지표 그룹

메트릭 그룹

제공되는 지표

XFS.*

읽기 및 쓰기 작업 수, 바이트 수 읽기 및 쓰기 횟수를 포함한 일반 XFS 지표. inode 수에 대한 카운터와 함께 플러시, 클러스터링 및 클러스터 실패 횟수가 함께 제공됩니다.

XFS.allocs.*

xfs.alloc_btree.*

파일 시스템에서 개체 할당과 관련된 지표 범위로, 여기에는 익스텐트 및 블록 생성/무료 수가 포함됩니다. btree에서 레코드 생성 및 삭제 확장과 함께 트리 조회 할당 및 비교.

xfs.block_map.*

xfs.bmap_btree.*

지표에는 읽기/쓰기 및 블록 삭제, 삽입, 삭제 및 조회에 대한 익스텐트 목록 작업, 블록 맵 수가 포함됩니다. 블록 맵의 비교, 조회, 삽입 및 삭제 작업을 위한 작업 카운터도 있습니다.

xfs.dir_ops.*

생성, 항목 삭제, "입력" 작업 수에 대한 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 버퍼 오브젝트와 관련된 지표 범위. 카운터에는 페이지를 찾을 때 요청된 버퍼 호출 수, 성공적인 버퍼 잠금, 대기된 버퍼 잠금, 누락_locks, miss_retries 및 버퍼 적중이 포함됩니다.

XFS.btree.*

XFS btree의 작업과 관련된 지표입니다.

xfs.control.reset

XFS 통계의 지표 카운터를 재설정하는 데 사용되는 구성 지표입니다. 제어 지표는 pmstore 툴을 통해 토글됩니다.

9.5. XFS의 장치당 PCP 지표 그룹

다음 테이블에서는 XFS에 사용할 수 있는 장치별 PCP 지표 그룹을 설명합니다.

표 9.2. XFS의 장치당 PCP 지표 그룹

메트릭 그룹

제공되는 지표

xfs.perdev.*

읽기 및 쓰기 작업 수, 바이트 수 읽기 및 쓰기 횟수를 포함한 일반 XFS 지표. inode 수에 대한 카운터와 함께 플러시, 클러스터링 및 클러스터 실패 횟수가 함께 제공됩니다.

xfs.perdev.allocs.*

xfs.perdev.alloc_btree.*

파일 시스템에서 개체 할당과 관련된 지표 범위로, 여기에는 익스텐트 및 블록 생성/무료 수가 포함됩니다. btree에서 레코드 생성 및 삭제 확장과 함께 트리 조회 할당 및 비교.

xfs.perdev.block_map.*

xfs.perdev.bmap_btree.*

지표에는 읽기/쓰기 및 블록 삭제, 삽입, 삭제 및 조회에 대한 익스텐트 목록 작업, 블록 맵 수가 포함됩니다. 블록 맵의 비교, 조회, 삽입 및 삭제 작업을 위한 작업 카운터도 있습니다.

xfs.perdev.dir_ops.*

생성, 항목 삭제, "입력" 작업 수에 대한 XFS 파일 시스템의 디렉터리 작업 카운터입니다.

xfs.perdev.transactions.*

메타 데이터 트랜잭션 수에 대한 카운터에는 동기 및 비동기 트랜잭션 수와 빈 트랜잭션 수가 포함됩니다.

xfs.perdev.inode_ops.*

운영 체제에서 다양한 결과가 있는 inode 캐시에서 XFS inode를 찾는 횟수의 카운터입니다. 이러한 개수 캐시 적중, 캐시 누락 등.

xfs.perdev.log.*

xfs.perdev.log_tail.*

XFS 파일보다 로그 버퍼 쓰기 횟수에 대한 카운터에는 디스크에 작성된 블록 수가 포함됩니다. 또한 로그 플러시 및 고정 수에 대한 지표입니다.

xfs.perdev.xstrat.*

XFS 플러시 데밍에 의해 플러시되는 파일 데이터 바이트 수와 디스크의 연속되지 않은 공간으로 플러시되는 버퍼 수에 대한 카운터를 계산합니다.

xfs.perdev.attr.*

모든 XFS 파일 시스템에 대한 get, set, remove 및 list 속성 수에 대한 개수입니다.

xfs.perdev.quota.*

XFS 파일 시스템을 통한 할당량 작업에 대한 메트릭에는 할당량 회수, 할당량 캐시 누락, 캐시 적중 및 할당량 데이터 회수 횟수에 대한 카운터가 포함됩니다.

xfs.perdev.buffer.*

XFS 버퍼 오브젝트와 관련된 지표 범위. 카운터에는 페이지를 찾을 때 요청된 버퍼 호출 수, 성공적인 버퍼 잠금, 대기된 버퍼 잠금, 누락_locks, miss_retries 및 버퍼 적중이 포함됩니다.

xfs.perdev.btree.*

XFS btree의 작업과 관련된 지표입니다.

10장. PCP 메트릭의 그래픽 표현 설정

pcp ,grafana, pcp redis,pcp bpftrace 벡터 의 조합을 사용하면 라이브 데이터 또는 PCP(Performance Co-Pilot)에서 수집한 데이터에 대한 그래픽 표현이 제공됩니다.

10.1. pcp-zeroconf를 사용하여 PCP 설정

다음 절차에서는 pcp-zeroconf 패키지를 사용하여 시스템에 PCP를 설정하는 방법을 설명합니다. pcp-zeroconf 패키지가 설치되면 시스템은 기본 지표 집합을 보관된 파일에 기록합니다.

절차

  • pcp-zeroconf 패키지를 설치합니다.

    # yum install pcp-zeroconf

검증

  • pmlogger 서비스가 활성 상태인지 확인하고 메트릭을 보관하기 시작합니다.

    # pcp | grep pmlogger
     pmlogger: primary logger: /var/log/pcp/pmlogger/localhost.localdomain/20200401.00.12

추가 리소스

10.2. grafana-server 설정

Grafana는 브라우저에서 액세스할 수 있는 그래프를 생성합니다. grafana-server 는 Grafana 대시보드의 백엔드 서버입니다. 기본적으로 모든 인터페이스에서 수신 대기하고 웹 브라우저를 통해 액세스하는 웹 서비스를 제공합니다. grafana-pcp 플러그인은 백엔드의 pmproxy 프로토콜과 상호 작용합니다.

이 절차에서는 grafana-server 를 설정하는 방법을 설명합니다.

사전 요구 사항

절차

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

    # yum 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 도움말 페이지

10.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 링크를 사용하여 포트 3000 에서 grafana-server 에 액세스합니다.

    192.0.2.0 을 사용자 시스템 IP로 바꿉니다.

  2. 첫 번째 로그인에 대해 Email(이메일) 또는 username (사용자 이름) 및 Password(암호 ) 필드에 모두 admin 을 입력합니다.

    Grafana는 보안 계정을 생성하기 위해 새 암호를 설정하라는 메시지를 표시합니다. 나중에 설정하려면 Skip (뛰기)를 클릭합니다.

  3. 메뉴에서 grafana gear icon 구성 아이콘 위에 커서를 이동한 다음 플러그인 을 클릭합니다.
  4. 플러그 탭에서 Search by name(이름으로 검색)에 performance co-pilot을 입력하거나 텍스트 상자를 입력한 다음 PCP( Performance Co-Pilot ) 플러그인을 클릭합니다.
  5. Plugins / Performance Co-Pilot 창에서 Enable(활성화 )을 클릭합니다.
  6. Grafana grafana home page whirl icon 아이콘을 클릭합니다. Grafana 페이지가 표시됩니다.

    그림 10.1. 홈 대시보드

    Grafana 홈 대시보드
    참고

    화면의 상단에는 유사한 grafana top corner settings icon 아이콘이 있지만 일반 대시보드 설정을 제어합니다.

  7. Grafana 페이지에서 첫 번째 데이터 소스 추가를 클릭하여 PCP Redis, PCP bpftrace 및 PCP Vector 데이터 소스를 추가합니다. 데이터 소스 추가에 대한 자세한 내용은 다음을 참조하십시오.

  8. 선택 사항: 메뉴에서 admin 프로필 grafana logout option icon 아이콘 위에 커서를 이동 하여 프로필 편집,암호 변경 또는 로그아웃을 포함한 IRQ를 변경합니다.

추가 리소스

  • grafana-cligrafana-server 도움말 페이지

10.4. PCP Redis 구성

PCP Redis 데이터 소스를 사용하여 다음을 수행합니다.

  • 데이터 아카이브 보기
  • pmseries 언어를 사용하여 시계열 쿼리
  • 여러 호스트에서 데이터 분석

사전 요구 사항

  1. PCP가 구성되어 있습니다. 자세한 내용은 pcp-zeroconf를 사용하여 PCP 설정을 참조하십시오.
  2. grafana-server 가 구성되어 있습니다. 자세한 내용은 Settings up a grafana-server 를 참조하십시오.
  3. 메일 전송 에이전트(예: sendmail 또는 postfix )가 설치 및 구성되어 있습니다.

절차

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

    # yum module install redis:6
    참고

    Red Hat Enterprise Linux 8.4에서 Redis 6은 지원되지만 yum update 명령은 Redis 5를 Redis 6로 업데이트하지 않습니다. Redis 5에서 Redis 6로 업데이트하려면 다음을 실행합니다.

    # yum module switch-to redis:6

  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) 도움말 페이지

10.5. PCP Redis 데이터 소스에서 패널 및 경고 생성

PCP Redis 데이터 소스를 추가한 후에는 유용한 지표의 개요로 대시보드를 보고, 쿼리를 추가하여 부하 그래프를 시각화하고, 발생한 후 시스템 문제를 확인하는 데 도움이 되는 경고를 만들 수 있습니다.

사전 요구 사항

  1. PCP Redis가 구성됩니다. 자세한 내용은 PCP Redis 구성을 참조하십시오.
  2. grafana-server 에 액세스할 수 있습니다. 자세한 내용은 Grafana 웹 UI 액세스를 참조하십시오.

절차

  1. Grafana 웹 UI에 로그인합니다.
  2. Grafana 페이지에서 첫 번째 데이터 소스 추가를 클릭합니다.
  3. Add data source (데이터 소스 추가) 창에서 Filter by name(이름으로 필터링)에 redis를 입력하거나 텍스트 상자를 입력한 다음 PCP Redis 를 클릭합니다.
  4. Data Sources / PCP Redis 창에서 다음을 수행합니다.

    1. URL 필드에 http://localhost:44322 을 추가한 다음 Save & Test (저장 및 테스트)를 클릭합니다.
    2. Dashboards 탭ImportPCP Redis를 클릭합니다. 호스트 개요 는 유용한 메트릭에 대한 개요가 있는 대시보드를 확인합니다.

      그림 10.2. PCP 빨간색: 호스트 개요

      PCP redis 호스트 개요
  5. 새 패널을 추가합니다.

    1. 메뉴에서 grafana plus sign 아이콘 생성 대시보드 추가 새 패널 아이콘 위에 커서를 이동하여 패널을 추가합니다.
    2. 쿼리 탭의 선택한 기본 옵션 대신 쿼리 목록에서 PCP Redis 를 선택하고 텍스트 필드에서 metric (예: kernel .all.load)를 입력하여 커널 로드 그래프를 시각화합니다.
    3. 선택 사항: 패널 제목과 설명을 추가하고 Settings (설정)에서 다른 옵션을 업데이트합니다.
    4. Save(저장 )를 클릭하여 변경 사항을 적용하고 대시보드를 저장합니다. 대시보드 이름 추가.
    5. Apply(적용 )를 클릭하여 변경 사항을 적용하고 대시보드로 돌아갑니다.

      그림 10.3. PCP Redis 쿼리 패널

      PCP redis 쿼리 패널
  6. 경고 규칙을 생성합니다.

    1. PCP Redis 쿼리 패널에서 redis alert icon 경고 를 클릭한 다음 경고 생성을 클릭합니다.
    2. Rule (규칙)에서 Name (이름),Evaluate(평가 쿼리 ) 및 For (예) 필드를 편집하고 경고에 대한 Conditions (조건)를 지정합니다.
    3. Save(저장 )를 클릭하여 변경 사항을 적용하고 대시보드를 저장합니다. Apply(적용 )를 클릭하여 변경 사항을 적용하고 대시보드로 돌아갑니다.

      그림 10.4. PCP Redis 패널에서 경고 생성

      PCP redis 쿼리 경고 패널
    4. 선택 사항: 동일한 패널에서 아래로 스크롤하고 Delete(삭제 ) 아이콘을 클릭하여 생성된 규칙을 삭제합니다.
    5. 선택 사항: 메뉴에서 alerting bell icon 경고 아이콘을 클릭하여 다양한 경고 상태로 생성된 경고 규칙을 확인하거나, 경고 규칙을 편집하거나, 경고 규칙 탭에서 기존 규칙을 일시 중지합니다.

      Grafana에서 경고 알림을 받기 위해 생성된 경고 규칙에 대한 알림 채널을 추가하려면 알림 채널 추가를 참조하십시오.

10.6. 경고에 대한 알림 채널 추가

알림 채널을 추가하면 경고 규칙 조건이 충족되고 시스템에서 추가 모니터링이 필요한 경우 Grafana로부터 알림 알림을 받을 수 있습니다.

이 경고는 DingDing,Discord,Email,Google¢outs Chat,HipChat,Kafka REST Proxy,,Microsoft Teams,OpsGenie 가 포함된 지원되는 알림기 목록에서 한 가지 유형을 선택한 후 수신할 수 있습니다. PagerDuty,Prometheus Alertmanager,Pushover,Sensu,Slack,, threema Gateway,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. Add notification 채널 세부 정보 창에서 다음을 수행합니다.

    1. Name (이름) 텍스트 상자에 이름을 입력합니다.
    2. 통신 유형 (예: Email)을 선택하고 이메일 주소를 입력합니다. 구분 기호를 사용하여 여러 이메일 주소를 추가할 수 있습니다.
    3. 선택 사항: 선택적 이메일 설정알림 설정 구성.
  3. 저장을 클릭합니다.
  4. 경고 규칙에서 알림 채널을 선택합니다.

    1. 메뉴에서 alerting bell icon 경고 아이콘 위에 커서를 이동한 다음 경고 규칙을 클릭합니다.
    2. Alert Rules(경고 규칙 ) 탭에서 생성된 경고 규칙을 클릭합니다.
    3. Notifications (알림) 탭의 Send to (보내기) 옵션에서 알림 채널 이름을 선택한 다음 경고 메시지를 추가합니다.
    4. Apply(적용)를 클릭합니다.

10.7. PCP 구성 요소 간 인증 설정

SASL(Simple Authentication Security Layer) 프레임워크를 통해 PCP에서 지원하는 scram-sha-256 인증 메커니즘을 사용하여 인증을 설정할 수 있습니다.

참고

Red Hat Enterprise Linux 8.3에서 PCP는 scram-sha-256 인증 메커니즘을 지원합니다.

절차

  1. scram-sha-256 인증 메커니즘을 위한 the sasl 프레임워크를 설치합니다.

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

검증

  • the sasl 구성을 확인합니다.

    # pminfo -f -h "pcp://127.0.0.1?username=metrics" disk.dev.read
    Password:
    disk.dev.read
    inst [0 or "sda"] value 19540

10.8. PCP bpftrace 설치

PCP bpftrace 에이전트를 설치하여 시스템을 세부 검사하고 커널 및 사용자 공간 추적 지점에서 지표를 수집합니다.

bpftrace 에이전트는 bpftrace 스크립트를 사용하여 지표를 수집합니다. bpftrace 스크립트는eBPF(Berkeley Packet Filter)를 사용합니다.

다음 절차에서는 pcp bpftrace 를 설치하는 방법을 설명합니다.

사전 요구 사항

  1. PCP가 구성되어 있습니다. 자세한 내용은 pcp-zeroconf를 사용하여 PCP 설정을 참조하십시오.
  2. grafana-server 가 구성되어 있습니다. 자세한 내용은 Settings up a grafana-server 를 참조하십시오.
  3. scram-sha-256 인증 메커니즘이 구성되어 있습니다. 자세한 내용은 PCP 구성 요소 간 인증 설정을 참조하십시오.

절차

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

    # yum install pcp-pmda-bpftrace
  2. bpftrace.conf 파일을 편집하고 {setting-up-authentication- betweenween-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 System Analysis dashboard 보기를 참조하십시오.

추가 리소스

  • pmdabpftrace(1)bpftrace 도움말 페이지

10.9. PCP bpftrace 시스템 분석 대시보드 보기

PCP bpftrace 데이터 소스를 사용하여 pmlogger 또는 아카이브에서 일반 데이터로 사용할 수 없는 소스에서 라이브 데이터에 액세스할 수 있습니다.

PCP bpftrace 데이터 소스에서 유용한 지표의 개요를 사용하여 대시보드를 볼 수 있습니다.

사전 요구 사항

  1. PCP bpftrace가 설치되어 있습니다. 자세한 내용은 PCP bpftrace 설치를 참조하십시오.
  2. grafana-server 에 액세스할 수 있습니다. 자세한 내용은 Grafana 웹 UI 액세스를 참조하십시오.

절차

  1. Grafana 웹 UI에 로그인합니다.
  2. Grafana 페이지에서 첫 번째 데이터 소스 추가를 클릭합니다.
  3. Add data source (데이터 소스 추가) 창에서 Filter by name(이름으로 필터링)에 bpftrace를 입력하거나 텍스트 상자에 bpftrace를 입력한 다음 PCP bpftrace 를 클릭합니다.
  4. Data Sources / PCP bpftrace 창에서 다음을 수행합니다.

    1. URL 필드에 http://localhost:44322 을 추가합니다.
    2. Basic Auth (기본 인증) 옵션을 토글하고 User and Password(사용자 및 암호 ) 필드에 생성된 사용자 자격 증명을 추가합니다.
    3. Save & Test (저장 및 테스트)를 클릭합니다.

      그림 10.5. 데이터 소스에 PCP bpftrace 추가

      bpftrace auth
    4. 대시보드 탭가져오기PCP bpftrace를 클릭합니다. 시스템 분석 은/는 유용한 메트릭의 개요가 있는 대시보드를 확인합니다.

      그림 10.6. PCP bpftrace: 시스템 분석

      PCP bpftrace bpftrace 시스템 분석

10.10. PCP 벡터 설치

다음 절차에서는 pcp 벡터 를 설치하는 방법을 설명합니다.

사전 요구 사항

  1. PCP가 구성되어 있습니다. 자세한 내용은 pcp-zeroconf를 사용하여 PCP 설정을 참조하십시오.
  2. grafana-server 가 구성되어 있습니다. 자세한 내용은 Settings up a grafana-server 를 참조하십시오.

절차

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

    # yum 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) 도움말 페이지

10.11. PCP 벡터 체크리스트 보기

PCP 벡터 데이터 소스는 라이브 지표를 표시하고 pcp 지표를 사용합니다. 개별 호스트에 대한 데이터를 분석합니다.

PCP 벡터 데이터 소스를 추가한 후에는 유용한 메트릭에 대한 개요를 통해 대시보드를 보고 체크리스트에서 관련 문제 해결 또는 참조 링크를 볼 수 있습니다.

사전 요구 사항

  1. PCP 벡터가 설치되어 있습니다. 자세한 내용은 PCP 벡터 설치를 참조하십시오.
  2. grafana-server 에 액세스할 수 있습니다. 자세한 내용은 Grafana 웹 UI 액세스를 참조하십시오.

절차

  1. Grafana 웹 UI에 로그인합니다.
  2. Grafana 페이지에서 첫 번째 데이터 소스 추가를 클릭합니다.
  3. Add data source (데이터 소스 추가) 창에서 Filter by name(이름으로 필터링)에ector를 입력하거나 텍스트 상자를 입력한 다음 PCP Vector (PCP 벡터)를 클릭합니다.
  4. Data Sources / PCP Vector 창에서 다음을 수행합니다.

    1. URL 필드에 http://localhost:44322 을 추가한 다음 Save & Test (저장 및 테스트)를 클릭합니다.
    2. 대시보드 탭가져오기PCP 벡터를 클릭합니다. 호스트 개요 는 유용한 메트릭에 대한 개요가 있는 대시보드를 확인합니다.

      그림 10.7. PCP 벡터: 호스트 개요

      PCP 벡터 호스트 개요
  5. 메뉴에서 pcp plugin in grafana Performance Co-Pilot 플러그인 위에 커서를 이동한 다음 PCP Vector Checklist 를 클릭합니다.

    PCP 체크리스트에서 pcp vector checklist troubleshooting doc 도움말 또는 pcp vector checklist warning 경고 아이콘을 클릭하여 관련 문제 해결 또는 참조 링크를 확인합니다.

    그림 10.8. Performance Co-Pilot / PCP 벡터 체크리스트

    PCP 벡터 체크리스트

10.12. Grafana에서 heatmaps 사용

Grafana에서 heatmaps를 사용하여 시간이 지남에 따라 데이터의 히스토그램을 보고, 데이터 추세와 패턴을 식별하고, 시간이 지남에 따라 어떻게 변경되는지 확인할 수 있습니다. heatmap 내의 각 열은 해당 히스토그램 내에서 지정된 값의 관찰의 다양한 밀도를 나타내는 다른 색상의 셀이 있는 단일 히스토그램을 나타냅니다.

중요

이 특정 워크플로는 Grafana 버전 9.2.10 이상에서 RHEL8의 heatmaps용입니다.

사전 요구 사항

절차

  1. 대시보드 탭 위에 커서를 올리고 + 새 대시보드 를 클릭합니다.
  2. 패널 추가 메뉴에서 새 패널 추가를 클릭합니다.
  3. 쿼리 탭에서 다음을 수행합니다.

    1. 선택한 기본 옵션 대신 쿼리 목록에서 PCP Redis 를 선택합니다.
    2. A 의 텍스트 필드에 지표를 입력합니다 (예: kernel.all.load ) 커널 로드 그래프를 시각화합니다.
  4. 기본적으로 시계열 로 설정된 시각화 드롭다운 메뉴를 클릭한 다음 Heatmap 을 클릭합니다.
  5. 선택 사항: Panel Options 드롭다운 메뉴에서 Panel 제목 및 설명을 추가합니다.
  6. Heatmap 드롭다운 메뉴의 데이터 설정에서 예를 클릭합니다.

    heatmap

    A configured Grafana heatmap

  7. 선택 사항: 색상 드롭다운 메뉴에서 기본 Orange 에서 Scheme 을 변경하고 단계 수(색영)를 선택합니다.
  8. 선택 사항: Tooltip 드롭다운 메뉴의 히스토그램(Y Cryostat) 설정에서 토글을 클릭하여 heatmap의 셀 위에 커서를 올리면 특정 히스토그램 내에 셀의 위치를 표시합니다. 예를 들면 다음과 같습니다.

    히스토그램(Ykafka) 셀 디스플레이 표시

    A cell’s specific position within its histogram

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

    여기서 1716 은 pmproxy의 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>
    [...]

11장. 웹 콘솔을 사용하여 시스템 성능 최적화

RHEL 웹 콘솔에서 성능 프로파일을 설정하여 선택한 작업에 대한 시스템의 성능을 최적화하는 방법을 알아봅니다.

11.1. 웹 콘솔의 성능 튜닝 옵션

Red Hat Enterprise Linux 8은 다음 작업을 위해 시스템을 최적화하는 여러 성능 프로필을 제공합니다.

  • 데스크탑을 사용하는 시스템
  • 처리량 성능
  • 대기 시간 성능
  • 네트워크 성능
  • 낮은 전력 소비
  • 가상 머신

TuneD 서비스는 선택한 프로필과 일치하도록 시스템 옵션을 최적화합니다.

웹 콘솔에서 시스템에서 사용하는 성능 프로필을 설정할 수 있습니다.

추가 리소스

11.2. 웹 콘솔에서 성능 프로필 설정

수행하려는 작업에 따라 웹 콘솔을 사용하여 적절한 성능 프로필을 설정하여 시스템 성능을 최적화할 수 있습니다.

사전 요구 사항

절차

  1. RHEL 8 웹 콘솔에 로그인합니다.

    자세한 내용은 웹 콘솔에 로그인 을 참조하십시오.

  2. Overview(개요 )를 클릭합니다.
  3. 구성 섹션에서 현재 성능 프로필을 클릭합니다.

    Image displaying the Overview pane of the cockpit interface.

  4. 성능 프로필 변경 대화 상자에서 필요한 프로필을 설정합니다.

    Image displaying the Change performance profile dialog box.

  5. 프로필 변경을 클릭합니다.

검증

  • 이제 개요 탭에 구성 섹션에서 선택한 성능 프로필이 표시됩니다.

11.3. 웹 콘솔을 사용하여 로컬 시스템에서 성능 모니터링

Red Hat Enterprise Linux 웹 콘솔에서는 문제 해결을 위해 UE(Utilization Saturation and Errors) 방법을 사용합니다. 새 성능 지표 페이지에는 최신 데이터와 함께 시간순으로 구성된 데이터 기록 보기가 있습니다.

지표 및 기록 페이지에서 리소스 사용률 및 포화 상태에 대한 이벤트, 오류 및 그래픽 표시를 볼 수 있습니다.

사전 요구 사항

  • RHEL 8 웹 콘솔을 설치했습니다.

    자세한 내용은 웹 콘솔 설치 및 활성화를 참조하십시오.

  • 성능 지표를 수집할 수 있는 cockpit-pcp 패키지가 설치됩니다.
  • PCP(Performance Co- Cryostat) 서비스가 활성화되어 있습니다.

    # systemctl enable --now pmlogger.service pmproxy.service

절차

  1. RHEL 8 웹 콘솔에 로그인합니다.

    자세한 내용은 웹 콘솔에 로그인 을 참조하십시오.

  2. Overview(개요 )를 클릭합니다.
  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

11.4. 웹 콘솔 및 Grafana를 사용하여 여러 시스템에서 성능 모니터링

Grafana를 사용하면 여러 시스템의 데이터를 한 번에 수집하고 수집된 PCP(Performance Co- Cryostat) 메트릭의 그래픽 표현을 검토할 수 있습니다. 웹 콘솔 인터페이스에서 여러 시스템에 대한 성능 지표 모니터링 및 내보내기를 설정할 수 있습니다.

사전 요구 사항

  • RHEL 8 웹 콘솔을 설치했습니다.

    자세한 내용은 웹 콘솔 설치 및 활성화를 참조하십시오.

  • cockpit-pcp 패키지를 설치했습니다.
  • PCP 서비스를 활성화했습니다.

    # systemctl enable --now pmlogger.service pmproxy.service
  • Grafana 대시보드를 설정했습니다. 자세 한 내용은 grafana-server 설정을 참조하십시오.
  • redis 패키지가 설치되어 있습니다.

    또는 나중에 절차의 웹 콘솔 인터페이스에서 패키지를 설치할 수 있습니다.

절차

  1. RHEL 8 웹 콘솔에 로그인합니다.

    자세한 내용은 웹 콘솔에 로그인 을 참조하십시오.

  2. 개요 페이지에서 사용 표의 지표 및 기록 보기를 클릭합니다.
  3. Metrics 설정 버튼을 클릭합니다.
  4. Export를 네트워크 슬라이 더로 이동합니다.

    Metrics settings

    redis 패키지가 설치되어 있지 않은 경우 웹 콘솔에서 설치하라는 메시지를 표시합니다.

  5. pmproxy 서비스를 열려면 드롭다운 목록에서 영역을 선택하고 pmproxy 추가 버튼을 클릭합니다.
  6. 저장을 클릭합니다.

검증

  1. 네트워킹 을 클릭합니다.
  2. 방화벽 테이블에서 규칙 및 영역 편집 버튼을 클릭합니다.
  3. 선택한 영역에서 pmproxy 를 검색합니다.
중요

보고 싶은 모든 시스템에 대해 이 절차를 반복합니다.

12장. 디스크 스케줄러 설정

디스크 스케줄러는 스토리지 장치에 제출된 I/O 요청을 주문합니다.

여러 가지 방법으로 스케줄러를 구성할 수 있습니다.

참고

Red Hat Enterprise Linux 8에서 블록 장치는 다중 대기열 스케줄링만 지원합니다. 이를 통해 솔리드 스테이트 드라이브(SSD) 및 멀티 코어 시스템으로 블록 계층 성능을 확장할 수 있습니다.

Red Hat Enterprise Linux 7 및 이전 버전에서 사용할 수 있는 기존의 단일 대기열 스케줄러가 제거되었습니다.

12.1. 사용 가능한 디스크 스케줄러

Red Hat Enterprise Linux 8에서는 다음과 같은 멀티 큐 디스크 스케줄러가 지원됩니다.

none
FIFO(선입선출) 스케줄링 알고리즘을 구현합니다. 간단한 마지막 캐시를 통해 일반 블록 계층의 요청을 병합합니다.
mq-deadline

요청이 스케줄러에 도달하는 시점의 요청에 대해 보장된 대기 시간을 제공합니다.

mq-deadline 스케줄러는 대기 중인 I/O 요청을 읽기 또는 쓰기 배치로 정렬한 다음, 논리 블록 주소 지정(LBA) 순서를 늘리도록 실행하도록 예약합니다. 애플리케이션이 읽기 I/O 작업에서 차단될 가능성이 높기 때문에 기본적으로 읽기 배치는 쓰기 배치보다 우선합니다. mq-deadline 이 배치를 처리한 후 쓰기 작업이 프로세서 시간이 지난 시간을 확인하고 다음 읽기 또는 쓰기 배치를 적절하게 예약합니다.

이 스케줄러는 대부분의 사용 사례에 적합하지만 특히 쓰기 작업이 주로 비동기식으로 사용됩니다.

bfq

데스크탑 시스템 및 대화형 작업을 대상으로 합니다.

bfq 스케줄러는 단일 애플리케이션이 모든 대역폭을 사용하지 않도록 합니다. 결과적으로 스토리지 장치는 항상 유휴 상태인 것처럼 반응합니다. 기본 구성에서 bfq 는 최대 처리량을 달성하는 대신 가장 낮은 대기 시간을 전달하는 데 중점을 둡니다.

BFQcfq 코드를 기반으로 합니다. 고정된 시간 슬라이스에 대해 각 프로세스에 디스크에 부여하지 않지만 섹터 수로 측정된 예산을 프로세스에 할당합니다.

이 스케줄러는 대용량 파일을 복사하는 동안 적합하며 이 경우 시스템이 응답하지 않습니다.

kyber

스케줄러는 블록 I/O 계층에 제출된 모든 I/O 요청 대기 시간을 계산하여 대기 시간 목표를 달성하도록 자체적으로 조정합니다. 캐시 누락 및 동기 쓰기 요청의 경우 읽기, 에 대한 대상 대기 시간을 구성할 수 있습니다.

이 스케줄러는 NVMe, SSD 또는 기타 짧은 대기 시간이 짧은 장치 등 빠른 장치에 적합합니다.

12.2. 다양한 사용 사례에 맞는 다른 디스크 스케줄러

시스템에서 수행하는 작업에 따라 분석 및 튜닝 작업 전에 다음 디스크 스케줄러를 기준으로 사용하는 것이 좋습니다.

표 12.1. 다양한 사용 사례의 디스크 스케줄러
사용 사례디스크 스케줄러

SCSI 인터페이스가 있는 기존 HDD

mq-deadline 또는 bfq 를 사용합니다.

고성능 SSD 또는 빠른 스토리지가 있는 CPU 바운드 시스템

특히 엔터프라이즈 애플리케이션을 실행할 때는 none 을 사용합니다. 또는 kyber 를 사용합니다.

데스크탑 또는 대화형 작업

bfq 사용.

가상 게스트

mq-deadline 사용. 멀티 큐를 사용할 수 있는 HBA(호스트 버스 어댑터) 드라이버에서는 none 을 사용합니다.

12.3. 기본 디스크 스케줄러

블록 장치는 다른 스케줄러를 지정하지 않는 한 기본 디스크 스케줄러를 사용합니다.

참고

특히 비volatile Memory Express(NVMe) 블록 장치의 경우 기본 스케줄러는 none 이며 Red Hat은 변경하지 않는 것이 좋습니다.

커널은 장치 유형에 따라 기본 디스크 스케줄러를 선택합니다. 자동 선택된 스케줄러는 일반적으로 최적의 설정입니다. 다른 스케줄러가 필요한 경우 Red Hat은 udev 규칙 또는 TuneD 애플리케이션을 사용하여 구성하는 것이 좋습니다. 선택한 장치와 일치하고 해당 장치에 대해서만 스케줄러를 전환합니다.

12.4. 활성 디스크 스케줄러 확인

다음 절차에서는 지정된 블록 장치에서 현재 활성화된 디스크 스케줄러를 결정합니다.

절차

  • /sys/block/device/queue/scheduler 파일의 내용을 읽습니다.

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

    파일 이름에서 device 를 exampledc의 블록 장치 이름으로 바꿉니다.

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

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

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

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

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

사전 요구 사항

  • TuneD 서비스가 설치되고 활성화됩니다. 자세한 내용은 TuneD 설치 및 사용을 참조하십시오.

절차

  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(World Wide Name) 또는 일련 번호로 식별된 모든 값을 반환합니다. WWN을 사용하는 것이 바람직하지만 WWN은 지정된 장치에 항상 사용 가능한 것은 아니며 예제 명령에서 반환된 값은 장치 시스템 고유 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 를 선택한 식별자 값으로 바꿉니다(예: 0x5002538d0000).

        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/장치/queue/scheduler 파일의 내용을 읽습니다.

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

    파일 이름에서 device 를 exampledc의 블록 장치 이름으로 바꿉니다.

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

12.6. udev 규칙을 사용하여 디스크 스케줄러 설정

이 절차에서는 udev 규칙을 사용하여 특정 블록 장치에 지정된 디스크 스케줄러를 설정합니다. 이 설정은 시스템을 재부팅해도 유지됩니다.

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

  • 블록 장치의 이름이 있는 장치(예: sdf)
  • 장치에 설정할 디스크 스케줄러가 있는 select -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(World Wide Name) 또는 일련 번호로 식별된 모든 값을 반환합니다. WWN을 사용하는 것이 바람직하지만 WWN은 지정된 장치에 항상 사용 가능한 것은 아니며 예제 명령에서 반환된 값은 장치 시스템 고유 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 를 선택한 식별자 값으로 바꿉니다(예: 0x5002538d0000).
  3. udev 규칙을 다시 로드합니다.

    # udevadm control --reload-rules
  4. 스케줄러 구성을 적용합니다.

    # udevadm trigger --type=devices --action=change

검증

  • 활성 스케줄러를 확인합니다.

    # cat /sys/block/device/queue/scheduler

12.7. 특정 디스크에 대한 임시로 스케줄러 설정

이 절차에서는 특정 블록 장치에 지정된 디스크 스케줄러를 설정합니다. 이 설정은 시스템을 재부팅해도 유지되지 않습니다.

절차

  • 선택한 스케줄러의 이름을 /sys/block/장치/queue/scheduler 파일에 작성합니다.

    # echo selected-scheduler > /sys/block/device/queue/scheduler

    파일 이름에서 device 를 exampledc의 블록 장치 이름으로 바꿉니다.

검증

  • 스케줄러가 장치에서 활성화되어 있는지 확인합니다.

    # cat /sys/block/device/queue/scheduler

13장. Samba 서버의 성능 튜닝

특정 상황에서 Samba의 성능을 향상시킬 수 있는 설정과 성능에 부정적인 영향을 미칠 수 있는 설정에 대해 알아봅니다.

이 섹션의 일부는 Samba Wiki에 게시된 성능 튜닝 설명서에서 채택되었습니다. 라이센스: CC BY 4.0. 저자 및 기여자: Wiki 페이지에서 히스토리 탭을 참조하십시오.

사전 요구 사항

13.1. SMB 프로토콜 버전 설정

각각의 새 SMB 버전은 기능을 추가하고 프로토콜의 성능을 향상시킵니다. 최근 Windows 및 Windows Server 운영 체제는 항상 최신 프로토콜 버전을 지원합니다. Samba도 최신 프로토콜 버전을 사용하는 경우 Samba에 연결하는 Windows 클라이언트는 성능 향상을 통해 이점을 얻을 수 있습니다. Samba에서 서버 max 프로토콜의 기본값은 지원되는 최신 안정적인 SMB 프로토콜 버전으로 설정됩니다.

참고

항상 안정적인 최신 SMB 프로토콜 버전을 활성화하려면 server max protocol 매개 변수를 설정하지 마십시오. 매개 변수를 수동으로 설정하는 경우 최신 프로토콜 버전이 활성화되도록 각 새 버전의 SMB 프로토콜로 설정을 수정해야 합니다.

다음 절차에서는 server max protocol 매개 변수에서 기본값을 사용하는 방법을 설명합니다.

절차

  1. /etc/samba/smb.conf 파일의 [global] 섹션에서 server max protocol 매개 변수를 제거합니다.
  2. Samba 설정을 다시 로드합니다

    # smbcontrol all reload-config

13.2. 많은 수의 파일이 포함된 디렉토리와의 공유 조정

Linux는 대소문자를 구분하는 파일 이름을 지원합니다. 이러한 이유로 Samba는 파일을 검색하거나 액세스할 때 대문자 및 소문자로 된 파일 이름에 대해 디렉토리를 스캔해야 합니다. 소문자 또는 대문자로만 새 파일을 생성하도록 공유를 구성할 수 있으므로 성능이 향상됩니다.

사전 요구 사항

  • Samba가 파일 서버로 구성되어 있습니다.

절차

  1. 공유의 모든 파일의 이름을 소문자로 바꿉니다.

    참고

    이 절차의 설정을 사용하면 소문자가 아닌 이름이 있는 파일이 더 이상 표시되지 않습니다.

  2. 공유의 섹션에서 다음 매개변수를 설정합니다.

    case sensitive = true
    default case = lower
    preserve case = no
    short preserve case = no

    매개 변수에 대한 자세한 내용은 smb.conf(5) 도움말 페이지에서 해당 설명을 참조하십시오.

  3. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  4. Samba 구성을 다시 로드합니다.

    # smbcontrol all reload-config

이러한 설정을 적용한 후 이 공유에서 새로 생성된 모든 파일의 이름은 소문자를 사용합니다. 이러한 설정으로 인해 Samba가 더 이상 디렉터리를 대문자 및 소문자로 스캔할 필요가 없으므로 성능이 향상됩니다.

13.3. 성능에 부정적인 영향을 줄 수 있는 설정

기본적으로 Red Hat Enterprise Linux의 커널은 높은 네트워크 성능을 위해 조정됩니다. 예를 들어 커널은 버퍼 크기에 자동 조정 메커니즘을 사용합니다. /etc/samba/smb.conf 파일에서 socket options 매개 변수를 설정하면 이러한 커널 설정이 재정의됩니다. 결과적으로 이 매개 변수를 설정하면 대부분의 경우 Samba 네트워크 성능이 저하됩니다.

커널에서 최적화된 설정을 사용하려면 /etc/samba/smb.conf[global] 섹션에서 socket options 매개 변수를 제거합니다.

14장. 가상 머신 성능 최적화

VM(가상 시스템)은 항상 호스트와 비교하여 일정 수준의 성능 저하를 경험합니다. 다음 섹션에서는 이러한 문제가 발생하는 이유를 설명하고, 하드웨어 인프라 리소스를 최대한 효율적으로 사용할 수 있도록 RHEL 8의 가상화 성능 영향을 최소화하는 방법에 대한 지침을 제공합니다.

14.1. 가상 머신 성능에 어떤 영향을 주는가

VM은 호스트에서 사용자 공간 프로세스로 실행됩니다. 따라서 하이퍼바이저는 VM에서 사용할 수 있도록 호스트의 시스템 리소스를 변환해야 합니다. 결과적으로 변환에서 리소스의 일부를 소비하므로 VM은 호스트와 동일한 성능 효율성을 달성할 수 없습니다.

시스템 성능에 가상화가 미치는 영향

VM 성능 손실의 구체적인 이유는 다음과 같습니다.

  • 가상 CPU(vCPU)는 Linux 스케줄러에서 처리하는 호스트의 스레드로 구현됩니다.
  • VM은 호스트 커널에서 NUMA 또는 대규모 페이지와 같은 최적화 기능을 자동으로 상속하지 않습니다.
  • 호스트의 디스크 및 네트워크 I/O 설정은 VM에 상당한 성능 영향을 줄 수 있습니다.
  • 네트워크 트래픽은 일반적으로 소프트웨어 기반 브릿지를 통해 VM으로 이동합니다.
  • 호스트 장치 및 해당 모델에 따라 특정 하드웨어의 에뮬레이션으로 인해 상당한 오버헤드가 발생할 수 있습니다.

VM 성능에 대한 가상화 영향의 심각도는 다음과 같은 다양한 요인의 영향을 받습니다.

  • 동시에 실행 중인 VM 수입니다.
  • 각 VM에서 사용하는 가상 장치의 양입니다.
  • VM에서 사용하는 장치 유형입니다.
VM 성능 손실 감소

RHEL 8에서는 가상화의 부정적인 성능 효과를 줄이는 데 사용할 수 있는 여러 가지 기능을 제공합니다. 특히:

  • TuneD 서비스는 VM의 리소스 배포 및 성능을 자동으로 최적화할 수 있습니다.
  • 블록 I/O 튜닝을 사용하면 디스크와 같은 VM 블록 장치의 성능을 향상시킬 수 있습니다.
  • NUMA 튜닝 은 vCPU 성능을 향상시킬 수 있습니다.
  • 가상 네트워킹 을 다양한 방식으로 최적화할 수 있습니다.
중요

VM 성능 튜닝은 다른 가상화 기능에 부정적인 영향을 미칠 수 있습니다. 예를 들어 수정된 VM을 마이그레이션하기가 더 어려워질 수 있습니다.

14.2. TuneD를 사용하여 가상 머신 성능 최적화

TuneD 유틸리티는 CPU 집약적인 작업 또는 스토리지 네트워크 처리량 응답성 요구 사항과 같은 특정 워크로드 특성에 RHEL을 조정하는 튜닝 프로필 전달 메커니즘입니다. 다수의 특정 사용 사례에서 성능을 향상시키고 전력 소비를 줄이기 위해 사전 구성된 여러 튜닝 프로필을 제공합니다. 이러한 프로필을 편집하거나 새 프로필을 생성하여 가상화 환경을 포함한 환경에 맞는 성능 솔루션을 만들 수 있습니다.

가상화를 위해 RHEL 8을 최적화하려면 다음 프로필을 사용하십시오.

  • RHEL 8 가상 머신의 경우 virtual-guest 프로필을 사용합니다. 일반적으로 적용 가능한 throughput-performance 프로필을 기반으로 하지만 가상 메모리의 스왑성도 줄어듭니다.
  • RHEL 8 가상화 호스트의 경우 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

14.3. 가상 머신 메모리 구성

VM(가상 시스템)의 성능을 개선하기 위해 VM에 추가 호스트 RAM을 할당할 수 있습니다. 마찬가지로 호스트 메모리를 다른 VM 또는 작업에 할당할 수 있도록 VM에 할당된 메모리 양을 줄일 수 있습니다.

이러한 작업을 수행하려면 웹 콘솔 또는 명령줄 인터페이스를 사용할 수 있습니다.

14.3.1. 웹 콘솔을 사용하여 가상 머신 메모리 추가 및 제거

VM(가상 머신)의 성능을 개선하거나 사용 중인 호스트 리소스를 확보하려면 웹 콘솔을 사용하여 VM에 할당된 메모리 양을 조정할 수 있습니다.

사전 요구 사항

  • RHEL 8 웹 콘솔을 설치했습니다.

    자세한 내용은 웹 콘솔 설치 및 활성화를 참조하십시오.

  • 게스트 OS는 메모리 balloon 드라이버를 실행하고 있습니다. 이러한 경우인지 확인하려면 다음을 수행합니다.

    1. VM 구성에 memballoon 장치가 포함되어 있는지 확인합니다.

      # virsh dumpxml testguest | grep memballoon
      <memballoon model='virtio'>
          </memballoon>

      이 명령은 출력을 표시하며 모델을 none 으로 설정하지 않으면 memballoon 장치가 있습니다.

    2. guest OS에서 balloon 드라이버가 실행 중인지 확인합니다.

      • Windows 게스트에서 드라이버는 virtio-win 드라이버 패키지의 일부로 설치됩니다. 자세한 내용은 Windows 가상 머신용 반가상화 KVM 드라이버 설치를 참조하십시오.
      • Linux 게스트에서는 일반적으로 드라이버가 기본적으로 포함되며 memballoon 장치가 있는 경우 활성화됩니다.
  • 웹 콘솔 VM 플러그인이 시스템에 설치되어 있습니다.

절차

  1. 선택 사항: 최대 메모리와 현재 VM에 사용된 메모리에 대한 정보를 가져옵니다. 그러면 변경 사항과 확인을 위한 기준선으로 사용할 수 있습니다.

    # virsh dominfo testguest
    Max memory:     2097152 KiB
    Used memory:    2097152 KiB
  1. RHEL 8 웹 콘솔에 로그인합니다.

    자세한 내용은 웹 콘솔에 로그인 을 참조하십시오.

  2. Virtual Machines (가상 시스템) 인터페이스에서 표시할 정보가 있는 VM을 클릭합니다.

    VM의 그래픽 인터페이스에 액세스하기 위한 선택한 VM 및 콘솔 섹션에 대한 기본 정보가 포함된 Overview(개요) 섹션이 포함된 새 페이지가 열립니다.

  3. Overview(개요) 창에서 Memory(메모리 ) 행 옆에 있는 Edit(편집)를 클릭합니다.

    Memory Adjustment(메모리 조정 ) 대화 상자가 표시됩니다.

    VM 메모리 조정 대화 상자를 표시하는 이미지.
  4. 선택한 VM의 가상 메모리를 구성합니다.

    • max allocation (최대 할당) - VM이 프로세스에 사용할 수 있는 최대 호스트 메모리 양을 설정합니다. VM을 생성할 때 최대 메모리를 지정하거나 나중에 늘릴 수 있습니다. 메모리를 MiB 또는 GiB의 배수로 지정할 수 있습니다.

      메모리 할당 최대 조정은 종료 VM에서만 가능합니다.

    • current allocation (현재 할당) - VM에 할당된 실제 메모리 양을 설정합니다. 이 값은 최대 할당보다 작을 수 있지만 초과할 수는 없습니다. 해당 프로세스에 대해 VM에서 사용할 수 있는 메모리를 제어하도록 값을 조정할 수 있습니다. 메모리를 MiB 또는 GiB의 배수로 지정할 수 있습니다.

      이 값을 지정하지 않으면 기본 할당은 최대 할당 값입니다.

  5. 저장을 클릭합니다.

    VM의 메모리 할당이 조정됩니다.

14.3.2. 명령줄 인터페이스를 사용하여 가상 머신 메모리 추가 및 제거

VM(가상 머신)의 성능을 개선하거나 사용 중인 호스트 리소스를 확보하려면 CLI를 사용하여 VM에 할당된 메모리 양을 조정할 수 있습니다.

사전 요구 사항

  • 게스트 OS는 메모리 balloon 드라이버를 실행하고 있습니다. 이러한 경우인지 확인하려면 다음을 수행합니다.

    1. VM 구성에 memballoon 장치가 포함되어 있는지 확인합니다.

      # virsh dumpxml testguest | grep memballoon
      <memballoon model='virtio'>
          </memballoon>

      이 명령은 출력을 표시하며 모델을 none 으로 설정하지 않으면 memballoon 장치가 있습니다.

    2. ballon 드라이버가 게스트 OS에서 실행 중인지 확인합니다.

      • 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의 메모리 증대 통계를 가져와 메모리 사용을 효과적으로 규제하는 방법을 평가할 수 있습니다.

     # 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

14.3.3. 추가 리소스

14.4. 가상 머신 I/O 성능 최적화

VM(가상 시스템)의 입력 및 출력(I/O) 기능은 VM의 전반적인 효율성을 크게 제한할 수 있습니다. 이 문제를 해결하기 위해 블록 I/O 매개변수를 구성하여 VM의 I/O를 최적화할 수 있습니다.

14.4.1. 가상 머신의 블록 I/O 튜닝

하나 이상의 VM에서 여러 블록 장치를 사용하는 경우 I/O 가중치를 수정하여 특정 가상 장치의 I/O 우선 순위를 조정하는 것이 중요할 수 있습니다.

장치의 I/O 가중치를 늘리면 I/O 대역폭의 우선 순위가 증가하므로 더 많은 호스트 리소스를 제공합니다. 마찬가지로 장치의 가중치를 줄이면 호스트 리소스를 더 적게 소비할 수 있습니다.

참고

각 장치의 가중치 값은 1 00~1000 범위 내에 있어야 합니다. 또는 장치별 목록에서 해당 장치를 제거하는 값이 0 일 수 있습니다.

절차

VM의 블록 I/O 매개변수를 표시하고 설정하려면 다음을 수행합니다.

  1. VM의 현재 <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

    예를 들어, 다음에서는 testguest1 VM의 /dev/sda 장치의 가중치를 500으로 변경합니다.

    # virsh blkiotune testguest1 --device-weights /dev/sda, 500

14.4.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 디스크를 초당 읽기 및 쓰기 I/O 작업 수가 1000개, 초당 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 8을 VM 호스트로 사용할 때 지원되지 않는 기능에 대한 자세한 내용은 RHEL 8 가상화에서 지원되지 않는 기능을 참조하십시오.

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

14.5. 가상 머신 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 튜닝은 VM에 할당된 시스템 메모리에 대한 보다 능률적인 액세스를 제공하므로 vCPU 처리 효율성이 향상될 수 있습니다.

    자세한 내용은 가상 머신에서 NUMA 구성샘플 vCPU 성능 튜닝 시나리오를 참조하십시오.

14.5.1. 명령줄 인터페이스를 사용하여 가상 CPU 추가 및 제거

VM(가상 머신)의 CPU 성능을 늘리거나 최적화하려면 VM에 할당된 가상 CPU(vCPU)를 추가하거나 제거할 수 있습니다.

실행 중인 VM에서 수행되는 경우 vCPU 핫 플러그 및 핫 플러그 해제라고도 합니다. 그러나 RHEL 8에서는 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 에서 사용하는 vCPU 수는 2개로 변경되며 2개의 vCPU를 핫 플러그로 연결할 수 있습니다.

절차

  1. VM에 연결할 수 있는 최대 vCPU 수를 조정하여 다음 부팅 시 적용됩니다.

    예를 들어 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의 다음 부팅 후 testguest 의 VM 성능 및 호스트 부하 공간이 줄어듭니다. 그러나 필요한 경우 VM에 추가 vCPU를 핫플러그하여 일시적으로 성능을 향상시킬 수 있습니다.

검증

  • VM의 현재 vCPU 상태에 변경 사항이 반영되는지 확인합니다.

    # virsh vcpucount testguest
    maximum      config         8
    maximum      live           4
    current      config         1
    current      live           4

14.5.2. 웹 콘솔을 사용하여 가상 CPU 관리

RHEL 8 웹 콘솔을 사용하면 웹 콘솔이 연결된 VM(가상 머신)에서 사용하는 가상 CPU를 검토하고 구성할 수 있습니다.

사전 요구 사항

절차

  1. RHEL 8 웹 콘솔에 로그인합니다.

    자세한 내용은 웹 콘솔에 로그인 을 참조하십시오.

  2. Virtual Machines (가상 시스템) 인터페이스에서 표시할 정보가 있는 VM을 클릭합니다.

    VM의 그래픽 인터페이스에 액세스하기 위한 선택한 VM 및 콘솔 섹션에 대한 기본 정보가 포함된 Overview(개요) 섹션이 포함된 새 페이지가 열립니다.

  3. Overview(개요) 창에서 vCPU의 수 옆에 있는 Edit( 편집 )를 클릭합니다.

    vCPU 세부 정보 대화 상자가 나타납니다.

    VM CPU 세부 정보 대화 상자를 표시하는 이미지.
  1. 선택한 VM에 대해 가상 CPU를 구성합니다.

    • vCPU 개수 - 현재 사용 중인 vCPU 수입니다.

      참고

      vCPU 수는 vCPU 최대보다 클 수 없습니다.

    • vCPU 최대 - VM에 대해 구성할 수 있는 최대 가상 CPU 수입니다. 이 값이 vCPU 개수 보다 크면 VM에 추가 vCPU를 연결할 수 있습니다.
    • sockets - VM에 표시할 소켓 수입니다.
    • Cores per socket (소켓당 코어 수) - 각 소켓이 VM에 노출될 코어 수입니다.
    • 코어당 스레드 - 각 코어가 VM에 노출될 스레드 수입니다.

      소켓,소켓당 코어, 코어 옵션당 스레드 는 VM의 CPU 토폴로지를 조정합니다. 이는 vCPU 성능에 도움이 될 수 있으며 게스트 OS의 특정 소프트웨어의 기능에 영향을 줄 수 있습니다. 배포에서 다른 설정이 필요하지 않은 경우 기본값을 유지합니다.

  2. Apply(적용)를 클릭합니다.

    VM의 가상 CPU가 구성됩니다.

    참고

    가상 CPU 설정 변경 사항은 VM을 다시 시작한 후에만 적용됩니다.

14.5.3. 가상 머신에서 NUMA 구성

다음 방법을 사용하여 RHEL 8 호스트에서 가상 머신(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 성능을 안전하게 개선하는 방법으로 권장됩니다.

    예를 들어 다음 명령은 각각 CPU 1, 3, 5, 7, 9, 11을 호스팅하도록 testguest6 VM의 0~5 vCPU 스레드를 고정합니다.

    # 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
참고

최상의 성능 결과를 얻으려면 위에 나열된 수동 튜닝 방법을 모두 사용하는 것이 좋습니다.

추가 리소스

14.5.4. 샘플 vCPU 성능 튜닝 시나리오

가능한 한 최상의 vCPU 성능을 얻으려면 다음 시나리오와 같이 수동 vcpupin,emulatorpinnumatune 설정을 함께 사용하는 것이 좋습니다.

시나리오 시작

  • 호스트에는 다음과 같은 하드웨어 세부 사항이 있습니다.

    • NUMA 노드 2개
    • 각 노드의 CPU 코어 3개
    • 각 코어에 두 개의 스레드

    이러한 머신의 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 대규모 페이지를 설정하고 마운트합니다.

    참고

    ARM 64 호스트와 같은 일부 아키텍처 및 구성에서 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의 대규모 페이지와 node 2 에서 4GiB의 대규모 페이지가 예약됩니다.

    4. 이전 단계에서 생성한 스크립트를 실행 파일로 만듭니다.

      # chmod +x /etc/systemd/hugetlb-reserve-pages.sh
    5. 부팅 시 대규모 페이지 예약을 활성화합니다.

      # systemctl enable hugetlb-gigantic-pages
  4. virsh edit 명령을 사용하여 최적화하려는 VM의 XML 구성을 편집합니다. 이 예제 super-VM:

    # virsh edit super-vm
  5. 다음과 같은 방식으로 VM의 XML 구성을 조정합니다.

    1. 8개의 정적 vCPU를 사용하도록 VM을 설정합니다. 이 작업을 수행하려면 <vcpu/> 요소를 사용합니다.
    2. 각 vCPU 스레드를 토폴로지에서 미러링하는 해당 호스트 CPU 스레드에 고정합니다. 이렇게 하려면 < cputune> 섹션에서 <vcpupin/ > 요소를 사용합니다.

      위의 virsh 기능 유틸리티에 표시된 대로 호스트 CPU 스레드는 해당 코어에서 순차적으로 정렬되지 않습니다. 또한 vCPU 스레드는 동일한 NUMA 노드에서 사용 가능한 최고 수준의 호스트 코어 세트에 고정되어야 합니다. 테이블 그림은 아래의 샘플 토폴로지 섹션을 참조하십시오.

      a 및 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"/>
  6. 결과적으로 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>
  7. 선택 사항: 해당 툴 및 유틸리티를 사용하여 VM 최적화의 영향을 평가하여 VM의 성능을 테스트합니다.

토폴로지 샘플

  • 다음 표에서는 고정해야 하는 vCPU와 호스트 CPU 간의 연결을 보여줍니다.

    표 14.1. 호스트 토폴로지

    CPU 스레드

    0

    3

    1

    4

    2

    5

    6

    9

    7

    10

    8

    11

    코어

    0

    1

    2

    3

    4

    5

    소켓

    0

    1

    NUMA 노드

    0

    1

    표 14.2. VM 토폴로지

    vCPU 스레드

    0

    1

    2

    3

    4

    5

    6

    7

    코어

    0

    1

    2

    3

    소켓

    0

    1

    NUMA 노드

    0

    1

    표 14.3. 결합된 호스트 및 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

    이 시나리오에는 2개의 NUMA 노드와 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'/>

14.5.5. 커널 동일 페이지 병합 비활성화

커널 동일 페이지 병합(KSM)은 메모리 밀도를 향상하지만 CPU 사용률을 높이며 워크로드에 따라 전반적인 성능에 부정적 영향을 미칠 수 있습니다. 이러한 경우 KSM을 비활성화하여 VM(가상 머신) 성능을 향상시킬 수 있습니다.

요구 사항에 따라 단일 세션에서 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의 물리적 메모리에서 투명한 대규모 페이지를 다시 빌드합니다.

14.6. 가상 머신 네트워크 성능 최적화

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> 섹션에 다음을 추가하고 N 을 VM의 vCPU 수로, 최대 16까지 교체합니다.

<interface type='network'>
      <source network='default'/>
      <model type='virtio'/>
      <driver name='vhost' queues='N'/>
</interface>

VM이 실행 중인 경우 변경 사항이 적용되도록 VM을 다시 시작하십시오.

네트워크 패킷 배치

긴 전송 경로가 있는 Linux VM 구성에서는 커널에 제출하기 전에 패킷을 일괄 처리하면 캐시 사용률이 향상될 수 있습니다. 패킷 일괄 처리를 설정하려면 호스트에서 다음 명령을 사용하고, VM에서 사용하는 네트워크 인터페이스 이름으로 tap0 을 바꿉니다.

# ethtool -C tap0 rx-frames 64
SR-IOV
호스트 NIC에서 SR-IOV를 지원하는 경우 vNIC에 SR-IOV 장치 할당을 사용합니다. 자세한 내용은 SR-IOV 장치 관리를 참조하십시오.

추가 리소스

14.7. 가상 머신 성능 모니터링 툴

가장 많은 VM 리소스를 사용하는 항목과 VM 성능에 최적화가 필요한 측면을 식별하기 위해 일반적인 성능 진단 툴과 VM별 툴을 사용할 수 있습니다.

기본 OS 성능 모니터링 툴

표준 성능 평가의 경우 호스트 및 게스트 운영 체제에서 기본적으로 제공하는 유틸리티를 사용할 수 있습니다.

  • RHEL 8 호스트에서 root로 최상위 유틸리티 또는 시스템 모니터 애플리케이션을 사용하고 출력에서 qemuvirt 을 찾습니다. 그러면 VM에서 사용하는 호스트 시스템 리소스의 양을 확인할 수 있습니다.

    • 모니터링 도구가 qemu 또는 virt 프로세스에서 호스트 CPU 또는 메모리 용량의 대부분을 사용하는 것을 표시하는 경우 perf 유틸리티를 사용하여 조사합니다. 자세한 내용은 아래를 참조하십시오.
    • 또한 vhost_net-1234 와 같은 vhost_net 스레드 프로세스가 과도한 호스트 CPU 용량을 소비하는 것으로 표시되는 경우 가상 네트워크 최적화 기능 (예: multi-queue virtio-net )을 사용하는 것이 좋습니다.
  • 게스트 운영 체제에서 시스템에서 사용할 수 있는 성능 유틸리티 및 애플리케이션을 사용하여 가장 많은 시스템 리소스를 사용하는 프로세스를 평가합니다.

    • Linux 시스템에서는 top 유틸리티를 사용할 수 있습니다.
    • Windows 시스템에서 Task Manager 응용 프로그램을 사용할 수 있습니다.

perf kvm

perf 유틸리티를 사용하여 RHEL 8 호스트의 성능에 대한 가상화별 통계를 수집하고 분석할 수 있습니다. 이렇게 하려면 다음을 수행합니다.

  1. 호스트에서 perf 패키지를 설치합니다.

    # yum install perf
  2. 가상화 호스트에 대한 perf kvm stat 명령 중 하나를 사용하여 가상화 호스트에 대한 perf 통계를 표시합니다.

    • 하이퍼바이저를 실시간으로 모니터링하려면 perf kvm stat live 명령을 사용합니다.
    • 일정 기간 동안 하이퍼바이저의 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 stat 의 출력에서 문제를 신호를 보낼 수 있는 기타 이벤트 유형은 다음과 같습니다.

perf 를 사용하여 가상화 성능을 모니터링하는 방법에 대한 자세한 내용은 perf-kvm 도움말 페이지를 참조하십시오.

numastat

시스템의 현재 NUMA 구성을 보려면 numa ctl 패키지를 설치하여 제공되는 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

15장. 전원 관리의 중요성

컴퓨터 시스템의 전체 전력 소비를 줄이는 것은 비용 절감에 도움이 됩니다. 각 시스템 구성 요소의 에너지 사용을 효과적으로 최적화하면 시스템에서 수행하는 다양한 작업을 학습하고 해당 작업의 성능이 적합하도록 각 구성 요소를 구성하는 작업이 포함됩니다. 특정 구성 요소 또는 시스템의 전력 소비를 전체적으로 줄임으로써 열과 성능을 낮출 수 있습니다.

적절한 전원 관리 결과는 다음과 같습니다.

  • 서버 및 컴퓨팅 센터의 Heat 감소
  • 냉각, 공간, 케이블, 발전기 및 무정전 전력 공급 장치(UPS) 등 2차 비용 절감
  • 노트북의 배터리 수명 연장
  • 탄소 배출량 감소
  • 친환경 IT와 관련된 정부 규정 또는 법적 요건 충족(예: Energy Star)
  • 새로운 시스템에 대한 회사 지침 충족

이 섹션에서는 Red Hat Enterprise Linux 시스템의 전원 관리에 관한 정보를 설명합니다.

15.1. 전원 관리 기본 사항

효과적인 전원 관리는 다음과 같은 원칙에 따라 구축됩니다:

유휴 CPU는 필요할 때만 작동 중지해야 합니다.

Red Hat Enterprise Linux 6부터 커널은 틱리스 를 실행하므로 이전의 주기적인 타이머 인터럽트가 온디맨드 인터럽트로 교체되었습니다. 따라서 처리를 위해 새 작업이 대기 상태가 될 때까지 유휴 상태로 남아 있고 더 낮은 전원 상태를 입력한 CPU는 이러한 상태에 더 오래 유지될 수 있습니다. 그러나 불필요한 타이머 이벤트를 생성하는 애플리케이션이 시스템에 있는 경우 이 기능의 이점을 오프셋할 수 있습니다. 볼륨 변경 사항 또는 마우스 이동 검사와 같은 폴링 이벤트는 이러한 이벤트의 예입니다.

Red Hat Enterprise Linux에는 CPU 사용량을 기준으로 애플리케이션을 식별하고 감사할 수 있는 툴이 포함되어 있습니다. 자세한 내용은 감사 및 분석 개요감사 도구에서 참조하십시오.

사용하지 않는 하드웨어 및 장치를 완전히 비활성화해야합니다.
이는 이동 부품이 있는 장치(예: 하드 디스크)에 적용됩니다. 이 외에도 일부 애플리케이션은 사용되지 않지만 활성화된 장치를 "열기" 상태로 둘 수 있습니다. 이 경우 커널은 장치가 사용 중이라고 가정하여 장치가 절전 상태로 전환되지 않도록 할 수 있습니다.
낮은 활동은 낮은 wattage로 전환해야 합니다.

그러나 대부분의 경우 이는 최신 하드웨어와 올바른 BIOS 구성 또는 최신 시스템의 UEFI(x86이 아닌 아키텍처 포함)에 따라 달라집니다. 시스템에 최신 공식 펌웨어를 사용하고 있으며 BIOS의 전원 관리 또는 장치 구성 섹션에서 전원 관리 기능이 활성화되어 있는지 확인합니다. 검색할 몇 가지 기능은 다음과 같습니다.

  • ARM64를 위한 공동 작업 프로세스 성능 제어(CPPC) 지원
  • IBM Power Systems에 대한 PowerNV 지원
  • SpeedStep
  • 파워트워트!
  • Coff''Quiet
  • ACPI(C-state)
  • 스마트

    하드웨어가 이러한 기능을 지원하고 BIOS에서 활성화되어 있는 경우 Red Hat Enterprise Linux는 기본적으로 이러한 기능을 사용합니다.

다양한 형식의 CPU 상태 및 해당 영향

최신 CPU와 고급 구성 및 전원 인터페이스(ACPI)는 서로 다른 전원 상태를 제공합니다. 세 가지 상태는 다음과 같습니다.

  • 절전 (C-상태)
  • 빈도 및 온도 (P-states)
  • Heat 출력(T-states 또는 열 상태)

    절전 상태에서 실행되는 CPU는 가장 적은 watt를 사용하지만 필요할 때 해당 상태에서 벗어나는 데 시간이 훨씬 더 걸립니다. 드문 경우지만 이로 인해 CPU가 수면 상태가 될 때마다 즉시 작동해야 할 수 있습니다. 이 상황으로 인해 효과적으로 사용 가능한 CPU가 발생하고 다른 상태가 사용되면 잠재적인 절전이 손실됩니다.

끄기된 시스템은 최소 전력을 사용합니다.
전력 절감을 위한 가장 좋은 방법 중 하나는 시스템을 끄는 것입니다. 예를 들어, 회사에서는 휴식 시간이나 집이 이동하는 경우 시스템을 끄는 지침으로 "신규 IT" 인식에 초점을 맞춘 기업 문화를 개발할 수 있습니다. 또한 Red Hat Enterprise Linux와 함께 제공되는 가상화 기술을 사용하여 여러 물리적 서버를 하나의 더 큰 서버에 통합하고 가상화 기술을 사용하여 가상화할 수도 있습니다.

15.2. 감사 및 분석 개요

단일 시스템의 상세 수동 감사, 분석 및 튜닝은 일반적으로 시간과 비용이 이러한 마지막 시스템 튜닝에서 얻은 이점보다 우선하기 때문입니다.

그러나 거의 동일한 수의 시스템에서 이러한 작업을 한 번 수행하면 모든 시스템에 대해 동일한 설정을 재사용할 수 있는 매우 유용할 수 있습니다. 예를 들어, 수천 대의 데스크탑 시스템 또는 시스템이 거의 동일한 HPC 클러스터를 배포하는 경우를 생각해 보십시오. 감사 및 분석을 수행하는 또 다른 이유는 향후 회귀 또는 시스템 동작 변경을 식별할 수 있는 비교 기반을 제공하기 위한 것입니다. 이 분석 결과는 하드웨어, BIOS 또는 소프트웨어 업데이트가 정기적으로 수행되고 전력 소비와 관련하여 놀라운 일이 발생하지 않는 경우에 매우 유용할 수 있습니다. 일반적으로 철저한 감사 및 분석을 통해 특정 시스템에서 실제로 발생하는 상황을 훨씬 더 잘 이해할 수 있습니다.

사용 가능한 최신 시스템을 사용하더라도 전력 소비와 관련하여 시스템을 감사하고 분석하는 것이 비교적 어렵습니다. 대부분의 시스템은 소프트웨어를 통해 전력 사용을 측정하는 데 필요한 수단을 제공하지 않습니다. 예외가 있습니다.

  • Hewlett Packard 서버 시스템의 ILO 관리 콘솔에는 웹을 통해 액세스할 수 있는 전원 관리 모듈이 있습니다.
  • IBM은 BladeCenter 전원 관리 모듈에서 유사한 솔루션을 제공합니다.
  • 일부 Dell 시스템에서 IT 도우미는 전원 모니터링 기능도 제공합니다.

다른 벤더는 해당 서버 플랫폼에 대해 유사한 기능을 제공할 수 있지만 모든 벤더가 지원하는 단일 솔루션은 없다는 것을 알 수 있습니다. 전력 소비의 직접 측정은 최대한의 비용 절감 효과를 극대화하기 위해서만 종종 필요합니다.

15.3. 감사를 위한 툴

Red Hat Enterprise Linux 8은 시스템 감사 및 분석을 수행할 수 있는 도구를 제공합니다. 대부분은 귀하가 이미 발견한 내용을 확인하거나 특정 부분에 대한 보다 심층적인 정보가 필요한 경우 정보의 보조 소스로 사용할 수 있습니다.

이러한 도구는 대부분 다음과 같은 성능 튜닝에도 사용됩니다.

PowerTOP
CPU를 자주 손상시키는 커널 및 사용자 공간 애플리케이션의 특정 구성 요소를 식별합니다. powertop 명령을 root로 사용하여 PowerTop 툴과 powertop --calibrate 를 시작하여 전력 추정 엔진을 조정합니다. PowerTop에 대한 자세한 내용은 PowerTOP로 전력 소비 관리를 참조하십시오.
diskdevstat 및 netdevstat

시스템에서 실행되는 모든 애플리케이션의 디스크 활동 및 네트워크 활동에 대한 자세한 정보를 수집하는 SystemTap 툴입니다. 이러한 툴을 통해 수집된 통계를 사용하여 더 적은 수의 대규모 작업보다 많은 소규모 I/O 작업을 통해 전력을 낭비하는 애플리케이션을 식별할 수 있습니다. yum 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

sysstat 패키지에서 제공합니다. 이 도구는 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 은 장치 주 및 부사입니다. 두 번째 열인 1 은 CPU에 대한 정보를 제공하고 그 뒤에 IO 프로세스를 실행하는 프로세스의 타임스탬프 및 PID에 대한 열을 제공합니다.

여섯 번째 열인 Q 는 이벤트 유형, 쓰기 작업의 경우 7번째 열, 8번째 열, 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초마다 결과를 출력합니다.

Turbostat 는 전력 사용 또는 유휴 시간 측면에서 비효율적인 서버를 식별하는 데도 유용합니다. 또한 시스템에서 발생하는 SMI(시스템 관리 인터럽트)의 속도를 식별하는 데 도움이 됩니다. 또한 전원 관리 튜닝의 영향을 확인하는 데 사용할 수 있습니다.

cpupower

IT는 프로세서의 전력 절약 기능을 검사하고 조정하는 도구 모음입니다. cpupower 명령을 frequency-info,frequency- set, idle- info,idle- set,set,info, monitor 옵션과 함께 사용하여 프로세서 관련 값을 표시 및 설정합니다.

예를 들어 사용 가능한 cpufreq governor를 보려면 다음을 사용합니다.

$ cpupower frequency-info --governors
analyzing CPU 0:
  available cpufreq governors: performance powersave

cpupower 에 대한 자세한 내용은 CPU 관련 정보 보기를 참조하십시오.

GNOME Power Manager
GNOME 데스크탑 환경의 일부로 설치된 데몬입니다. GNOME Power Manager는 시스템 전원 상태의 변경 사항을 알립니다. 예를 들어, 배터리에서 AC 전원으로 변경됨. 또한 배터리 상태를 보고하고 배터리 전력이 낮을 때 경고를 표시합니다.

추가 리소스

  • PowerTOP(1), disk devstat(8), netdevstat(8), tuned(8), vmstat(8), iostat(1), bl ktrace(8), blkparse(8)turbostat(8) 도움말 페이지
  • cpupower(1), cpu power-set(1), cpu power-info(1), cpu power-idle(1), cpu power-frequency-set(1), cpu power-frequency-info(1)cpupower-monitor(1) 도움말 페이지

16장. PowerTOP를 사용하여 전력 소비 관리

시스템 관리자는 PowerTOP 툴을 사용하여 전력 소비를 분석하고 관리할 수 있습니다.

16.1. PowerTOP의 목적

PowerTOP 는 전력 소비와 관련된 문제를 진단하고 배터리 수명을 연장하는 방법에 대한 제안을 제공하는 프로그램입니다.

PowerTOP 툴은 시스템의 총 전력 사용량을 추정하고 각 프로세스, 장치, 커널 작업자, 타이머 및 인터럽트 핸들러에 대한 개별 전원 사용량을 제공할 수 있습니다. 또한 이 도구는 CPU를 자주 시작하는 커널 및 사용자 공간 애플리케이션의 특정 구성 요소를 식별할 수 있습니다.

Red Hat Enterprise Linux 8은 PowerTOP 버전 2.x를 사용합니다.

16.2. PowerTOP 사용

사전 요구 사항

  • PowerTOP 를 사용하려면 powertop 패키지가 시스템에 설치되어 있는지 확인합니다.

    # yum install powertop

16.2.1. PowerTOP 시작

절차

  • PowerTOP 를 실행하려면 다음 명령을 사용합니다.

    # powertop
중요

power top 명령을 실행할 때 노트북이 배터리 전원 에서 실행해야 합니다.

16.2.2. PowerTOP 조정

절차

  1. 랩탑에서 다음 명령을 실행하여 전원 추정 엔진을 조정할 수 있습니다.

    # powertop --calibrate
  2. 프로세스 중에 시스템과 상호 작용하지 않고 위로 마무리합니다.

    프로세스가 다양한 테스트를 수행하기 때문에 시간이 걸립니다. 온/오프 레벨 및 스위치 장치를 통해 순환합니다.

  3. 일단 프로세스가 완료되면 PowerTOP 가 정상적으로 시작됩니다. 약 1시간 동안 데이터를 수집하도록 합니다.

    충분한 데이터가 수집되면 출력 테이블의 첫 번째 열에 전원 추정 그림이 표시됩니다.

참고

powertop --calibrate 는 랩탑에서만 사용할 수 있습니다.

16.2.3. 측정 간격 설정

기본적으로 PowerTOP 는 20초 간격으로 측정합니다.

이 측정 빈도를 변경하려면 다음 절차를 사용하십시오.

절차

  • powertop 명령을 --time 옵션으로 실행합니다.

    # powertop --time=time in seconds

16.3. PowerTOP 통계

실행되는 동안 PowerTOP 는 시스템에서 통계를 수집합니다.

PowerTOP의 출력은 여러 탭을 제공합니다.

  • 개요
  • 유휴 상태 통계
  • 빈도 통계
  • 장치 통계
  • 튜닝 가능 항목
  • WakeUp

TabShift+Tab 키를 사용하여 이러한 탭을 순환할 수 있습니다.

16.3.1. 개요 탭

Overview(개요 ) 탭에서는 가장 자주 발생하는 CPU 또는 가장 많은 전원을 사용하는 구성 요소 목록을 볼 수 있습니다. 프로세스, 인터럽트, 장치 및 기타 리소스를 포함하여 Overview(개요 ) 탭 내의 항목은 해당 사용률에 따라 정렬됩니다.

Overview(개요 ) 탭 내의 인접한 열에는 다음과 같은 정보가 있습니다.

사용법
리소스 사용 방법을 전원 추정합니다.
이벤트/s
초당 시작 수. 초당 시작 횟수는 커널의 서비스 또는 장치 및 드라이버가 얼마나 효율적으로 수행하는지 나타냅니다. 페일오버가 감소하면 전력 소비가 줄어듭니다. 구성 요소는 전력 사용량을 최적화할 수 있는 정도에 따라 정렬됩니다.
카테고리
구성 요소 분류(예: 프로세스, 장치 또는 타이머).
설명
구성 요소에 대한 설명입니다.

올바르게 측정된 경우 첫 번째 열에 나열된 모든 항목에 대한 전력 소비 추정도 표시됩니다.

그 외에도 Overview(개요 ) 탭에는 다음과 같은 요약 통계가 포함된 줄이 포함되어 있습니다.

  • 총 전력 소비
  • 나머지 배터리 수명 (해당되는 경우에만)
  • 초당 총 가동 시간 요약, 초당 GPU 작업, 초당 가상 파일 시스템 작업 요약

16.3.2. Idle 통계 탭

Idle 통계 탭에는 모든 프로세서 및 코어에 대한 C-상태가 표시되는 반면, Frequency 통계 탭에는 모든 프로세서 및 코어에 Turbo 모드를 포함한 P-state 사용이 표시됩니다. C- 또는 P-states 기간은 CPU 사용량이 최적화되었는지를 나타냅니다. 높은 C- 또는 P 상태(예: C4가 C3보다 높음)에 CPU가 유지될수록 CPU 사용량 최적화가 좋습니다. 이상적으로, 시스템이 유휴 상태일 때 가장 높은 C- 또는 P 상태의 90% 이상입니다.

16.3.3. 장치 통계 탭

Device stats(장치 통계 ) 탭은 Overview(개요 ) 탭과 비슷한 정보를 제공하지만 장치의 경우에만 사용됩니다.

16.3.4. 튜닝 가능 항목 탭

Tunables 탭에는 낮은 전력 소비를 위해 시스템을 최적화하기 위한 PowerTOP의 제안 사항이 포함되어 있습니다.

updown 키를 사용하여 제안을 통해 이동하고 Enter 키를 사용하여 제안을 켜거나 끕니다.

16.3.5. WakeUp 탭

WakeUp 탭에는 사용자가 필요에 따라 변경할 수 있는 장치 시작 설정이 표시됩니다.

위쪽아래쪽 키를 사용하여 사용 가능한 설정을 통해 이동하고 Enter 키를 사용하여 설정을 활성화하거나 비활성화합니다.

그림 16.1. PowerTOP 출력

powertop2 14

추가 리소스

PowerTOP 에 대한 자세한 내용은 PowerTOP의 홈페이지를 참조하십시오.

16.4. Powertop에서 일부 인스턴스에서 Frequency 통계 값을 표시하지 않는 이유

Intel P-State 드라이버를 사용하는 동안 드라이버가 패시브 모드인 경우 PowerTOP는 Frequency Stats 탭에만 값을 표시합니다. 그러나 이 경우에도 값이 불완전할 수 있습니다.

합계에는 Intel P-State 드라이버의 세 가지 가능한 모드가 있습니다.

  • HWP(하드웨어 P-States)를 사용하는 활성 모드
  • HWP 없는 활성 모드
  • 패시브 모드

ACPI CPUfreq 드라이버로 전환하면 전체 정보가 PowerTOP에 표시됩니다. 그러나 시스템을 기본 설정으로 유지하는 것이 좋습니다.

로드되고 어떤 모드에서 드라이버를 보려면 다음을 실행합니다.

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
  • Intel P-State 드라이버가 로드되고 활성 모드로 전환되면 intel_pstate 가 반환됩니다.
  • Intel P-State 드라이버가 로드되고 패시브 모드로 전환되면 intel_cpufreq 가 반환됩니다.
  • ACPI CPU freq 드라이버가 로드되면 ACPI-cpu freq가 반환됩니다.

Intel P-State 드라이버를 사용하는 동안 다음 인수를 커널 부트 명령줄에 추가하여 드라이버를 패시브 모드로 강제 실행합니다.

intel_pstate=passive

Intel P-State 드라이버를 비활성화하고 를 사용하려면 대신 ACPI CPUfreq 드라이버를 사용하려면 커널 부팅 명령줄에 다음 인수를 추가합니다.

intel_pstate=disable

16.5. HTML 출력 생성

터미널의 powertop 출력 외에 HTML 보고서를 생성할 수도 있습니다.

절차

  • --html 옵션을 사용하여 powertop 명령을 실행합니다.

    # powertop --html=htmlfile.html

    htmlfile.html 매개 변수를 출력 파일에 필요한 이름으로 바꿉니다.

16.6. 전력 소비 최적화

전원 소비를 최적화하려면 power top 서비스 또는 powertop 2tuned 유틸리티를 사용할 수 있습니다.

16.6.1. powertop 서비스를 사용하여 전력 소비 최적화

powertop 서비스를 사용하여 부팅 시 Tunables 탭에서 모든 PowerTOP의 제안 사항을 자동으로 활성화할 수 있습니다.

절차

  • powertop 서비스를 활성화합니다.

    # systemctl enable powertop

16.6.2. powertop2tuned 유틸리티

powertop2tuned 유틸리티를 사용하면 PowerTOP 제안 사항에서 사용자 지정 TuneD 프로필을 만들 수 있습니다.

기본적으로 powertop2tuned/etc/tuned/ 디렉터리에 프로필을 생성하고 현재 선택한 TuneD 프로필의 사용자 지정 프로필을 기반으로 합니다. 안전상의 이유로 새 프로필에서 모든 PowerTOP 튜닝이 초기에 비활성화됩니다.

튜닝을 활성화하려면 다음을 수행할 수 있습니다.

  • /etc/tuned/profile_name/tuned.conf 파일에서 주석 처리를 해제합니다.
  • enable 또는 - e 옵션을 사용하여 PowerTOP 에서 제안하는 대부분의 튜닝을 활성화하는 새 프로필을 생성합니다.

    USB 자동 일시 중지와 같은 특정 잠재적으로 문제가 있는 튜닝은 기본적으로 비활성화되어 있으며 수동으로 주석 처리를 해제해야 합니다.

16.6.3. powertop2tuned 유틸리티를 사용하여 전력 소비 최적화

사전 요구 사항

  • powertop2tuned 유틸리티는 시스템에 설치됩니다.

    # yum install tuned-utils

절차

  1. 사용자 정의 프로필을 생성합니다.

    # powertop2tuned new_profile_name
  2. 새 프로필을 활성화합니다.

    # tuned-adm profile new_profile_name

추가 정보

  • powertop2tuned 에서 지원하는 전체 옵션 목록은 다음을 사용합니다.

    $ powertop2tuned --help

16.6.4. powertop.service 및 powertop2tuned 비교

다음과 같은 이유로 powertop2tuned 를 사용하여 전원 소비를 최적화하는 것이 좋습니다.

  • powertop2tuned 유틸리티는 PowerTOPTuneD 에 통합하여 두 도구의 이점을 활용할 수 있습니다.
  • powertop2tuned 유틸리티를 사용하면 활성화된 튜닝을 세부적으로 제어할 수 있습니다.
  • powertop2tuned 를 사용하면 잠재적으로 위험한 튜닝이 자동으로 활성화되지 않습니다.
  • powertop2tuned 를 사용하면 재부팅하지 않으면 롤백이 가능합니다.

17장. 에너지 사용량을 최적화하기 위한 CPU 빈도 튜닝

필요한 CPUfreq governor를 설정한 후 요구 사항에 따라 사용 가능한 cpupower 명령을 사용하여 시스템에 CPU 속도를 설정하여 시스템의 전원 사용을 최적화할 수 있습니다.

17.1. 지원되는 cpupower 툴 명령

cpupower 툴은 프로세서의 전력 절약 관련 기능을 검사하고 조정하는 툴 모음입니다.

cpupower 툴은 다음 명령을 지원합니다.

idle-info
cpupower idle-info 명령을 사용하여 CPU 유휴 드라이버에 사용 가능한 유휴 상태 및 기타 통계를 표시합니다. 자세한 내용은 CPU Idle State를 참조하십시오.
idle-set
cpupower idle-set 명령을 root로 사용하여 특정 CPU 유휴 상태를 활성화하거나 비활성화합니다. d 사용하여 특정 CPU 유휴 상태를 비활성화하려면 -e 를 사용합니다.
frequency-info
cpu power frequency-info 명령을 사용하여 현재 cpufreq 드라이버와 사용 가능한 cpu freq governor를 표시합니다. 자세한 내용은 CPUfreq 드라이버,코어 CPUfreq GovernorsIntel P-state CPUfreq governors를 참조하십시오.
frequency-set
cpu power frequency-set 명령을 root로 사용하여 cpu freq 및 governor를 설정합니다. 자세한 내용은 CPUfreq governor 설정을 참조하십시오.
set

cpupower set 명령을 root로 사용하여 프로세서 절전 정책을 설정합니다.

--perf-bias 옵션을 사용하면 지원되는 Intel 프로세서에서 소프트웨어를 활성화하여 최적의 성능과 전력 절약 사이의 균형을 결정할 수 있습니다. 할당된 값은 0 에서 15 까지입니다. 여기서 0 은 최적의 성능이며 15 는 최적의 전력 효율성입니다. 기본적으로 -perf-bias 옵션은 모든 코어에 적용됩니다. 개별 코어에만 적용하려면 --cpu cpulist 옵션을 추가합니다.

info

cpupower set 명령을 사용하여 활성화한 프로세서 전원 관련 및 하드웨어 구성을 표시합니다. 예를 들어 --perf-bias 값을 5 로 할당하는 경우

# cpupower set --perf-bias 5
# cpupower info
analyzing CPU 0:
perf-bias: 5
모니터

cpupower monitor 명령을 사용하여 유휴 통계 및 CPU 요구 사항을 표시합니다.

# cpupower monitor
 | Nehalem       || Mperf    ||Idle_Stats
 CPU| C3   | C6   | PC3  | PC6  || C0   | Cx   | Freq || POLL | C1   | C1E  | C3   | C6   | C7s  | C8   | C9   | C10
   0|  1.95| 55.12|  0.00|  0.00||  4.21| 95.79|  3875||  0.00|  0.68|  2.07|  3.39| 88.77|  0.00|  0.00|  0.00| 0.00
[...]

l 옵션을 사용하면 시스템에서 사용 가능한 모든 모니터와 -m 옵션을 사용하여 특정 모니터와 관련된 정보를 표시할 수 있습니다. 예를 들어, Mperf 모니터와 관련된 정보를 모니터링하려면 cpupower monitor -m Mperf 명령을 root로 사용합니다.

추가 리소스

  • cpupower(1), cpu power-idle-info(1), cpu power-idle-set(1), cpu power-frequency-set(1), cpu power-frequency -info (1), cpu power-info(1)cpupower-monitor(1) 도움말 페이지

17.2. CPU ID 상태

x86 아키텍처가 있는 CPU는 비활성화되거나 더 낮은 성능 설정(C-states)을 사용하는 등 다양한 상태를 지원합니다.

이 상태를 사용하면 사용하지 않는 CPU를 부분적으로 비활성화하여 전력을 절약할 수 있습니다. 바람직하지 않은 전력이나 성능 문제를 방지하기 위해 governor가 필요한 P-state와 잠재적으로 설정된 P-state와 달리 C 상태를 구성할 필요가 없습니다. C 상태는 C0 이후부터 번호가 매겨지며 CPU 기능 감소와 전력 절약을 나타내는 숫자가 높습니다. 주어진 수의 C 상태는 프로세서 간에 광범위하게 유사하지만 상태의 특정 기능 세트의 정확한 세부 사항은 프로세서 제품군마다 다를 수 있습니다. C-states 0-3은 다음과 같이 정의됩니다.

C0
이 상태에서는 CPU가 작동 중이고 유휴 상태가 아닙니다.
C1, Halt
이 상태에서 프로세서는 명령을 실행하지 않지만 일반적으로 하위 전원 상태에 있지 않습니다. CPU는 지연 없이 계속 처리할 수 있습니다. C-state를 제공하는 모든 프로세서는 이 상태를 지원해야 합니다. Pentium 4 프로세서는 C1E라는 향상된 C1 상태를 지원하므로, 실제로 전력 소비를 줄이는 상태입니다.
C2, Stop-Clock
이 상태에서는 이 프로세서에 대한 클록이 있지만 레지스터와 캐시의 전체 상태를 유지하므로 시계를 다시 시작한 후 즉시 처리를 시작할 수 있습니다. 이는 선택적 상태입니다.
C3, Sleep
이 상태에서 프로세서는 유휴 상태로 전환되며 캐시를 최신 상태로 유지할 필요가 없습니다. 이러한 이유로 인해 이러한 상태에서 벗어나려면 C2 상태에서보다 훨씬 더 많은 시간이 필요합니다. 이는 선택적 상태입니다.

다음 명령을 사용하여 CPUidle 드라이버의 사용 가능한 유휴 상태 및 기타 통계를 볼 수 있습니다.

$ cpupower idle-info
CPUidle governor: menu
analyzing CPU 0:

Number of idle states: 9
Available idle states: POLL C1 C1E C3 C6 C7s C8 C9 C10
[...]

"Nehalem" 마이크로 아키텍처가 있는 Intel CPU에는 C6 상태가 있어 CPU의 공급을 0으로 줄일 수 있지만 일반적으로 전력 소비를 80%에서 90%까지 줄입니다. Red Hat Enterprise Linux 8의 커널에는 이 새로운 C 상태에 대한 최적화가 포함되어 있습니다.

추가 리소스

  • cpupower(1)cpupower-idle(1) 도움말 페이지

17.3. CPUfreq 개요

시스템의 전력 소비 및 열 출력을 줄이는 가장 효과적인 방법 중 하나는 Red Hat Enterprise Linux 8의 x86 및 ARM64 아키텍처에서 지원하는 CPUfreq입니다. CPU 속도 확장이라고도 하는 CPUfreq는 전력을 절약하기 위해 CPU 빈도를 확장할 수 있는 Linux 커널의 인프라입니다.

CPU 확장은 고급 구성 및 전원 인터페이스(ACPI) 이벤트에 응답하여 시스템 부하에 따라 자동으로 수행하거나 사용자 공간 프로그램에 의해 수동으로 수행할 수 있으며, 프로세서의 클록 속도를 즉각적으로 조정할 수 있습니다. 이렇게 하면 시스템이 짧은 클럭 속도로 실행되어 전력을 절약할 수 있습니다. 더 빠르거나 느린 클록 속도, 빈도를 변경할 때 등 빈도를 변경하는 규칙은 CPUfreq governor에 의해 정의됩니다.

cpu power frequency-info 명령을 root로 사용하여 cpu freq 정보를 볼 수 있습니다.

17.3.1. CPUfreq 드라이버

cpupower frequency-info --driver 명령을 root로 사용하여 현재 CPUfreq 드라이버를 볼 수 있습니다.

다음은 CPUfreq에 사용할 수 있는 두 가지 드라이버입니다.

ACPI CPUfreq
ACPI(Advanced Configuration and Power Interface) CPUfreq 드라이버는 ACPI를 통해 특정 CPU의 빈도를 제어하는 커널 드라이버로, 커널과 하드웨어 간의 통신을 보장합니다.
Intel P-state

Red Hat Enterprise Linux 8에서는 Intel P-state 드라이버가 지원됩니다. 드라이버는 Intel Xeon E 시리즈 아키텍처 또는 최신 아키텍처를 기반으로 프로세서에서 P-상태 선택을 제어하기 위한 인터페이스를 제공합니다.

현재 지원되는 CPU에 기본적으로 Intel P-state가 사용됩니다. intel_pstate=disable 명령을 커널 명령줄에 추가하여 ACPI CPUfreq를 사용하도록 전환할 수 있습니다.

Intel P-state는 setpolicy() 콜백을 구현합니다. 드라이버는 cpufreq 코어에서 요청된 정책에 따라 사용할 P-state를 결정합니다. 프로세서가 내부적으로 다음 P-상태를 선택할 수 있는 경우 드라이버는 이 책임을 프로세서에 오프로드합니다. 그렇지 않은 경우 드라이버는 알고리즘을 구현하여 다음 P-상태를 선택합니다.

Intel P-state는 자체 sysfs 파일을 제공하여 P 상태 선택을 제어합니다. 이러한 파일은 /sys/devices/system/cpu/intel_pstate/ 디렉터리에 있습니다. 파일의 변경 사항은 모든 CPU에 적용할 수 있습니다.

이 디렉터리에는 P-state 매개변수 설정에 사용되는 다음 파일이 포함되어 있습니다.

  • max_perf_pct 는 드라이버가 사용 가능한 성능의 백분율로 표현한 최대 P-state를 제한합니다. 사용 가능한 P-state 성능은 no_turbo 설정으로 줄일 수 있습니다.
  • min_perf_pct 는 드라이버에서 요청한 최소 P-상태를 제한하며, 이는 최대 no-turbo 성능 수준의 백분율로 표시됩니다.
  • no_turbo 는 turbo 빈도 범위 아래에 있는 P-state를 선택하도록 드라이버를 제한합니다.
  • turbo_pct 는 turbo 범위에 있는 하드웨어에서 지원하는 총 성능의 백분율을 표시합니다. 이 숫자는 turbo가 비활성화 되었는지 여부와 독립적입니다.
  • num_p states는 하드웨어에서 지원하는 P-state 수를 표시합니다. 이 숫자는 turbo가 비활성화되었는지 여부와 독립적입니다.

추가 리소스

  • cpupower-frequency-info(1) 도움말 페이지

17.3.2. 코어 CPUfreq governor

CPUfreq governor는 시스템 CPU의 전원 특성을 정의하며, 이 특성은 CPU 성능에 영향을 미칩니다. 각 governor는 워크로드 측면에서 고유한 동작, 목적 및 적합성을 갖습니다. cpupower frequency-info --governor 명령을 root로 사용하여 사용 가능한 CPUfreq governor를 볼 수 있습니다.

Red Hat Enterprise Linux 8에는 여러 코어 CPUfreq governor가 포함되어 있습니다.

cpufreq_performance
CPU가 가능한 가장 높은 클록 빈도를 사용하도록 강제 적용합니다. 이 빈도는 정적으로 설정되며 변경되지 않습니다. 따라서 이 특정 governor는 전력 절약 효과를 제공하지 않습니다. 워크로드가 많은 시간에만 적합하며 CPU가 거의 또는 유휴 상태가 되지 않는 경우에만 적합합니다.
cpufreq_powersave
CPU가 가능한 가장 낮은 클록 빈도를 사용하도록 강제 적용합니다. 이 빈도는 정적으로 설정되며 변경되지 않습니다. 이 governor는 최대 전력 절감을 제공하지만 CPU 성능이 가장 낮습니다. 기본적으로 전체 부하의 느린 CPU가 로드되지 않은 빠른 CPU보다 더 많은 전력을 소비하므로 "전원 저장"이라는 용어는 비활성화되는 경우가 있습니다. 따라서 예상 낮은 활동이 낮은 시간대에 절전 조정기를 사용하도록 CPU를 설정하는 것이 좋지만, 그 기간 동안 예기치 않은 높은 부하로 인해 시스템이 실제로 더 많은 전력을 소비할 수 있습니다. 절전 governor는 CPU의 속도 제한기보다 절전기입니다. 과열이 문제가 될 수 있는 시스템과 환경에서 가장 유용합니다.
cpufreq_ondemand
CPU가 시스템 로드가 높은 경우 최대 클록 빈도와 시스템이 유휴 상태일 때 최소 클록 빈도를 달성할 수 있는 동적 governor입니다. 따라서 시스템은 시스템 부하와 관련하여 전력 소비를 적절하게 조정할 수 있지만 빈도 전환 사이의 대기 시간이 소요되었습니다. 따라서 시스템이 유휴 워크로드와 작업량이 너무 자주 전환되는 경우 ondemand governor가 제공하는 모든 성능 또는 절전 이점을 오프셋할 수 있습니다. 대부분의 시스템에서 온 디맨드 governor는 난방 제거, 전력 소비, 성능 및 관리 효율성 사이에서 최상의 절충안을 제공할 수 있습니다. 시스템이 특정 시간에만 사용 중일 때 ondemand governor는 추가 개입 없이 부하에 따라 최대 빈도와 최소 빈도 간에 자동으로 전환합니다.
cpufreq_userspace
이를 통해 사용자 공간 프로그램 또는 root로 실행되는 모든 프로세스가 빈도를 설정할 수 있습니다. 모든 governor에서 사용자 공간은 가장 사용자 지정 가능한 공간 이며 구성 방법에 따라 시스템의 성능과 소비 간에 최적의 균형을 유지할 수 있습니다.
cpufreq_conservative
온 디맨드 governor와 마찬가지로, 보수적인 governor도 사용량에 따라 클럭 빈도를 조정합니다. 그러나 보수적인 governor는 빈도 사이에서 점점 더 점진적으로 전환됩니다. 즉, 보수적인 governor는 최대 및 최소 중에서 선택하는 대신 부하에 가장 적합한 클럭 빈도에 맞게 조정됩니다. 이는 전력 소비를 대폭 절감할 수 있지만, 온 디맨드 governor보다 더 많은 대기 시간을 확보할 수 있습니다.
참고

cron 작업을 사용하여 governor를 활성화할 수 있습니다. 이를 통해 하루 중 특정 시간에 특정 governor를 자동으로 설정할 수 있습니다. 따라서 유휴 시간(예: 근무 시간 후) 동안 낮은 빈도 governor를 지정하고 워크로드가 많은 시간 동안 더 높은 빈도의 governor로 돌아갈 수 있습니다.

특정 governor를 활성화하는 방법에 대한 지침은 CPUfreq governor 설정을 참조하십시오.

17.3.3. Intel P-state CPUfreq governors

기본적으로 Intel P-state 드라이버는 CPU가 HWP를 지원하는지 여부에 따라 HWP(하드웨어 p-state)를 사용하거나 사용하지 않고 활성 모드로 작동합니다.

cpupower frequency-info --governor 명령을 root로 사용하여 사용 가능한 CPUfreq governor를 볼 수 있습니다.

참고

성능절전 Intel P-state CPUfreq governors 기능은 동일한 이름의 코어 CPUfreq governor와 다릅니다.

Intel P-state 드라이버는 다음 세 가지 모드에서 작동할 수 있습니다.

하드웨어 관리 P-states를 사용하는 활성 모드

HWP를 사용한 활성 모드를 사용하는 경우 Intel P-state 드라이버는 CPU에 P 상태 선택을 수행하도록 지시합니다. 드라이버는 빈도 힌트를 제공할 수 있습니다. 그러나 최종 선택은 CPU 내부 논리에 따라 다릅니다. HWP를 사용한 활성 모드에서 Intel P-state 드라이버는 다음 두 가지 P 상태 선택 알고리즘을 제공합니다.

  • performance: performance governor를 사용하면 이 드라이버는 내부 CPU 로직을 성능 지향적으로 지시합니다. 허용되는 P-상태의 범위는 드라이버에서 사용할 수 있는 범위의 위쪽 경계로 제한됩니다.
  • powersave: powersave governor를 사용하면 이 드라이버는 내부 CPU 논리를 절전 지향으로 지시합니다.
하드웨어 관리 P-state가 없는 활성 모드

HWP가 없는 활성 모드를 사용하는 경우 Intel P-state 드라이버는 다음 두 가지 P 상태 선택 알고리즘을 제공합니다.

  • performance: performance governor를 사용하면 드라이버에서 사용할 수 있는 최대 P-state를 선택합니다.
  • powersave: powersave governor를 사용하면 드라이버에서 현재 CPU 사용률에 비례하여 P-상태를 선택합니다. 이 동작은 온디맨드 CPUfreq core governor와 유사합니다.
패시브 모드
passive 모드를 사용하면 Intel P-state 드라이버가 기존 CPUfreq 확장 드라이버와 동일하게 작동합니다. 사용 가능한 모든 일반 CPUFreq 코어 governor를 사용할 수 있습니다.

17.3.4. CPUfreq governor 설정

모든 CPUfreq 드라이버는 kernel-tools 패키지의 일부로 구축되며 자동으로 선택됩니다. CPUfreq를 설정하려면 governor를 선택해야 합니다.

사전 요구 사항

  • cpupower 를 사용하려면 kernel-tools 패키지를 설치합니다.

    # yum install kernel-tools

절차

  1. 특정 CPU에 사용할 수 있는 governor를 확인합니다.

    # cpupower frequency-info --governors
    analyzing CPU 0:
      available cpufreq governors: performance powersave
  2. 모든 CPU에서 governor 중 하나를 활성화합니다.

    # cpupower frequency-set --governor performance

    성능 governor를 요구 사항에 따라 cpufreq governor 이름으로 바꿉니다.

    특정 코어에서만 governor를 활성화하려면 범위 또는 쉼표로 구분된 CPU 번호와 함께 -c 를 사용합니다. 예를 들어 CPU 1-3 및 5의 userspace governor를 활성화하려면 다음을 사용합니다.

    # cpupower -c 1-3,5 frequency-set --governor cpufreq_userspace
참고

kernel-tools 패키지가 설치되지 않은 경우 CPUfreq 설정은 /sys/devices/system/cpu/cpuid/cpufreq/ 디렉토리에서 볼 수 있습니다. 이러한 튜닝 가능 항목에 작성하여 설정 및 값을 변경할 수 있습니다. 예를 들어 cpu0의 최소 클록 속도를 360 MHz로 설정하려면 다음을 사용합니다.

# echo 360000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

검증

  • governor가 활성화되었는지 확인합니다.

    # cpupower frequency-info
    analyzing CPU 0:
      driver: intel_pstate
      CPUs which run at the same hardware frequency: 0
      CPUs which need to have their frequency coordinated by software: 0
      maximum transition latency:  Cannot determine or is not supported.
      hardware limits: 400 MHz - 4.20 GHz
      available cpufreq governors: performance powersave
      current policy: frequency should be within 400 MHz and 4.20 GHz.
            The governor "performance" may decide which speed to use within this range.
      current CPU frequency: Unable to call hardware
      current CPU frequency: 3.88 GHz (asserted by call to kernel)
      boost state support:
        Supported: yes
        Active: yes

    현재 정책에는 최근 활성화된 cpufreq governor가 표시됩니다. 이 경우 성능이 우수합니다.

추가 리소스

  • cpupower-frequency-info(1)cpupower-frequency-set(1) 도움말 페이지

18장. perf 시작하기

시스템 관리자는 perf 툴을 사용하여 시스템의 성능 데이터를 수집 및 분석할 수 있습니다.

18.1. perf 소개

PCL(커널 기반 하위 시스템 성능 카운터)과 perf 사용자 공간 툴 인터페이스입니다. perf 는 PMU( 성능 모니터링 장치)를 사용하여 다양한 하드웨어 및 소프트웨어 이벤트를 측정, 기록 및 모니터링하는 강력한 도구입니다. perf 는 추적 지점, kprobes 및 uprobes도 지원합니다.

18.2. perf 설치

이 절차에서는 perf 사용자 공간 툴을 설치합니다.

절차

  • perf 툴을 설치합니다.

    # yum install perf

18.3. 일반적인 perf 명령

perf stat
이 명령은 실행된 명령과 사용된 클럭 사이클을 포함하여 일반적인 성능 이벤트에 대한 전반적인 통계를 제공합니다. 옵션을 사용하면 기본 측정 이벤트 이외의 이벤트를 선택할 수 있습니다.
perf 레코드
이 명령은 성능 데이터를 파일에 기록합니다 . perf.data 는 나중에 perf report 명령을 사용하여 분석할 수 있습니다.
perf 보고서
이 명령은 perf 레코드로 만든 perf.data 파일에서 성능 데이터를 읽고 표시합니다.
perf list
이 명령은 특정 시스템에서 사용할 수 있는 이벤트를 나열합니다. 이러한 이벤트는 시스템의 성능 모니터링 하드웨어 및 소프트웨어 구성에 따라 달라집니다.
perf top
이 명령은 top 유틸리티와 유사한 기능을 수행합니다. 성능 카운터 프로필을 실시간으로 생성하고 표시합니다.
perf 추적
이 명령은 strace 툴과 유사한 기능을 수행합니다. 지정된 스레드 또는 프로세스와 해당 애플리케이션에서 수신한 모든 신호에서 사용하는 시스템 호출을 모니터링합니다.
perf 도움말
이 명령은 전체 권한 명령 목록을 표시합니다.

추가 리소스

  • 하위 명령에 --help 옵션을 추가하여 도움말 페이지를 엽니다.

19장. perf top을 사용하여 실시간으로 CPU 사용량 프로파일링

perf top 명령을 사용하여 다양한 기능의 CPU 사용량을 실시간으로 측정할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다 .

19.1. perf top의 목적

perf top 명령은 실시간 시스템 프로파일링에 사용되며 top 유틸리티와 유사하게 작동합니다. 그러나 top 유틸리티에서 일반적으로 지정된 프로세스 또는 스레드가 사용하는 CPU 시간 양을 보여 주는 경우 perf top 은 각 특정 함수에서 사용하는 CPU 시간을 보여 줍니다. 기본 상태에서 perf top 은 사용자 공간 및 커널 공간의 모든 CPU에서 사용되는 기능에 대해 알려줍니다. perf top 을 사용하려면 루트 액세스가 필요합니다.

19.2. perf top을 사용하여 CPU 사용량 프로파일링

이 절차에서는 최상위 및 프로파일 CPU 사용량을 실시간으로 활성화합니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.
  • 루트 액세스 권한이 있습니다.

절차

  • 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) 도움말 페이지

19.3. perf 상위 출력 해석

perf top 모니터링 인터페이스는 여러 열에 데이터를 표시합니다.

"Overhead" 열
는 지정된 함수에서 사용 중인 CPU의 백분율을 표시합니다.
"Shared Object" 열
함수를 사용하고 있는 프로그램 또는 라이브러리의 이름을 표시합니다.
"Symbol" 열
함수 이름 또는 기호를 표시합니다. 커널 공간에서 실행되는 함수는 [k] 로 식별되며 사용자 공간에서 실행되는 함수는 [.] 로 식별됩니다.

19.4. perf가 일부 기능 이름을 원시 기능 주소로 표시하는 이유

커널 함수의 경우 perf/proc/kallsyms 파일의 정보를 사용하여 해당 함수 이름 또는 기호에 샘플을 매핑합니다. 그러나 사용자 공간에서 실행되는 함수의 경우 바이너리가 제거되므로 원시 함수 주소가 표시될 수 있습니다.

실행 파일의 The debuginfo 패키지를 설치해야 하거나 실행 파일이 로컬에서 개발된 애플리케이션인 경우 이러한 상황에서 기능 이름 또는 기호를 표시하려면 디버깅 정보를 사용하여 애플리케이션을 컴파일해야 합니다.

참고

실행 파일과 연결된 the debuginfo 를 설치한 후에는 perf record 명령을 다시 실행할 필요가 없습니다. perf report 명령을 간단히 다시 실행합니다.

19.5. 디버그 및 소스 리포지토리 활성화

Red Hat Enterprise Linux의 표준 설치에서는 디버그 및 소스 리포지토리를 활성화하지 않습니다. 이러한 리포지토리에는 시스템 구성 요소를 디버깅하고 성능을 측정하는 데 필요한 정보가 포함되어 있습니다.

절차

  • 소스 및 디버그 정보 패키지 채널을 활성화합니다.

    # subscription-manager repos --enable rhel-8-for-$(uname -i)-baseos-debug-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-baseos-source-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-appstream-debug-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-appstream-source-rpms

    $(uname -i) 부분은 자동으로 시스템 아키텍처의 일치하는 값으로 교체됩니다.

    아키텍처 이름현재의

    64비트 Intel 및 AMD

    x86_64

    64비트 ARM

    aarch64

    IBM POWER

    ppc64le

    64-bit IBM Z

    s390x

19.6. GDB를 사용하여 애플리케이션 또는 라이브러리용 debuginfo 패키지 가져오기

코드를 디버깅하려면 디버깅 정보가 필요합니다. 패키지에서 설치된 코드의 경우 GDB(GNU Debugger)는 누락된 디버그 정보를 자동으로 인식하고 패키지 이름을 해석하며 패키지를 가져오는 방법에 대한 구체적인 조언을 제공합니다.

사전 요구 사항

  • 디버깅할 애플리케이션 또는 라이브러리가 시스템에 설치되어 있어야 합니다.
  • GDB 및 the 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. GDB를 종료합니다. q입력하고 Enter 를 사용하여 확인합니다.

    (gdb) q
  3. GDB에서 제안하는 명령을 실행하여 required debuginfo 패키지를 설치합니다.

    # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

    dnf 패키지 관리 도구는 변경 사항에 대한 요약을 제공하고 확인 후 필요한 모든 파일을 다운로드 및 설치합니다.

  4. GDB가 debuginfo 패키지를 제안할 수 없는 경우 애플리케이션 또는 라이브러리의 debuginfo 패키지 가져오기에 설명된 절차를 수동으로 수행합니다.

20장. perf 통계를 사용하여 프로세스 실행 중 이벤트 수

perf stat 명령을 사용하여 프로세스 실행 중에 하드웨어 및 소프트웨어 이벤트를 계산할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다 .

20.1. perf stat의 목적

perf stat 명령은 지정된 명령을 실행하고 명령을 실행하는 동안 하드웨어 및 소프트웨어 이벤트 발생의 실행 수를 유지하고 이러한 개수의 통계를 생성합니다. 이벤트를 지정하지 않으면 통계가 공통 하드웨어 및 소프트웨어 이벤트 집합을 계산합니다.

20.2. perf 통계가 있는 이벤트 수

perf 통계를 사용하여 명령 실행 중에 하드웨어 및 소프트웨어 이벤트 발생 횟수를 계산하고 이러한 개수의 통계를 생성할 수 있습니다. 기본적으로 perf 통계는 스레드당 모드로 작동합니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다 .

절차

  • 이벤트 수를 계산합니다.

    • 루트 액세스 없이 perf stat 명령을 실행하면 사용자 공간에서 발생하는 이벤트만 계산됩니다.

      $ perf stat ls

      예 20.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 액세스 없이 실행될 때 이벤트 이름 뒤에는 해당 이벤트가 사용자 공간에서만 계산되었음을 나타냅니다.

    • 사용자 공간 및 커널 공간 이벤트를 모두 계산하려면 통계에 따라 root 액세스 권한이 있어야 합니다.

      # perf stat ls

      예 20.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 통계는 스레드당 모드로 작동합니다. CPU 전체 이벤트 개수로 변경하려면 -a 옵션을 perf stat 에 전달합니다. CPU 전체 이벤트를 계산하려면 루트 액세스가 필요합니다.

        # perf stat -a ls

추가 리소스

  • perf-stat(1) 도움말 페이지

20.3. perf stat 출력 해석

Perf stat 은 지정된 명령을 실행하고 명령 실행 중에 이벤트 발생 횟수를 계산하며 이러한 개수의 통계를 세 열로 표시합니다.

  1. 특정 이벤트에 대해 계산된 발생 수
  2. 계산된 이벤트의 이름
  3. 관련 지표를 사용할 수 있게 되면 오른쪽 끝에 있는 해시 기호(#) 뒤에 비율 또는 백분율이 표시됩니다.

    예를 들어 기본 모드에서 실행하는 경우 perf stat 은 사이클과 지침을 모두 계산하므로 오른쪽 끝에 있는 사이클당 명령을 계산하고 표시합니다. 기본적으로 두 이벤트가 모두 계산되므로 분기 누락과 관련하여 유사한 동작을 모든 분기의 백분율로 확인할 수 있습니다.

20.4. 실행 중인 프로세스에 perf 통계 연결

실행 중인 프로세스에 perf 통계를 연결할 수 있습니다. 이렇게 하면 명령을 실행하는 동안 지정된 프로세스에서만 이벤트 발생 수를 계산하도록 perf stat 에 지시합니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  • 실행 중인 프로세스에 perf 통계를 연결합니다.

    $ perf stat -p ID1,ID2 sleep seconds

    이전 예제에서는 sleep 명령을 사용하여 지정한 시간( ) 동안 ID1 및 ID2 를 사용하여 프로세스의 이벤트를 계산합니다.

추가 리소스

  • perf-stat(1) 도움말 페이지

21장. perf를 사용하여 성능 프로파일 기록 및 분석

perf 툴을 사용하면 성능 데이터를 기록하고 나중에 분석할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다 .

21.1. perf 레코드의 목적

perf record 명령은 성능 데이터를 샘플링하고 이를 다른 perf 명령으로 읽고 시각화할 수 있는 perf.data 파일에 저장합니다 . perf.data 는 현재 디렉터리에서 생성되며 나중에 다른 시스템에서 액세스할 수 있습니다.

동안 기록할 perf 레코드에 대한 명령을 지정하지 않으면 Ctrl+C 를 눌러 프로세스를 수동으로 중지할 때까지 기록됩니다. -p 옵션 다음에 하나 이상의 프로세스 ID를 전달하여 perf 레코드 를 특정 프로세스에 연결할 수 있습니다. 루트 액세스 없이 perf 레코드 를 실행할 수 있지만 사용자 공간에서만 샘플 성능 데이터만 실행할 수 있습니다. 기본 모드에서 perf 레코드 는 CPU 주기를 샘플링 이벤트로 사용하며 상속 모드가 활성화된 스레드별 모드에서 작동합니다.

21.2. 루트 액세스없이 성능 프로필 기록

샘플에 대한 루트 액세스 권한 없이 perf 레코드 를 사용하고 사용자 공간에만 성능 데이터를 기록할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다 .

절차

  • 성능 데이터를 샘플링하고 기록합니다.

    $ perf record command

    데이터를 샘플링하려는 명령으로 명령을 바꿉니다. 명령을 지정하지 않으면 Ctrl+C 를 눌러 수동으로 중지할 때까지 perf 레코드에서 데이터를 샘플링합니다.

추가 리소스

  • perf-record(1) 도움말 페이지

21.3. 루트 액세스 권한으로 성능 프로필 기록

샘플에 대한 루트 액세스 권한과 함께 perf 레코드 를 사용하고 사용자 공간과 커널 공간에 동시에 성능 데이터를 기록할 수 있습니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다 .
  • 루트 액세스 권한이 있습니다.

절차

  • 성능 데이터를 샘플링하고 기록합니다.

    # perf record command

    데이터를 샘플링하려는 명령으로 명령을 바꿉니다. 명령을 지정하지 않으면 Ctrl+C 를 눌러 수동으로 중지할 때까지 perf 레코드에서 데이터를 샘플링합니다.

추가 리소스

  • perf-record(1) 도움말 페이지

21.4. CPU당 모드에서 성능 프로필 기록

CPU당 perf 레코드 를 사용하여 모니터링된 CPU의 모든 스레드에서 동시에 및 사용자 공간 및 커널 공간에 성능 데이터를 샘플링하고 기록할 수 있습니다. 기본적으로 CPU당 모드는 모든 온라인 CPU를 모니터링합니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다 .

절차

  • 성능 데이터를 샘플링하고 기록합니다.

    # perf record -a command

    데이터를 샘플링하려는 명령으로 명령을 바꿉니다. 명령을 지정하지 않으면 Ctrl+C 를 눌러 수동으로 중지할 때까지 perf 레코드에서 데이터를 샘플링합니다.

추가 리소스

  • perf-record(1) 도움말 페이지

21.5. perf 레코드를 사용하여 호출 그래프 데이터 캡처

성능 프로필의 다른 기능을 호출하는 함수를 기록하도록 perf 레코드 툴을 구성할 수 있습니다. 여러 프로세스가 동일한 함수를 호출하는 경우 성능 장애를 식별하는 데 도움이 됩니다.

사전 요구 사항

  • perf 설치에 설명된 대로 perf 사용자 공간 도구가 설치되어 있습니다.

절차

  • call-graph 옵션을 사용하여 성능 데이터를 샘플링 하고 기록합니다.

    $ perf record --call-graph method command
    • 데이터를 샘플링하려는 명령으로 명령을 바꿉니다. 명령을 지정하지 않으면 Ctrl+C 를 눌러 수동으로 중지할 때까지 perf 레코드에서 데이터를 샘플링합니다.
    • 방법을 다음과 같은 팝업 방법 중 하나로 바꿉니다.

      fp
      프레임 포인터 방법을 사용합니다. 컴파일러 최적화(예: GCC 옵션 --fomit-frame-pointer 로 빌드된 바이너리)에 따라 스택이 풀링되지 않을 수 있습니다.
      dwarf
      DWARF 호출 프레임 정보를 사용하여 스택을 제거합니다.
      lbr
      Intel 프로세서에서 마지막 분기 레코드 하드웨어를 사용합니다.

추가 리소스

  • perf-record(1) 도움말 페이지

21.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) 도움말 페이지

21.7. perf 보고서 출력 해석

perf report 명령을 실행하여 표시된 테이블에서 데이터를 여러 열로 정렬합니다.

'Overhead' 열
이 특정 기능에서 수집된 전체 샘플의 백분율을 나타냅니다.
'Command' 열
은 샘플이 수집한 프로세스를 알려줍니다.
'Shared Object' 열
는 샘플이 제공된 ELF 이미지의 이름을 표시합니다(커널.kallsyms 이름이 커널에서 온 경우 이름).
'Symbol' 열
함수 이름 또는 기호를 표시합니다.

기본 모드에서는 함수가 가장 높은 오버헤드가 가장 높은 함수가 먼저 내림차순으로 정렬됩니다.

21.8. 다른 장치에서 읽을 수 있는 perf.data 파일 생성

perf 도구를 사용하여 성능 데이터를 perf .data 파일에 기록하여 다른 장치에서 분석할 수 있습니다.

사전 요구 사항

절차

  1. 조사에 관심이 있는 성능 데이터를 캡처합니다.

    # perf record -a --call-graph fp sleep seconds

    이 예제에서는 sleep 명령을 사용하여 지정한 시간 동안 전체 시스템에 perf.data 를 생성합니다. 또한 프레임 포인터 방법을 사용하여 호출 그래프 데이터를 캡처합니다.

  2. 기록된 데이터의 디버그 기호가 포함된 아카이브 파일을 생성