8.6. 커널
대규모 시스템에서 시스템 부팅이 실패하는 경우가 있음
부팅 프로세스 중에 udev 장치 관리자는 대규모 시스템에 너무 많은 규칙을 생성하는 경우가 있습니다. 예를 들어 32TB 메모리와 192개의 CPU가 있는 시스템에서 문제가 발생했습니다. 결과적으로 부팅 프로세스가 응답하지 않거나 시간이 초과되고 긴급 쉘로 전환됩니다.
문제를 해결하려면 udev.3-4-max 값을 늘립니다.
-
/etc/default/grub파일의 kernel 명령줄에udev.>-<-max=1000옵션을 추가합니다.udev.knative-max의 다양한 값을 실험하여 시스템에서 가장 빠르게 부팅되는 값을 확인할 수 있습니다. kdump커널의udev.>-<-max값을 제한합니다./etc/sysconfig/kdump파일의KDUMP_COMMANDLINE_REMOVE행에udev.>-<-max옵션을 추가합니다.kdump옵션을 지정하지 않으면 IBM POWER 시스템에서kdump또는fadump캡처 후 시스템이 긴급 모드로 전환될 수 있습니다.kdump서비스를 다시 시작하십시오.# systemctl restart kdump
그 결과 시스템이 성공적으로 부팅됩니다.
(BZ#1722855)
미러 세그먼트 유형이 스택된 구성에서 시스템 교착 상태 발생
미러 세그먼트 유형의 사용량과 그 위에 논리 볼륨을 배치하면 스택된 구성에 시스템 교착 상태가 발생합니다. 이 문제를 해결하기 위해 Red Hat은 세그먼트 유형 raid1 과 함께 RAID 1 논리 볼륨을 사용하는 것이 좋습니다.
미러 장치를 변환을 참조하십시오.
raid1 로 변환하려면 미러링 된 LVM 장치를 RAID1 장치로
(BZ#1772107)
zlib 압축 형식으로 인해 vmcore 캡처가 느려질 수 있습니다.
kdump 구성 파일은 기본적으로 lovn 압축 형식 (makedumpfile -l)을 사용합니다. zlib 압축 형식(makedumpfile -c)을 사용하도록 구성 파일을 수정하면 vmcore 캡처 프로세스의 속도가 느려집니다. 그 결과 zlib 를 lECDHE에 비해 사용할 때 vmcore를 캡처하는 데 . 따라서 속도가 주요 구동 요인인 경우 Red Hat은 기본 kdump 가 약 4배 더 걸릴 수 있습니다l ovn을 사용하는 것이 좋습니다. 그러나 대상 머신이 사용 가능한 공간인 경우 zlib 가 더 나은 옵션입니다.
(BZ#1737111)
아이러니 드라이버를 사용하는 Intel 네트워크 장치는 bridge-over-VLAN 토폴로지를 사용할 때 트래픽을 전달하지 않습니다.
이더넷 장치는 ICMP(Internet Control Message Protocol) 에코 요청을 전송하지 않으며 다음 조건이 모두 충족되는 경우 트래픽을 응답하지 않습니다.
-
이더넷 장치는
아이스Intel 드라이버를 사용합니다. - 이더넷 장치는 브리지의 멤버입니다.
- 브릿지는 802.1Q 프로토콜에 따라 VLAN 태그 지정을 사용합니다.
결과적으로 NIC(Network Interface Controller)는 설명된 네트워크 토폴로지에 대한 트래픽을 전달하지 않습니다. 이 문제에 대한 해결방법이 없습니다.
(BZ#1787295)
