11.7. 커널
커널 페이지 크기에 따라 종속 항목이 있는 고객 애플리케이션은 4k에서 64k 페이지 크기 커널로 이동할 때 업데이트해야 할 수 있습니다.
RHEL은 4k 및 64k 페이지 크기 커널과 호환됩니다. 4k 커널 페이지 크기에 종속된 고객 애플리케이션은 4k에서 64k 페이지 크기 커널로 이동할 때 업데이트해야 할 수 있습니다. 알려진 인스턴스에는 jemalloc 및 종속 애플리케이션이 포함됩니다.
jemalloc 메모리 al Cryostat 라이브러리는 시스템의 런타임 환경에서 사용되는 페이지 크기에 민감합니다. 라이브러리는 4k 및 64k 페이지 크기 커널(예: --with-lg-page=16 또는 env JEMALLOC_SYS_WITH_LG_PAGE=16 )과 호환되도록 빌드할 수 있습니다. 결과적으로 런타임 환경의 페이지 크기와 jemalloc 에 의존하는 바이너리를 컴파일할 때 존재하는 페이지 크기 간에 불일치가 발생할 수 있습니다. 결과적으로 jemalloc기반 애플리케이션을 사용하면 다음 오류가 트리거됩니다.
<jemalloc>: Unsupported system page size
이 문제를 방지하려면 다음 방법 중 하나를 사용하십시오.
- 적절한 빌드 구성 또는 환경 옵션을 사용하여 4k 및 64k 페이지 크기 호환 바이너리를 생성합니다.
-
최종 64k 커널 및 런타임 환경으로 부팅한 후
jemalloc을 사용하는 사용자 공간 패키지를 빌드합니다.
예를 들어, Rust 패키지 관리자와 함께 jemalloc 도 사용하는 fd-find 툴을 빌드할 수 있습니다. 최종 64k 환경에서 다음을 입력하여 모든 종속 항목의 새 빌드를 트리거하여 페이지 크기의 불일치를 해결합니다.
# cargo install fd-find --force
Bugzilla:2167783[1]
dnf 를 사용하여 최신 실시간 커널로 업그레이드해도 여러 커널 버전이 병렬로 설치되지 않음
dnf 패키지 관리자를 사용하여 최신 실시간 커널을 설치하려면 패키지 종속성을 확인해야 새 커널 버전과 현재 커널 버전을 동시에 유지해야 합니다. 기본적으로 dnf 는 업그레이드 중에 이전 kernel-rt 패키지를 제거합니다.
이 문제를 해결하려면 /etc/yum.conf 구성 파일의 installonlypkgs 옵션에 현재 kernel-rt 패키지를 추가합니다(예: installonlypkgs=kernel-rt ).
installonlypkgs 옵션은 dnf 에서 사용하는 기본 목록에 kernel-rt 를 추가합니다. installonlypkgs 지시문에 나열된 패키지는 자동으로 제거되지 않으므로 동시에 설치할 여러 커널 버전을 지원합니다.
여러 커널이 설치되어 있는 것은 새 커널 버전으로 작업할 때 대체 옵션을 사용하는 방법입니다.
Bugzilla:2181571[1]
지연 계정 기능은 기본적으로 SWAPIN 및 IO% 통계 열을 표시하지 않습니다.
초기 버전과 달리 지연된 계정 기능은 기본적으로 비활성화되어 있습니다. 결과적으로 iotop 애플리케이션에 SWAPIN 및 IO% 통계 열이 표시되지 않고 다음 경고가 표시됩니다.
CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO%
작업stats 인터페이스를 사용하여 스레드 그룹에 속하는 모든 작업 또는 스레드에 대한 지연 통계를 제공합니다. 작업 실행 지연은 커널 리소스가 제공될 때까지 기다립니다(예: 사용 가능한 CPU가 실행될 때까지 기다리는 작업). 작업의 CPU 우선 순위, I/O 우선 순위 및 rss 제한 값을 적절하게 설정하는 데 도움이 됩니다.
이 문제를 해결하려면 런타임 또는 부팅 시 delayacct 부팅 옵션을 활성화할 수 있습니다.
런타임에
delayacct를 활성화하려면 다음을 입력합니다.echo 1 > /proc/sys/kernel/task_delayacct
이 명령은 기능 시스템 전체 기능을 활성화하지만 이 명령을 실행한 후에 시작하는 작업에만 적용됩니다.
부팅 시
지연을영구적으로 활성화하려면 다음 절차 중 하나를 사용합니다./etc/sysctl.conf파일을 편집하여 기본 매개변수를 재정의합니다./etc/sysctl.conf파일에 다음 항목을 추가합니다.kernel.task_delayacct = 1
자세한 내용은 Red Hat Enterprise Linux에서 sysctl 변수를 설정하는 방법을 참조하십시오.
- 변경 사항을 적용하려면 시스템을 재부팅합니다.
커널 명령줄에
delayacct옵션을 추가합니다.자세한 내용은 커널 명령줄 매개변수 구성을 참조하십시오.
결과적으로 iotop 애플리케이션에 SWAPIN 및 IO% 통계 열이 표시됩니다.
Bugzilla:2132480[1]
코어가 큰 시스템에서 실시간 커널의 하드웨어 인증으로 skew-tick=1 부팅 매개변수를 전달해야 할 수 있습니다.
다수의 소켓과 대규모 코어 개수가 있는 대규모 또는 중간 규모의 시스템은 시간 보관 시스템에 사용되는 xtime_lock 의 잠금 경합으로 인해 대기 시간이 급증할 수 있습니다. 결과적으로 멀티프로세싱 시스템에서 대기 시간이 급증하고 하드웨어 인증 지연이 발생할 수 있습니다. 이 문제를 해결하려면 skew_tick=1 부팅 매개변수를 추가하여 CPU당 타이머 눈금을 다른 시간에 시작할 수 있습니다.
잠금 충돌을 방지하려면 skew_tick=1 을 활성화합니다.
grubby를 사용하여skew_tick=1매개변수를 활성화합니다.# grubby --update-kernel=ALL --args="skew_tick=1"
- 변경 사항을 적용하려면 재부팅하십시오.
부팅 중에 전달하는 커널 매개변수를 표시하여 새 설정을 확인합니다.
cat /proc/cmdline
skew_tick=1 을 활성화하면 전력 소비가 크게 증가하므로 대기 시간에 민감한 실시간 워크로드를 실행하는 경우에만 활성화해야 합니다.
Jira:RHEL-9318[1]
kdump 메커니즘이 LUKS 암호화 대상에서 vmcore 파일을 캡처하지 못했습니다
Linux 통합 키 설정(LUKS) 암호화된 파티션이 있는 시스템에서 kdump 를 실행하는 경우 시스템에 특정 양의 사용 가능한 메모리가 필요합니다. 사용 가능한 메모리가 필요한 메모리 양보다 작으면 systemd-cryptsetup 서비스가 파티션을 마운트하지 못합니다. 결과적으로 두 번째 커널은 LUKS 암호화 대상에서 크래시 덤프 파일을 캡처하지 못합니다.
이 문제를 해결하려면 Recommended crashkernel 값을 쿼리하고 메모리 크기를 적절한 값으로 점진적으로 늘립니다. Recommended crashkernel 값은 필요한 메모리 크기를 설정하는 참조 역할을 할 수 있습니다.
추정된 크래시 커널 값을 출력합니다.
# kdumpctl estimate
crashkernel값을 늘려 필요한 메모리 양을 구성합니다.# grubby --args=crashkernel=652M --update-kernel=ALL
변경 사항을 적용하려면 시스템을 재부팅합니다.
# reboot
결과적으로 kdump 는 LUKS 암호화 파티션이 있는 시스템에서 올바르게 작동합니다.
Jira:RHEL-11196[1]
kdump 서비스가 IBM Z 시스템에서 initrd 파일을 빌드하지 못했습니다
64비트 IBM Z 시스템에서 s390-subchannels 와 같은 znet 관련 구성 정보가 비활성 NetworkManager 연결 프로필에 있는 경우 kdump 서비스가 초기 RAM 디스크(initrd)를 로드하지 못합니다. 결과적으로 kdump 메커니즘이 다음 오류와 함께 실패합니다.
dracut: Failed to set up znet kdump: mkdumprd: failed to make kdump initrd
이 문제를 해결하려면 다음 솔루션 중 하나를 사용하십시오.
znet구성 정보가 있는 연결 프로필을 다시 사용하여 네트워크 본딩 또는 브리지를 구성합니다.$ nmcli connection modify enc600 master bond0 slave-type bond
비활성 연결 프로필에서 활성 연결 프로필에
znet구성 정보를 복사합니다.nmcli명령을 실행하여NetworkManager연결 프로필을 쿼리합니다.# nmcli connection show NAME UUID TYPE Device bridge-br0 ed391a43-bdea-4170-b8a2 bridge br0 bridge-slave-enc600 caf7f770-1e55-4126-a2f4 ethernet enc600 enc600 bc293b8d-ef1e-45f6-bad1 ethernet --
비활성 연결의 구성 정보로 활성 프로필을 업데이트합니다.
#!/bin/bash inactive_connection=enc600 active_connection=bridge-slave-enc600 for name in nettype subchannels options; do field=802-3-ethernet.s390-$name val=$(nmcli --get-values "$field"connection show "$inactive_connection") nmcli connection modify "$active_connection" "$field" $val" done
변경 사항을 적용하려면
kdump서비스를 다시 시작하십시오.# kdumpctl restart
kmod 의 약한 모듈이 모듈 상호 의존과 함께 작동하지 않음
kmod 패키지에서 제공하는 weak-modules 스크립트는 설치된 커널과 kABI와 호환되는 모듈을 결정합니다. 그러나 모듈의 커널 호환성을 확인하는 동안 약한 모듈은 빌드된 커널의 상위 릴리스에서 더 낮은 릴리스까지 종속성을 기호화합니다. 결과적으로 다른 커널 릴리스에 빌드된 상호 종속 관계가 있는 모듈은 호환되지 않는 것으로 해석될 수 있으므로 이 시나리오에서는 weak-modules 스크립트가 작동하지 않을 수 있습니다.
이 문제를 해결하려면 새 커널을 설치하기 전에 최신 커널에 대해 추가 모듈을 빌드하거나 배치하십시오.
Bugzilla:2103605[1]
Intel® i40e 어댑터가 IBM Power10에서 영구적으로 실패합니다.
IBM Power10 시스템에서 i40e 어댑터가 I/O 오류가 발생하면EEH(Enhanced I/O Error Handling) 커널 서비스가 네트워크 드라이버의 재설정 및 복구를 트리거합니다. 그러나 EEH는 i40e 드라이버가 사전 정의된 최대 EEH 정지에 도달할 때까지 I/O 오류를 반복적으로 보고합니다. 결과적으로 EEH로 인해 장치가 영구적으로 실패합니다.
Jira:RHEL-15404[1]
dkms 는 64비트 ARM CPU에서 올바르게 컴파일된 드라이버를 사용하여 프로그램 오류에 대한 잘못된 경고를 제공합니다.
동적 커널 모듈 지원(dkms) 유틸리티는 64비트 ARM CPU의 커널 헤더가 4 킬로바이트 및 64 킬로바이트 페이지 크기가 있는 커널 모두에서 작동하는지 인식하지 못합니다. 결과적으로 커널 업데이트가 수행되고 kernel-64k-devel 패키지가 설치되지 않은 경우 dkms 는 프로그램이 올바르게 컴파일된 드라이버에서 실패한 이유에 대한 잘못된 경고를 제공합니다. 이 문제를 해결하려면 두 가지 유형의 ARM CPU 아키텍처에 대한 헤더 파일이 포함된 kernel-headers 패키지를 설치하고 dkms 및 해당 요구 사항에 국한되지 않습니다.
Jira:RHEL-25967[1]
