☰

다시 시작이 소프트웨어로 인해 발생했는지 아니면 하드웨어로 인해 발생했는지 디버깅하는 방법은 무엇입니까?

tag-icon • tag-icon debian hardware reboot
다시 시작이 소프트웨어로 인해 발생했는지 아니면 하드웨어로 인해 발생했는지 디버깅하는 방법은 무엇입니까?

새로운 Linux debian 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012 x86_64 GNU/Linux 서버가 여러 번 재부팅되었습니다.

' last -x'출력 결과는 다음과 같습니다.

root     pts/0        192.168.254.11   Sat Dec 15 13:13   still logged in   
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 13:10 - 13:17  (00:06)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 13:10 - 13:17  (00:06)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 12:53 - 13:10  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 12:53 - 13:17  (00:23)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 12:36 - 12:53  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 12:36 - 13:17  (00:40)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 12:19 - 12:36  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 12:19 - 13:17  (00:57)    
root     pts/0        192.168.254.11   Sat Dec 15 12:04 - crash  (00:14)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 12:01 - 12:19  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 12:01 - 13:17  (01:15)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 11:44 - 12:01  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 11:44 - 13:17  (01:32)    
root     pts/0        192.168.254.11   Sat Dec 15 11:36 - crash  (00:08)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 11:26 - 11:44  (00:18)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 11:26 - 13:17  (01:50)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 11:08 - 11:26  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 11:08 - 13:17  (02:08)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 10:51 - 11:08  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 10:51 - 13:17  (02:25)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 10:34 - 10:51  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 10:34 - 13:17  (02:42)    
root     pts/0        192.168.254.11   Sat Dec 15 02:41 - crash  (07:53)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 02:32 - 10:34  (08:02)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 02:32 - 13:17  (10:45)    
runlevel (to lvl 0)   2.6.32-5-amd64   Sat Dec 15 02:12 - 02:32  (00:19)

top충돌/재시작 전 0.1초 이내에 " " 명령의 출력:

top - 15:14:04 up 16 min,  2 users,  load average: 0.00, 0.00, 0.01
Tasks: 163 total,   1 running, 162 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  8.3%sy,  0.0%ni, 91.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8191048k total,    87356k used,  8103692k free,     2432k buffers
Swap:        0k total,        0k used,        0k free,    20120k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                       
 2296 root      20   0 19072 1432 1032 R    9  0.0   0:10.25 top                                                                                                            
    1 root      20   0  8356  820  684 S    0  0.0   0:00.79 init                                                                                                           
    2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd                                                                                                       
    3 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/0                                                                                                    
    4 root      20   0     0    0    0 S    0  0.0   0:00.03 ksoftirqd/0                                                                                                    
    5 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/0                                                                                                     
    6 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/1                                                                                                    
    7 root      20   0     0    0    0 S    0  0.0   0:00.00 ksoftirqd/1                                                                                                    
    8 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/1                                                                                                     
    9 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/2

16분의 " " 출력은 다음을 Sensors보여줍니다.

temp1:       +37.0 C  (high = +60.0 C, hyst = +55.0 C)  sensor = thermistor
temp2:       +75.0 C  (high = +95.0 C, hyst = +92.0 C)  sensor = diode
temp3:       +32.0 C  (high = +75.0 C, hyst = +70.0 C)  sensor = thermistor

업데이트 #2:

  • 실행하는 동안 top문제는 일반적으로 가동 시간 16분에 발생합니다.
  • Corsair 1050HX PSU에 연결된 부하가 더 적은 경우(74개의 SATA 드라이브 대신 60개) 이 문제는 발생하지 않습니다.
  • 74개의 SATA 드라이브가 연결된 상태에서 14분에 "와트 증가 여부" 측정기가 갑자기 증가된 전력 소비를 측정하기 시작했습니다. 즉, 326와트가 아닌 435와트입니다.
  • 14분에 급격한 전력 증가는 스토리지 모듈이 커널에 로드되지 않은(/dev/sdb 등 없음) 다른 bpo.3 및 bpo.4 커널 버전에서도 발생합니다.

업데이트 #3: 하나의 부팅 드라이브를 제외한 모든 드라이브는 분할되지 않고 포맷되지 않으며 마운트 해제됩니다.

업데이트 #4: Hitachi/Toshiba HDS5C 드라이브가 더 많은 전력을 소비하기 시작하는 문제 - 읽기/쓰기 활동 없이 3.5W 대신 5.34W - cat /proc/diskstats | grep " sd"224개 섹터 읽기가 반환되므로 15분 후 더 많은 전력은 OS(소프트웨어)와 관련이 없는 것 같습니다. 시작 후 작성된 섹터 수를 합하면 0이 되며, 전력 소비가 급증하기 시작하면 이 숫자는 동일하게 유지됩니다.

문제는 이러한 재시작이 다음으로 인해 발생하는지 확인하는 방법입니다.

  • 소프트웨어
  • 하드웨어(예: 단락 조건에 대한 전원 공급 장치 과전류 보호)?

답변1

"와트 증가?"를 사용하여 시스템의 전력 소비를 더욱 자세히 모니터링하십시오. 전력계는 이러한 재시작이 전원 공급 장치의 과전류 보호(OCP) 활성화로 인해 발생한다는 확신을 더해줍니다.

시작 후 15분 후에 전력 소비가 증가한 이유를 묻는 질문에 serverfault의 대답은 시작 후 15분 후에 74개 드라이브 모두가 자동 오프라인 SMART(하드 드라이브 자체 모니터링, 분석 및 보고)를 동시에 실행하기 시작할 수 있다는 것입니다. 시간 기술) 테스트.

다음 시도는 자동 오프라인 테스트 실행을 비활성화하는 것이었습니다 smartctl --offlineauto=off /dev/sdx. 이제 전원 급증이나 재부팅 없이 20시간이 지났기 때문에 초기 결론은 주기적인 오프라인 SMART 테스트를 실행하도록 드라이브를 설정한 것이 원인이라는 것이었습니다.

답변2

첫째, 72개의 하드 드라이브는 많은 양입니다(제 가장 큰 컴퓨터에는 24개만 있고 전원 공급 장치는 1200W입니다). 엇갈린 회전을 사용하시기 바랍니다.

드라이브가 오프라인 데이터 수집을 시작하는 것을 볼 수 있습니다. 이는 전기 사용량의 증가를 설명할 수 있다. 이는 또한 실제로 드라이브를 사용하는 경우 전력 소비가 최소한 그만큼 높아질 가능성이 있음을 의미합니다.

드라이브 사양 시트에는 12V 레일에서 피크 전류가 2A로 표시되어 있습니다. 귀하의 전원 공급 장치는 12V 레일에서 87.5A를 제공할 수 있다고 주장합니다. 따라서 특히 다른 구성 요소에도 일부 값이 필요하므로 이 값을 쉽게 초과할 수 있습니다. 이러한 일이 발생하는지 확인하기 위해 해당 레일에 전압계(가능한 경우 전류계)를 설치하는 것이 좋습니다.

나는 계속해서 대답이 "예"라고 추측하겠습니다. 실행 중인 공급 장치는 드라이브 수에 비해 적습니다. 예를 들어, 우리가 사용하는 시스템 빌더는1400W 전원 공급 장치를 갖춘 45드라이버 JBOD, 더 많은 드라이브와 컴퓨터가 있습니다. 물론 이 JBOD는 15K SAS 드라이브용으로 지정될 수도 있습니다. 하지만 추가로 27개의 드라이브가 있습니다.

소프트웨어 충돌 디버깅(그렇지 않을 수도 있음)

소프트웨어 충돌을 찾으려고 할 때 가장 중요한 것은 커널 로그를 마지막 순간까지 가져오는 것입니다. 직렬 포트가 있는 경우 가장 좋은 방법은 다른 컴퓨터에 연결하고 직렬 콘솔을 사용하는 것입니다(커널 명령줄에 console=/dev/ttyS0,57600 추가). 두 번째로 좋은 방법은 netconsole을 사용하는 것입니다. 이는 시스템이 시작된 후(그러나 16분이 되기 전에) 쉽게 구성할 수 있습니다.

먼저 다른 컴퓨터에서 실행합니다 nc -l -u -p 1234. 그런 다음 항상 충돌이 발생하는 컴퓨터에서는 modprobe netconsole netconsole=@/eth0,1234@some-ip/netcat 창에 몇 가지 콘솔 메시지가 즉시 표시됩니다.

[508073.196581] console [netcon0] enabled
[508073.197026] netconsole: network logging started

물론 타임스탬프는 훨씬 낮을 것입니다.

답변3

출력 결과에 따르면 last -x17~18분마다 재부팅되는 것 같으니 먼저 재부팅하도록 설정된 스크립트나 크론이 있는지 확인해야 합니까? 그렇지 않다면 아래를 읽어보세요.

하드웨어 관련 오류를 확인하거나 서버에서 일반적으로 실행하는 특정 응용 프로그램 또는 (데비안 기반) 의 로그에서 소프트웨어 관련 로그를 찾을 dmesg | tail수 있습니다 .tail -f /var/log/messagestail -f /var/log/syslog

소프트웨어 문제인지 하드웨어 문제인지 빠르게 확인하고 싶다면 를 확인해야 합니다 top.

hi  --  Hardware IRQ
          The amount of time the CPU has been servicing hardware interrupts.

si  --  Software Interrupts
          The amount of time the CPU has been servicing software interrupts.

여기에 이미지 설명을 입력하세요.

또한 상단의 %wa 값을 확인해야 합니다. 하드 드라이브에 문제가 발생할 경우를 대비해 이 값이 증가합니다. 따라서 사용중인 도구 hdparam -T /dev/sdx및 기타 도구를 확인할 수 있습니다 . 하지만 아직 최종 단계는 아니므로 확인할 수 있는 방법은 여러 가지가 있을 수 있습니다.

답변4

CPU 온도를 확인해야 하며, 다음 명령을 사용하여 시스템 로그를 확인할 수 있습니다. - grep 'temperature' /var/log/syslog 위 명령 출력이 비어 있으면 패키지를 설치 lm-sensors하고 실행해야 하며, sudo sensors-detect모든 예/아니요 질문에 "예"를 선택합니다. 센서 감지가 끝나면 로드해야 할 모듈 목록이 표시됩니다. 센서가 /etc/modules에 삽입된 이러한 모듈을 감지하도록 하려면 "yes"를 입력하거나 /etc/modules를 직접 편집하십시오. 다음으로 sudo service module-init-tools restart이를 실행하면 3단계에서 /etc/modules에 대한 변경 사항을 읽고 새 모듈을 커널에 삽입합니다. 다음으로 lm 센서가 제대로 작동하는지 테스트해야 합니다. sensors명령을 실행 하고 가능한 사후 출력을 확인하십시오. 매번 17시에서 18시 사이에 재부팅되므로 시스템 부팅 시간 15분 후에 이 명령을 실행해야 할 것 같습니다.

관련 정보