CPU 와 메모리 문제 해결  |  |
|
Linux의 안정성에 대한 명성은 가히 전설적이다. 그러나 가장 안정성 있는 운영체제라고 해도 하드웨어에 결함이 있거나 구성이 잘못되면 Linux의 안정성도 유익이 되지 못한다. 이 글에서 Daniel Robbins는 CPU 플레이킹(flaking) 현상을 진단하고 결함을 고치는 방법과 RAM테스트 방법에 대해서 설명한다. Linux를 사용하고 있는 사용자들이라면 하드웨어 문제를 경험했을 것이다. 대부분 각자가 선호하는 Linux 배포판을 설치하고 추가 애플리케이션을 컴파일 했을 것이다. 모든 것이 완벽한 것 같지만 나중에 새 시스템에서 심각한 하드웨어 버그를 발견했던 경험이 있을 것이다. 그 증상이 무작위 분절화 결함(segmentation faults), 데이터 손상, 하드 록(hard locks) 또는 데이터 유실과 같이 하드웨어에 이상이 생긴다면 Linux를 효율적이고 신뢰성 있게 유지할 수 없다. 이 글은 CPU및 RAM의 플레이킹 현상을 발견하는 방법을 상세히 설명한다. 따라서 사전에 하드웨어의 결함 부분을 교체하여 손상을 예방하고자 한다. 불안정성의 원인이 하드웨어와 관련이 있다는 의심이 들었다면 CPU와 메모리의 작동 여부를 테스트할 것을 권장한다. 설사 이런 불안정 문제를 겪고 있지 않더라도 CPU와 메모리 테스트를 수행하는 것은 나쁘지 않은 생각이다. 그렇게 되면 하드웨어 문제를 미리 파악하여 다급한 시기에 문제가 발생해도 데이터 손실이나 근본적인 원인을 몰라 당황하며 많은 시간을 허비하지 않아도 되기 때문이다. 시스템이 테스트를 통과했다면 그 시스템은 표준 이상이니까 안심을 해도 된다. 결함이 많은 CPU를 가지고 있다면 머신은 Linux를 부팅할 수 없거나 몇분 동안 실행하다가 잠금 현상(locking up)이 발생할 수 있다. 이런 소모된 상태의 CPU는 징후가 명백하니까 결함을 진단하기는 쉽다. 그러나 좀 미세한 CPU 결함은 그렇게 쉽게 발견할 수 없다. 일반적으로 발견하기 어려운 모호한 오류의 경우 머신이 종종 이유없이 멈추거나 갑자기 프로세스를 중단되는 것을 말한다. 대부분 불안정한 CPU는 "exercise"에 의해 촉발될 수 있다. 즉 과중한 작업 부담으로 가열되어 CPU작동이 약화된다. 몇 가지 CPU 스트레스 테스트 방법에 대해 살펴보자. CPU 안정성에 대한 최대의 테스트 중 하나는 Linux 내장 방법 즉 커널 컴파일이라고 하면 아마 매우 놀랄 것이다. gcc 컴파일러는 일반적 CPU 안정성을 위한 우수한 툴이며 커널 빌드에 많이 사용된다. /usr/src/linux 디렉토리에서 다음의 스크립트를 작성하고 실행하여 머신에 고성능 커널 컴파일 스트레스 테스트를 할 수 있다: cpubuild 스크립트
이 스크립트가 머신으로 하여금 커널을 반복 컴파일 하도록 하는 것을 발견할 것이다. 이유는 간단하다. 어떤 CPU는 간헐적으로 고장이 일어난다. 정확히 시간의 95%를 커널 컴파일 하는데 소모하면서도 가끔 커널 컴파일을 강제적으로 실행 중단시킨다. 대개 그 이유는 5 개 이상의 커널 컴파일 하면 프로세서가 불안정한 상태가 될 정도로 가열되기 때문이다. 상기 스크립트에서 -j옵션을 연속되는 다음 숫자(사용자 일반 시스템의 CPU 숫자)보다 1 이상 크도록 조정해야 한다. 다시 말하면 이중 프로세서 용 "3", 단일 프로세서 용 "2" 등을 사용한다. -j옵션은 make에게 지시하여 make가 커널을 병렬로 구축하여 각 소스 파일이 컴파일 된 다음에 적어도 항상 gcc 프로세스가 준비되게 하여 CPU 스트레스도 최대화 시킨다. Linux 박스가 오후 동안 사용하지 못해도 지장이 없다면 상기 스크립트를 실행하고 머신이 수 시간 동안 커널을 컴파일 시킨다.
만약 스크립트가 몇 시간 순조롭게 작동된다면 축하한다. 사용자 CPU는 첫 번째 테스트 관문을 통과한 것이다. 그러나 상기 스크립트가 갑자기 멈출 가능성이 있다. 그런데 그 원인이 다른 게 아니고 바로 CPU 문제 때문이라는 것을 어떻게 알 수 있을까? gcc가 이런 오류를 유발한 경우는 대개 CPU 결함일 가능성이 높다:
CPU 상태 시점에 대한 세 가지의 가능성은 다음과 같다:
로드가 많아 CPU가 간헐적 오류를 겪고 있다면 전혀 CPU에는 결함이 없거나 아니면 단순히 CPU의 열이 적당하게 식지 않아서 발생된 것일 가능성이 높다. 다음은 CPU점검 사항을 나열한 것이다:
모든 것이 이상이 없다면 케이스를 열어 놓고 커널 컴파일 테스트를 해도 좋다. 커널 컴파일이 약 5분간 작동하고 나서 작동 중인 머신 안에 손을 집어넣어 전원 공급 금속 케이스 바깥 쪽을 접촉하여 신체가 접지가 되도록 한다. 그리고 나서 히트 싱크의 온도를 손가락 끝으로 조심스럽게 테스트하라. 히트 싱크가 예외로 고온이라면 히트 싱크/팬 콤보가 특정 CPU에 적합하지 않을 가능성이 크다. 이런 경우 시스템의 쿨링(cooling) 하드웨어를 업그레이드해라. 아마 CPU는 영구적 손상까지는 입지는 않았으며 아직 양호할 것으로 판단된다.
CPU 안정성 테스트에는 커널 컴파일 테스트가 좋은 방법이다. 그러나 원하는 경우 극단적 CPU 테스트도 사용 가능하다. 이 테스트를 마지막으로 남겨둔 이유는 CPU가 아주 차가운 상태에서 이 특정 테스트를 하게 되면 CPU가 과열되어 이론적으로는 CPU에 영구적인 손상을 유발할 수 있기 때문이다. 이 테스트는 커널 컴파일 테스트를 문제없이 통과할 수 있는 시스템, 즉 가장 도전적인 CPU 로드까지도 쉽게 처리할 수 있는 시스템 용으로 적합하게 설계되었다. CPU가 적절하게 식어지면 이 테스트를 통과한 것이고 그렇지 못한 경우 CPU 쿨링 시스템 보완이 필요하다. 극단적 CPU 테스트 수행을 위한 첫 번째로 일은 Lm_sensors 페이지(참고자료참조)로 가서 lm_sensors 페이지를 다운로드 한 것이다. 이 소스 tarball은 거의 모든 마더보드에 내장된 건강(health) 모니터 기능과 상호작용 하는 다양한 커널 모듈을 포함하고 있다. 일단 이 패키지가 올바르게 설치되고 적당한 모듈(prog/detect/sensors_detect 스트립트를 이용하여 알아낸다) 로드 된 경우에는 새로운 파일과 디렉토리가 /proc/sys/dev/sensors에 나타나는 것을 보게 될 것이다. 이 파일은 CPU 팬의 속도, 모두 실시간으로 갱신되는 CPU와 메인 보드 온도 표시 등의 필요한 정보를 포함한다. 이 패키지 구성으로 모듈을 컴파일하고 sensors_detect 스크립트로 어떤 모듈을 부팅 시 로드 여부에 대해 파악할 것을 권장한다. 개인적으로 이 구성을 사용하여 좋은 결과를 거두었다. 일단 lm_sensors 모듈이 로드 한 경우 /proc/sys/dev/sensors에 있는 "cat" 파일에 반복적으로 의존하지 않고서도 CPU 로드와 온도를 실시간으로 볼 수 있도록 해주는 그래픽 CPU/sensors 모니터 설치를 권장한다. 이런 목적을 위해 gkrellm(참고자료 참조)라는 작지만 우수한 프로그램을 사용한다. 다음은 CPU 사용법, 마더보드 온도 설정 및 기타 여러 사항을 모니터하는 gkrellm app의 스냅샷이다: gkrellm 실행 중임  기타 lm_sensors와 호환 가능한 그래픽 모니터링 패키지가 사용 가능하다. 이런 일단의 패키지는 "links" 섹션에 있는 lm_sensors 홈 페이지에 나열되어 있으니 참고 바란다. 마지막 예비 단계는 cpuburn 프로그램을 다운로드 하는 것이다. (참고자료 참조) 이 작고 편리한 프로그램은 특정 CPU에 수동적 머신 지시 조합을 사용하여 반복적인 커널 컴파일보다 좀더 많은 최대의 스트레스를 준다. 아카이브에는 P5, P6 클래스 프로세서 설정에 맞춘 여러 작은 프로그램 및 AMDK6 용 특별 버전이 포함되어 있다. 일단 cpuburn tarball을 해체하면(unpacked) README 파일을 읽는다. README 파일은 푼 파일 중에 포함되어 있는 어셈블리와 소스파일을 컴파일 하는 방법을 설명한다. 이 작업이 끝나면 사용자 고유의 작은 cpuburn 프로그램을 갖게 될 것이다. 테스트를 위해 대개 그래픽 센서 모니터를 가동한 다음 cpuburn 프로그램을 루트로서 시작한다. 그리고 나서 CPU 온도 표시가 상승하다가 안정되는 것을 살펴본다. 그리고 나서 cpuburn을 1시간 정도 실행한다. 이런 단계를 반복하여 CPU 온도가 이상적으로 계속 높은 온도로 상승하면(화씨 160도 정도는 비정상적인 높은 온도로 간주됨) CPU 쿨링 시스템을 크게 손질할 필요가 있을 것이다. 사용자의 머신이 충돌(crash) 및 잠금 현상(lock up)이 일어나는 경우 또는 cpuburn 프로세스가 작동 중단(dies)되면, CPU 쿨링 시스템을 개선해야 한다. 아니면 특정한 CPU가 단지 "spec" 미달일 수 도 있다. CPU 온도 표시를 이용하여 판단을 내릴 수 있다. 그러나 만약 모든 것이 제대로 작동되면 여러분 시스템은 어떤 도전도 처리할 수 있으므로 1시간 정도 후에 가서 cpuburn 프로그램을 종료하고 정상 운영을 재개하라.
완전히 신뢰할 수 있는 CPU 포함이 정말 중요하고 그것 못지않게 견고한RAM 칩을 갖는 것도 중요하다. 혹자는 SIMMS와 DIMMS는 결코 실패하는 경우가 없어 테스트할 필요도 없다고 생각할 수도 있다. 불행하게도 이는 사실이 아니다. 불량한 메모리는 매우 흔한 현상이며 모두 경계해야 한다. 또 다른 사용자는 불량 RAM이 있어도 어떤 RAM 오류도 BIOS 메모리 검사에 의해 발견될 수 있다고 믿는다. 이것 또한 잘못이다. BIOS 메모리 검사는 불량한 RAM의 대다수를 발견하지 못한다. 따라서 BIOS 검사로 인해 보안에 대한 잘못된 인식을 갖지 않도록 주의하라.
불량 RAM이 있고 지금 누군가가 여러분의 머신에 앉아있다고 하자. 다음은 사용자의 컴퓨터가 불량 RAM을 포함하고 있다고 표시하는 주의 신호이다:
이 같은 문제를 겪고 있다면 사용자 시스템의 RAM이 결함이 있을 가능성이 높다. 다음 메소드를 사용하여 RAM 테스트를 해야 할 것이다. 이런 문제를 겪고 있지 않더라도 장래 예기치 못한 RAM 이상 현상(quirks) 발생으로 곤란을 겪지 않도록 시스템에서 RAM을 검사하는 것도 좋은 생각이다. memtest86
그 다음 2.5" 공 디스크를 플로피 디스크 드라이브에 삽입하고 아래 사항을 입력한다:
몇 초가 지나면 3.5" 디스크에는 멋지면서 작은 부팅 가능한 메모리 테스터 그 안에 생긴다. 이 테스트를 수행하는 가장 좋은 방법은 머신이 적어도 6시간은 천천히 작동할 수 있도록 시간을 내는 것이다. 즉 수면 또는 퇴근 시간을 이용해서 테스트를 시작하는 것이 좋다. 테스트를 시작하기 위해 3.5" 디스크를 드라이브에 넣고 머신을 재부팅 하라. 시스템이 부팅되면 memtest86 프로그램은 즉시 시작한다: 사용자 자체 개발 머신에서 RAM 테스트하고 있는 memtest86  "dead" 조각 같은 중요 메모리 이상 현상은 몇 초 내에 발견된다. 불행하게도 흔히 발생되는 특정한 조각 형태에 의해 유발된 실패는 몇 시간이 걸려도 발견되지 않을 수 있다. 물론 결국에는 발견되겠지만 말이다. memtest86이 결함 있는 조각을 발견하면 즉시 스크린 하단에 메시지가 나타나면서 테스트를 계속한다. 아침에 모니터를 키면 테스트가 종료되었다는 것을 알게 되고 스크린에 주의 표시가 사용자의 RAM은 이상이 없는 것이다. 그러나 여러분의 RAM이 "불량한 메모리 증상" 섹션 리스트에 계속 나열되면 RAM은 가끔 발생하는 이상 현상 증상이 있는 것으로 교체할 필요가 있다.
사용자의 RAM이 원활하게 작동되기를 바란다. 그러나 불행히도 RAM 이상을 겪는 부류에 속해도 전부를 잃은 것은 아니다. 불량 RAM을 고칠 가능성이 있다. 첫째로 BIOS 설치 프로그램을 방문하여 사용자의 메모리 설정을 확인하라. 어떤 BIOS 설정 프로그램에는 "Turbo Mode"라는 메모리 옵션이 있다. 만약 분명히 이와 유사한 것을 사용 가능 상태로 설정한다면 사용 불가로 설정해야 한다. BIOS 메모리 타이밍 부정확 할 가능성도 있다. 타이밍 설정은 조정할 수 있으며(refresh 율 증가 또는 CAS 설정 낮추는 것) memtest86을 재실행하여 문제가 해결되는지 확인할 수 있다. 여전히 memtest가 오류를 발견할 경우, 사용자의 머신에서 SIMM 또는 DIMM이 잘못되었는지(faulty) 검색해야 한다. 사용자가 메모리 모듈을 1개 이상 설치했다면 단일 모듈을 설치하고자 할 것인데 (또는 SIMMS를 가진 경우에는 두 개 모듈) 그렇다면 memtest86을 실행한다. 모든 모듈을 순환(cycle)해 본다. 그러면 어느 것이 결함이 있는지 판단할 수 있다. 좋은 메모리 모듈을 쓰레기 통에 버릴 필요는 없는 것이다 🙂 다음에는 IRQ와 PCI 잠복 문제를 포함한 하드웨어 구성과 관련 문제를 수정하는 방법에 대해 살펴 보겠다. 그 동안 다음 참고자료를 숙지하기를 권한다. |
