스마일 서브리눅스 시스템을 운영하다 보면 시스템 Hang-up에 대한 문제점을 많이 들어나게 됩니다. 물론 리눅스 시스템
자체의 문제점이라고 보다는 특정 운영 프로세스에 대해서 인터럽트 또는 스케쥴이 정상적으로 진행되지 못했을때 나타는 문제점에 대해서 간략해 소개해 보고자 합니다.
갑자기 시스템 로그에서 출력하게된 /var/log/message 의 시스템 로그.
|
kernel: INFO: task startup.sh:9902 blocked for more than 120 seconds. |
[예상 문제점 1]
시스템 로그에서 나타난 kernel:INFO: task 의 메세지를 나타내는 의미는 현재 운영하고자 하는 startup.sh
스크립트에 대해서 120초 (2분 default) 동안 khungtaskd 쓰레드에서 D-state 상태를 감지하여 call trace
를 호출하게 되는 상황으로 예측할 수 있습니다.
[예상 문제점2]
시스템의 성능저하 특히 레드햇의 보고서에 의하면 디스크의 heavy I/O 로 나타나는 문제점으로
예측될수 있습니다.
[예상 문제점 2]
운영되고 있는 Application에 대해서 “D-state” (Uninterruptible sleep) 모드가 120초 동안 지속되었을때
예측될수 있는 문제로 해당 프로세스가 정상적으로 스케쥴링이 일어나지 않았을 때도 나타나게 됩니다
[ D-state 원인분석을 위해서는 ? ]
위와같은 문제점에 대해서 접근할수 있는 기본적인 방법에 대해서는 정확한 문제점을 파악하기 위해서는 커널의 덤프를 이용하여 core를 분석하는 것이 가장 정확할수 있습니다. core를 분석하기 위한 방법론에 대해서는 다음
블로깅을 통하여 소개하도록 하겠습니다.
|
# echo 1 > /proc/sys/kernel/hung_task_panic |
위와 같이 kernel core를 생성하기 위해 설정을 진행한 후 동일한 현생이 발생되어 core가 생성이 되면 문제가
되는 운영 프로세스의 D-state 문점에 대해서 분석이 가능합니다.
[ hung_task_timeout을 Disable 시켜라]
기본적인 Work-Arround에 대해서는 아래와 같이 hung_task_timeout 부분에 대해서 Disable 시켜주는 것을 권장하고 있습니다.
|
# echo 0 > /proc/sys/kernel/hung_task_timeout_secs |
위와 같이 커널에서 Hang Time OUt 을 체크하는 부분에 대해서 Disable 시켜준 후에는 call trace 여부가 지속적으로 발생되는지 모니터링이 필요합니다. 만약 해당 프로세스에 대해서 Uninterrupt sleep이 지속적으로 발생한다면 커널 업데이트 또한 고려해야 합니다.
[polldaddy rating=”7739789″]