Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

가상화 튜닝 및 최적화 가이드

Red Hat Enterprise Linux 7

RHEL에서 호스트 시스템 및 가상화 게스트의 KVM 성능 기능 사용

초록

Red Hat Enterprise Linux Virtualization 조정 및 최적화 가이드에서는 KVM 및 가상화 성능을 다룹니다. 이 가이드에서는 호스트 시스템 및 가상화 게스트에 대한 KVM 성능 기능과 옵션을 최대한 활용하기 위한 팁과 제안을 찾을 수 있습니다.

1장. 소개

1.1. 가상화에서 Performance Optimization Matters를 선택해야 하는 이유

KVM Virtualization에서 게스트는 호스트 머신의 프로세스로 표시됩니다. 즉, 호스트의 처리 전원, 메모리 및 기타 리소스는 게스트 가상 하드웨어의 기능과 기능을 에뮬레이션하는 데 사용됩니다.
그러나 게스트 하드웨어는 호스트보다 리소스를 사용하는 데 덜 효과적 일 수 있습니다. 따라서 게스트가 예상 속도로 작업을 수행하기 위해 할당된 호스트 리소스의 양을 조정해야 할 수 있습니다. 또한 다양한 유형의 가상 하드웨어는 오버헤드 수준이 다를 수 있으므로 적절한 가상 하드웨어 구성이 게스트 성능에 상당한 영향을 미칠 수 있습니다. 마지막으로 상황에 따라 가상 시스템에서 호스트 리소스를 보다 효율적으로 사용할 수 있도록 특정 구성을 사용합니다.

1.2. KVM 성능 아키텍처 개요

다음 포인트는 시스템 성능과 프로세스 및 스레드 관리와 관련된 KVM에 대한 간략한 개요를 제공합니다.
  • KVM을 사용하는 경우 게스트는 호스트에서 Linux 프로세스로 실행됩니다.
  • 가상 CPU(vCPU)는 Linux 스케줄러에서 처리하는 일반 스레드로 구현됩니다.
  • 게스트는 커널에서 NUMA 및 대규모 페이지와 같은 기능을 자동으로 상속하지 않습니다.
  • 호스트의 디스크 및 네트워크 I/O 설정은 성능에 큰 영향을 미칩니다.
  • 네트워크 트래픽은 일반적으로 소프트웨어 기반 브리지를 통해 이동합니다.
  • 장치 및 해당 모델에 따라 특정 하드웨어의 에뮬레이션으로 인해 상당한 오버헤드가 발생할 수 있습니다.

1.3. 가상화 성능 기능 및 개선 사항

Red Hat Enterprise Linux 7의 가상화 성능 개선

Red Hat Enterprise Linux 7에서 가상화 성능을 향상시키는 기능은 다음과 같습니다.
자동 NUMA 분산
자동 NUMA 분산은 Red Hat Enterprise Linux 7 게스트에 필요한 수동 튜닝 없이도 NUMA 하드웨어 시스템에서 실행되는 애플리케이션의 성능을 향상시킵니다. 자동 NUMA 분산은 실행 중인 메모리에 더 가깝게 스레드 또는 프로세스일 수 있는 작업을 이동합니다. 이를 통해 제로 구성을 사용하여 우수한 성능을 얻을 수 있습니다. 그러나 경우에 따라 더 정확한 게스트 구성을 제공하거나 CPU 및 메모리에 대한 게스트를 호스트하도록 설정하면 더 나은 결과를 얻을 수 있습니다.
자동 NUMA 분산에 대한 자세한 내용은 9.2절. “자동 NUMA 분산” 을 참조하십시오.
VirtIO 모델
virtio 모델이 있는 모든 가상 하드웨어에는 모든 특정 항목으로 하드웨어를 에뮬레이션하는 오버헤드가 없습니다. virtio 장치는 가상화 환경에서 사용하도록 특별히 설계되었기 때문에 오버헤드가 낮습니다. 그러나 모든 게스트 운영 체제가 이러한 모델을 지원하는 것은 아닙니다.
멀티 큐 virtio-net
게스트의 사용 가능한 vCPU 수를 사용하여 패킷 전송/취소 처리를 가능하게 하는 네트워킹 접근 방식입니다.
멀티 큐 virtio-net에 대한 자세한 내용은 5.4.2절. “멀티 큐 virtio-net” 을 참조하십시오.
Bridge Zero Copy Transmit
제로 복사 전송 모드는 처리량에 영향을 주지 않고 게스트 네트워크와 외부 네트워크 간에 큰 패킷을 전송하는 호스트 CPU 오버헤드를 최대 15 %까지 줄입니다. 브리지 제로 복사 전송은 Red Hat Enterprise Linux 7 가상 머신에서 완전히 지원되지만 기본적으로 비활성화되어 있습니다.
제로 복사 전송에 대한 자세한 내용은 5.4.1절. “Bridge Zero Copy Transmit” 을 참조하십시오.
APIC 가상화(APICv)
최신 Intel 프로세서는 Advanced Programmable Interrupt Controller (APICv)의 하드웨어 가상화를 제공합니다. APICv는 가상화 AMD64 및 Intel 64 게스트 성능을 개선하여 게스트가 APIC에 직접 액세스하여 인터럽트 대기 시간을 크게 줄이고 APIC로 인해 발생하는 가상 머신의 수를 단축할 수 있습니다. 이 기능은 최신 Intel 프로세서에서 기본적으로 사용되며 I/O 성능이 향상됩니다.
EOISTDOUT
가상 APIC 기능 없이 이전 칩셋의 높은 대역폭 I/O에 대한 종단간 가속화.
멀티 큐 virtio-scsi
virtio-scsi 드라이버에서 다중 대기열 지원이 제공하는 스토리지 성능 및 확장성 개선 이를 통해 각 가상 CPU는 다른 vCPU에 영향을 주지 않고 별도의 대기열과 인터럽트를 사용할 수 있습니다.
다중 큐 virtio-scsi에 대한 자세한 내용은 7.4.2절. “다중 대기열 virtio-scsi” 을 참조하십시오.
반가상화 티켓 잠금
반가상화 티켓 잠금(pvticketlocks)은 CPU가 초과 구독된 Red Hat Enterprise Linux 7 호스트에서 실행되는 Red Hat Enterprise Linux 7 게스트 가상 시스템의 성능을 향상시킵니다.
반가상화 페이지 Faults
호스트에서 스왑 아웃한 페이지에 액세스하려고 할 때 반가상화 페이지 폴트가 게스트에 삽입됩니다. 이렇게 하면 호스트 메모리가 과다 할당되고 게스트 메모리가 스왑 아웃될 때 KVM 게스트 성능이 향상됩니다.
반가상화 시간 vsyscall Optimization
gettimeofday 및 clock_gettime 시스템 호출은 vsyscall 메커니즘을 통해 사용자 공간에서 실행됩니다. 이전에는 이러한 시스템 호출을 실행하여 커널 모드로 전환한 다음 사용자 공간으로 다시 전환해야 했습니다. 따라서 일부 애플리케이션의 성능이 크게 향상됩니다.

Red Hat Enterprise Linux의 가상화 성능 기능

  • CPU/커널
    • NUMA - NUMA(Non-Uniform Memory Access) NUMA에 대한 자세한 내용은 9장. NUMA 를 참조하십시오.
    • CFS - 완전 공정 스케줄러. 최신 클래스 중심 스케줄러입니다.
    • RCU - 복사 업데이트 읽기. 공유 스레드 데이터 처리 개선.
    • 최대 160개의 가상 CPU(vCPU).
  • 메모리
    • 대규모 페이지 및 메모리 집약적 환경에 대한 기타 최적화. 자세한 내용은 8장. 메모리 을 참조하십시오.
  • 네트워킹
    • vhost-net - 빠른 커널 기반 VirtIO 솔루션입니다.
    • SR-IOV - 거의 네이티브 네트워킹 성능 수준입니다.
  • 블록 I/O
    • AIO - 다른 I/O 작업을 겹치는 스레드를 지원합니다.
    • MSI - PCI 버스 장치 인터럽트 생성.
    • 디스크 I/O 제한 - 호스트 리소스를 과도하게 사용하지 않도록 게스트 디스크 I/O 요청을 제어합니다. 자세한 내용은 7.4.1절. “디스크 I/O Throttling” 을 참조하십시오.
참고
가상화 지원, 제한 및 기능에 대한 자세한 내용은 Red Hat Enterprise Linux 7 Virtualization 시작하기 가이드 및 다음 URL을 참조하십시오.
https://access.redhat.com/certified-hypervisors
https://access.redhat.com/articles/rhel-kvm-limits

2장. 성능 모니터링 툴

이 장에서는 게스트 가상 머신 환경을 모니터링하는 데 사용되는 툴에 대해 설명합니다.

2.1. perf kvm

kvm 옵션과 함께 perf 명령을 사용하여 호스트에서 게스트 운영 체제 통계를 수집하고 분석할 수 있습니다. perf 패키지는 perf 명령을 제공합니다. 다음 명령을 실행하여 설치됩니다. 
# yum install perf
호스트에서 perf kvm 을 사용하려면 게스트의 /proc/modules 및 /proc/kallsyms 파일에 액세스할 수 있어야 합니다. 절차 2.1. “게스트에서 호스트로 /proc 파일 복사” 를 참조하여 파일을 호스트로 전송하고 파일에서 보고서를 실행합니다.

절차 2.1. 게스트에서 호스트로 /proc 파일 복사

중요
필요한 파일(예: scp)을 직접 복사하는 경우 제로 길이의 파일만 복사합니다. 이 절차에서는 먼저 게스트의 파일을 임시 위치( cat 명령 포함)에 저장한 다음, perf kvm 에서 사용할 수 있도록 호스트에 복사하는 방법을 설명합니다.

  1. 게스트에 로그인하고 파일을 저장합니다.

    게스트에 로그인하고 /proc/ modules 및 /proc /kallsyms 를 임시 위치인 /tmp 에 저장합니다. 
    # cat /proc/modules > /tmp/modules
# cat /proc/kallsyms > /tmp/kallsyms

  2. 임시 파일을 호스트에 복사

    게스트에서 로그아웃한 후 다음 예제 scp 명령을 실행하여 저장된 파일을 호스트에 복사합니다. 호스트 이름과 TCP 포트가 다른 경우 교체해야합니다. 
    # scp root@GuestMachine:/tmp/kallsyms guest-kallsyms
# scp root@GuestMachine:/tmp/modules guest-modules
    이제 호스트의 게스트(guest-kallsyms 및 guest-modules)의 두 개의 파일이 있어 perf kvm 에서 사용할 수 있습니다.

  3. kvm을 사용하여 기록 및 보고 이벤트

    이전 단계에서 얻은 파일을 사용하여 게스트, 호스트 또는 둘 다에서 이벤트를 기록하고 보고할 수 있습니다.
    다음 예제 명령을 실행합니다. 
    # perf kvm --host --guest --guestkallsyms=guest-kallsyms \
--guestmodules=guest-modules record -a -o perf.data
    참고
    명령에 --host 및 --guest 를 모두 사용하면 출력이 perf.data.kvm 에 저장됩니다. --host 만 사용하면 파일 이름이 perf.data.host 이 됩니다. 마찬가지로 --guest 만 사용하면 파일 이름이 perf.data.guest 이 됩니다.
    Ctrl-C를 누르면 기록이 중지됩니다.

  4. 보고 이벤트

    다음 예제 명령은 기록 프로세스에서 얻은 파일을 사용하고 출력을 새 파일로 리디렉션하고 을 분석합니다. 
    perf kvm --host --guest --guestmodules=guest-modules report -i perf.data.kvm \
--force > analyze
    분석 파일의 내용을 보고 기록된 이벤트를 검사합니다. 
    # cat analyze


# Events: 7K cycles
#
# Overhead       Command  Shared Object      Symbol
# ........  ............  .................  .........................
#
    95.06%            vi  vi                 [.] 0x48287
     0.61%          init  [kernel.kallsyms]  [k] intel_idle
     0.36%            vi  libc-2.12.so       [.] _wordcopy_fwd_aligned
     0.32%            vi  libc-2.12.so       [.] __strlen_sse42
     0.14%       swapper  [kernel.kallsyms]  [k] intel_idle
     0.13%          init  [kernel.kallsyms]  [k] uhci_irq
     0.11%          perf  [kernel.kallsyms]  [k] generic_exec_single
     0.11%          init  [kernel.kallsyms]  [k] tg_shares_up
     0.10%      qemu-kvm  [kernel.kallsyms]  [k] tg_shares_up

[output truncated...]

2.2. 가상 성능 모니터링 장치(vPMU)

가상 성능 모니터링 장치(vPMU)는 게스트 가상 시스템의 작동 방식을 나타내는 통계를 표시합니다.
가상 성능 모니터링 장치를 통해 사용자는 게스트 가상 머신에서 가능한 성능 문제의 원인을 확인할 수 있습니다. vPMU는 Intel의 PMU(Performance Monitoring Unit)를 기반으로 하며 Intel 시스템에서만 사용할 수 있습니다.
이 기능은 Red Hat Enterprise Linux 6 또는 Red Hat Enterprise Linux 7을 실행하는 게스트 가상 머신에서만 지원되며 기본적으로 비활성화되어 있습니다.
시스템에서 vPMU가 지원되는지 확인하려면 다음을 실행하여 호스트 CPU의 arch_perfmon 플래그를 확인합니다. 
# cat /proc/cpuinfo|grep arch_perfmon
vPMU를 활성화하려면 게스트 XML에서 cpu mode 를 host-passthrough 로 지정합니다. 
# virsh dumpxml guest_name |grep "cpu mode"
<cpu mode='host-passthrough'>
vPMU가 활성화되면 게스트 가상 시스템에서 perf 명령을 실행하여 가상 시스템의 성능 통계를 표시합니다.

2.3. 가상 머신 관리자에서 성능 모니터링

가상 머신 모니터를 사용하여 시스템의 가상 머신에 대한 성능 정보를 볼 수 있습니다. Virtual Machine Manager에 표시되는 성능 정보를 구성할 수도 있습니다.

2.3.1. 가상 머신 관리자에서 성능 개요 보기

가상 머신 관리자를 사용하여 가상 머신에 대한 성능 개요를 보려면 다음을 수행합니다.
  1. Virtual Machine Manager 메인 창에서 보려는 가상 머신을 강조 표시합니다.

    그림 2.1. 표시할 가상 머신 선택

    표시할 가상 머신 선택
  2. 가상 머신 관리자 편집 메뉴에서 가상 머신 세부 정보를 선택합니다.
    가상 머신 세부 정보 창이 열리면 콘솔이 표시될 수 있습니다. 이러한 상황이 발생하면 보기를 클릭한 다음 세부 정보를 선택합니다. 기본적으로 개요 창이 먼저 열립니다.
  3. 왼쪽의 탐색 창에서 Performance 를 선택합니다.
    성능 보기에는 CPU 및 메모리 사용량, 디스크 및 디스크 및 네트워크 입력 및 출력을 포함하여 게스트 성능에 대한 요약이 표시됩니다.

    그림 2.2. 게스트 성능 세부 정보 표시

    게스트 성능 세부 정보 표시

2.3.2. 성능 모니터링

virt-manager 의 기본 설정 창을 사용하여 성능 모니터링 기본 설정을 수정할 수 있습니다.
성능 모니터링을 구성하려면 다음을 수행합니다.
  1. 편집 메뉴에서 환경 설정을 선택합니다.
    Preference 창이 나타납니다.
  2. 폴링 탭의 시간(초) 또는 통계 폴링 옵션을 지정합니다.

    그림 2.3. 성능 모니터링 구성

    성능 모니터링 구성

2.3.3. 게스트의 CPU 사용량 표시

시스템의 모든 게스트의 CPU 사용량을 보려면 다음을 수행합니다.
  1. 보기 메뉴에서 그래프 를 선택하고 Guest CPU Usage (게스트 CPU 사용량) 확인란을 선택합니다.
  2. 가상 머신 관리자는 시스템의 모든 가상 머신에 대한 CPU 사용량 그래프를 보여줍니다.

    그림 2.4. 게스트 CPU 사용량 그래프

    게스트 CPU 사용량 그래프

2.3.4. 호스트의 CPU 사용량 표시

시스템의 모든 호스트에 대한 CPU 사용량을 보려면 다음을 수행합니다.
  1. View (보기) 메뉴에서 Graph, Host CPU Usage (호스트 CPU 사용량) 확인란을 선택합니다.
  2. 가상 머신 관리자는 시스템의 호스트 CPU 사용량 그래프를 보여줍니다.

    그림 2.5. 호스트 CPU 사용량 그래프

    호스트 CPU 사용량 그래프

2.3.5. 디스크 I/O 표시

시스템의 모든 가상 머신의 디스크 I/O를 보려면 다음을 수행합니다.
  1. 디스크 I/O 통계 컬렉션이 활성화되어 있는지 확인합니다. 이렇게 하려면 편집 메뉴에서 환경 설정을 선택하고 폴링 탭을 클릭합니다.
  2. 디스크 I/O 확인란을 선택합니다.

    그림 2.6. 디스크 I/O 활성화

    디스크 I/O 활성화
  3. 디스크 I/O 디스플레이를 활성화하려면 View 메뉴에서 Graph, then Disk I/O 확인란을 선택합니다.
  4. 가상 머신 관리자는 시스템의 모든 가상 머신에 대한 디스크 I/O 그래프를 보여줍니다.

    그림 2.7. 디스크 I/O 표시

    디스크 I/O 표시

2.3.6. 네트워크 I/O 표시

시스템에 있는 모든 가상 머신의 네트워크 I/O를 보려면 다음을 수행합니다.
  1. 네트워크 I/O 통계 컬렉션이 활성화되어 있는지 확인합니다. 이렇게 하려면 편집 메뉴에서 환경 설정을 선택하고 폴링탭을 클릭합니다.
  2. Network I/O 확인란을 선택합니다.

    그림 2.8. 네트워크 I/O 활성화

    네트워크 I/O 활성화
  3. 네트워크 I/O 통계를 표시하려면 보기 메뉴에서 그래프, 네트워크 I/O 확인란을 선택합니다.
  4. 가상 머신 관리자는 시스템의 모든 가상 머신에 대한 네트워크 I/O 그래프를 보여줍니다.

    그림 2.9. 네트워크 I/O 표시

    네트워크 I/O 표시

2.3.7. 메모리 사용량 표시

시스템의 모든 가상 머신의 메모리 사용량을 보려면 다음을 수행합니다.
  1. 메모리 사용량 통계 컬렉션이 활성화되어 있는지 확인합니다. 이렇게 하려면 편집 메뉴에서 환경 설정을 선택하고 폴링탭을 클릭합니다.
  2. 메모리 통계 확인란을 선택합니다.

    그림 2.10. 메모리 사용량 활성화

    메모리 사용량 활성화
  3. 메모리 사용량을 표시하려면 View (보기) 메뉴에서 Graph, Memory Usage (메모리 사용량) 확인란을 선택합니다.
  4. 가상 머신 관리자는 시스템의 모든 가상 머신에 대해 사용 중인 메모리의 백분율(MB)을 나열합니다.

    그림 2.11. 메모리 사용량 표시

    메모리 사용량 표시

3장. virt-manager로 가상화 성능 최적화

이 장에서는 게스트 가상 머신 관리를 위한 데스크탑 툴인 virt-manager 에서 사용할 수 있는 성능 튜닝 옵션에 대해 설명합니다.

3.1. 운영 체제 세부 정보 및 장치

3.1.1. 게스트 가상 머신 세부 정보 지정

virt-manager 툴에서는 새 게스트 가상 머신에 대해 선택한 운영 체제 유형 및 버전에 따라 다른 프로필을 제공합니다. 게스트를 만들 때 가능한 한 많은 세부 정보를 제공해야 합니다. 이로 인해 특정 유형의 게스트에서 사용 가능한 기능을 활성화하여 성능을 향상시킬 수 있습니다.
virt-manager 툴의 다음 화면 캡처를 참조하십시오. 새 게스트 가상 머신을 생성할 때 항상 원하는 OS 유형 및 버전을 지정합니다.

그림 3.1. OS 유형 및 버전 제공

OS 유형 및 버전 제공

3.1.2. 사용되지 않는 장치 제거

사용되지 않거나 불필요한 장치를 제거하면 성능이 향상될 수 있습니다. 예를 들어 웹 서버로 하는 게스트는 오디오 기능 또는 연결된 타블릿이 필요하지 않습니다.
virt-manager 툴의 다음 화면 캡처를 참조하십시오. 제거 버튼을 클릭하여 불필요한 장치를 제거합니다.

그림 3.2. 사용되지 않는 장치 제거

사용되지 않는 장치 제거

3.2. CPU 성능 옵션

게스트 가상 머신에서 여러 CPU 관련 옵션을 사용할 수 있습니다. 올바르게 구성하면 이러한 옵션이 성능에 큰 영향을 미칠 수 있습니다. 다음 이미지는 게스트가 사용할 수 있는 CPU 옵션을 보여줍니다. 이 섹션의 나머지 부분에서는 이러한 옵션의 영향을 보여줍니다.

그림 3.3. CPU 성능 옵션

CPU 성능 옵션

3.2.1. 옵션: 사용 가능한 CPU

게스트에서 사용할 수 있는 가상 CPU(vCPU)의 양을 조정하려면 이 옵션을 사용합니다. 호스트에서 사용 가능한 이상으로 할당 가능한 경우 다음 이미지에 표시된 대로 경고가 표시됩니다.

그림 3.4. CPU 과다 할당

CPU 과다 할당
시스템의 모든 게스트의 vCPU 합계가 시스템의 호스트 CPU 수보다 클 때 CPU가 오버 커밋됩니다. 총 vCPU 수가 호스트 CPU 수보다 큰 경우 하나 이상의 게스트로 CPU를 과다 할당할 수 있습니다.
중요
메모리 과다 할당과 마찬가지로 CPU 과다 할당은 게스트 워크로드가 크거나 예측할 수 없는 경우와 같이 성능에 부정적인 영향을 미칠 수 있습니다. 오버 커밋에 대한 자세한 내용은 가상화 배포 및 관리 가이드 를 참조하십시오.

3.2.2. 옵션: CPU 구성

이 옵션을 사용하여 의도한 CPU 모델에 따라 CPU 구성 유형을 선택합니다. 호스트 CPU 구성 복사 확인란을 클릭하여 물리적 호스트의 CPU 모델 및 구성을 감지 및 적용하거나 목록을 확장하여 사용 가능한 옵션을 확인합니다. CPU 구성을 선택하면 사용 가능한 CPU 기능/구성이 표시되고 CPU 기능 목록에서 개별적으로 활성화/비활성화할 수 있습니다.

그림 3.5. CPU 구성 옵션

CPU 구성 옵션
참고
호스트 CPU 구성을 수동으로 구성하는 것이 좋습니다.
참고
또는 호스트 시스템에서 virsh capabilities 명령을 실행하여 CPU 유형 및 NUMA 기능을 포함하여 시스템의 가상화 기능을 확인합니다.

3.2.3. 옵션: CPU 토폴로지

게스트 가상 시스템의 가상 CPU에 특정 CPU 토폴로지(Sockets, Cores, Threads)를 적용하려면 이 옵션을 사용합니다.

그림 3.6. CPU 토폴로지 옵션

CPU 토폴로지 옵션
참고
사용자 환경은 다른 요구 사항을 지정할 수 있지만 원하는 개수의 소켓을 선택할 수는 있지만 단일 코어와 단일 스레드만 있으면 최상의 성능 결과를 얻을 수 있습니다.

3.3. 가상 디스크 성능 옵션

성능에 영향을 줄 수 있는 설치 중에 게스트 가상 머신에서 여러 가상 디스크 관련 옵션을 사용할 수 있습니다. 다음 이미지는 게스트가 사용할 수 있는 가상 디스크 옵션을 보여줍니다.
virt-manager 의 가상 디스크 섹션에서 캐시 모드, IO 모드 및 IO 튜닝을 선택할 수 있습니다. 다음 이미지에 표시된 대로 Performance 옵션 아래의 필드에서 다음 매개변수를 설정합니다.

그림 3.7. 가상 디스크 성능 옵션

가상 디스크 성능 옵션
중요
virt-manager 에서 가상 디스크 성능 옵션을 설정할 때 설정이 적용되려면 가상 머신을 재시작해야 합니다.
게스트 XML 구성에서 이러한 설정 및 편집 방법은 7.2절. “캐싱” 및 7.3절. “I/O 모드” 를 참조하십시오.

4장. tuned 및 tuned-adm

이 장에서는 가상화 환경에서 시스템 설정 튜닝을 위해 tuned 데몬을 사용하는 방법을 설명합니다.
tuned 는 CPU 집약적인 작업 요구 사항 또는 스토리지/네트워크 처리량 응답과 같은 특정 워크로드 특성에 맞게 Red Hat Enterprise Linux를 조정하는 튜닝 프로파일 제공 메커니즘입니다. 여러 특정 사용 사례에서 성능을 향상시키고 전력 소비를 줄이기 위해 사전 구성된 여러 튜닝 프로필을 제공합니다. 이러한 프로필을 편집하거나 새 프로필을 생성하여 사용자 환경에 맞는 성능 솔루션을 만듭니다.
tuned 의 일부로 제공되는 가상화 관련 프로필은 다음과 같습니다.
virtual-guest
throughput-performance 프로필에 따라 virtual-guest 는 가상 메모리의 스왑성도 줄입니다.
Red Hat Enterprise Linux 7 게스트 가상 머신을 생성할 때 virtual-guest 프로필이 자동으로 선택됩니다. 가상 머신에 권장되는 프로필입니다.
이 프로필은 Red Hat Enterprise Linux 6.3 이상에서 사용할 수 있지만 가상 머신을 설치할 때 수동으로 선택해야 합니다.
virtual-host
throughput-performance 프로필에 따라 virtual-host 를 사용하면 더 공격적으로 더티 페이지 쓰기가 가능합니다. 이 프로필은 KVM 및 RHV(Red Hat Virtualization) 호스트를 모두 포함하여 가상화 호스트에 권장되는 프로필입니다.
Red Hat Enterprise Linux 7 설치에 기본적으로 tuned 패키지가 설치되고 tuned 서비스가 활성화됩니다.
사용 가능한 모든 프로필을 나열하고 현재 활성 프로필을 확인하려면 다음을 실행합니다. 
# tuned-adm list
Available profiles:
- balanced
- desktop
- latency-performance
- network-latency
- network-throughput
- powersave
- sap
- throughput-performance
- virtual-guest
- virtual-host
Current active profile: throughput-performance
사용자 지정 tuned 프로필을 생성하여 튜닝 매개변수 세트를 캡슐화할 수도 있습니다. 사용자 지정 tuned 프로필 생성에 대한 지침은 tuned.conf 매뉴얼 페이지를 참조하십시오.
현재 활성화된 프로필만 표시하려면 다음을 실행합니다. 
tuned-adm active
사용 가능한 프로필 중 하나로 전환하려면 다음을 실행합니다. 
tuned-adm profile profile_name
예를 들어 virtual-host 프로필로 전환하려면 다음을 실행합니다. 
tuned-adm profile virtual-host
중요
Red Hat Enterprise Linux 7.1 이상에서 tuned 프로필을 설정한 후 재부팅 후 구성된 프로파일에 맞게 tuned 서비스를 활성화해야 합니다. 
# systemctl enable tuned
경우에 따라 수동으로 설정된 매개변수를 사용하도록 tuned 를 비활성화하는 것이 좋습니다. 현재 세션에 대한 모든 튜닝을 비활성화하려면 다음을 실행합니다. 
# tuned-adm off
tuned 를 영구적으로 비활성화하고 수행된 변경 사항을 모두 되돌리려면 다음을 실행합니다. 
# tuned-adm off; systemctl disable tuned
참고

5장. 네트워킹

이 장에서는 가상화 환경의 네트워크 최적화 주제를 다룹니다.

5.1. 네트워킹 튜닝 팁

  • 여러 네트워크를 사용하여 단일 네트워크에서 혼잡을 방지합니다. 예를 들어 관리, 백업 또는 실시간 마이그레이션을 위한 전용 네트워크가 있습니다.
  • Red Hat은 동일한 네트워크 세그먼트에서 여러 인터페이스를 사용하지 않는 것이 좋습니다. 그러나 피할 수 없는 경우 arp_filter 를 사용하여 호스트와 게스트 모두에서 발생할 수 있으며, ARP 요청에 응답하는 것이 바람직하지 않은 조건입니다. echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter 또는 / etc/sysctl.conf 를 편집하여 이 설정을 영구적으로 설정합니다.
참고
ARP Flux에 대한 자세한 내용은 를 참조하십시오. http://linux-ip.net/html/ether-arp.html#ether-arp-flux

5.2. virtio 및 vhost_net

다음 다이어그램은 Virtio 및 vhost_net 아키텍처에서 커널의 참여를 보여줍니다.

그림 5.1. virtio 및 vhost_net 아키텍처

virtio 및 vhost_net 아키텍처
vhost_net은 Virtio 드라이버의 일부를 사용자 공간에서 커널로 이동합니다. 이렇게 하면 복사 작업이 줄어들고 대기 시간 및 CPU 사용량이 줄어듭니다.

5.3. 장치 할당 및 SR-IOV

다음 다이어그램은 장치 할당 및 SR-IOV 아키텍처에서 커널의 참여를 보여줍니다.

그림 5.2. 장치 할당 및 SR-IOV

장치 할당 및 SR-IOV
장치 할당은 전체 장치를 게스트에 제공합니다. SR-IOV는 NIC와 시스템 보드를 포함하여 드라이버 및 하드웨어에서 지원이 필요하며 여러 가상 장치를 생성하여 다른 게스트로 전달할 수 있습니다. 게스트에 벤더별 드라이버가 필요하지만 SR-IOV는 네트워크 옵션 중 가장 짧은 대기 시간을 제공합니다.

5.4. Network Tuning Techniques

이 섹션에서는 가상화 환경에서 네트워크 성능을 조정하는 방법을 설명합니다.
중요
Red Hat Enterprise Linux 7 하이퍼바이저 및 가상 머신에서 지원되는 기능은 Red Hat Enterprise Linux 6.6 이상을 실행하는 가상 시스템에서도 지원됩니다.

5.4.1. Bridge Zero Copy Transmit

0개의 복사 전송 모드는 대규모 패킷 크기에서 유효합니다. 일반적으로 처리량에 영향을 주지 않고 게스트 네트워크와 외부 네트워크 간에 큰 패킷을 전송할 때 호스트 CPU 오버헤드를 최대 15 %까지 줄입니다.
게스트 간, 게스트 간 호스트 또는 소규모 패킷 워크로드의 성능에 영향을 미치지 않습니다.
브리지 제로 복사 전송은 Red Hat Enterprise Linux 7 가상 머신에서 완전히 지원되지만 기본적으로 비활성화되어 있습니다. 제로 복사 전송 모드를 활성화하려면 vhost_net 모듈의 experimental_zcopytx 커널 모듈 매개변수를 1로 설정합니다. 자세한 내용은 가상화 배포 및 관리 가이드 를 참조하십시오.
참고
추가 데이터 사본은 일반적으로 서비스 거부 및 정보 누출 공격에 대한 위협 완화 기술로 전송하는 동안 생성됩니다. 제로 복사 전송을 활성화하면 이 위협 완화 기술을 사용할 수 없습니다.
성능 회귀가 관찰되거나 호스트 CPU 사용률이 문제가 아닌 경우 experimental_zcopytx 을 0으로 설정하여 복사 전송 모드를 비활성화할 수 있습니다.

5.4.2. 멀티 큐 virtio-net

멀티 큐 virtio-net에서는 vCPU 수가 증가할 때 네트워크 성능을 스케일링하는 접근 방식을 제공하여 한 번에 둘 이상의 virtqueue 쌍을 통해 패킷을 전송할 수 있습니다.
오늘날의 고급 서버에는 더 많은 프로세서가 있으며 게스트는 다수의 vCPU를 사용하는 경우가 많습니다. 단일 큐 virtio-net에서는 vCPU 수가 증가함에 따라 네트워크 성능이 확장되지 않으므로 게스트의 프로토콜 스택 규모가 제한됩니다. virtio-net에는 TX 및 RX 대기열만 있으므로 게스트는 병렬로 패킷을 전송하거나 검색할 수 없습니다.
멀티 큐 지원에서는 병렬 패킷 처리를 허용하여 이러한 병목 현상을 제거합니다.
멀티 큐 virtio-net은 다음과 같은 경우 가장 큰 성능 이점을 제공합니다.
  • 트래픽 패킷은 상대적으로 큽니다.
  • 게스트는 게스트 간에 트래픽이 실행되고, 게스트를 외부 시스템으로 또는 게스트 간에 실행되는 동시에 여러 연결에서 활성화됩니다.
  • 대기열 수는 vCPU 수와 동일합니다. 이는 멀티 큐가 특정 vCPU에 특정 큐를 개인으로 만들기 위해 RX 인터럽트 선호도 및 TX 대기열 선택을 최적화하기 때문입니다.
참고
현재 멀티 큐 virtio-net 연결을 설정하면 나가는 트래픽 성능에 부정적인 영향을 미칠 수 있습니다. 특히 이는 TCP(Transmission Control Protocol) 스트림을 통해 1,500바이트 미만의 패킷을 보낼 때 발생할 수 있습니다. 자세한 내용은 Red Hat Knowledgebase를 참조하십시오.

5.4.2.1. 다중 대기열 virtio-net 구성

멀티 큐 virtio-net을 사용하려면 게스트 XML 구성에 다음을 추가하여 게스트의 지원을 활성화합니다(여기서 N 값은 1에서 256, 즉 커널이 멀티 큐 탭 장치에 대해 최대 256개의 큐를 지원하므로) 게스트 XML 구성에 다음을 추가합니다. 
<interface type='network'>
      <source network='default'/>
      <model type='virtio'/>
      <driver name='vhost' queues='N'/>
</interface>
게스트에서 N virtio-net 큐를 사용하여 가상 머신을 실행하는 경우 다음 명령을 사용하여 다중 대기열 지원을 활성화합니다( M 값은 1에서 N까지): 
# ethtool -L eth0 combined M

5.5. 네트워크 패킷 배치

긴 전송 경로가 있는 구성에서 패킷을 커널에 제출하기 전에 배치하는 경우 캐시 사용률이 향상될 수 있습니다.
배치할 수 있는 최대 패킷 수를 구성하려면 N 은 배치할 최대 패킷 수입니다. 
# ethtool -C $tap rx-frames N
type='bridge' 또는 type='network' 인터페이스에 대해 tun/tap rx 배치를 지원하려면 다음과 유사한 스니펫을 도메인 XML 파일에 추가합니다. 
...
<devices>
  <interface type='network'>
    <source network='default'/>
    <target dev='vnet0'/>
      <coalesce>
        <rx>
          <frames max='7'/>
        </rx>
      </coalesce>
  </interface>
</devices>

6장. I/O 스케줄링

입력/출력(I/O) 스케줄러를 사용하여 Red Hat Enterprise Linux 7이 가상화 게스트인 경우와 가상화 게스트 인 경우 디스크 성능을 향상시킬 수 있습니다. ???

6.1. 가상화 호스트로 Red Hat Enterprise Linux를 사용한 I/O 스케줄링

Red Hat Enterprise Linux 7을 가상화된 게스트의 호스트로 사용하는 경우 일반적으로 기본 데드라인 스케줄러가 이상적입니다. 이 스케줄러는 거의 모든 워크로드에서 제대로 작동합니다.
그러나 게스트 워크로드에서 I/O 처리량을 최대화하는 것이 게스트 워크로드에서 I/O 대기 시간을 최소화하는 것보다 더 중요한 경우 대신 cfq 스케줄러를 사용하는 것이 유용할 수 있습니다.

6.2. 가상화 게스트로 Red Hat Enterprise Linux를 사용한 I/O 스케줄링

Red Hat Enterprise Linux 게스트 가상 머신에서 게스트가 실행되는 하이퍼바이저에 관계없이 I/O 스케줄링을 사용할 수 있습니다. 다음은 고려해야 할 이점 및 문제 목록입니다.
  • Red Hat Enterprise Linux 게스트는 noop 스케줄러를 사용하여 많은 이점을 얻을 수 있습니다. 스케줄러는 I/O를 하이퍼바이저로 보내기 전에 게스트 운영 체제의 소규모 요청을 더 큰 요청으로 병합합니다. 이를 통해 하이퍼바이저는 I/O 요청을 보다 효율적으로 처리할 수 있으므로 게스트의 I/O 성능을 크게 향상시킬 수 있습니다.
  • 워크로드 I/O 및 스토리지 장치를 연결하는 방법에 따라 데드라인 과 같은 스케줄러는 noop 보다 더 유용할 수 있습니다. Red Hat은 어떤 스케줄러가 최상의 성능 영향을 미치는지 확인하기 위해 성능 테스트를 권장합니다.
  • iSCSI, SR-IOV 또는 물리적 장치 패스스루에서 액세스하는 스토리지를 사용하는 게스트는 noop 스케줄러를 사용해서는 안 됩니다. 이러한 방법에서는 호스트가 기본 물리적 장치에 I/O 요청을 최적화할 수 없습니다.
참고
가상화된 환경에서는 호스트 및 게스트 계층 모두에서 I/O를 예약하는 것이 유용할 수 있습니다. 여러 게스트가 호스트 운영 체제에서 관리하는 파일 시스템 또는 블록 장치에서 스토리지를 사용하는 경우 호스트는 모든 게스트의 요청을 인식하므로 보다 효율적으로 I/O를 예약할 수 있습니다. 또한 호스트는 스토리지의 물리적 레이아웃을 알고 있으며, 이는 게스트의 가상 스토리지에 선형적으로 매핑되지 않을 수 있습니다.
일반적으로 합성 벤치마크는 가상 환경에서 공유 리소스를 사용하는 시스템의 성능을 정확하게 비교하지 않으므로 모든 스케줄러 튜닝을 일반적인 운영 조건에서 테스트해야 합니다.

6.2.1. Red Hat Enterprise Linux 7용 I/O 스케줄러 구성

Red Hat Enterprise Linux 7 시스템에 사용되는 기본 스케줄러는 데드라인 입니다. 그러나 Red Hat Enterprise Linux 7 게스트 머신에서는 다음을 수행하여 스케줄러를 noop 로 변경하는 것이 유용할 수 있습니다.
  1. /etc/default/grub 파일에서 GRUB_CMDLINE_LINUX 줄의 lift =deadline 문자열을 lift =noop 로 변경합니다. 엘레베이터 = 문자열이 없는 경우 줄 끝에 lift =noop 를 추가합니다.
    다음은 성공적인 변경 후 /etc/default/grub 파일을 보여줍니다. 
    # cat /etc/default/grub
[...]
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=vg00/lvroot rhgb quiet elevator=noop"
[...]
  2. /boot/grub2/grub.cfg 파일을 다시 빌드합니다.
    • BIOS 기반 시스템에서 다음을 수행합니다. 
      # grub2-mkconfig -o /boot/grub2/grub.cfg
    • UEFI 기반 시스템에서 다음을 수행합니다. 
      # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

7장. 블록 I/O

이 장에서는 가상화 환경의 I/O 설정 최적화에 대해 설명합니다.

7.1. 블록 I/O 튜닝

virsh blkiotune 명령을 사용하면 관리자가 게스트 XML 구성의 <blkio> 요소에서 게스트 가상 머신의 블록 I/O 매개 변수를 수동으로 설정하거나 표시할 수 있습니다.
가상 머신의 현재 <blkio> 매개변수를 표시하려면 다음을 수행합니다. 
# virsh blkiotune virtual_machine
가상 머신의 <blkio> 매개변수를 설정하려면 virsh blkiotune 명령을 사용하고 환경에 따라 옵션 값을 바꿉니다. 

# virsh blkiotune virtual_machine [--weight number] [--device-weights string] [--config] [--live] [--current]
매개변수는 다음과 같습니다.
weight
I/O 가중치는 100~1000 범위입니다.
장치의 I/O 가중치를 늘리면 I/O 대역폭에 대한 우선 순위가 증가하므로 더 많은 호스트 리소스를 제공합니다. 마찬가지로 장치의 가중치를 줄이면 호스트 리소스를 덜 소비하게 됩니다.
device-weights
하나 이상의 장치/가중 쌍을/path/to/device,weight, /path/to/device,weight 의 형식으로 나열하는 단일 문자열입니다. 각 가중치는 100-1000 범위 내에 있거나 값 0을 사용하여 장치별 목록에서 해당 장치를 제거해야 합니다. 문자열에 나열된 장치만 수정됩니다. 다른 장치에 대한 기존 장치별 가중치는 변경되지 않은 상태로 유지됩니다.
config
다음 부팅 시 변경 사항을 적용하려면 --config 옵션을 추가합니다.
live
--live 옵션을 추가하여 실행 중인 가상 머신 에 변경 사항을 적용합니다.
참고
--live 옵션을 사용하려면 하이퍼바이저가 이 작업을 지원해야 합니다. 모든 하이퍼바이저가 최대 메모리 제한을 실시간으로 변경할 수 있는 것은 아닙니다.
current
--current 옵션을 추가하여 현재 가상 머신 에 변경 사항을 적용합니다.
예를 들어, 다음에서는 liftbrul VM의 /dev/sda 장치의 가중치를 500으로 변경합니다. 
# virsh blkiotune liftbrul --device-weights /dev/sda, 500
참고
virsh blkiotune 명령을 사용하는 방법에 대한 자세한 내용은 virsh help blkiotune 명령을 사용하십시오.

7.2. 캐싱

캐싱 옵션은 게스트 설치 중에 virt-manager 또는 게스트 XML 구성을 편집하여 기존 게스트 가상 머신에 구성할 수 있습니다.

표 7.1. 캐싱 옵션

캐싱 옵션설명
cache=none게스트의 I/O는 호스트에 캐시되지 않지만 쓰기 디스크 캐시에 보관될 수 있습니다. 대규모 I/O 요구 사항이 있는 게스트에 이 옵션을 사용합니다. 이 옵션은 일반적으로 최상의 선택이며 마이그레이션을 지원하는 유일한 옵션입니다.
cache=writethrough게스트의 I/O는 호스트에 캐시되지만 물리적 미디어를 통해 기록됩니다. 이 모드는 느리고 문제가 발생하기 쉽습니다. I/O 요구 사항이 낮은 수의 게스트에서 가장 적합합니다. 마이그레이션이 필요하지 않은 나중 쓰기 캐시(예: Red Hat Enterprise Linux 5.5 및 이전 버전)를 지원하지 않는 게스트를 위한 것이 좋습니다.
Cache=writeback게스트의 I/O가 호스트에 캐시됩니다.
cache=directsyncwritethrough 과 유사하지만 게스트의 I/O는 호스트 페이지 캐시를 무시합니다.
Cache=unsafe호스트는 모든 디스크 I/O를 캐시할 수 있으며 게스트의 동기화 요청은 무시됩니다.
Cache=default캐시 모드가 지정되지 않은 경우 시스템의 기본 설정이 선택됩니다.
virt-manager 에서 캐싱 모드는 가상 디스크 아래에 지정할 수 있습니다. virt-manager 를 사용하여 캐시 모드를 변경하는 방법에 대한 자세한 내용은 다음을 참조하십시오. 3.3절. “가상 디스크 성능 옵션”
게스트 XML에서 캐시 모드를 구성하려면 driver 태그 내부의 cache 설정을 편집하여 캐싱 옵션을 지정합니다. 예를 들어 캐시를 writeback 로 설정하려면 다음을 수행합니다. 
<disk type='file' device='disk'>
          <driver name='qemu' type='raw' cache='writeback'/>

7.3. I/O 모드

게스트 설치 중 또는 게스트 XML 구성을 편집하여 기존 게스트 가상 머신에서 I/O 모드 옵션을 virt-manager 로 구성할 수 있습니다.

표 7.2. IO 모드 옵션

IO 모드 옵션설명
IO=nativeRHV(Red Hat Virtualization) 환경의 기본값입니다. 이 모드는 직접 I/O 옵션을 사용하는 커널 비동기 I/O를 나타냅니다.
IO=threads기본값은 호스트 사용자 모드 기반 스레드입니다.
IO=defaultRed Hat Enterprise Linux 7의 기본값은 스레드 모드입니다.
virt-manager 에서 I/O 모드는 가상 디스크 아래에 지정할 수 있습니다. virt-manager 를 사용하여 I/O 모드를 변경하는 방법에 대한 자세한 내용은 다음을 참조하십시오. 3.3절. “가상 디스크 성능 옵션”
게스트 XML에서 I/O 모드를 구성하려면 io 태그 내의 driver 설정을 편집하여 native, threads 또는 default 를 지정합니다. 예를 들어 I/O 모드를 threads 로 설정하려면 다음을 수행합니다. 
<disk type='file' device='disk'>
          <driver name='qemu' type='raw' io='threads'/>

7.4. 블록 I/O 튜닝 기술

이 섹션에서는 가상화 환경에서 블록 I/O 성능을 조정하는 더 많은 기술을 설명합니다.

7.4.1. 디스크 I/O Throttling

여러 가상 머신이 동시에 실행되는 경우 과도한 디스크 I/O를 사용하여 시스템 성능을 방해할 수 있습니다. KVM의 디스크 I/O 제한은 가상 머신에서 호스트 시스템으로 전송된 디스크 I/O 요청에 대한 제한을 설정하는 기능을 제공합니다. 이렇게 하면 가상 머신이 공유 리소스를 과도하게 활용하고 다른 가상 시스템의 성능에 영향을 줄 수 있습니다.
디스크 I/O 제한은 다양한 상황에서 유용할 수 있습니다(예: 다른 고객에 속하는 게스트 가상 머신이 동일한 호스트에서 실행 중이거나 다른 게스트에 대해 서비스 품질 보장이 제공되는 경우). 디스크 I/O 제한은 느린 디스크를 시뮬레이션하는 데 사용할 수도 있습니다.
I/O 제한은 게스트에 연결된 각 블록 장치에 독립적으로 적용할 수 있으며 처리량 및 I/O 작업에 대한 제한을 지원합니다. virsh blkdeviotune 명령을 사용하여 가상 머신에 대한 I/O 제한을 설정합니다. 
# virsh blkdeviotune virtual_machine device --parameter limit
device는 가상 머신에 연결된 디스크 장치 중 하나에 대한 고유한 대상 이름(<target dev='name'/>) 또는 소스 파일(<source file='name'/>)을 지정합니다. 디스크 장치 이름 목록에 virsh domblk list 명령을 사용합니다.
선택적 매개변수는 다음과 같습니다.
total-bytes-sec
초당 총 처리량 제한(바이트)입니다.
read-bytes-sec
읽기 처리량 제한(초당 바이트).
write-bytes-sec
쓰기 처리량 제한(초당 바이트).
total-iops-sec
초당 총 I/O 작업 제한입니다.
read-iops-sec
읽기 I/O 작업 제한 초당 제한입니다.
write-iops-sec
초당 쓰기 I/O 작업 제한입니다.
예를 들어 virtual_machine 의 vda 를 초당 1000개의 I/O 작업으로 제한하고 초당 50MB의 I/O 작업을 실행하려면 다음 명령을 실행합니다. 
# virsh blkdeviotune virtual_machine vda --total-iops-sec 1000 --total-bytes-sec 52428800

7.4.2. 다중 대기열 virtio-scsi

multi-queue virtio-scsi는 virtio-scsi 드라이버에서 향상된 스토리지 성능 및 확장성을 제공합니다. 이를 통해 각 가상 CPU는 다른 vCPU에 영향을 주지 않고 별도의 대기열과 인터럽트를 수행할 수 있습니다.

7.4.2.1. 다중 대기열 virtio-scsi 구성

Red Hat Enterprise Linux 7에서 멀티 큐 virtio-scsi는 기본적으로 비활성화되어 있습니다.
게스트에서 다중 대기열 virtio-scsi 지원을 활성화하려면 게스트 XML 구성에 다음을 추가합니다. 여기서 N 은 vCPU 대기열의 총 수 입니다. 
   <controller type='scsi' index='0' model='virtio-scsi'>
   <driver queues='N' />
    </controller>

8장. 메모리

이 장에서는 가상화 환경의 메모리 최적화 옵션에 대해 설명합니다.

8.1. 메모리 튜닝 팁

가상화 환경의 메모리 성능을 최적화하려면 다음을 고려하십시오.
  • 사용할 것보다 더 많은 리소스를 게스트에 할당하지 마십시오.
  • 가능한 경우 단일 NUMA 노드에 게스트를 할당하여 해당 NUMA 노드에 해당 리소스를 충분히 제공합니다. NUMA 사용에 대한 자세한 내용은 9장. NUMA 을 참조하십시오.

8.2. 가상 머신의 메모리 튜닝

8.2.1. 메모리 모니터링 툴

베어 메탈 환경에서 사용되는 툴을 사용하여 가상 머신에서 메모리 사용량을 모니터링할 수 있습니다. 메모리 사용량을 모니터링하고 메모리 관련 문제를 진단하는 데 유용한 툴은 다음과 같습니다.
  • top
  • vmstat
  • numastat
  • /proc/
참고
이러한 성능 툴 사용에 대한 자세한 내용은 Red Hat Enterprise Linux 7 Performance Tuning Guide 및 해당 명령의 man 페이지를 참조하십시오.

8.2.2. virsh를 사용한 메모리 튜닝

게스트 XML 구성의 선택적 <memtune> 요소를 사용하면 관리자가 게스트 가상 머신 메모리 설정을 수동으로 구성할 수 있습니다. <memtune> 를 생략하면 VM은 VM 생성 중에 할당 및 할당된 방식에 따라 메모리를 사용합니다.
가상 머신의 <memtune> 요소에서 virsh memtune 명령을 사용하여 메모리 매개변수를 표시하거나 설정하고 환경에 따라 값을 교체합니다. 
# virsh memtune virtual_machine --parameter size
선택적 매개변수 는 다음과 같습니다.
hard_limit
가상 시스템에서 사용할 수 있는 최대 메모리(KB 1024바이트)입니다.
주의
이 제한을 너무 낮게 설정하면 커널에서 가상 시스템이 종료될 수 있습니다.
soft_limit
메모리 경합 중에 kibibytes로 강제 실행하기 위한 메모리 제한(24바이트 블록).
swap_hard_limit
가상 시스템이 사용할 수 있는 최대 메모리 및 스왑을 kibibytes(24바이트 블록)로 사용할 수 있습니다. swap_hard_limit 값은 hard_limit 값보다 커야 합니다.
min_guarantee
가상 시스템에 대해 보장된 최소 메모리 할당( kibibytes)입니다(24바이트의 블록).
참고
virsh memtune 명령을 사용하는 방법에 대한 자세한 내용은 # virsh help memtune 을 참조하십시오.
선택적 <memoryBacking> 요소는 호스트 페이지에서 가상 메모리 페이지를 지원하는 방법에 영향을 미치는 여러 요소를 포함할 수 있습니다.
locked 를 설정하면 호스트가 게스트에 속하는 메모리 페이지를 스왑 아웃하지 않습니다. 게스트 XML에 다음을 추가하여 호스트 메모리의 가상 메모리 페이지를 잠급니다. 
<memoryBacking>
        <locked/>
</memoryBacking>
중요
locked 를 설정하면 hard_limit 요소에서 게스트에 구성된 최대 메모리와 <memtune> 프로세스 자체에서 사용하는 메모리를 설정해야 합니다.
nosharepages 를 설정하면 호스트가 게스트 간에 사용된 동일한 메모리를 병합하지 않습니다. 하이퍼바이저가 게스트의 공유 페이지를 비활성화하도록 지시하려면 게스트의 XML에 다음을 추가합니다. 
<memoryBacking>
         <nosharepages/>
</memoryBacking>

8.2.3. 대규모 페이지 및 투명한 대규모 페이지

AMD64 및 Intel 64 CPU는 일반적으로 4kB 페이지의 메모리를 처리하지만 대규모 페이지라는 더 큰 2MB 또는 1GB 페이지를 사용할 수 있습니다. TLB( Transaction Lookaside Buffer )에 대해 CPU 캐시 적중을 늘려 성능을 개선하기 위해 KVM 게스트를 대규모 페이지 메모리 지원과 함께 배포할 수 있습니다.
Red Hat Enterprise Linux 7에서 기본적으로 활성화된 커널 기능은 대규모 페이지가 특히 대규모 메모리 및 메모리 집약적인 워크로드의 경우 성능을 크게 향상시킬 수 있습니다. Red Hat Enterprise Linux 7은 대규모 페이지 사용을 통해 페이지 크기를 늘려 많은 양의 메모리를 보다 효과적으로 관리할 수 있습니다. 대규모 페이지 관리의 효과와 편의성을 높이기 위해 Red Hat Enterprise Linux 7은 기본적으로 THP( Transparent Huge Page)를 사용합니다. 대규모 페이지 및 THP에 대한 자세한 내용은 성능 튜닝 가이드 를 참조하십시오.
Red Hat Enterprise Linux 7 시스템은 부팅시 또는 런타임 시 할당할 수 있는 2MB 및 1GB 대규모 페이지를 지원합니다. 여러 대규모 페이지 크기 활성화에 대한 지침은 8.2.3.3절. “부팅 또는 런타임 시 게스트용 1GB 대규모 페이지 활성화” 를 참조하십시오.

8.2.3.1. Transparent Huge Pages 설정

THP(Transparent Huge Page)는 대규모 페이지를 생성, 관리 및 사용하는 대부분의 측면을 자동화하는 추상화 계층입니다. 기본적으로 성능을 위해 시스템 설정을 자동으로 최적화합니다.
참고
KSM을 사용하면 투명한 대규모 페이지의 발생을 줄일 수 있으므로 THP를 활성화하기 전에 KSM을 비활성화하는 것이 좋습니다. 자세한 내용은 8.3.4절. “KSM 비활성화” 에서 참조하십시오.
투명한 대규모 페이지는 기본적으로 활성화되어 있습니다. 현재 상태를 확인하려면 다음을 실행합니다. 
# cat /sys/kernel/mm/transparent_hugepage/enabled
기본적으로 투명한 대규모 페이지를 사용하려면 다음을 실행합니다. 
# echo always > /sys/kernel/mm/transparent_hugepage/enabled
이렇게 하면 /sys/kernel/mm/transparent_hugepage/enabled 가 always 로 설정됩니다.
투명한 대규모 페이지를 비활성화하려면 다음을 수행합니다. 
# echo never > /sys/kernel/mm/transparent_hugepage/enabled
투명한 Huge Page 지원에서는 정적 대규모 페이지를 사용하지 않습니다. 그러나 정적 대규모 페이지를 사용하지 않는 경우 KVM은 일반 4kB 페이지 크기 대신 투명한 대규모 페이지를 사용합니다.

8.2.3.2. 정적 대규모 페이지 구성

경우에 따라 대규모 페이지를 더 많이 제어하는 것이 좋습니다. 게스트의 정적 대규모 페이지를 사용하려면 virsh edit 를 사용하여 게스트 XML 구성에 다음을 추가합니다. 
<memoryBacking>
        <hugepages/>
</memoryBacking>
이는 기본 페이지 크기를 사용하는 대신 대규모 페이지를 사용하여 게스트에 메모리를 할당하도록 호스트에 지시합니다.
다음 명령을 실행하여 현재 대규모 페이지 값을 확인합니다. 
cat /proc/sys/vm/nr_hugepages

절차 8.1. 대규모 페이지 설정

다음 예제 절차에서는 대규모 페이지를 설정하는 명령을 보여줍니다.
  1. 현재 대규모 페이지 값을 확인합니다. 
    # cat /proc/meminfo | grep Huge
AnonHugePages:      2048 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
  2. 대규모 페이지는 2MB 단위로 설정됩니다. 대규모 페이지 수를 25000으로 설정하려면 다음 명령을 사용합니다. 
    echo 25000 > /proc/sys/vm/nr_hugepages
    참고
    설정을 영구적으로 설정하려면 게스트 시스템의 /etc/sysctl.conf 파일에 다음 행을 추가합니다. X는 의도한 대규모 페이지 수입니다. 
    # echo 'vm.nr_hugepages = X' >> /etc/sysctl.conf
# sysctl -p
    그런 다음 게스트의 /etc/grub2.cfg 파일의 /kernel 행 끝에 추가하여 transparent_hugepage=never 를 커널 부팅 매개변수에 추가합니다.
  3. 대규모 페이지를 마운트합니다. 
    # mount -t hugetlbfs hugetlbfs /dev/hugepages
  4. 가상 머신의 XML 구성의 memoryBacking 섹션에 다음 행을 추가합니다. 
    <hugepages>
  <page size='1' unit='GiB'/>
</hugepages>
  5. libvirtd 를 다시 시작합니다. 
    # systemctl restart libvirtd
    • VM을 시작합니다. 
      # virsh start virtual_machine
    • VM이 이미 실행 중인 경우 다시 시작합니다. 
      # virsh reset virtual_machine
  7. /proc/meminfo 의 변경 사항을 확인합니다. 
    # cat /proc/meminfo | grep Huge
AnonHugePages:         0 kB
HugePages_Total:   25000
HugePages_Free:    23425
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
대규모 페이지는 호스트뿐만 아니라 게스트도 활용할 수 있지만 총 대규모 페이지 값은 호스트에서 사용 가능한 것보다 작아야 합니다.

8.2.3.3. 부팅 또는 런타임 시 게스트용 1GB 대규모 페이지 활성화

Red Hat Enterprise Linux 7 시스템은 부팅시 또는 런타임 시 할당할 수 있는 2MB 및 1GB 대규모 페이지를 지원합니다.

절차 8.2. 부팅 시 1GB 대규모 페이지 할당

  1. 부팅 시 다양한 대규모 페이지를 할당하려면 다음 명령을 사용하여 대규모 페이지 수를 지정합니다. 이 예에서는 4개의 1GB 대규모 페이지와 10242MB 대규모 페이지를 할당합니다. 
    'default_hugepagesz=1G hugepagesz=1G hugepages=4 hugepagesz=2M hugepages=1024'
    부팅 시 할당할 다른 수의 대규모 페이지를 지정하려면 이 명령줄을 변경합니다.
    참고
    부팅 시 1GB 대규모 페이지를 처음 할당할 때 다음 두 단계를 완료해야 합니다.
  2. 호스트에 2MB 및 1GB 대규모 페이지를 마운트합니다. 
    # mkdir /dev/hugepages1G
# mount -t hugetlbfs -o pagesize=1G none /dev/hugepages1G
# mkdir /dev/hugepages2M
# mount -t hugetlbfs -o pagesize=2M none /dev/hugepages2M
  3. 가상 머신의 XML 구성의 memoryBacking 섹션에 다음 행을 추가합니다. 
    <hugepages>
  <page size='1' unit='GiB'/>
</hugepages>
  4. libvirtd를 다시 시작하여 게스트에서 1GB 대규모 페이지를 사용할 수 있도록 합니다. 
    # systemctl restart libvirtd

절차 8.3. 런타임 시 1GB 대규모 페이지 할당

1GB 대규모 페이지도 런타임 시 할당할 수 있습니다. 시스템 관리자는 런타임 할당을 통해 해당 페이지를 할당할 NUMA 노드를 선택할 수 있습니다. 그러나 런타임 페이지 할당은 메모리 조각화로 인해 부팅 시간 할당보다 할당 실패가 더 어려울 수 있습니다.
  1. 런타임 시 다양한 대규모 페이지를 할당하려면 다음 명령을 사용하여 대규모 페이지 수에 대한 값을 교체하고, NUMA 노드는 해당 페이지를 할당하지 않고 대규모 페이지 크기를 지정합니다. 
    # echo 4 > /sys/devices/system/node/node1/hugepages/hugepages-1048576kB/nr_hugepages
# echo 1024 > /sys/devices/system/node/node3/hugepages/hugepages-2048kB/nr_hugepages
    이 예제 명령은 node1 에서 4개의 1GB 대규모 페이지와 node3 에서 10242MB 대규모 페이지를 할당합니다.
    이러한 대규모 페이지 설정은 호스트 시스템의 사용 가능한 메모리 크기에 따라 위 명령을 사용하여 언제든지 변경할 수 있습니다.
    참고
    다음 두 단계는 런타임에 1GB 대규모 페이지를 처음 할당할 때 완료해야 합니다.
  2. 호스트에 2MB 및 1GB 대규모 페이지를 마운트합니다. 
    # mkdir /dev/hugepages1G
# mount -t hugetlbfs -o pagesize=1G none /dev/hugepages1G
# mkdir /dev/hugepages2M
# mount -t hugetlbfs -o pagesize=2M none /dev/hugepages2M
  3. 가상 머신의 XML 구성의 memoryBacking 섹션에 다음 행을 추가합니다. 
    <hugepages>
  <page size='1' unit='GiB'/>
</hugepages>
  4. libvirtd를 다시 시작하여 게스트에서 1GB 대규모 페이지를 사용할 수 있도록 합니다. 
    # systemctl restart libvirtd

8.3. 커널 동일 페이지 병합(KSM)

KVM 하이퍼바이저에서 사용하는 KSM(커널 동일 페이지 병합)을 통해 KVM 게스트가 동일한 메모리 페이지를 공유할 수 있습니다. 이러한 공유 페이지는 일반적으로 공통 라이브러리 또는 기타 동일한 고가용성 데이터입니다. KSM은 메모리 복제를 방지하여 동일하거나 유사한 게스트 운영 체제의 게스트 밀도를 높일 수 있습니다.
공유 메모리의 개념은 최신 운영 체제에서 일반적입니다. 예를 들어 프로그램이 처음 시작되면 모든 메모리를 부모 프로그램과 공유합니다. 자식 또는 부모 프로그램이 이 메모리를 수정하려고 하면 커널은 새 메모리 영역을 할당하고, 원래 내용을 복사하고 프로그램이 이 새 영역을 수정할 수 있도록 합니다. 이 작업을 쓰기 시 복사라고 합니다.
KSM은 이 개념을 역순으로 사용하는 Linux 기능입니다. KSM을 사용하면 커널이 두 개 이상의 이미 실행 중인 프로그램을 검사하고 메모리를 비교할 수 있습니다. 메모리 영역 또는 페이지가 동일한 경우 KSM은 여러 동일한 메모리 페이지를 단일 페이지로 줄입니다. 그런 다음 이 페이지는 쓰기 시 복사로 표시됩니다. 페이지 콘텐츠를 게스트 가상 시스템에서 수정하면 해당 게스트에 대해 새 페이지가 생성됩니다.
이는 KVM을 사용한 가상화에 유용합니다. 게스트 가상 머신이 시작되면 호스트 qemu-kvm 프로세스의 메모리만 상속합니다. 게스트가 실행 중이면 게스트 운영 체제 이미지의 콘텐츠를 게스트가 동일한 운영 체제 또는 애플리케이션을 실행할 때 공유할 수 있습니다. KSM을 사용하면 KVM에서 동일한 게스트 메모리 영역을 공유할 것을 요청할 수 있습니다.
KSM은 향상된 메모리 속도 및 사용률을 제공합니다. KSM을 사용하면 일반적인 프로세스 데이터가 캐시 또는 주 메모리에 저장됩니다. 이를 통해 일부 애플리케이션 및 운영 체제의 성능을 향상시킬 수 있는 KVM 게스트의 캐시 누락이 줄어듭니다. 둘째, 메모리를 공유하면 게스트의 전체 메모리 사용량이 줄어들어 더 높은 밀도와 리소스 사용률을 높일 수 있습니다.
참고
Red Hat Enterprise Linux 7에서 KSM은 NUMA 인식. 이를 통해 페이지를 병합하는 동안 NUMA 현지성을 고려할 수 있으므로 페이지와 관련된 성능 저하가 원격 노드로 이동되지 않습니다. KSM을 사용하는 경우 노드 간 메모리 병합을 방지하는 것이 좋습니다. KSM이 사용 중인 경우 NUMA 노드 간에 페이지를 병합하지 않도록 /sys/kernel/mm/ksm/merge_across_nodes 튜닝 가능 항목을 0 로 변경합니다. 이 작업은 virsh node-memory-tune --shm-merge-across-nodes 0 명령을 사용하여 수행할 수 있습니다. 커널 메모리 회계 통계는 대량의 교차 노드 병합 후 결국 서로 모순될 수 있습니다. 따라서 KSM 데몬에서 대량의 메모리를 병합한 후 numad가 혼동될 수 있습니다. 시스템에 사용 가능한 메모리가 많은 경우 KSM 데몬을 끄고 비활성화하여 더 높은 성능을 얻을 수 있습니다. NUMA에 대한 자세한 내용은 9장. NUMA"를 참조하십시오.
중요
KSM을 사용하지 않고도 커밋된 RAM에 스왑 크기가 충분한지 확인합니다. KSM은 동일하거나 유사한 게스트의 RAM 사용량을 줄입니다. 충분한 스왑 공간없이 게스트를 오버 커밋할 수 있지만 게스트 가상 머신 메모리 사용을 사용하면 페이지가 공유되지 않을 수 있기 때문에 권장되지 않습니다.
Red Hat Enterprise Linux는 KSM을 제어하기 위한 두 가지 다른 방법을 사용합니다.
  • ksm 서비스는 KSM 커널 스레드를 시작하고 중지합니다.
  • ksmtuned 서비스는 동일한 페이지 병합을 동적으로 관리하면서 ksm 서비스를 제어하고 조정합니다. ksmtuned 는 ksm 서비스를 시작하고 메모리 공유가 필요하지 않은 경우 ksm 서비스를 중지합니다. 새 게스트가 생성 또는 삭제되면 실행할 retune 매개 변수를 사용하여 ksmtuned 에 지시합니다.
이러한 두 서비스는 모두 표준 서비스 관리 툴로 제어됩니다.
참고
KSM은 Red Hat Enterprise Linux 6.7에서 기본적으로 꺼져 있습니다.

8.3.1. KSM 서비스

  • ksm 서비스는 qemu-kvm 패키지에 포함되어 있습니다.
  • ksm 서비스가 시작되지 않으면 KSM(커널 동일한 페이지 병합)은 2000 페이지만 공유합니다. 이 기본값은 제한된 메모리 절감 이점을 제공합니다.
  • ksm 서비스가 시작되면 KSM은 호스트 시스템의 기본 메모리의 절반까지 공유합니다. KSM이 더 많은 메모리를 공유할 수 있도록 ksm 서비스를 시작합니다. 
# systemctl start ksm
Starting ksm:                                              [  OK  ]
ksm 서비스는 기본 시작 시퀀스에 추가할 수 있습니다. systemctl 명령을 사용하여 ksm 서비스를 영구적으로 만듭니다. 
# systemctl enable ksm

8.3.2. KSM Tuning Service

ksmtuned 서비스는 ksm 을 반복하고 조정하여 커널 KSM(동적 페이지 병합) 구성을 미세 조정합니다. 또한 게스트 가상 머신이 생성 또는 삭제될 때 libvirt에서 ksmtuned 서비스에 의해 알림을 받습니다. ksmtuned 서비스에는 옵션이 없습니다. 
# systemctl start ksmtuned
Starting ksmtuned:                                         [  OK  ]
ksmtuned 서비스는 조정 기능을 수동으로 실행하도록 ksmtuned 에 지시하는 retune 매개 변수를 사용하여 조정할 수 있습니다.
/etc/ksmtuned.conf 파일은 ksmtuned 서비스의 구성 파일입니다. 아래의 파일 출력은 기본 ksmtuned.conf 파일입니다. 
# Configuration file for ksmtuned.
# How long ksmtuned should sleep between tuning adjustments
# KSM_MONITOR_INTERVAL=60

# Millisecond sleep between ksm scans for 16Gb server.
# Smaller servers sleep more, bigger sleep less.
# KSM_SLEEP_MSEC=10

# KSM_NPAGES_BOOST - is added to the `npages` value, when `free memory` is less than `thres`.
# KSM_NPAGES_BOOST=300

# KSM_NPAGES_DECAY - is the value given is subtracted to the `npages` value, when `free memory` is greater than `thres`.
# KSM_NPAGES_DECAY=-50

# KSM_NPAGES_MIN - is the lower limit for the `npages` value.
# KSM_NPAGES_MIN=64

# KSM_NPAGES_MAX - is the upper limit for the `npages` value.
# KSM_NPAGES_MAX=1250

# KSM_THRES_COEF - is the RAM percentage to be calculated in parameter `thres`.
# KSM_THRES_COEF=20

# KSM_THRES_CONST - If this is a low memory system, and the `thres` value is less than `KSM_THRES_CONST`, then reset `thres` value to `KSM_THRES_CONST` value.
# KSM_THRES_CONST=2048

# uncomment the following to enable ksmtuned debug information
# LOGFILE=/var/log/ksmtuned
# DEBUG=1
/etc/ksmtuned.conf 파일 내에서 npages 는 ksm d 데몬이 비활성 상태가 되기 전에 ksm이 검사할 페이지 수를 설정합니다. 이 값은 /sys/kernel/mm/ksm/pages_to_scan 파일에도 설정됩니다.
KSM_THRES_CONST 값은 ksm 을 활성화하는 임계값으로 사용되는 사용 가능한 메모리의 양을 나타냅니다. ksmd 는 다음 중 하나가 발생하면 활성화됩니다.
  • 사용 가능한 메모리의 양은 KSM_THRES_CONST 에 설정된 임계값 미만으로 감소합니다.
  • 커밋된 메모리 및 임계값 KSM_THRES_CONST 의 양은 총 메모리 양을 초과합니다.

8.3.3. KSM 변수 및 모니터링

커널 동일 페이지 병합(KSM)은 모니터링 데이터를 /sys/kernel/mm/ksm/ 디렉토리에 저장합니다. 이 디렉터리의 파일은 커널에 의해 업데이트되며 KSM 사용량 및 통계에 대한 정확한 기록입니다.
아래 목록의 변수는 위에 명시된 대로 /etc/ksmtuned.conf 파일의 구성 가능한 변수이기도 합니다.

/sys/kernel/mm/ksm/ 에 있는 파일:

full_scans
전체 검사 실행.
merge_across_nodes
여러 NUMA 노드의 페이지를 병합할 수 있는지 여부입니다.
pages_shared
총 페이지 공유.
pages_sharing
현재 공유된 페이지입니다.
pages_to_scan
페이지를 스캔하지 않습니다.
pages_unshared
페이지가 더 이상 공유되지 않습니다.
pages_volatile
휘발성 페이지 수입니다.
run
KSM 프로세스가 실행 중인지 여부
sleep_millisecs
수면 밀리초입니다.
이러한 변수는 virsh node-memory-tune 명령을 사용하여 수동으로 튜닝할 수 있습니다. 예를 들어 다음은 공유 메모리 서비스가 절전 상태로 전환되기 전에 검사할 페이지 수를 지정합니다. 
# virsh node-memory-tune --shm-pages-to-scan number
DEBUG=1 행이 /etc/ksmtuned.conf 파일에 추가되는 경우 KSM 튜닝 활동이 /var/log/ksmtuned 로그 파일에 저장됩니다. 로그 파일 위치는 LOGFILE 매개변수를 사용하여 변경할 수 있습니다. 로그 파일 위치 변경은 권장되지 않으며 SELinux 설정을 특별한 설정이 필요할 수 있습니다.

8.3.4. KSM 비활성화

커널 동일 페이지 병합(KSM)에는 특정 환경 또는 호스트 시스템에 비해 너무 클 수 있는 성능 오버헤드가 있습니다. KSM은 게스트 간에 정보를 유출하는데 잠재적으로 사용될 수 있는 측면 채널을 도입할 수도 있습니다. 우려되는 경우 게스트별로 KSM을 비활성화할 수 있습니다.
KSM은 ksmtuned 및 ksm 서비스를 중지하여 비활성화할 수 있습니다. 그러나 이 작업은 재시작 후 유지되지 않습니다. KSM을 비활성화하려면 터미널에서 root로 다음을 실행합니다. 
# systemctl stop ksmtuned
Stopping ksmtuned:                                         [  OK  ]
# systemctl stop ksm
Stopping ksm:                                              [  OK  ]
ksmtuned 를 중지하고 ksm 은 KSM이 비활성화되지만, 다시 시작한 후에는 이 작업이 유지되지 않습니다. systemctl 명령을 사용하여 KSM을 영구적으로 비활성화합니다. 
# systemctl disable ksm
# systemctl disable ksmtuned
KSM이 비활성화되면 KSM을 비활성화하기 전에 공유한 모든 메모리 페이지가 계속 공유됩니다. 시스템의 모든 PageKSM을 삭제하려면 다음 명령을 사용하십시오. 
# echo 2 >/sys/kernel/mm/ksm/run
이 작업이 수행되면 khugepaged 데몬은 KVM 게스트 물리적 메모리에 투명한 hugepages를 다시 빌드할 수 있습니다. # echo 0 >/sys/kernel/mm/ksm/run 을 사용하면 KSM이 중지되지만 이전에 생성된 모든 KSM 페이지를 공유 해제하지는 않습니다 (이는 # systemctl stop ksmtuned 명령과 동일).

9장. NUMA

이전에는 AMD64 및 Intel 64 시스템의 모든 메모리에 동일하게 모든 CPU에 액세스할 수 있습니다. UMA(Uniform Memory Access)라고 하는 액세스 시간은 작업을 수행하는 CPU와 관계없이 동일합니다.
이 동작은 더 이상 최근 AMD64 및 Intel 64 프로세서의 경우에는 해당되지 않습니다. NUMA(Non-Uniform Memory Access)에서 시스템 메모리는 소켓에 해당하거나 시스템 메모리의 로컬 하위 집합에 대해 동일한 액세스 대기 시간이 있는 특정 CPU 집합에 해당하는 NUMA 노드로 나뉩니다.
이 장에서는 가상화 환경의 메모리 할당 및 NUMA 튜닝 구성에 대해 설명합니다.

9.1. NUMA 메모리 할당 정책

다음 정책은 시스템의 노드에서 메모리 할당 방법을 정의합니다.
Strict
엄격한 정책이란 대상 노드에 메모리를 할당할 수 없는 경우 할당이 실패했음을 의미합니다.
메모리 모드 속성을 정의하지 않고 NUMA 노드 세트 목록을 지정하는 기본값은 strict 모드입니다.
Interleave
메모리 페이지는 노드 세트에서 지정한 노드 간에 할당되지만 라운드 로빈 방식으로 할당됩니다.
Preferred
메모리는 하나의 기본 메모리 노드에서 할당됩니다. 충분한 메모리를 사용할 수 없는 경우 다른 노드에서 메모리를 할당할 수 있습니다.
의도한 정책을 활성화하려면 도메인 XML 파일의 < memory mode&gt; 요소의 값으로 설정합니다. 
<numatune>
        <memory mode='preferred' nodeset='0'>
</numatune>
중요
strict 모드에서 메모리를 과다 할당하고 게스트에 충분한 스왑 공간이 없는 경우 커널은 일부 게스트 프로세스를 종료하여 추가 메모리를 검색합니다. 이 상황을 방지하기 위해 preferred 할당 사용 및 단일 노드 세트(예: nodeset='0')를 사용하는 것이 좋습니다.

9.2. 자동 NUMA 분산

자동 NUMA 분산은 NUMA 하드웨어 시스템에서 실행되는 애플리케이션의 성능을 향상시킵니다. Red Hat Enterprise Linux 7 시스템에서 기본적으로 활성화되어 있습니다.
일반적으로 애플리케이션은 프로세스 스레드가 스레드와 동일한 NUMA 노드의 메모리에 액세스하는 경우 가장 적합합니다. 자동 NUMA 분산은 액세스 중인 메모리에 더 가깝게 작업( threads 또는 프로세스일 수 있음)을 이동합니다. 또한 애플리케이션 데이터를 참조하는 작업에 더 가까운 메모리로 이동합니다. 이 모든 작업은 자동 NUMA 분산이 활성화될 때 커널에 의해 자동으로 수행됩니다.
자동 NUMA 분산은 시스템에서 자동 NUMA 분산이 활성화된 경우에만 활성 및 할당된 알고리즘 및 데이터 구조를 사용합니다.
  • 프로세스 메모리의 주기적인 NUMA 매핑
  • NUMA 힌트 오류
  • migrate-on-Fault (MoF) - 메모리를 실행하는 위치로 이동합니다.
  • task_numa_placement - 실행중인 프로그램을 메모리에 더 가깝게 이동합니다.

9.2.1. 자동 NUMA 분산 구성

자동 NUMA 분산은 Red Hat Enterprise Linux 7에서 기본적으로 활성화되어 있으며 NUMA 속성을 사용하여 하드웨어에서 부팅될 때 자동으로 활성화됩니다.
자동 NUMA 분산은 다음 조건이 모두 충족되면 활성화됩니다.
  • # numactl --hardware 는 여러 노드를 표시
  • # cat /proc/sys/kernel/numa_balancing s 1
애플리케이션의 수동 NUMA 튜닝은 자동 NUMA 분산을 재정의하여 메모리의 일정 매핑, NUMA 오류, 마이그레이션 및 해당 애플리케이션의 자동 NUMA 배치를 비활성화합니다.
시스템 전체 수동 NUMA 튜닝이 권장되는 경우도 있습니다.
자동 NUMA 분산을 비활성화하려면 다음 명령을 사용하십시오. 
# echo 0 > /proc/sys/kernel/numa_balancing
자동 NUMA 분산을 활성화하려면 다음 명령을 사용합니다. 
# echo 1 > /proc/sys/kernel/numa_balancing

9.3. libvirt NUMA 튜닝

일반적으로 NUMA 시스템에서 최상의 성능은 게스트 크기를 단일 NUMA 노드의 리소스 양으로 제한하여 달성됩니다. NUMA 노드 간에 리소스를 불필요하게 분할하지 않도록 합니다.
numastat 툴을 사용하여 프로세스 및 운영 체제에 대한 NUMA별 메모리 통계를 확인합니다.
다음 예에서 numastat 툴에서는 NUMA 노드 간에 메모리 정렬이 있는 네 개의 가상 머신을 표시합니다. 
# 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
numad 를 실행하여 게스트의 CPU 및 메모리 리소스를 자동으로 정렬합니다.
그런 다음 numastat -c qemu-kvm 을 다시 실행하여 numad 실행 결과를 확인합니다. 다음 출력은 리소스가 정렬되었음을 보여줍니다. 
# 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
참고
-c 를 사용하여 numastat 를 실행하면 컴팩트 출력을 제공합니다. -m 옵션을 추가하면 노드별로 시스템 전체 메모리 정보가 출력에 추가됩니다. 자세한 내용은 numastat man 페이지를 참조하십시오.

9.3.1. 호스트 NUMA 노드당 메모리 모니터링

nodestats.py 스크립트를 사용하여 호스트의 각 NUMA 노드에 대한 총 메모리 및 사용 가능한 메모리를 보고할 수 있습니다. 이 스크립트는 또한 실행 중인 각 도메인의 특정 호스트 노드에 엄격하게 바인딩된 메모리 양을 보고합니다. 예를 들어 다음과 같습니다. 
# /usr/share/doc/libvirt-python-2.0.0/examples/nodestats.py
NUMA stats
NUMA nodes:     0       1       2       3
MemTotal:       3950    3967    3937    3943
MemFree:        66      56      42      41
Domain 'rhel7-0':
         Overall memory: 1536 MiB
Domain 'rhel7-1':
         Overall memory: 2048 MiB
Domain 'rhel6':
         Overall memory: 1024 MiB nodes 0-1
         Node 0: 1024 MiB nodes 0-1
Domain 'rhel7-2':
         Overall memory: 4096 MiB nodes 0-3
         Node 0: 1024 MiB nodes 0
         Node 1: 1024 MiB nodes 1
         Node 2: 1024 MiB nodes 2
         Node 3: 1024 MiB nodes 3
이 예에서는 호스트 NUMA 노드 4개를 나타내며 각각 약 4GB의 RAM을 총(MemTotal)에 포함합니다. 각 도메인(MemFree)에서 거의 모든 메모리가 사용됩니다. 실행 중인 네 개의 도메인(가상 시스템)이 있습니다. 'rhel7-0' 에는 특정 호스트 NUMA 노드에 고정되어 있지 않은 1.5GB 메모리가 있습니다. 그러나 도메인 'rhel7-2' 에는 호스트 노드에 1:1 고정되는 4GB 메모리와 4개의 NUMA 노드가 있습니다.
호스트 NUMA 노드 통계를 출력하려면 환경에 대한 nodestats.py 스크립트를 만듭니다. 예제 스크립트는 /usr/share/doc/libvirt-python-version/examples/nodestats.py 에서 libvirt-python 패키지 파일을 찾을 수 있습니다. rpm -ql libvirt-python 명령을 사용하여 스크립트의 특정 경로를 표시할 수 있습니다.

9.3.2. NUMA vCPU 고정

vCPU 고정은 베어 메탈 시스템의 작업 고정과 유사한 이점을 제공합니다. vCPU는 호스트 운영 체제에서 사용자 공간 작업으로 실행되므로 캐시 효율성이 향상됩니다. 한 가지 예는 모든 vCPU 스레드가 동일한 물리적 소켓에서 실행 중인 환경이므로 L3 캐시 도메인을 공유합니다.
참고
Red Hat Enterprise Linux 버전 7.0~ 7.2에서는 활성 vCPU를 고정할 수 있습니다. 그러나 Red Hat Enterprise Linux 7.3에서는 비활성 vCPU를 고정할 수도 있습니다.
vCPU 고정을 numatune 과 결합하면 NUMA 누락을 방지할 수 있습니다. NUMA 누락의 성능에 미치는 영향은 일반적으로 10% 이상의 성능 히트에서 시작합니다. vCPU 고정 및 numatune 을 함께 구성해야 합니다.
가상 시스템이 스토리지 또는 네트워크 I/O 작업을 수행하는 경우 모든 vCPU 및 메모리를 I/O 어댑터에 물리적으로 연결된 동일한 물리적 소켓에 고정하는 것이 유용할 수 있습니다.
참고
lstopo 툴을 사용하여 NUMA 토폴로지를 시각화할 수 있습니다. 또한 vCPU가 동일한 물리적 소켓의 코어에 바인딩되어 있는지 확인하는 데 도움이 될 수 있습니다. lstopo:https://access.redhat.com/site/solutions/62879 에 대한 자세한 내용은 다음 지식 베이스 문서를 참조하십시오.
중요
고정은 물리 코어보다 많은 vCPU가 있는 경우 복잡성이 향상되었습니다.
다음 예제 XML 구성에는 물리 CPU 0-7에 고정된 도메인 프로세스가 있습니다. vCPU 스레드는 자체 cpuset에 고정됩니다. 예를 들어 vCPU0은 물리 CPU 0, vCPU1이 물리적 CPU 1에 고정되어 있습니다. 
<vcpu cpuset='0-7'>8</vcpu>
        <cputune>
                <vcpupin vcpu='0' cpuset='0'/>
                <vcpupin vcpu='1' cpuset='1'/>
                <vcpupin vcpu='2' cpuset='2'/>
                <vcpupin vcpu='3' cpuset='3'/>
                <vcpupin vcpu='4' cpuset='4'/>
                <vcpupin vcpu='5' cpuset='5'/>
                <vcpupin vcpu='6' cpuset='6'/>
                <vcpupin vcpu='7' cpuset='7'/>
        </cputune>
vcpu와 vcpupin 태그 간에 직접적인 관계가 있습니다. vcpupin 옵션을 지정하지 않으면 값이 자동으로 결정되고 상위 vcpu 태그 옵션에서 상속됩니다. 다음 구성에서는 vcpu 5 누락에 대한 <vcpupin> 을 보여줍니다. 따라서 상위 태그 <vcpu> 에 지정된 대로 vCPU5 가 물리적 CPU 0-7에 고정됩니다. 
<vcpu cpuset='0-7'>8</vcpu>
        <cputune>
                <vcpupin vcpu='0' cpuset='0'/>
                <vcpupin vcpu='1' cpuset='1'/>
                <vcpupin vcpu='2' cpuset='2'/>
                <vcpupin vcpu='3' cpuset='3'/>
                <vcpupin vcpu='4' cpuset='4'/>
                <vcpupin vcpu='6' cpuset='6'/>
                <vcpupin vcpu='7' cpuset='7'/>
        </cputune>
중요
<vcpupin>, <numatune>, <emulatorpin> 은 최적의 결정적 성능을 발휘하려면 함께 구성해야 합니다. <numatune> 태그에 대한 자세한 내용은 9.3.3절. “도메인 프로세스” 를 참조하십시오. <emulatorpin> 태그에 대한 자세한 내용은 9.3.6절. “emulatorpin 사용” 를 참조하십시오.

9.3.3. 도메인 프로세스

Red Hat Enterprise Linux에서 제공되는 대로 libvirt는 libnuma를 사용하여 도메인 프로세스에 대한 메모리 바인딩 정책을 설정합니다. 이러한 정책의 노드 세트는 정적 (도메인 XML에서 지정됨) 또는 auto ( numad 쿼리로 구성)로 구성할 수 있습니다. <numatune> 태그 내부에서 이를 구성하는 방법에 대한 예는 다음 XML 구성을 참조하십시오. 
<numatune>
        <memory mode='strict' placement='auto'/>
</numatune>

<numatune>
        <memory mode='strict' nodeset='0,2-3'/>
</numatune>
libvirt는 sched_setaffinity(2) 를 사용하여 도메인 프로세스에 대한 CPU 바인딩 정책을 설정합니다. cpuset 옵션은 정적 (도메인 XML에 지정됨) 또는 auto ( numad 쿼리로 구성)일 수 있습니다. <vcpu> 태그 내부에서 이를 구성하는 방법에 대한 예는 다음 XML 구성을 참조하십시오. 
<vcpu placement='auto'>8</vcpu>

<vcpu placement='static' cpuset='0-10,ˆ5'>8</vcpu>
<vcpu> 과 <numatune> 에 사용하는 배치 모드 사이에는 암시적 상속 규칙이 있습니다.
  • <numatune> 의 배치 모드는 기본적으로 동일한 배치 모드인 <vcpu> 또는 <nodeset> 가 지정된 경우 static 으로 설정됩니다.
  • 마찬가지로 <vcpu> 의 배치 모드는 기본적으로 <numatune> 의 동일한 배치 모드 또는 <cpuset> 가 지정된 경우 static 으로 설정됩니다.
즉, 도메인 프로세스의 CPU 튜닝 및 메모리 튜닝을 별도로 지정하고 정의할 수 있지만 다른 배치 모드에 종속되도록 구성할 수도 있습니다.
시작 시 모든 vCPU를 고정하지 않고 선택한 vCPU 수를 부팅하도록 numad로 시스템을 구성할 수도 있습니다.
예를 들어 32개의 vCPU가 있는 시스템에서 8개의 vCPU만 부팅하려면 다음과 유사한 XML을 구성합니다. 
<vcpu placement='auto' current='8'>32</vcpu>
참고
vcpu 및 numatune http://libvirt.org/formatdomain.html#elementsCPUAllocation 에 대한 자세한 내용은 다음 URL을 참조하십시오. http://libvirt.org/formatdomain.html#elementsNUMATuning

9.3.4. 도메인 vCPU 스레드

libvirt는 도메인 프로세스 튜닝 외에도 XML 구성에서 각 vcpu 스레드에 대한 고정 정책을 설정할 수 있습니다. <cputune> 태그 내의 각 vcpu 스레드에 대한 고정 정책을 설정합니다. 
<cputune>
        <vcpupin vcpu="0" cpuset="1-4,ˆ2"/>
        <vcpupin vcpu="1" cpuset="0,1"/>
        <vcpupin vcpu="2" cpuset="2,3"/>
        <vcpupin vcpu="3" cpuset="0,4"/>
</cputune>
이 태그에서 libvirt는 cgroup 또는 sched_setaffinity(2) 를 사용하여 vcpu 스레드를 지정된 cpuset에 고정합니다.
참고
<cputune> 에 대한 자세한 내용은 다음 URL을 참조하십시오. http://libvirt.org/formatdomain.html#elementsCPUTuning
또한 단일 NUMA 노드보다 vCPU가 많은 가상 머신을 설정해야 하는 경우 게스트가 호스트에서 NUMA 토폴로지를 감지하도록 호스트를 구성합니다. 이를 통해 CPU, 메모리 및 NUMA 노드를 1:1 매핑할 수 있습니다. 예를 들어 이 작업은 vCPU 4개 및 6GB 메모리가 있는 게스트 및 다음 NUMA 설정을 사용하여 적용할 수 있습니다. 
4 available nodes (0-3)
Node 0:	CPUs 0 4, size 4000 MiB
Node 1: CPUs 1 5, size 3999 MiB
Node 2: CPUs 2 6, size 4001 MiB
Node 3: CPUs 0 4, size 4005 MiB
이 시나리오에서는 다음 도메인 XML 설정을 사용합니다. 
<cputune>
	<vcpupin vcpu="0" cpuset="1"/>
	<vcpupin vcpu="1" cpuset="5"/>
	<vcpupin vcpu="2" cpuset="2"/>
	<vcpupin vcpu="3" cpuset="6"/>
</cputune>
<numatune>
  <memory mode="strict" nodeset="1-2"/> 
</numatune>
<cpu>
	<numa>
		<cell id="0" cpus="0-1" memory="3" unit="GiB"/>
		<cell id="1" cpus="2-3" memory="3" unit="GiB"/>
	</numa>
</cpu>

9.3.5. 캐시 할당 기술을 사용하여 성능 개선

특정 CPU 모델에서 커널이 제공하는 Cache Allocation Technology(CAT)를 사용할 수 있습니다. 이를 통해 vCPU 스레드에 대한 호스트 CPU 캐시의 일부를 할당할 수 있으므로 실시간 성능이 향상됩니다.
cachetune 태그 내에 vCPU 캐시 할당을 구성하는 방법에 대한 예는 다음 XML 구성을 참조하십시오. 
<domain>
  <cputune>
    <cachetune vcpus='0-1'>
      <cache id='0' level='3' type='code' size='3' unit='MiB'/>
      <cache id='0' level='3' type='data' size='3' unit='MiB'/>
    </cachetune>
  </cputune>
</domain>
위의 XML 파일은 vCPU 0 및 1의 스레드가 할당된 첫 번째 L3 캐시(level='3' id='0')에서 3MiB를 갖도록 구성합니다.
참고
단일 가상 머신에는 여러 <cachetune> 요소가 있을 수 있습니다.
자세한 내용은 업스트림 libvirt 문서의 cachetune 를 참조하십시오.

9.3.6. emulatorpin 사용

도메인 프로세스 고정 정책을 조정하는 또 다른 방법은 <cputune> 내부에서 <emulatorpin> 태그를 사용하는 것입니다.
<emulatorpin> 태그는 에뮬레이터 가 고정되는 물리적 CPU(vCPU를 포함하지 않는 도메인의 하위 집합)를 지정합니다. <emulatorpin> 태그는 에뮬레이터 스레드 프로세스에 정확한 선호도를 설정하는 방법을 제공합니다. 결과적으로 vhost 스레드는 물리적 CPU 및 메모리의 동일한 서브 세트에서 실행되므로 캐시 locality를 활용할 수 있습니다. 예를 들면 다음과 같습니다. 
<cputune>
        <emulatorpin cpuset="1-3"/>
</cputune>
참고
Red Hat Enterprise Linux 7에서는 기본적으로 자동 NUMA 분산이 활성화됩니다. 자동 NUMA 분산은 vhost-net 에뮬레이터 스레드가 vCPU 작업을 보다 안정적으로 따르므로 <emulatorpin> 를 수동으로 튜닝할 필요가 줄어듭니다. 자동 NUMA 분산에 대한 자세한 내용은 9.2절. “자동 NUMA 분산” 을 참조하십시오.

9.3.7. virsh를 사용하여 vCPU 고정 조정

중요
다음은 예제 명령 전용입니다. 환경에 따라 값을 대체해야 합니다.
다음 예제 virsh 명령은 ID가 1인 vcpu 스레드 rhel7 을 물리적 CPU 2에 고정합니다. 
% virsh vcpupin rhel7 1 2
virsh 명령을 사용하여 현재 vcpu 고정 구성을 가져올 수도 있습니다. 예를 들어 다음과 같습니다. 
% virsh vcpupin rhel7

9.3.8. virsh를 사용하여 도메인 프로세스 CPU 고정 조정

중요
다음은 예제 명령 전용입니다. 환경에 따라 값을 대체해야 합니다.
emulatorpin 옵션은 CPU 선호도 설정을 각 도메인 프로세스와 연결된 스레드에 적용합니다. 완전한 고정을 위해 이전에 표시된 것처럼 virsh vcpupin 과 각 게스트에 대해 virsh emulatorpin 을 모두 사용해야합니다. 예를 들어 다음과 같습니다. 
% virsh emulatorpin rhel7 3-4

9.3.9. virsh를 사용하여 도메인 프로세스 메모리 정책 조정

도메인 프로세스 메모리를 동적으로 튜닝할 수 있습니다. 다음 예제 명령을 참조하십시오. 
% virsh numatune rhel7 --nodeset 0-10
이러한 명령의 자세한 내용은 virsh man 페이지에서 확인할 수 있습니다.

9.3.10. 게스트 NUMA 토폴로지

게스트 가상 머신의 XML에 있는 <cpu> 태그 내에서 <numa> 태그를 사용하여 게스트 NUMA 토폴로지를 지정할 수 있습니다. 다음 예제를 확인하고 그에 따라 값을 바꿉니다. 
<cpu>
        ...
    <numa>
      <cell cpus='0-3' memory='512000'/>
      <cell cpus='4-7' memory='512000'/>
    </numa>
    ...
</cpu>
각 <cell> 요소는 NUMA 셀 또는 NUMA 노드를 지정합니다. cpus 노드의 일부인 CPU의 CPU 또는 범위를 지정하고 memory 는 노드 메모리를 kibibytes (24바이트 블록)로 지정합니다. 각 셀 또는 노드에는 0부터 시작하는 순서에 따라 cellid 또는 nodeid 가 할당됩니다.
중요
구성된 CPU 소켓, 코어 및 스레드의 토폴로지를 사용하여 게스트 가상 머신의 NUMA 토폴로지를 수정할 때 단일 소켓에 속하는 코어 및 스레드가 동일한 NUMA 노드에 할당되어 있는지 확인합니다. 동일한 소켓의 스레드 또는 코어가 다른 NUMA 노드에 할당되면 게스트가 부팅되지 않을 수 있습니다.
주의
게스트 NUMA 토폴로지는 Red Hat Enterprise Linux 7에서 동시에 지원되지 않으며 Red Hat Virtualization 또는 Red Hat OpenStack Platform 과 같은 계층화된 제품에서만 사용할 수 있습니다. ???

9.3.11. PCI 장치용 NUMA 노드 위치

새 가상 머신을 시작할 때 PCI 패스스루가 요청될 때 게스트가 최적의 메모리 성능을 위해 올바른 NUMA 노드에 고정되도록 호스트 NUMA 토폴로지와 PCI 장치 연결을 모두 알아야 합니다.
예를 들어, 게스트가 NUMA 노드 0-1에 고정되어 있지만 PCI 장치 중 하나가 노드 2 와 연결된 경우 노드 간 데이터 전송에는 약간의 시간이 걸립니다.
Red Hat Enterprise Linux 7.1 이상에서 libvirt는 게스트 XML 에서 PCI 장치에 대한 NUMA 노드 현지성을 보고하여 관리 애플리케이션에서 더 나은 성능 결정을 내릴 수 있도록 합니다.
이 정보는 /sys/devices/pci*/*/numa_node 의 sysfs 파일에 표시됩니다. 이러한 설정을 확인하는 한 가지 방법은 lstopo 도구를 사용하여 sysfs 데이터를 보고하는 것입니다. 
# lstopo-no-graphics
Machine (126GB)
  NUMANode L#0 (P#0 63GB)
    Socket L#0 + L3 L#0 (20MB)
      L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
      L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#2)
      L2 L#2 (256KB) + L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2 + PU L#2 (P#4)
      L2 L#3 (256KB) + L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3 + PU L#3 (P#6)
      L2 L#4 (256KB) + L1d L#4 (32KB) + L1i L#4 (32KB) + Core L#4 + PU L#4 (P#8)
      L2 L#5 (256KB) + L1d L#5 (32KB) + L1i L#5 (32KB) + Core L#5 + PU L#5 (P#10)
      L2 L#6 (256KB) + L1d L#6 (32KB) + L1i L#6 (32KB) + Core L#6 + PU L#6 (P#12)
      L2 L#7 (256KB) + L1d L#7 (32KB) + L1i L#7 (32KB) + Core L#7 + PU L#7 (P#14)
    HostBridge L#0
      PCIBridge
        PCI 8086:1521
          Net L#0 "em1"
        PCI 8086:1521
          Net L#1 "em2"
        PCI 8086:1521
          Net L#2 "em3"
        PCI 8086:1521
          Net L#3 "em4"
      PCIBridge
        PCI 1000:005b
          Block L#4 "sda"
          Block L#5 "sdb"
          Block L#6 "sdc"
          Block L#7 "sdd"
      PCIBridge
        PCI 8086:154d
          Net L#8 "p3p1"
        PCI 8086:154d
          Net L#9 "p3p2"
      PCIBridge
        PCIBridge
          PCIBridge
            PCIBridge
              PCI 102b:0534
                GPU L#10 "card0"
                GPU L#11 "controlD64"
      PCI 8086:1d02
  NUMANode L#1 (P#1 63GB)
    Socket L#1 + L3 L#1 (20MB)
      L2 L#8 (256KB) + L1d L#8 (32KB) + L1i L#8 (32KB) + Core L#8 + PU L#8 (P#1)
      L2 L#9 (256KB) + L1d L#9 (32KB) + L1i L#9 (32KB) + Core L#9 + PU L#9 (P#3)
      L2 L#10 (256KB) + L1d L#10 (32KB) + L1i L#10 (32KB) + Core L#10 + PU L#10 (P#5)
      L2 L#11 (256KB) + L1d L#11 (32KB) + L1i L#11 (32KB) + Core L#11 + PU L#11 (P#7)
      L2 L#12 (256KB) + L1d L#12 (32KB) + L1i L#12 (32KB) + Core L#12 + PU L#12 (P#9)
      L2 L#13 (256KB) + L1d L#13 (32KB) + L1i L#13 (32KB) + Core L#13 + PU L#13 (P#11)
      L2 L#14 (256KB) + L1d L#14 (32KB) + L1i L#14 (32KB) + Core L#14 + PU L#14 (P#13)
      L2 L#15 (256KB) + L1d L#15 (32KB) + L1i L#15 (32KB) + Core L#15 + PU L#15 (P#15)
    HostBridge L#8
      PCIBridge
        PCI 1924:0903
          Net L#12 "p1p1"
        PCI 1924:0903
          Net L#13 "p1p2"
      PCIBridge
        PCI 15b3:1003
          Net L#14 "ib0"
          Net L#15 "ib1"
          OpenFabrics L#16 "mlx4_0"
이 출력은 다음을 표시합니다.
  • NIC em* 및 디스크 sd* 는 NUMA 노드 0에 연결되고, 코어 0,2,4,6,8,10,12,14입니다.
  • NIC p1* 및 ib* 는 NUMA 노드 1 및 코어 1,3,5,7,9,11,13,15에 연결되어 있습니다.

9.4. NUMA-Aware Kernel SamePage Merging (KSM)

KSM(Kernel SamePage Merging)을 사용하면 가상 머신이 동일한 메모리 페이지를 공유할 수 있습니다. KSM은 시스템이 NUMA 메모리를 사용하고 있으며 다른 NUMA 노드에서 페이지를 병합하는 것을 제어할 수 있습니다.
sysfs /sys/kernel/mm/ksm/merge_across_nodes 매개변수를 사용하여 다른 NUMA 노드에서 페이지 병합을 제어합니다. 기본적으로 모든 노드의 페이지를 함께 병합할 수 있습니다. 이 매개변수를 0으로 설정하면 동일한 노드의 페이지만 병합됩니다.
일반적으로 시스템 메모리를 초과 구독하지 않으면 KSM 공유를 비활성화하여 더 나은 런타임 성능을 얻을 수 있습니다.
중요
KSM이 여러 게스트 가상 머신이 있는 NUMA 호스트의 노드를 병합하는 경우 게스트 및 CPU가 더 멀리 있는 노드의 경우 병합된 KSM 페이지에 대한 액세스 대기 시간이 크게 증가할 수 있습니다.
하이퍼바이저가 게스트의 공유 페이지를 비활성화하도록 지시하려면 게스트의 XML에 다음을 추가합니다. 
<memoryBacking>
         <nosharepages/>
</memoryBacking>
<memoryBacking> 요소를 사용하여 메모리 설정을 조정하는 방법에 대한 자세한 내용은 8.2.2절. “virsh를 사용한 메모리 튜닝” 를 참조하십시오.

부록 A. 개정 내역

고친 과정
고침 1.0-35Thus May 23 2019Jiri Herrmann
7.7 베타 게시 버전
고침 1.0-34Tue Oct 25 2018Jiri Herrmann
7.6 GA 게시용 버전
고침 1.0-32Tue Aug 14 2018Jiri Herrmann
7.6 베타 게시 버전
고침 1.0-31Wed Apr 4 2018Jiri Herrmann
7.5 GA 버전
고침 1.0-27Mon Jul 27 2017Jiri Herrmann
7.4 GA 게시의 버전
고침 1.0-24Mon Oct 17 2016Jiri Herrmann
7.3 GA 게시의 버전
고침 1.0-22Mon Dec 21 2015Laura Novich
여러 버그를 수정하기 위한 게시 가이드
고침 1.0-19Thu Oct 08 2015Jiri Herrmann
버전 기록 정리