Menu Close
Settings Close

Language and Page Formatting Options

Red Hat Training

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

3장. CPU

다음 부분에서는 Red Hat Enterprise Linux 7에서 애플리케이션 성능에 영향을 미치는 CPU 하드웨어 정보 및 설정 옵션에 대해 설명합니다. 3.1절. “고려 사항”에서는 성능에 영향을 미치는 CPU 관련 요인에 대해 설명합니다. 3.2절. “성능 관련 문제 모니터링 및 진단”에서는 CPU 하드웨어나 설정에 관련된 성능 문제를 분석하기 위한 Red Hat Enterprise Linux 7 도구 사용 방법에 대해 설명합니다. 3.3절. “권장 설정 ”에서는 Red Hat Enterprise Linux 7에서 CPU 관련 성능 문제를 해결하기 위해 사용할 수 있는 도구 및 전략에 대해 설명합니다.

3.1. 고려 사항

다음 부분에서는 시스템 및 애플리케이션 성능에 영향을 미치는 요인에 대해 설명합니다:
  • 메모리와 같은 관련 리소스 및 프로세서 간 연결 형태
  • 프로세서가 실행을 위해 스레드 스케줄링 계획 방법
  • Red Hat Enterprise Linux 7에서 프로세서 인터럽트 처리 방법

3.1.1. 시스템 토폴로지

현대적인 컴퓨터 시스템에서 대부분의 시스템에는 여러 프로세서가 있기 때문에 central processing unit이라는 개념은 오해를 불러일으킬 수 있습니다. 이러한 프로세서가 서로 연결된 방법 및 다른 시스템 리소스와의 연결 방법 — 시스템 토폴로지 —에 따라 시스템, 애플리케이션 성능 및 시스템 튜닝 시 고려 사항에 크게 영향을 미칠 수 있습니다.
최근 컴퓨팅에서 주로 사용되는 두 가지 유형의 토폴로지는 다음과 같습니다:
SMP (Symmetric Multi-Processor) 토폴로지
SMP 토폴로지에서는 모든 프로세서가 동일한 시간 동안 메모리에 액세스할 수 있습니다. 하지만 공유되는 동등한 메모리 액세스는 기본적으로 전체 CPU에서 직렬화된 메모리 액세스를 강제하기 때문에 SMP 시스템 확장 제약이 전반적으로 허용되지 않습니다. 이러한 이유로 실제로 최근 모든 서버 시스템은 NUMA 시스템을 사용하고 있습니다.
NUMA (Non-Uniform Memory Access) 토폴로지
NUMA 토폴로지는 SMP 토폴로지 보다 최근에 개발되었습니다. NUMA 시스템에서 여러 프로세서는 하나의 소켓에 물리적으로 그룹화되어 있습니다. 각 소켓에는 메모리 전용 영역과 이러한 메모리에 로컬 액세스하는 노드라고 부르는 프로세서가 있습니다.
동일한 노드에 있는 프로세서는 노드 메모리 뱅크에 고속으로 액세스할 수 있으며 다른 노드에 있는 메모리 뱅크로의 액세스는 느려집니다. 따라서 비-로컬 메모리에 액세스 하는 경우 성능이 저하됩니다.
이러한 성능 저하에 따라 NUMA 토폴로지를 사용하는 시스템에서 성능에 민감한 애플리케이션의 경우 애플리케이션을 실행하는 프로세서와 동일한 노드에 있는 메모리에 액세스하고 가능한 원격 메모리 액세스는 피하도록 합니다.
따라서 NUMA 토폴로지를 사용하는 시스템에서 애플리케이션 성능을 조정할 때 애플리케이션이 실행되는 위치와 실행되는 지점에서 가장 가까운 메모리 뱅크가 무엇인지를 고려해야 합니다.
NUMA 토폴로지를 사용하는 시스템에서 /sys 파일 시스템에는 프로세서, 메모리, 주변 장치가 연결된 방법에 관한 정보가 들어 있습니다. /sys/devices/system/cpu 디렉토리에는 시스템의 프로세서가 서로 연결된 방법에 대한 정보가 들어 있습니다. /sys/devices/system/node 디렉토리에는 시스템의 NUMA 노드와 노드 간의 상대 거리에 대한 정보가 들어 있습니다.

3.1.1.1. 시스템 토폴로지 지정

시스템 토폴로지를 이해하는데 도움이 될 수 있는 여러 명령이 있습니다. numactl --hardware 명령은 시스템 토폴로지 개요를 표시합니다.
$ numactl --hardware
available: 4 nodes (0-3)
node 0 cpus: 0 4 8 12 16 20 24 28 32 36
node 0 size: 65415 MB
node 0 free: 43971 MB
node 1 cpus: 2 6 10 14 18 22 26 30 34 38
node 1 size: 65536 MB
node 1 free: 44321 MB
node 2 cpus: 1 5 9 13 17 21 25 29 33 37
node 2 size: 65536 MB
node 2 free: 44304 MB
node 3 cpus: 3 7 11 15 19 23 27 31 35 39
node 3 size: 65536 MB
node 3 free: 44329 MB
node distances:
node   0   1   2   3 
  0:  10  21  21  21 
  1:  21  10  21  21 
  2:  21  21  10  21 
  3:  21  21  21  10
util-linux 패키지로 제공되는 lscpu 명령은 CPU, 스레드, 코어, 소켓, NUMA 노드 수와 같은 CPU 아키텍처에 대한 정보를 수집합니다.
$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                40
On-line CPU(s) list:   0-39
Thread(s) per core:    1
Core(s) per socket:    10
Socket(s):             4
NUMA node(s):          4
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 47
Model name:            Intel(R) Xeon(R) CPU E7- 4870  @ 2.40GHz
Stepping:              2
CPU MHz:               2394.204
BogoMIPS:              4787.85
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              30720K
NUMA node0 CPU(s):     0,4,8,12,16,20,24,28,32,36
NUMA node1 CPU(s):     2,6,10,14,18,22,26,30,34,38
NUMA node2 CPU(s):     1,5,9,13,17,21,25,29,33,37
NUMA node3 CPU(s):     3,7,11,15,19,23,27,31,35,39
hwloc 패키지로 제공되는 lstopo 명령은 시스템의 그래픽 이미지를 표시합니다. lstopo-no-graphics 명령을 사용하면 텍스트 출력합니다.
Graphical output of the lstopo command on a system with four NUMA nodes
lstopo 명령 출력

3.1.2. 스케줄링

Red Hat Enterprise Linux에서는 프로세스 실행의 최소 단위를 스레드 (thread)라고 합니다. 시스템 스케줄러는 스레드 실행 프로세서와 스레드 실행 기간을 지정합니다. 하지만 스케줄러의 주요 목적은 시스템을 계속 가동하는데 있으므로 애플리케이션 성능을 최적화하도록 스레드를 스케줄링하지 않을 수 있습니다.
예를 들어 NUMA 시스템에서 노드 B의 프로세서를 사용할 수 있을 때 애플리케이션이 노드 A에서 실행 중이라고 합시다. 노드 B 프로세서를 계속 가동시키려면 스케줄러는 애플리케이션 스레드 중 하나를 노드 B로 옮겨야 합니다. 스레드는 노드 B에서 실행되고 있고 노드 A 메모리는 더이상 스레드의 로컬 메모리가 아니기 때문에 액세스하는데 시간이 걸리게 됩니다. 스레드가 노드 B에서 실행 완료하는데 걸리는 시간이 노드 A에서 프로세서를 사용 가능하게 될 때 까지의 대기 시간과 로컬 메모리 액세스가 있는 원래의 노드에 있는 스레드를 실행하기 위한 시간 보다 더 걸릴 수 있습니다.
성능에 민감한 애플리케이션의 경우 설계자 또는 관리자가 스레드를 실행할 위치를 지정하는 것이 좋을 수 있습니다. 성능에 민감한 애플리케이션에 필요한 스레드를 적절하게 스케줄링하는 방법에 대한 자세한 내용은 3.3.6절. “스케줄링 정책 조정 ”에서 확인하십시오.

3.1.2.1. 커널 틱

Red Hat Enterprise Linux 이전 버전에서 Linux 커널은 완료해야할 작업을 확인하기 위해 정기적으로 각각의 CPU를 중단하고 이러한 결과를 사용하여 프로세스 스케줄링 및 부하 분산에 대한 결정을 내렸습니다. 이러한 정기적인 인터럽트는 커널 틱 (tick)이라고 했습니다.
코어에서 실행해야 할 작업 유무에 관계 없이 틱이 발생했습니다. 즉 유휴 상태인 코어도 인터럽트에 응답하기 위해 정기적으로 (초 당 최대 1000회) 높은 전력 상태로 강제되었습니다. 이로 인해 시스템에 최신 x86 프로세서가 포함된 경우 절전 상태를 효율적으로 사용할 수 없습니다.
Red Hat Enterprise Linux 6 및 7에서 기본적으로 커널은 전력 소비가 낮은 유휴 상태의 CPU를 인터럽트하지 않습니다. 이러한 동작은 틱리스 커널이라고 합니다. 실행 중인 작업이 적은 경우 주기적 인터럽트는 요청 시 인터럽트를 대신하고 있기 때문에 CPU는 유휴 상태 혹은 저전력 상태로 오래남아 있어 전력 사용을 줄일 수 있습니다.
Red Hat Enterprise Linux 7에서는 동적 틱리스 옵션 (nohz_full)을 제공하여 사용자 영역 작업에 의한 커널 간섭을 감소시킴으로써 기능이 개선되었습니다. 이러한 옵션은 nohz_full 커널 매개 변수를 사용하여 지정된 코어에서 활성화할 수 있습니다. 이러한 옵션을 코어에서 사용할 때 모든 시간 관리 동작은 대기 시간 제약이 없는 코어로 이동합니다. 이는 사용자 영역 작업이 커널 타이머 틱과 관련된 마이크로초 단위의 대기 시간 제약이 있는 고성능 계산 및 실시간 계산을 필요로하는 작업에 유용합니다.
Red Hat Enterprise Linux 7에서 동적 틱리스 동작을 활성화하는 방법에 대한 자세한 내용은 3.3.1절. “커널 틱 시간 설정 ”에서 참조하십시오.

3.1.3. IRQ (Interrupt Request) 처리

인터럽트 요청 또는 IRQ는 일부 하드웨어에서 프로세서에 신속한 대응을 요청하는 신호입니다. 시스템의 각 장치에는 하나 이상의 IRQ 번호가 지정되어 있어 고유한 인터럽트를 전송할 수 있습니다. 인터럽트를 활성화하면 인터럽트 요청을 수신하는 프로세서는 이러한 요청에 응답하기 위해 현재 애플리케이션 스레드 실행을 바로 중단합니다.
이는 정상 작동을 중지시키기 때문에 인터럽트 비율이 높을 경우 시스템 성능이 현저히 저하될 수 있습니다. 인터럽트 선호도를 설정하거나 여러 낮은 우선 순위의 인터럽트를 배치(여러 인터럽트를 통합)에 전송하여 인터럽트 시간을 감소시킬 수 있습니다.
인터럽트 요청 조정에 대한 보다 자세한 내용은 3.3.7절. “인터럽트 친화도 설정 ” or 3.3.8절. “Tuna를 사용하여 CPU, 스레드, 인터럽트 친화도 설정 ”에서 참조하십시오. 네트워크 인터럽트에 대한 자세한 내용은 6장. 네트워킹 에서 확인하십시오.