Linux는 세 가지 주요 스레드 스케줄링 정책을 사용합니다.

syslog 서버는 네트워크를 통해 프로그램에서 로그 메시지를 전달합니다. 이 경우가 작을수록 보류 중인 트랜잭션이 클 수 있습니다. 트랜잭션이 매우 크면 I/O 급증을 유발할 수 있습니다. 이를 방지하기 위해 간격을 적절히 작게 유지하십시오.

시스템 로깅 데몬 syslogd 는 다른 프로그램에서 메시지를 수집하는 데 사용됩니다. 또한 커널에서 보고한 정보를 커널 로깅 데몬인 klogd 에서 수집합니다. 일반적으로 syslogd 로그는 로컬 파일에 로그되지만 네트워크를 통해 원격 로깅 서버에 기록하도록 구성할 수도 있습니다.

실행 중인 모든 애플리케이션은 시스템 리소스를 사용합니다. 시스템에서 실행되는 불필요한 애플리케이션이 없도록 하면 성능이 크게 향상됩니다.

taskset 유틸리티는 CPU 선호도에서만 작동하며 메모리 노드와 같은 다른 NUMA 리소스에 대한 지식이 없습니다. NUMA와 함께 프로세스 바인딩을 수행하려면 taskset 대신 numactl 명령을 사용합니다.

NUMA API에 대한 자세한 내용은 Andi Kleen의 백서 Linux용 NUMA API를 참조하십시오.

debugfs 파일 시스템은 디버깅 및 사용자가 정보를 사용할 수 있도록 특별히 설계되었습니다. RHEL 8에서 /sys/kernel/debug/ 디렉토리에 자동으로 마운트됩니다.

InfiniBand는 대역폭을 늘리고, QoS(Quality of Service)를 개선하고, 페일오버를 제공하는 데 자주 사용되는 통신 아키텍처의 유형입니다. RDP(Remote Direct Memory Access) 메커니즘을 사용하여 대기 시간을 개선할 수도 있습니다.

RHEL for Real Time에서 InfiniBand에 대한 지원은 Red Hat Enterprise Linux 9에서 제공되는 지원과 동일합니다. 자세한 내용은 InfiniBand 및 RDMA 네트워크 구성을 참조하십시오.

RoCEE (RDMA over Converged Enhanced Ethernet)는 이더넷 네트워크를 통해 RDMA(Remote Direct Memory Access)를 구현하는 프로토콜입니다. 이를 통해 중요한 트랜잭션을 위해 결정적이고 짧은 대기 시간 데이터 전송을 제공하는 동시에 데이터 센터에서 일관되고 고속 환경을 유지할 수 있습니다.

HPN( High Performance Networking )은 커널에 RoCEE 인터페이스를 제공하는 공유 라이브러리 집합입니다. HPN 은 독립 네트워크 인프라를 통하지 않고 표준 이더넷 인프라를 사용하여 직접 원격 시스템 메모리에 데이터를 배치하여 CPU 오버헤드를 줄이고 인프라 비용을 줄입니다.

RHEL for Real Time에서 RoCEE 및 HPN 에 대한 지원은 RHEL 8에서 제공되는 지원과 다르지 않습니다.

기본 RHEL 커널은 기본적으로 실시간 그룹 스케줄링 기능인 CONFIG_RT_GROUP_SCHED 를 활성화합니다. 그러나 실시간 커널의 경우 이 기능은 비활성화되어 있습니다.

CONFIG_RT_GROUP_SCHED 기능은 kernel-rt 패키지에 사용된 PREEMPT_RT 패치 세트와 독립적으로 개발되었으며 기본 RHEL 커널에서 실시간 프로세스에서 작동하도록 설계되었습니다. CONFIG_RT_GROUP_SCHED 기능은 대기 시간이 급증할 수 있으므로 PREEMPT_RT 지원 커널에서 비활성화됩니다. 따라서 기본 RHEL 커널에서 실행 중인 컨테이너에서 워크로드를 테스트할 때 일부 실시간 대역폭을 컨테이너에 할당하여 해당 내부에서 gRPC _FIFO 또는ECDHE _ RR 작업을 실행할 수 있습니다.

실시간 스레드는 표준 스레드보다 우선 순위가 높습니다. 정책에는 최소 값 1에서 최대 99까지의 스케줄링 우선순위 값이 있습니다.

다음 정책은 실시간에 중요합니다.

각 Cryostat_DEADLINE 작업은 마침표,런타임 및 데드라인 매개 변수로 지정됩니다. 이러한 매개변수의 값은 나노초의 정수입니다.

/etc/sysctl.conf 파일에 매개변수를 추가하여 커널 튜닝 매개변수를 영구적으로 변경할 수 있습니다.

기존 UNIX 및 POSIX 신호는 특히 오류 처리를 위해 사용되지만 실시간 애플리케이션에서 이벤트 전달 메커니즘으로 적합하지 않습니다. 이는 현재 Linux 커널 신호 처리 코드가 매우 복잡하기 때문에 주로 레거시 동작과 지원되는 많은 API로 인해 발생합니다. 이러한 복잡성은 신호를 전달할 때 걸리는 코드 경로가 항상 최적의 것은 아니며 애플리케이션에서 긴 대기 시간을 경험할 수 있음을 의미합니다.

UNIX 신호의 원래 어려움은 실행의 서로 다른 "스레드" 사이에 여러 개의 제어 스레드 (프로세스)에 있습니다. 신호는 운영 체제 인터럽트와 동일하게 작동합니다. 즉, 신호가 애플리케이션에 전달되면 애플리케이션의 컨텍스트가 저장되고 이전에 등록된 신호 처리기 실행을 시작합니다. 신호 처리기가 완료되면 애플리케이션이 신호가 전달된 시점의 실행으로 돌아갑니다. 이것은 실제로 복잡해질 수 있습니다.

신호는 실시간 애플리케이션에서 신뢰할 수 없을 만큼 결정적이지 않습니다. 더 나은 옵션은 POSIX 스레드(pthreads)를 사용하여 워크로드를 배포하고 다양한 구성 요소 간에 통신하는 것입니다. pthreads 메커니즘, 조건 변수 및 장벽을 사용하여 스레드 그룹을 조정할 수 있습니다. 이러한 비교적 새로운 구성을 통한 코드 경로는 신호의 기존 처리 코드보다 훨씬 더 명확합니다.

sched_yield 명령은 더 낮은 우선 순위 스레드를 실행할 기회를 허용할 수 있는 동기화 메커니즘입니다. 이러한 유형의 요청은 잘못 작성된 애플리케이션 내에서 발행된 경우 오류가 발생하기 쉽습니다.

우선 순위가 높은 스레드는 sched_yield() 를 호출하여 다른 스레드가 실행될 기회를 허용할 수 있습니다. 호출 프로세스가 해당 우선 순위에서 실행되는 프로세스 대기열의 tail으로 이동합니다. 동일한 우선 순위에서 다른 프로세스가 실행되지 않는 경우 호출 프로세스가 계속 실행됩니다. 해당 프로세스의 우선 순위가 높은 경우 사용 중인 루프를 만들어 머신을 사용할 수 없게 될 수 있습니다.

CloudEvent _DEADLINE 작업이 sched_yield() 를 호출하면 구성된 CPU를 제공하며 나머지 런타임은 다음 기간까지 즉시 제한됩니다. sched_yield() 동작을 사용하면 다음 기간이 시작될 때 작업을 시작할 수 있습니다.

스케줄러는 실제로 실행을 기다리는 다른 스레드가 있는 시기를 더 잘 확인할 수 있습니다. 모든 실시간 작업에 sched_yield() 를 사용하지 않도록 합니다.

systemd 명령을 사용하여 부팅 프로세스 중에 시작된 서비스의 실시간 우선 순위를 설정할 수 있습니다. 이 내용은 부팅 시 서비스의 우선 순위를 변경하는 데 설명되어 있습니다.

해당 프로세스에서 지정된 예에서 일부 커널 스레드는 매우 높은 우선 순위를 지정할 수 있습니다. 이를 통해 기본 우선순위는 RTSJ( Real Time Specification for Java )의 요구 사항과 원활하게 통합될 수 있습니다. RTSJ 에는 10에서 89까지 다양한 우선순위가 필요합니다.

RTSJ가 사용되지 않는 배포의 경우 애플리케이션에서 사용할 수 있는 90 미만의 스케줄링 우선순위가 광범위한 것입니다. 필수 시스템 서비스가 실행되지 않도록 할 수 있으므로 우선 순위 49를 초과하는 애플리케이션 스레드를 예약할 때는 시스템 서비스가 실행되지 않도록 할 수 있습니다. 이로 인해 차단된 네트워크 트래픽, 차단된 가상 메모리 페이징 및 파일 시스템 저널링 차단으로 인한 데이터 손상 등 예기치 않은 동작이 발생할 수 있습니다.

애플리케이션 스레드가 우선 순위 89 위에 예약된 경우 스레드가 매우 짧은 코드 경로만 실행해야 합니다. 그러지 않으면 RHEL for Real Time 커널의 짧은 대기 시간이 부족해질 수 있습니다.

실시간 애플리케이션을 개발할 때 프로그램 실행 중에 결정적이지 않은 대기 시간을 방지하기 위해 시작시 기호를 해결하는 것이 좋습니다. 시작 시 기호를 해결하면 프로그램 초기화 속도가 느려질 수 있습니다.

동적 링커/로 LD_BIND_NOW 변수를 ld.so 로 설정하여 애플리케이션 시작 시 동적 라이브러리가 로드되도록 지시할 수 있습니다.

예를 들어 다음 쉘 스크립트는 값이 1인 LD_BIND_NOW 변수를 내보낸 다음 스케줄러 정책 FIFO 및 우선 순위 1 을 사용하여 프로그램을 실행합니다.

#!/bin/sh

LD_BIND_NOW=1
export LD_BIND_NOW

chrt --fifo 1 _/opt/myapp/myapp-server &_

BIOS 전원 관리 옵션은 시스템 클럭 빈도를 변경하거나 CPU를 다양한 수면 상태에 배치하여 전원을 저장하는 데 도움이 됩니다. 이러한 작업은 시스템이 외부 이벤트에 얼마나 빨리 응답하는지에 영향을 미칠 수 있습니다.

응답 시간을 개선하기 위해 BIOS에서 모든 전원 관리 옵션을 비활성화합니다.

EDAC(Error Detection and Correction) 장치는 ECC(Error Correcting Code) 메모리에서 신호된 오류를 탐지하고 수정하는 장치입니다. 일반적으로 EDAC 옵션 범위는 ECC가 없는 경우 모든 메모리 노드의 주기적으로 검사에서 오류를 검사합니다. EDAC 수준이 높을수록 BIOS에서 사용하는 시간이 늘어납니다. 이로 인해 중요한 이벤트 기한이 누락될 수 있습니다.

응답 시간을 개선하기 위해 EDAC를 끄십시오. 이 작업을 수행할 수 없는 경우 EDAC를 가장 낮은 기능 수준으로 구성합니다.

SMI(System Management Interrupts)는 시스템이 올바르게 작동하는지 확인하기 위한 하드웨어 공급업체입니다. BIOS 코드는 일반적으로 SMI 인터럽트를 서비스합니다. SMI는 일반적으로 열 관리, 원격 콘솔 관리(IPMI), EDAC 점검 및 기타 다양한 하우스키핑 작업에 사용됩니다.

BIOS에 SMI 옵션이 포함되어 있는 경우 공급 업체 및 관련 문서를 확인하여 비활성화가 안전한 정도를 확인합니다.

하드웨어 아키텍처 또는 BIOS/EFI 펌웨어가 도입한 대기 시간을 찾고 있기 때문에 hwlatdetect 프로그램을 실행하는 동안 시스템에서 부하를 실행할 필요가 없습니다. hwlatdetect 의 기본값은 초당 0.5초 동안 폴링하고 연속 호출 간에 10마이크로초보다 큰 간격을 보고하여 시간을 가져오는 것입니다. hwlatdetect 는 시스템에서 가능한 최대 대기 시간을 반환합니다.

따라서 최대 대기 시간 값이 10us 미만이고 hwlatdetect 가 간격 중 하나를 20us로 보고하는 애플리케이션이 있는 경우 시스템은 20us의 대기 시간만 보장할 수 있습니다.

하드웨어 대기 시간 탐지기(hwlatdetect)는 추적기 메커니즘을 사용하여 하드웨어 아키텍처 또는 BIOS/EFI 펌웨어가 도입한 대기 시간을 감지합니다. hwlatdetect 에서 측정한 대기 시간을 확인하여 RHEL for Real Time 커널을 지원하는 데 잠재적인 하드웨어가 적합한지 확인할 수 있습니다.

적합한 hardware-firmware 조합을 찾은 후 다음 단계는 로드 중에 시스템의 실시간 성능을 테스트하는 것입니다.

rteval 유틸리티를 실행하여 부하에서 시스템 실시간 성능을 테스트할 수 있습니다.

다음은 R teval 보고서의 예입니다.

System:
Statistics:
	Samples:           1440463955
	Mean:              4.40624790712us
	Median:            0.0us
	Mode:              4us
	Range:             54us
	Min:               2us
	Max:               56us
	Mean Absolute Dev: 1.0776661507us
	Std.dev:           1.81821060672us

CPU core 0       Priority: 95
Statistics:
	Samples:           36011847
	Mean:              5.46434910711us
	Median:            4us
	Mode:              4us
	Range:             38us
	Min:               2us
	Max:               40us
	Mean Absolute Dev: 2.13785341159us
	Std.dev:           3.50155558554us

보고서에는 시스템 하드웨어에 대한 세부 정보, 실행 기간, 사용된 옵션, 타이밍 결과(cpu 및 시스템 전체)가 포함됩니다.

실시간으로 taskset 명령은 실행 중인 프로세스의 CPU 선호도를 설정하거나 검색하는 데 도움이 됩니다. taskset 명령은 -p 및 -c 옵션을 사용합니다. -p 또는 --pid 옵션은 기존 프로세스를 작동하며 새 작업을 시작하지 않습니다. -c 또는 --cpu-list 는 비트마스크 대신 숫자 프로세서 목록을 지정합니다. 이 목록에는 둘 이상의 항목을 쉼표로 구분하여 포함할 수 있으며 다양한 프로세서가 포함될 수 있습니다. 예: 0,5,7,9-11

real-time sched_setaffinity() 시스템 호출을 사용하여 프로세서 선호도를 설정할 수도 있습니다.

실시간 cpusets 메커니즘을 사용하여 gRPC _DEADLINE 작업의 CPU 및 메모리 노드 집합을 할당할 수 있습니다. 높은 CPU를 활용하는 작업을 포함하는 작업 세트에서 높은 사용률 작업을 실행하고 높은 사용률 작업을 실행하도록 CPU를 분리하고 다양한 CPU 세트에서 작은 사용률 작업을 예약하면 모든 작업이 할당된 런타임 을 충족할 수 있습니다.

일반적인 대기 시간 급증 소스는 커널 타이머 틱 처리기의 공통 잠금에 여러 CPU가 충돌하는 경우입니다. 경합을 담당하는 일반적인 잠금은 xtime_lock 이며 시간 유지 시스템과 RCU(Read-Copy-Update) 구조 잠금에서 사용됩니다. skew_tick=1 을 사용하면 CPU당 타이머 눈금을 다른 시간에 시작하도록 오프셋하고 잠재적인 잠금 충돌을 방지할 수 있습니다.

skew_tick 커널 명령줄 매개 변수는 대규모 core-count가 있는 대규모 시스템에서 대규모 시스템에 대한 대기 시간이 변동되고 대기 시간에 민감한 워크로드가 있을 수 있습니다.

pcscd 데몬은 병렬 통신(PC 또는 PCMCIA) 및 스마트 카드(SC) 리더에 대한 연결을 관리합니다. pcscd 는 일반적으로 우선 순위가 낮은 작업이지만 다른 데몬보다 더 많은 CPU를 사용할 수 있습니다. 따라서, 추가 배경 노이즈는 더 높은 선점 비용을 실시간 작업 및 결정론에 대한 기타 바람직하지 않은 영향을 유발할 수 있습니다.

mlock() 및 mlockall() 시스템 호출은 지정된 메모리 범위를 잠그고 이 메모리를 페이징하지 않습니다. 다음은 mlock() 시스템 호출 그룹입니다.

mlock() 시스템 호출, 주소 범위의 페이지 잠금은 addr 에서 시작하여 len 바이트를 계속합니다. 호출이 성공적으로 반환되면 지정된 주소 범위의 일부가 포함된 모든 페이지는 나중에 잠금 해제할 때까지 메모리에 유지됩니다.

mlockall() 시스템 호출을 사용하면 매핑된 모든 페이지를 지정된 주소 범위로 잠글 수 있습니다. 메모리 잠금은 스택이 아닙니다. 여러 호출에 의해 잠긴 모든 페이지는 지정된 주소 범위 또는 단일 munlock() 시스템 호출을 사용하여 전체 영역의 잠금을 해제합니다. munlockall() 시스템 호출을 사용하면 전체 프로그램 공간을 잠금 해제할 수 있습니다.

특정 범위에 포함된 페이지의 상태는 플래그 인수의 값에 따라 다릅니다. flags 인수는 0 또는 MLOCK_ONFAULT 일 수 있습니다.

메모리 잠금은 포크를 통해 하위 프로세스에서 상속되지 않으며 프로세스가 종료될 때 자동으로 제거됩니다.

실시간 mlock() 시스템 호출은 addr 매개변수를 사용하여 주소 범위의 시작을 지정하고 len 을 사용하여 주소 공간의 길이를 바이트 단위로 정의합니다. alloc_workbuf() 함수는 메모리 버퍼를 동적으로 할당하고 잠급니다. 메모리 할당은 메모리 영역을 페이지에 정렬하기 위해 posix_memalig() 함수에 의해 수행됩니다. free_workbuf() 함수는 메모리 영역을 잠금 해제합니다.

mlockall() 및 munlockall() 시스템 호출을 사용하여 실시간 메모리를 잠금 및 잠금 해제하려면 플래그 인수를 0 또는 MCL_ECDHERRENT 또는 MCL_ FUTURE 중 하나로 설정합니다. MCL_FUTURE 를 사용하면 mmap2(), sbrk2() 또는 malloc3() 와 같은 향후 시스템 호출이 실패할 수 있습니다. 이로 인해 잠긴 바이트 수가 허용되는 최대를 초과할 수 있기 때문입니다.

실시간 시스템에서 대용량 메모리 할당의 경우malloc(메모리 할당) 방법은 mmap() 시스템 호출을 사용하여 메모리 공간을 찾습니다. flags 매개변수에서 MAP_LOCKED 를 설정하여 메모리 영역을 할당하고 잠글 수 있습니다. mmap() 은 페이지를 기준으로 메모리를 할당하므로 동일한 페이지에서 두 개의 잠금을 방지하여 이중 잠금 또는 단일 잠금 문제가 발생하지 않습니다.

다음 표에는 mlock() 매개변수가 나열되어 있습니다.

추적 시스템의 curret_tracer 파일에 timerlat 를 추가하여 timerlat 추적기를 구성할 수 있습니다. current_tracer 파일은 일반적으로 /sys/kernel/tracing 디렉토리에 마운트됩니다. timerlat 추적기에서 인터럽트 요청(IRQ)을 측정하고 스레드 대기 시간이 100마이크로초를 초과하면 분석을 위해 추적 출력을 저장합니다.

timerlat tracer는 osnoise tracer 위에 구축됩니다. 따라서 /osnoise/config 디렉터리의 옵션을 설정하여 스레드 스케줄링 대기 시간에 대한 정보를 추적 및 캡처할 수 있습니다.

rtla-timerlat-top tracer는 timerlat 추적기에서 정기적인 출력 요약을 표시합니다. 추적기 출력은 또한 각 운영 체제의 노이즈 및 이벤트(예: osnoise ) 및 tracepoints 에 대한 정보를 제공합니다. 이 정보는 -t 옵션을 사용하여 볼 수 있습니다.

rtla timerlat top --help 명령을 사용하면 rtla-timerlat-top tracer 옵션에 대한 도움말 사용법을 볼 수 있습니다.

Linux 커널에는 운영 체제 노이즈(osnoise) 추적기용 인터페이스를 제공하는 실시간 분석(rtla) 툴이 포함되어 있습니다. rtla-osnoise tracer는 지정된 기간 동안 주기적으로 실행되는 스레드를 생성합니다. 마침표가 시작될 때 스레드는 인터럽트를 비활성화하고 샘플링을 시작하고 루프의 시간을 캡처합니다.At the start of a period, the thread disables interrupts, starts sampling, and captures the time in a loop.

rtla-osnoise tracer는 다음과 같은 기능을 제공합니다.

rtla-osnoise 추적기에서는 기간 종료 시 노이즈 소스에 대한 다음 정보가 포함된 실행 보고서를 출력합니다.

추적 시스템의 curret_tracer 파일에 osnoise 를 추가하여 rtla-osnoise tracer를 구성할 수 있습니다. current_tracer 파일은 일반적으로 /sys/kernel/tracing/ 디렉토리에 마운트됩니다. rtla-osnoise tracer는 인터럽트 요청(IRQ)을 측정하고 단일 노이즈 발생을 위해 스레드 대기 시간이 20마이크로초를 초과하면 분석을 위한 추적 출력을 저장합니다.

rtla-osnoise tracer의 구성 옵션은 /sys/kernel/tracing/ 디렉터리에서 사용할 수 있습니다.

rtla-osnoise 에는 운영 체제 노이즈의 소스(osnoise)를 식별하는 일련의 추적 지점이 포함되어 있습니다.

osnoise/options 파일에는 rtla-osnoise tracer 에 대한 설정 및 해제 설정 옵션이 포함되어 있습니다.

rtla osnoise-top tracer는 유해 소스의 발생 카운터에 대한 정보와 함께 osnoise 추적기의 주기적인 요약을 측정하고 출력합니다.

rtla osnoise top --help 명령을 사용하면 rtla-osnoise-top tracer에 사용 가능한 옵션에서 도움말 사용량을 볼 수 있습니다.

atime 특성을 비활성화하면 성능이 향상되고 파일 시스템 저널에 대한 쓰기 횟수를 제한하여 전원 사용량이 감소합니다.

Teletype (tty) 기본 커널 콘솔을 사용하면 입력 데이터를 시스템에 전달하고 그래픽 콘솔에 대한 출력 정보를 표시하여 시스템과 상호 작용할 수 있습니다.

그래픽 콘솔을 구성하지 않고 그래픽 어댑터에 로깅하지 못하도록 합니다. 이렇게 하면 시스템에서 tty0 을 사용할 수 없으며 그래픽 콘솔에서 메시지 인쇄를 비활성화하는 데 도움이 됩니다.

/proc/sys/kernel/printk 파일에서 필요한 로그 수준을 구성하여 그래픽 콘솔에 전송되는 출력 메시지의 양을 제어할 수 있습니다.

NUMA(Non-Uniform Memory Access) 및 SMP(Symmetric Multiprocessing)와 같은 다중 프로세서 시스템에서 발견된 여러 클럭 소스 인스턴스는 CPU 빈도 스케일링 또는 에너지 충돌 모드 입력과 같은 시스템 이벤트에 반응하는 방식으로 실시간 커널에 적합한 클럭 소스를 결정합니다.

기본 클럭 소스는 TSC(Time Stamp CloudEvent)입니다. TSC를 사용할 수 없는 경우 HPET(High Precision Event Timer)가 두 번째 최선의 옵션입니다. 그러나 모든 시스템에 HPET 시계가 있는 것은 아니며 일부 HPET 시계는 신뢰할 수 없습니다.

TSC 및 HPET가 없는 경우 다른 옵션에는 ACPI Power Management Timer(ACPI_PM), PIT(Programmable Interval Timer) 및 RTC(Real Time Clock)가 포함됩니다. 마지막 두 가지 옵션은 읽기 비용이 많이 들거나 낮은 해상도(시간 세분성)이므로 실시간 커널과 함께 사용할 수 있는 하위 선택 사항입니다.

시스템에서 사용 가능한 클럭 소스 목록은 /sys/devices/system/clocksource/clocksource0/available_clocksource 파일에 있습니다.

시스템에서 현재 사용되는 클럭 소스는 /sys/devices/system/clocksource/clocksource0/current_clocksource 파일에 저장됩니다.

때때로 시계의 알려진 문제로 인해 시스템의 주요 애플리케이션에 대한 최상의 시계가 사용되지 않는 경우가 있습니다. 문제가 있는 모든 시계를 제거한 후 실시간 시스템의 최소 요구사항을 충족할 수 없는 하드웨어 시계를 사용할 수 있습니다.

중요한 애플리케이션에 대한 요구 사항은 시스템마다 다릅니다. 따라서 각 애플리케이션에 가장 적합한 시계와 결과적으로 각 시스템도 달라집니다. 일부 애플리케이션은 클럭 해상도에 따라 다르며 안정적인 나노초 수치를 제공하는 시계가 더 적합할 수 있습니다. 시계를 너무 자주 읽는 애플리케이션은 읽기 비용이 적게 드는 시계의 이점을 누릴 수 있습니다(읽음 요청과 결과 사이의 시간).

이러한 경우 재정의의 부작용을 이해하고 지정된 하드웨어 클록의 알려진 단점을 트리거하지 않는 환경을 생성할 수 있는 경우 커널에서 선택한 시계를 재정의할 수 있습니다.

시스템의 시계 속도를 비교할 수 있습니다. TSC에서 읽는 것은 프로세서에서 레지스터를 읽는 것과 관련이 있습니다. HPET 시계에서 읽는 것은 메모리 영역을 읽는 것입니다. TSC에서 읽는 것이 더 빠르기 때문에 초당 수십만 개의 메시지를 타임스탬프할 때 상당한 성능 이점을 제공합니다.

현재 AMD64 Opteron 프로세서의 현재 생성은 대규모 gettimeofday skew에 취약할 수 있습니다. 이 스큐는 cpufreq 및 TSC( Time Stamp Forwarded)를 모두 사용할 때 발생합니다. RHEL for Real Time은 모든 프로세서가 동일한 빈도로 동시에 변경되는 것을 방지할 수 있는 방법을 제공합니다. 결과적으로 단일 프로세서의 TSC는 다른 프로세서의 TSC와 다른 속도로 증가하지 않습니다.

clock_timing 프로그램은 현재 시계 소스를 10만 번 읽습니다. 시간 유틸리티와 함께 이 작업을 수행하는 데 필요한 시간을 측정합니다.

최신 프로세서는 낮은 상태에서 더 높은 전력 절약 상태 (C-states)로 적극적으로 전환합니다. 슬프게도 높은 절전 상태에서 실행 상태로 전환하면 실시간 애플리케이션에 가장 적합한 것보다 더 많은 시간이 걸릴 수 있습니다. 이러한 전환을 방지하기 위해 애플리케이션은 PM QoS(Power Management Quality of Service) 인터페이스를 사용할 수 있습니다.

PM QoS 인터페이스를 사용하면 시스템은 idle=poll 및 processor.max_cstate=1 매개변수의 동작을 에뮬레이션할 수 있지만 전원 절약 상태를 보다 세밀하게 제어할 수 있습니다. idle=poll 은 프로세서가 유휴 상태로 전환되지 않습니다. processor.max_cstate=1 은 프로세서가 더 깊은 C 상태(energy-saving 모드)를 입력하지 못하도록 합니다.

애플리케이션에 /dev/cpu_dma_latency 파일이 열려 있으면 PM QoS 인터페이스에서 프로세서가 깊은 절전 상태를 입력하지 못하도록 하여 종료 시 예기치 않은 대기 시간이 발생합니다. 파일이 닫히면 시스템은 절전 상태로 돌아갑니다.

전원 관리 상태를 구성하여 전원 관리 전환을 제어할 수 있습니다. 보다 구체적으로는 /dev/cpu_dma_latency 파일에 값을 작성하여 프로세스의 최대 응답 시간을 마이크로초 단위로 변경할 수 있습니다. 또는 애플리케이션 또는 스크립트에서 이 파일을 참조할 수 있습니다.

다른 전용 CPU의 사용자 프로세스에서 인터럽트(IRQ)를 격리하면 실시간 환경에서 대기 시간을 최소화하거나 제거할 수 있습니다.

인터럽트는 일반적으로 CPU 간에 균등하게 공유됩니다. 이렇게 하면 CPU가 새 데이터 및 명령 캐시를 작성해야 하는 경우 인터럽트 처리가 지연될 수 있습니다. 이러한 인터럽트 지연으로 인해 동일한 CPU에서 다른 처리가 실행될 수 있습니다.

시간이 중요한 인터럽트 및 프로세스를 특정 CPU(또는 CPU 범위)에 할당할 수 있습니다. 이러한 방식으로 이 인터럽트를 처리하는 코드 및 데이터 구조는 프로세서 및 명령 캐시에 있을 가능성이 높습니다. 결과적으로 전용 프로세스는 가능한 한 빨리 실행될 수 있지만 다른 모든 비시간 크리티컬 프로세스는 다른 CPU에서 실행됩니다. 이는 관련된 속도가 메모리의 제한 또는 메모리의 제한과 사용 가능한 경미한 버스 대역폭에 특히 중요할 수 있습니다. 메모리가 프로세서 캐시로 가져오기를 기다릴 경우 전체 처리 시간과 결정성에 큰 영향을 미칩니다.

실제로 최적의 성능은 전적으로 애플리케이션에 따라 다릅니다. 예를 들어 다른 회사에서 유사한 기능을 가진 애플리케이션을 튜닝하려면 완전히 다른 최적의 성능 튜닝이 필요했습니다.

irqbalance 데몬은 기본적으로 활성화되어 있으며 주기적으로 CPU에서 인터럽트를 처리하는 방식으로 강제 처리됩니다. 그러나 실시간 배포에서는 애플리케이션이 일반적으로 특정 CPU에 바인딩되므로 irqbalance 가 필요하지 않습니다.

IRQ 밸런싱 서비스를 사용하여 인터럽트(IRQ) 밸런싱에서 제외할 CPU를 지정할 수 있습니다. /etc/sysconfig/irqbalance 구성 파일의 IRQBALANCE_BANNED_CPUS 매개변수는 이러한 설정을 제어합니다. 매개 변수의 값은 64비트 16진수 비트 마스크이며 마스크의 각 비트는 CPU 코어를 나타냅니다.

CPU 선호도를 할당하면 프로세스 및 스레드를 지정된 CPU 또는 CPU 범위에 바인딩 및 바인딩 해제할 수 있습니다. 이렇게 하면 캐싱 문제를 줄일 수 있습니다.

taskset 유틸리티는 작업의 PID(프로세스 ID)를 사용하여 CPU 선호도를 보거나 설정합니다. 유틸리티를 사용하여 선택한 CPU 선호도로 명령을 실행할 수 있습니다.

선호도를 설정하려면 CPU 마스크를 10진수 또는 16진수로 가져와야 합니다. mask 인수는 수정 중인 명령 또는 PID에 적합한 CPU 코어를 지정하는 비트 마스크 입니다.

/proc/sys/vm/panic_on_oom 파일에는 OOM(Out of Memory) 동작을 제어하는 스위치인 값이 포함되어 있습니다. 파일에 1 개가 포함된 경우 커널은 OOM에 패닉 상태가 되고 예상대로 작동하지 않습니다.

기본값은 0 입니다. 이는 시스템이 OOM 상태에 있을 때 커널이 oom_killer() 함수를 호출하도록 지시합니다. 일반적으로 oom_killer() 는 불필요한 프로세스를 종료하므로 시스템이 유지될 수 있습니다.

/proc/sys/vm/panic_on_oom 의 값을 변경할 수 있습니다.

oom_killer() 함수로 종료되는 프로세스의 우선 순위를 지정할 수 있습니다. 이렇게 하면 OOM 상태 중에 우선 순위가 높은 프로세스가 계속 실행되도록 할 수 있습니다. 각 프로세스에는 디렉토리인 /proc/PID 가 있습니다. 각 디렉터리에는 다음 파일이 포함됩니다.

메모리 부족 상태에서 oom_killer() 함수는 oom_score 가장 높은 프로세스를 종료합니다.

프로세스에 대한 oom_adj 파일을 편집하여 종료할 프로세스의 우선 순위를 지정할 수 있습니다.

oom_killer() 를 예약된 값 -17 로 설정하여 프로세스에 대해 oom_ killer() 함수를 비활성화할 수 있습니다. 이렇게 하면 프로세스가 OOM 상태인 경우에도 계속 유지됩니다.

tuna CLI(명령줄 인터페이스)는 시스템을 변경하는 데 도움이 되는 도구입니다.

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

이제 tuna CLI에 명령 세트가 있으며 이전에는 작업 옵션이었습니다. 이러한 명령은 다음과 같습니다.

tuna -h 명령을 사용하여 명령을 볼 수 있습니다. 각 명령에는 tuna <command> -h 명령으로 볼 수 있는 선택적 인수가 있습니다. 예를 들어 tuna isolate -h 명령을 사용하면 isolate 에 대한 옵션을 볼 수 있습니다.

tuna CLI를 사용하여 여러 전용 CPU의 사용자 프로세스에서 인터럽트(IRQ)를 분리하여 실시간 환경에서 대기 시간을 최소화할 수 있습니다. CPU 분리에 대한 자세한 내용은 Interrupt 및 프로세스 바인딩 을 참조하십시오.

tuna CLI를 사용하여 인터럽트(IRQ)를 전용 CPU로 이동하여 실시간 환경에서 대기 시간을 최소화하거나 제거할 수 있습니다. IRQ 이동에 대한 자세한 내용은 Interrupt 및 process binding 을 참조하십시오.

tuna CLI를 사용하여 프로세스 스케줄링 정책 및 우선 순위를 변경할 수 있습니다.

# tuna priority FIFO:1 --threads=42369,42416,43859

# tuna show_threads --threads=42369,42416,43859

스레드 우선순위는 0 (최저 우선 순위)에서 99 (최고 우선 순위) 사이의 일련의 수준을 사용하여 설정됩니다. systemd 서비스 관리자를 사용하여 커널 부팅 후 스레드의 기본 우선 순위를 변경할 수 있습니다.

systemd 를 사용하면 부팅 프로세스 중에 시작된 서비스의 실시간 우선 순위를 설정할 수 있습니다.

장치 구성 지시문은 부팅 프로세스 중에 서비스의 우선 순위를 변경하는 데 사용됩니다. 부팅 프로세스 우선 순위 변경은 /etc/systemd/system/service .system.d/priority.conf의서비스 섹션에 있는 다음 지시문을 사용하여 수행됩니다.

systemd 를 사용하여 서비스를 실행할 수 있는 CPU를 지정할 수 있습니다.

:_content-type: REFERENCE

스케줄러 우선순위는 그룹에 정의되며, 일부 그룹은 특정 커널 함수로 전용됩니다.

처리량이 우선 순위인 대량의 데이터를 전송하는 시스템에서는 기본값을 사용하거나 병합을 늘리면 처리량이 증가하고 CPU에 도달한 인터럽트 수가 줄어들 수 있습니다. 신속한 네트워크 대응이 필요한 시스템의 경우, 병합을 줄이거나 비활성화하는 것이 좋습니다.

인터럽트 수를 줄이기 위해 패킷을 수집하고 패킷 컬렉션에 대해 단일 인터럽트를 생성할 수 있습니다.

# ethtool -c tun0
Coalesce parameters for tun0:
Adaptive RX: n/a  TX: n/a
stats-block-usecs: n/a
sample-interval: n/a
pkt-rate-low: n/a
pkt-rate-high: n/a

rx-usecs: n/a
rx-frames: 0
rx-usecs-irq: n/a
rx-frames-irq: n/a

tx-usecs: n/a
tx-frames: n/a
tx-usecs-irq: n/a
tx-frames-irq: n/a

rx-usecs-low: n/a
rx-frame-low: n/a
tx-usecs-low: n/a
tx-frame-low: n/a

rx-usecs-high: n/a
rx-frame-high: n/a
tx-usecs-high: n/a
tx-frame-high: n/a

CQE mode RX: n/a  TX: n/a

I/O 스위치는 종종 전체 버퍼로 인해 네트워크 데이터가 빌드되는 백업 압축의 영향을 받을 수 있습니다. pause 매개변수를 변경하고 네트워크 혼잡을 방지할 수 있습니다.

# ethtool -a enp0s31f6
Pause parameters for enp0s31f6:
Autonegotiate:	on
RX:		on
TX:		on

netstat 명령을 사용하여 네트워크 트래픽을 모니터링할 수 있습니다.

$ netstat -s
Ip:
    Forwarding: 1
    30817508 total packets received
    2927 forwarded
    0 incoming packets discarded
    30813320 incoming packets delivered
    19184491 requests sent out
    181 outgoing packets dropped
    2628 dropped because of missing route
Icmp
    29450 ICMP messages received
    213 input ICMP message failed
    ICMP input histogram:
        destination unreachable: 29431
        echo requests: 19
    10141 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 10122
        echo replies: 19
IcmpMsg:
        InType3: 29431
        InType8: 19
        OutType0: 19
        OutType3: 10122
Tcp:
    162638 active connection openings
    89 passive connection openings
    38908 failed connection attempts
    17869 connection resets received
    48 connections established
    8456952 segments received
    9323882 segments sent out
    69885 segments retransmitted
    1143 bad segments received
    56209 resets sent
Udp:
    21929780 packets received
    1319 packets to unknown port received
    712919 packet receive errors
    10134989 packets sent
    712919 receive buffer errors
    180 send buffer errors
    IgnoredMulti: 39231

trace-cmd 유틸리티는 ftrace 유틸리티에 프런트 엔드를 제공합니다.

trace-cmd 유틸리티를 사용하여 모든 ftrace 기능에 액세스할 수 있습니다.

여러 trace-cmd 예제를 제공합니다.

격리할 CPU를 선택하려면 시스템의 CPU 토폴로지를 신중하게 고려해야 합니다. 다른 사용 사례에는 다른 구성이 필요합니다.

hwloc 패키지는 lstopo-no-graphics 및 numactl 을 포함하여 CPU에 대한 정보를 얻는 데 유용한 유틸리티를 제공합니다.

CPU 격리를 위한 초기 메커니즘은 커널 부팅 명령줄에 boot 매개변수 isolcpus=cpulist 를 지정하는 것입니다. RHEL for Real Time에 이 작업을 수행하는 권장 방법은 TuneD 데몬과 tuned-profiles-realtime 패키지를 사용하는 것입니다.

nohz 및 nohz_full 매개 변수는 지정된 CPU의 활동을 수정합니다. 이러한 커널 부팅 매개변수를 활성화하려면 realtime-virtual-host,realtime-virtual-guest 또는 cpu-partitioning 의 다음 TuneD 프로필 중 하나를 사용해야 합니다.

a ECDHE_OTHER 작업이 다른 많은 작업을 생성하는 경우 모두 동일한 CPU에서 실행됩니다. 마이그레이션 작업 또는 softirq 는 유휴 상태의 CPU에서 실행할 수 있도록 이러한 작업의 균형을 맞추려고 합니다.

sched_nr_migrate 옵션을 조정하여 한 번에 이동할 작업 수를 지정할 수 있습니다. 실시간 작업은 마이그레이션 방법이 다르기 때문에 이 문제의 직접적인 영향을 받지 않습니다. 그러나 softirq 가 작업을 이동할 때 실행 대기열 회전이 잠기므로 인터럽트를 비활성화합니다.

이동해야 하는 작업이 많이 있는 경우 인터럽트가 비활성화된 동안 발생하므로 타이머 이벤트 또는 발생 시 동시에 발생할 수 있습니다. 이로 인해 sched_nr_migrate 가 큰 값으로 설정된 경우 실시간 작업에 심각한 대기 시간이 발생할 수 있습니다.

sched_nr_migrate 변수를 늘리면 실시간 대기 시간을 고려하여 많은 작업을 생성하는 gRPC _OTHER 스레드의 고성능이 제공됩니다.

low real-time task latency at the cost of ECDHE_OTHER task performance, value must be lowered. 기본값은 8 입니다.

TCP 타임스탬프를 끄면 TCP 성능이 저하될 수 있습니다.

타임스탬프를 생성하면 TCP 성능이 급증할 수 있습니다. TCP 타임스탬프를 비활성화하여 TCP 성능 급증을 줄일 수 있습니다. TCP 타임스탬프 생성이 TCP 성능 급증을 유발하지 않는 경우 활성화할 수 있습니다.

TCP 타임스탬프 생성 상태를 볼 수 있습니다.

rcu_nocbs 및 rcu_nocb_poll 커널 매개변수를 사용하여 RLoadBalancer 콜백을 오프로드할 수 있습니다.

하우스키핑 CPU를 할당하여 모든 RECDHE 콜백 스레드를 처리할 수 있습니다. 이렇게 하려면 tuna 명령을 사용하고 모든 RECDHE 콜백을 하우스키핑 CPU로 이동합니다.

이 작업은 CPU X 이외의 모든 CPU가 RECDHE 콜백 스레드를 처리하지 못하도록 합니다.

Ranchor 오프로드 스레드는 다른 CPU에서 RECDHE 콜백을 수행할 수 있지만 각 CPU는 해당 R ScanSetting 오프로드 스레드를 재지정해야 합니다. 이 책임에서 CPU를 줄일 수 있습니다.

ftrace 유틸리티를 사용하여 대기 시간을 추적할 수 있습니다.

다음은 /sys/kernel/debug/tracing/ 디렉토리의 기본 파일입니다.

커널 구성 방법에 따라 지정된 커널에서 일부 추적기를 사용할 수 있는 것은 아닙니다. RHEL for Real Time 커널의 경우 추적 및 디버그 커널에는 프로덕션 커널과 다른 추적기가 있습니다. 이는 추적기가 커널에 구성되어 있지만 활성 상태가 아닌 경우 일부 추적기에서 눈에 띄는 오버헤드가 있기 때문입니다. 이러한 추적자는 trace 및 debug 커널에만 활성화됩니다.

다음은 추적되는 함수 필터링을 변경하기 위한 여러 예제를 제공합니다. * 와일드카드는 단어의 시작과 끝에서 모두 사용할 수 있습니다. 예를 들면 *irq\* 는 이름에 irq 가 포함된 모든 기능을 선택합니다. 그러나 와일드카드는 단어 내에서 사용할 수 없습니다.

검색어와 와일드카드 문자를 이중 따옴표로 캡슐화하면 쉘이 현재 작업 디렉토리로 검색을 확장하지 않습니다.

POSIX는 시간 소스를 구현하고 표시하기 위한 표준입니다. 시스템의 다른 애플리케이션에 영향을 주지 않고 애플리케이션에 POSIX 시계를 할당할 수 있습니다. 이는 커널에 의해 선택되고 시스템 전체에 구현된 하드웨어 시계와 대조됩니다.

지정된 POSIX 시계를 읽는 데 사용되는 함수는 clock_gettime() 이며 < time.h>에서 정의됩니다. clock_gettime() 과 커널 카운터는 시스템 호출입니다. 사용자 프로세스에서 clock_gettime() 을 호출하는 경우 :

그러나 사용자 애플리케이션에서 커널로 컨텍스트 전환에는 CPU 비용이 발생합니다. 이 비용이 매우 낮더라도 작업이 수천 번 반복되면 누적된 비용이 애플리케이션의 전반적인 성능에 영향을 미칠 수 있습니다. 커널로 컨텍스트 전환을 피하기 위해 CLOCK_MONOTONIC_COARSE 및 CLOCK_REALTIME_COARSE POSIX 클럭에 대한 지원, 가상 동적 공유 오브젝트(VDSO) 라이브러리 기능의 형태로 클럭을 더 빠르게 읽을 수 있습니다.

_COARSE 클럭 변형 중 하나를 사용하여 clock_gettime() 에 의해 수행되는 시간 읽기는 커널 개입이 필요하지 않으며 사용자 공간에서 완전히 실행됩니다. 이로 인해 성능이 크게 향상됩니다. _COARSE 시계에 대한 시간 측정은 밀리초(ms) 해상도로, 1ms보다 작은 시간 간격은 기록되지 않습니다. POSIX 시계의 _COARSE 변형은 밀리 초 시계 해상도를 수용할 수 있는 모든 애플리케이션에 적합합니다.

다음 코드는 CLOCK_MONOTONIC_COARSE POSIX 시계와 함께 clock_gettime 함수를 사용하는 코드의 예를 보여줍니다.

#include <time.h>

main()
{
	int rc;
	long i;
	struct timespec ts;

	for(i=0; i<10000000; i++) {
		rc = clock_gettime(CLOCK_MONOTONIC_COARSE, &ts);
	}
}

위의 예제에서는 clock_gettime() 의 반환 코드를 확인하고 rc 변수 값을 확인하거나 ts 구조의 내용을 신뢰할 수 있는지 확인하는 검사를 추가하여 개선할 수 있습니다.

전송되는 모든 패킷에 대해 대기 시간이 짧은 애플리케이션은 TCP_NODELAY 옵션이 활성화된 소켓에서 실행되어야 합니다. 이렇게 하면 이벤트가 발생하는 즉시 커널에 버퍼 쓰기를 보냅니다.

애플리케이션에 논리적으로 관련된 여러 버퍼가 있고 하나의 패킷으로 전송되어야 하는 경우 다음 해결 방법 중 하나를 적용하여 성능이 저하되지 않도록 합니다.

애플리케이션의 다양한 구성 요소에 의해 논리 패킷이 커널에 빌드된 경우 소켓을 분리하여 TCP 가 즉시 누적된 논리 패킷을 보낼 수 있어야 합니다.

TCP_NODELAY 옵션은 이벤트가 발생할 때 버퍼 쓰기를 커널에 전송하며 지연은 없습니다. setsockopt() 함수를 사용하여 TCP_NODELAY 를 활성화합니다.

TCP_CORK 옵션은 소켓이 "cocorked"될 때까지 TCP 가 패킷을 전송하지 못하도록 합니다.

상호 제외(mutex) 알고리즘은 공통 리소스를 사용하여 프로세스를 동시에 방지하는 데 사용됩니다. 빠른 사용자 공간 10.0.0.1(futex)은 커널 공간으로 컨텍스트 전환을 요구하지 않고 사용자 공간 스레드가 이미 다른 스레드에 의해 보유되지 않은 경우 사용자 공간 스레드를 클레임할 수 있는 툴입니다.

표준 속성, 비공개, 비재귀, 비로버스 및 우선순위가 없는 inherited-enabled로 pthread_mutex_t 오브젝트를 초기화하면 우선순위가 적용되지 않습니다. 이 오브젝트는 pthreads API 및 RHEL for Real Time 커널에서 제공하는 ben fits를 제공하지 않습니다.

pthreads API 및 RHEL for Real Time 커널의 이점을 얻으려면 pthread_mutexattr_t 오브젝트를 만듭니다. 이 개체는 futex에 대해 정의된 특성을 저장합니다.

CloudEvent에 대한 추가 기능을 정의하려면 pthread_mutexattr_t 오브젝트를 만듭니다. 이 개체는 futex에 대해 정의된 특성을 저장합니다. 이는 항상 수행해야 하는 기본적인 안전 절차입니다.

고급 attributes에 대한 자세한 내용은 고급 attributes를 참조하십시오.

표준 속성, 비공개, 비재귀, 비로버스 및 우선순위가 없는 inherited-enabled로 pthread_mutex_t 오브젝트를 초기화하면 우선순위가 적용되지 않습니다.

다음 고급 속성을 태그 특성 개체에 저장할 수 있습니다.

10.0.0.1 특성 개체를 사용하여 만든 후에는 특성 개체를 유지하여 동일한 형식의 더 많은 device를 초기화하거나 정리할 수 있습니다.After theECDHE has been created using theECDHE attribute object, you can keep the attribute object to initialize more of the same type, or you can clean it up. 두 경우 모두 영향을 받지 않습니다.

perf record 명령은 시스템 전체 통계를 수집하는 데 사용됩니다. 모든 프로세서에서 사용할 수 있습니다.

perf archive 명령을 사용하여 다른 시스템에서 perf 의 perf 결과를 분석할 수 있습니다. 다음의 경우 필요하지 않을 수 있습니다.

이제 perf 레코드 기능의 데이터를 perf report 명령을 사용하여 직접 조사할 수 있습니다.

하드웨어 추적 지점 활동을 가져올 수 있는 다양한 옵션이 있습니다.

perf stat 명령을 사용하여 특정 이벤트를 볼 수 있습니다.

부동 소수점 단위는 부동 소수점 연산을 수행하는 프로세서의 기능 부분입니다.A floating-point unit is the functional part of the processor that performs floating-point arithmetic operations. 부동 소수점 단위는 수치화 작업을 처리하고 부동 숫자 또는 10진수 계산을 더 간단하게 만듭니다.

--matrix-method 옵션을 사용하면 CPU 부동 소수점 작업 및 프로세서 데이터 캐시를 테스트하는 데 어려움을 겪을 수 있습니다.

stress-ng 툴은 여러 개의 stress 테스트를 실행합니다. 기본 모드에서는 지정된 stressor 메커니즘을 병렬로 실행합니다.

CPU heat 생성을 측정하기 위해 지정된 응력기는 짧은 기간 동안 높은 온도를 생성하여 최대 heat 생성 시 시스템의 번화 신뢰성과 안정성을 테스트합니다. --matrix-size 옵션을 사용하면 짧은 기간 동안 Celsius도 CPU 온도를 측정할 수 있습니다.

stress-ng 툴은 초당 bogo 작업을 측정하여 대기 테스트 처리량을 측정할 수 있습니다. bogo 작업의 크기는 강조 표시 상태에 따라 다릅니다. 테스트 결과는 정확하지 않지만 성능의 대략적인 추정치를 제공합니다.

이 측정을 정확한 벤치마크 지표로 사용해서는 안 됩니다. 이러한 추정치는 서로 다른 커널 버전 또는 과부하를 구축하는 데 사용되는 다른 컴파일러 버전에서 시스템 성능 변경 사항을 이해하는 데 도움이 됩니다. --metrics-brief 옵션을 사용하여 시스템에서 사용 가능한 전체 bogo 작업과 매트릭스 과부하 성능을 표시합니다.

메모리 부족이 있을 때 커널은 스왑에 페이지 쓰기를 시작합니다. --page-in 옵션을 사용하여 가상 메모리를 과부하시켜 비동시 페이지가 가상 메모리로 다시 스왑되도록 강제할 수 있습니다. 이로 인해 가상 시스템이 크게 실행됩니다. --page-in 옵션을 사용하면 bigheap,mmap 및 가상 머신(vm) 과부하 요인에 대해 이 모드를 활성화할 수 있습니다. --page-in 옵션, 코어가 아닌 할당된 페이지를 눌러 의 페이지로 강제 적용합니다.

높은 빈도에서 타이머 실행은 대규모 인터럽트 로드를 생성할 수 있습니다. 적절하게 선택된 타이머 주파수를 가진 -timer stressor는 초당 많은 인터럽트를 강제할 수 있습니다.

stress-ng 를 사용하면 메모리에 로드되지 않은 주요 페이지 폴트를 생성하여 페이지 폴트 속도를 테스트하고 분석할 수 있습니다. 새 커널 버전에서 userfaultfd 메커니즘은 프로세스의 가상 메모리 레이아웃에서 페이지 폴트에 대한 스레드를 찾는 오류를 알립니다.

CPU 강조 표시 테스트에는 CPU를 실행하는 방법이 포함되어 있습니다. which 옵션을 사용하여 모든 방법을 볼 수 있도록 출력을 출력할 수 있습니다.

기본적으로 테스트 방법을 지정하지 않으면 stressor는 라운드 로빈 방식으로 모든 과부하를 확인하여 각 부하에 대해 CPU를 테스트합니다.

검증 모드는 테스트가 활성화될 때 결과를 검증합니다. 테스트 실행의 메모리 콘텐츠를 확인하고 예기치 않은 오류를 보고합니다.

모든 오버로드는 확인 모드가 없으며 활성화로 인해 이 모드에서 추가 확인 단계가 실행되므로 bogo 작업 통계를 줄일 수 있습니다.

실시간 커널과 기본 RHEL 커널 모두에서 다음 옵션을 모두 사용할 수 있습니다. kernel-rt 패키지는 잠재적인 결정성을 개선하고 일반적인 문제 해결을 허용합니다.

Dockerfile로 빌드된 컨테이너를 실행할 수 있습니다.

이 예에서는 필요한 실시간 관련 옵션이 있는 podman run 명령을 보여줍니다. 예를 들면 다음과 같습니다.

chrt 유틸리티는 스케줄러 정책 및 우선순위를 확인하고 조정합니다. 원하는 속성을 사용하여 새 프로세스를 시작하거나 실행 중인 프로세스의 속성을 변경할 수 있습니다.

지정된 프로세스의 현재 스케줄링 정책 및 스케줄링 우선 순위를 표시할 수 있습니다.

실시간 프로세스는 일련의 함수를 사용하여 정책 및 우선 순위를 제어합니다. sched_getscheduler() 함수를 사용하여 지정된 프로세스에 대한 스케줄러 정책을 표시할 수 있습니다.

sched_get_priority_min() 및 sched_get_priority_max() 함수를 사용하여 지정된 스케줄러 정책에 유효한 우선순위 범위를 확인할 수 있습니다.

이제 sched_get 프로그램이 준비되었으며 저장된 디렉터리에서 실행할 수 있습니다.

ScanSetting _RR (round-robin) 정책은 10.0.0.1 _FIFO (first-in, first-out) 정책과 약간 다릅니다. gRPC_RR 은 라운드 로빈 회전에서 우선 순위가 동일한 동시 프로세스를 할당합니다. 이러한 방식으로 각 프로세스에 timeslice가 할당됩니다. sched_rr_get_interval() 함수는 각 프로세스에 할당된 timeslice를 보고합니다.

timeslice 정보는 timespec 으로 반환됩니다. 이것은 00:00:00 GMT의 기본 시간, 1970년 1월 1일 이후의 초 및 나노초 수입니다.

struct timespec {
  time_t tv_sec;  /* seconds / long tv_nsec; / nanoseconds */
};

sched_getattr() 함수는 PID로 식별되는 지정된 프로세스에 현재 적용되는 스케줄링 정책을 쿼리합니다. PID가 0이면 호출 프로세스의 정책이 검색됩니다.

size 인수는 사용자 공간에 알려진 sched_attr 구조의 크기를 반영해야 합니다. 커널은 sched_attr::size 를 sched_attr 구조의 크기로 채웁니다.

입력 구조가 작은 경우 커널은 제공된 공간 외부의 값을 반환합니다. 그 결과 시스템 호출이 E2BIG 오류와 함께 실패합니다. 다른 sched_attr 필드는 The sched_attr 구조에 설명된 대로 채워집니다.

sched_attr 구조에는 지정된 스레드에 대한 스케줄링 정책 및 관련 속성을 포함하거나 정의합니다. sched_attr 구조의 형식은 다음과 같습니다.

    struct sched_attr {
     u32 size;
     u32 sched_policy
     u64 sched_flags
     s32 sched_nice
     u32 sched_priority

     /* SCHED_DEADLINE fields */
               u64 sched_runtime
               u64 sched_deadline
               u64 sched_period
           };

deadline _DEADLINE 필드는 데드라인 예약에만 지정해야 합니다.

프로세스는 완료되면 또는 디스크의 데이터, 키 누름 또는 네트워크 패킷과 같은 이벤트를 대기 중이므로 CPU를 자발적으로 산출할 수 있습니다.

또한 프로세스는 자발적으로 CPU를 산출할 수 있습니다. 이를 선점이라고 하며 더 높은 우선 순위 프로세스에서 CPU를 사용하려는 경우 발생합니다.

선점은 시스템 성능에 특히 부정적인 영향을 미칠 수 있으며 지속적인 선점으로 인해 스래싱으로 알려진 상태가 발생할 수 있습니다. 이 문제는 프로세스가 지속적으로 선점되고 완료까지 프로세스가 실행되지 않을 때 발생합니다.

작업의 우선 순위를 변경하면 일시적인 선점을 줄이는 데 도움이 될 수 있습니다.

지정된 프로세스에 대해 자발적으로 및 자발적으로 제공하는 선점 상태를 확인할 수 있습니다. 상태는 /proc/PID/status 에 저장됩니다.

chrt 유틸리티는 스케줄러 정책 및 우선순위를 확인하고 조정합니다. 원하는 속성을 사용하여 새 프로세스를 시작하거나 실행 중인 프로세스의 속성을 변경할 수 있습니다.

chrt 유틸리티 옵션에는 명령의 프로세스 및 우선 순위를 지정하는 명령 옵션 및 매개변수가 포함되어 있습니다.

실시간 프로세스는 정책 및 우선 순위를 제어하기 위해 다른 라이브러리 호출 세트를 사용합니다. 다음 라이브러리 호출은 비실시간 프로세스의 우선 순위를 설정하는 데 사용됩니다.

이 함수는 비실시간 프로세스의 좋은 값을 조정합니다. nice 값은 프로세서에서 실행할 준비가 된 비실시간 프로세스 목록을 정렬하는 방법에 대한 스케줄러 제안의 역할을 합니다. 목록의 헤드에 있는 프로세스는 목록의 추가 감소 전에 실행됩니다.

스케줄러 정책 및 기타 매개변수는 sched_setscheduler() 함수를 사용하여 설정할 수 있습니다. 현재 실시간 정책에는 하나의 매개변수 sched_priority 가 있습니다. 이 매개변수는 프로세스의 우선 순위를 조정하는 데 사용됩니다.

sched_setscheduler() 함수에는 sched_setscheduler (sched_setscheduler,pid_t pid, int 정책, const struct sched_param *sp) 형식의 매개변수가 필요합니다.

프로세스 ID가 0이면 sched_setscheduler() 함수가 호출 프로세스에 대해 작동합니다.

다음 코드 발췌에서는 현재 프로세스의 스케줄러 정책을 10.0.0.1 _FIFO 스케줄러 정책으로 설정하고 우선순위를 50 으로 설정합니다.

struct sched_param sp = { .sched_priority = 50 };
int ret;

ret = sched_setscheduler(0, SCHED_FIFO, &sp);
if (ret == -1) {
  perror("sched_setscheduler");
  return 1;
}

sched_setparam() 함수는 특정 프로세스의 스케줄링 매개변수를 설정하는 데 사용됩니다. 그런 다음 sched_getparam() 함수를 사용하여 확인할 수 있습니다.

스케줄링 정책만 반환하는 sched_getscheduler() 함수와 달리 sched_getparam() 함수는 지정된 프로세스에 대한 모든 스케줄링 매개변수를 반환합니다.

struct sched_param sp;
int ret;

ret = sched_getparam(0, &sp);
sp.sched_priority += 2;
ret = sched_setparam(0, &sp);

이 코드가 실제 애플리케이션에서 사용된 경우 함수에서 반환 값을 확인하고 오류를 적절하게 처리해야 합니다.

sched_setattr() 함수는 PID에 지정된 인스턴스 ID에 대한 스케줄링 정책 및 관련 속성을 설정합니다. pid=0인 경우 sched_setattr() 은 호출 스레드의 프로세스 및 속성에서 작동합니다.

실시간 스케줄링 정책은 하나의 주요 특성을 공유합니다. 높은 우선 순위 스레드가 스레드 또는 스레드가 I/O를 잠급거나 수행하여 대기할 때까지 실행됩니다.

Cryostat _RR 의 경우 운영 체제는 실행 중인 스레드를 중단하여 동일한 Cryostat _RR 우선순위의 다른 스레드를 실행할 수 있도록 합니다. 이러한 경우 중 하나에서 더 낮은 우선 순위 스레드가 CPU 시간을 얻을 수 있도록 정책을 정의하는 POSIX 사양에 의해 프로비저닝이 이루어지지 않습니다. 실시간 스레드의 이러한 특성은 지정된 CPU의 100%를 단조하는 애플리케이션을 쉽게 작성할 수 있음을 의미합니다. 그러나 이로 인해 운영 체제에 문제가 발생합니다. 예를 들어 운영 체제는 시스템 전체 및 CPU별 리소스를 모두 관리하는 역할을 하며 주기적으로 이러한 리소스를 설명하는 데이터 구조를 검사하고 해당 리소스를 사용하는 하우스키핑 활동을 수행해야 합니다. 그러나 코어가 Cryostat _FIFO 스레드에 의해 단조되는 경우 하우스키핑 작업을 수행할 수 없습니다. 결국 전체 시스템이 불안정해지고 잠재적으로 충돌할 수 있습니다.

RHEL for Real Time 커널에서 인터럽트 핸들러는 hieradata _FIFO 우선 순위가 있는 스레드로 실행됩니다. 기본 우선순위는 50입니다. 인터럽트 처리기 스레드보다 높은 Cryostat _FIFO 또는 Cryostat _RR 정책이 있는 cpu-hog 스레드는 인터럽트 처리기가 실행되지 않도록 할 수 있습니다. 이로 인해 프로그램이 인터럽트에 의해 전달되는 데이터 신호를 대기하고 실패하게 됩니다.

실시간 커널에는 실시간 작업에서 사용할 대역폭을 할당할 수 있는 보호 메커니즘이 포함되어 있습니다. 보호 메커니즘을 실시간 스케줄러 제한이라고 합니다.

실시간 제한 메커니즘의 기본값은 실시간 작업에서 CPU 시간의 95%를 사용할 수 있음을 정의합니다. 나머지 5%는 Cryostat _OTHER 및 유사한 스케줄링 정책에서 실행되는 작업과 같이 실시간이 아닌 작업에 사용됩니다. 단일 실시간 작업이 95% CPU 시간 슬롯을 사용하는 경우 해당 CPU의 나머지 실시간 작업이 실행되지 않습니다. 실시간이 아닌 작업만 나머지 5%의 CPU 시간을 사용합니다. 기본값은 다음과 같은 성능에 영향을 미칠 수 있습니다.

실시간 스케줄러 제한은 /proc 파일 시스템의 다음 매개변수에 의해 제어됩니다.

스레드가 고가용성 임계값보다 긴 CPU 실행 큐에 있고 진행하지 않는 경우 발생합니다. 스레드 중단의 일반적인 원인은 CPU에 바인딩된 Cryostat _FIFO 또는 Cryostat _ RR 과 같은 고정 우선 순위의 폴링 애플리케이션을 실행하는 것입니다. 폴링 애플리케이션은 I/O를 차단하지 않으므로 kworkers 와 같은 다른 스레드가 해당 CPU에서 실행되지 않도록 할 수 있습니다.

스레드 래핑을 줄이기 위한 초기 시도는 실시간 제한으로 호출됩니다. 실시간 제한에서 각 CPU는 비 실시간 작업에 전용 실행 시간의 일부를 갖습니다. 제한의 기본 설정은 실시간 작업에 대해 CPU의 95%를 사용하고 5%는 비실시간 작업을 위해 예약되어 있습니다. 단일 실시간 작업이 있는 경우 결함이 발생하지만 CPU에 할당된 실시간 작업이 여러 개 있는 경우 작동하지 않습니다. 다음을 사용하여 문제를 해결할 수 있습니다.