CentOS 7의 kdump

kdump커널 크래시 덤프 메커니즘입니다. 시스템이 충돌하면 kdump커널 충돌 덤프가 생성되어 추가 분석에 사용될 수 있습니다. 오류의 심각도에 따라 이 크래시 덤프가 추가 분석에 사용할 수 있는 유일한 정보일 수 있습니다.

이는 시스템이 충돌할 경우 시스템 호출을 kdump사용하여 두 번째 커널을 메모리에 로드함으로써 작동합니다. kexec두 번째 커널은 첫 번째 커널 메모리의 내용을 캡처합니다. 이 정보는 크래시 덤프로 저장됩니다.

두 번째 커널을 메모리에 로드하려면 시스템 메모리의 일부를 이를 위해 영구적으로 예약해야 합니다. 첫 번째 코어는 이 메모리 영역에 액세스할 수 없습니다. 예약된 메모리 양은 시스템 아키텍처와 시스템에 설치된 총 메모리 양에 따라 다릅니다. 예를 들어 x86_64이 아키텍처와 설치된 메모리가 2GiB인 시스템에는 최소 163968KiB(160.25MiB)가 필요합니다 kdump.

kdump(대부분의) 신규 설치의 경우 RHEL 7(및 확장에 따라 CentOS 7)에는 이 메커니즘이 기본적으로 설치되고 활성화됩니다. Anaconda 설치 프로그램은 제한된 구성 옵션을 제공합니다 kdump. 다른 설치 옵션(예: Kickstart)은 기본적으로 활성화되지 않을 수 있습니다 kdump.

자세한 내용(설치, 구성, 사용법)은 kdump커널 관리에 대한 RHEL 7 설명서를 참조하세요.커널 크래시 덤프 가이드

kdump커널 충돌 시 커널 메모리를 덤프합니다. 그래서

1. 커널이 충돌하지 않으면 kdump를 안전하게 비활성화할 수 있습니다

2. 커널 충돌에 신경쓰지 않는다면 kdump를 비활성화하는 것이 안전합니다.

3. 지원 계약이 없고 커널 충돌을 직접 디버깅하는 데 필요한 지식이 없으며 커널 충돌을 진단하기 위해 누군가에게 일회성 비용을 지불할 의사가 없는 경우 kdump를 비활성화하는 것이 안전합니다.

그렇지 않으면 활성화된 상태로 유지됩니다.

대부분의 사람들에게는 (1)이 맞습니다. 나머지는 (2)나 (3)이 맞을 수도 있습니다. 임베디드 Linux를 사용하여 고가치 장치를 만드는 경우 kdump는 매우 유용할 수 있습니다.

kdump는 커널 충돌 디버깅을 위해 특별히 설계되었습니다. 이를 활성화하면 한 가지 큰 단점이 있는데, 이는 많은 메모리를 차지한다는 것입니다. 예를 들어, 2GB RAM이 있는 시스템에서는 RAM의 8% 미만을 사용합니다. RAM은 서버 성능을 제한하는 요소인 경우가 많기 때문에 대부분의 사용자에게 "가장 약한 링크"에 도달하므로 이로 인해 심각한 피해가 발생할 수 있습니다. RAM이 영향을 받는 것 외에는 단점이 없습니다.

제 질문은: 커널 충돌을 디버깅해야 합니까?입니다.

CentOS와 Rocky Linux 및 AlmaLinux와 같은 최신 클론은 물론 상용 버전인 Red Hat Enterprise Linux도 프로덕션 환경의 안정성을 위해 선택되는 경우가 많습니다. 19년 이상 프로덕션 서버를 운영하면서 CentOS나 어떤 프로덕션 서버에서도 커널 패닉을 경험한 적이 없습니다. 심지어 "덜 안정적인" 배포판을 실행하는 서버에서도 마찬가지입니다.

실험적인 드라이버나 데스크톱 시스템용 설정을 사용하여 자체 커널을 컴파일할 때, 그리고 Gentoo나 LFS와 같은 "최첨단" Linux 시스템을 사용할 때만 커널 패닉을 경험했습니다. 이러한 경우에 나는 내가 겪고 있는 상황을 알고 kdump가 활성화되어 있는지 확인합니다. 그곳에서도 사고는 거의 발생하지 않습니다. 저는 프로덕션 서버용으로 많은 사용자 정의 커널을 컴파일했는데 그 중 어느 것도 충돌한 적이 없습니다.

프로덕션 서버를 실행하는 대다수의 사람들은 kdump를 비활성화하기를 원할 것입니다. CentOS나 상대적으로 안정적인 배포판을 사용하고 자체 커널을 컴파일하지 않는 경우 이 기능을 비활성화하십시오. 자신의 커널을 컴파일하는 일부 사람들은 자신이 사용하는 설정에 확신이 있다면 커널을 비활성화하기를 원할 수도 있습니다.