CentOS가 설치된 32GB 비 ECC RAM 전용 서버가 있습니다.
하루에 한 번 /var/log/kern.log, /var/log/messages, mysql, apache에서 오류 없이 무작위로 충돌합니다.
CPU/RAM/IO는 특별히 높지도 낮지도 않습니다.
"이제 ECC 비용을 지불할 시간입니다"라는 결론을 내릴 수 있는 CentOS 어딘가에 기록된 오류가 있습니까?
답변1
무엇을 기록하시겠습니까? CentOS는 비ECC 메모리의 내용이 손상되었음을 알 수 없습니다. 왜냐하면 알 수 없기 때문입니다. 기억의 내용이 의미가 없다는 것만 알 수 있고, 자기 불일치가 발견되면 당황할 수밖에 없습니다. 이러한 불일치는 RAM 손상으로 인해 발생할 수도 있지만 커널 버그나 다른 원인으로 인해 발생할 수도 있습니다.
메모리가 손상되었는지 확실하게 알 수 있는 유일한 방법은 그러한 손상 검사 지원을 명시적으로 포함하는 메모리를 사용하는 것입니다. 즉, ECC 메모리입니다.
편집하다: 질문하신 내용과는 전혀 다른 질문입니다. 그러나 내 전략은 다음과 같습니다. memtest86+하드웨어에서 실행하여 쉽게 포착할 수 있는 반복 가능한 오류가 있는지 확인하고 syslog서버에서 원격 ging을 활성화합니다(커널 패닉이 발생하면 종종 FS에 쓰기가 중지되지만 여전히 압박할 수 있음). NIC의 로그 메시지), 다음 패닉 시 기록된 내용을 확인합니다.
답변2
ECC 메모리에는 두 가지 장점이 있습니다.
- 이는 등록되어 있습니다. 이는 칩의 다른 구성요소 앞에 레지스터가 있음을 의미합니다. 이는 메모리 컨트롤러에서 전기적 부하를 제거하기 위한 것입니다. 이는 ECC RAM뿐만 아니라 모든 RDIMM에 해당됩니다.
- 오류를 감지할 수 있으며 오류를 복구할 수 없는 경우 최소한 오류가 발생했음을 보고합니다.
이를 감안할 때 ECC 램이 없어도 ECC 램의 이점을 누릴 수 있는지 여부를 판단하는 것은 실제로 매우 어렵습니다. 정의에 따르면 오류 감지 실패를 기록할 수 없으며 발생했을 수도 있고 발생하지 않았을 수도 있는 오류가 메모리 컨트롤러 문제의 결과인지 여부에 대한 데이터가 확실히 없습니다.
즉, memtest를 실행하면 몇 가지 사항을 결정하게 됩니다. 오류가 발견되지 않으면 ECC RAM이 필요하거나 문제가 다른 것에 있는 것입니다. 따라서 하드웨어와 소프트웨어의 모든 부분을 원인으로 배제한다면 ECC RAM이 필요하다는 의미입니다. 지속적인 오류가 발견되면 RAM이 불량이므로 교체해야 할 가능성이 있습니다. 일관되지 않은 오류가 발견되면 CPU가 불량이거나 ECC RAM이 필요할 수 있습니다. memtest86이 충돌하는 경우 가장 낮은 순서의 DIMM이 불량이거나 CPU가 불량이거나 ECC RAM이 필요한 것입니다.
그럼에도 불구하고 이것은 확실히 보여주기가 매우 까다롭습니다. ECC RAM은 눈에 보이지 않는 계산 오류로 인해 심각한 문제가 발생할 가능성이 있는 애플리케이션이나 RAM의 양이 다른 조건과 결합되어 통계적으로 오류가 발생할 가능성이 있는 애플리케이션에서 가장 유용합니다. 그러나 이러한 기준 자체는 모호하고 주관적이므로 이에 대한 객관적인 기준은 실제로 존재하지 않는다는 결론이 나옵니다.
답변3
어디에 있다면 아마 로그인할 것입니다.
/var/log/mcelog
(여기서 RHEL 품종에 대한 중요한 CPU 이벤트가 발생합니다)