Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
6장. CPU
이 장에서는 Red Hat Enterprise Linux 7의 애플리케이션 성능에 영향을 주는 CPU 하드웨어 세부 정보 및 구성 옵션에 대해 간단히 설명합니다. 6.1절. “고려 사항” 성능에 영향을 주는 CPU 관련 요인에 대해 설명합니다. 6.2절. “성능 문제 모니터링 및 진단” Red Hat Enterprise Linux 7 툴을 사용하여 CPU 하드웨어 또는 구성 세부 정보와 관련된 성능 문제를 진단하는 방법을 교육합니다. 6.3절. “구성 제안” Red Hat Enterprise Linux 7의 CPU 관련 성능 문제를 해결하는 데 사용할 수 있는 툴과 전략에 대해 설명합니다.
6.1. 고려 사항
이 섹션을 읽고 시스템 및 애플리케이션 성능이 다음과 같은 요인의 영향을 받는 방법을 알아보십시오.
- 프로세서가 서로 연결되고 메모리와 같은 관련 리소스에 연결되는 방법.
- 프로세서에서 실행을 위해 스레드를 예약하는 방법
- Red Hat Enterprise Linux 7의 인터럽트를 처리하는 프로세서 방법.
6.1.1. 시스템 토폴로지
최신 컴퓨팅에서 중앙 처리 단위의 개념은 대부분의 최신 시스템에 여러 프로세서가 있으므로 잘못된 것입니다. 이러한 프로세서를 서로 및 기타 시스템 리소스에 연결하는 방법 - 시스템의 토폴로지 는 시스템 및 애플리케이션 성능에 크게 영향을 미칠 수 있습니다.
최신 컴퓨팅에서 사용되는 토폴로지 유형에는 다음 두 가지가 있습니다.
- 대칭 SMP(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 노드와 해당 노드 간의 상대 거리에 대한 정보가 포함되어 있습니다.
6.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 명령은 자세한 텍스트 출력을 제공합니다.
lstopo 명령의 출력
6.1.2. 스케줄링
Red Hat Enterprise Linux에서 가장 작은 프로세스 실행 단위를 스레드 라고 합니다. 시스템 스케줄러는 스레드를 실행하는 프로세서와 스레드가 실행되는 기간을 결정합니다. 그러나 스케줄러의 주요 문제는 시스템을 사용 중인 상태로 유지하는 것이므로 애플리케이션 성능에 맞게 스레드를 최적으로 예약하지 못할 수 있습니다.
예를 들어 노드 B의 프로세서를 사용할 수 있게 되면 NUMA 시스템의 애플리케이션이 노드 A에서 실행되고 있다고 가정합니다. 노드 B에서 프로세서를 사용 중인 상태로 유지하려면 스케줄러에서 애플리케이션의 스레드 중 하나를 노드 B로 이동합니다. 그러나 애플리케이션 스레드는 여전히 노드 A의 메모리에 액세스해야 합니다. 스레드가 이제 노드 B에서 실행 중이고 노드 A가 더 이상 스레드에 로컬되지 않으므로 더 이상 액세스할 수 없습니다. 노드 A의 프로세서가 사용 가능할 때까지 기다린 후 로컬 메모리 액세스 권한이 있는 원래 노드에서 스레드를 실행하는 데 걸리는 것보다 스레드가 노드 B에서 실행을 완료하는 데 시간이 더 오래 걸릴 수 있습니다.
성능에 민감한 애플리케이션은 종종 로더 또는 관리자가 스레드 실행 위치를 결정하는 이점을 얻을 수 있습니다. 성능에 민감한 애플리케이션의 요구 사항에 맞게 스레드를 적절하게 예약하는 방법에 대한 자세한 내용은 6.3.6절. “스케줄링 정책 튜닝” 을 참조하십시오.
6.1.2.1. Kernel Ticks
이전 버전의 Red Hat Enterprise Linux에서는 Linux 커널이 각 CPU를 정기적으로 중단하여 수행해야 하는 작업을 확인합니다. 결과를 사용하여 프로세스 스케줄링 및 로드 밸런싱에 대한 결정을 내렸습니다. 이 정기적인 중단을 커널 틱 이라고 했습니다.
이 틱은 코어에서 수행할 작업이 있는지 여부와 관계없이 발생했습니다. 이로 인해 유휴 코어도 인터럽트에 응답하기 위해 정기적으로 더 높은 전원 상태로 강제 적용되었습니다(초당 최대 1000회). 이로 인해 시스템은 최근 세대의 x86 프로세서에 포함된 깊은 수면 상태를 효과적으로 사용하지 못했습니다.
기본적으로 Red Hat Enterprise Linux 6 및 7에서는 커널이 더 이상 유휴 CPU를 중단하지 않으므로 전원 상태가 낮은 경향이 있습니다. 이 동작을 틱리스 커널이라고 합니다. 하나 이상의 작업이 실행 중인 경우 주기적인 인터럽트가 온 디맨드 인터럽트로 교체되어 CPU가 더 오래 유휴 상태이거나 낮은 전원 상태에 남아 있을 수 있으며 전원 사용량을 줄일 수 있습니다.
Red Hat Enterprise Linux 7은 사용자 공간 작업으로 커널 간섭을 줄임으로써 결정성을 더욱 개선할 수 있는 동적 틱리스 옵션(
nohz_full)을 제공합니다. 이 옵션은 nohz_full 커널 매개변수를 사용하여 지정된 코어에서 활성화할 수 있습니다. 이 옵션을 코어에서 활성화하면 모든 시간 유지 활동이 대기 시간에 민감한 코어로 이동합니다. 이는 사용자 공간 작업이 커널 타이머 틱과 관련된 마이크로초 수준의 대기 시간에 특히 민감한 고성능 컴퓨팅 및 실시간 컴퓨팅 워크로드에 유용할 수 있습니다.
Red Hat Enterprise Linux 7에서 동적 틱리스 동작을 활성화하는 방법에 대한 자세한 내용은 6.3.1절. “커널 틱 시간 구성” 을 참조하십시오.
6.1.3. 인터럽트 요청(IRQ) 처리
인터럽트 요청 또는 IRQ는 하드웨어 조각에서 프로세서로 즉각적인 주의가 전송되는 신호입니다. 시스템의 각 장치에는 고유 인터럽트를 보낼 수 있도록 하나 이상의 IRQ 번호가 할당됩니다. 인터럽트가 활성화되면 인터럽트 요청을 수신하는 프로세서는 인터럽트 요청을 해결하기 위해 현재 애플리케이션 스레드의 실행을 즉시 일시 중지합니다.
정상적인 작동을 중단하기 때문에 중단률이 높아 시스템 성능이 저하될 수 있습니다. 인터럽트 선호도를 구성하거나 배치에서 여러 하위 우선 순위 인터럽트를 전송하여 인터럽트에 의해 걸린 시간을 줄일 수 있습니다(중요한 인터럽트 수 포함).
인터럽트 요청 튜닝에 대한 자세한 내용은 6.3.7절. “AMD64 및 Intel 64에서 Interrupt Affinity 설정” 또는 6.3.8절. “Tuna를 사용하여 CPU, Thread 및 Interrupt Affinity 구성” 을 참조하십시오. 네트워크 중단과 관련된 자세한 내용은 9장. 네트워킹 을 참조하십시오.
