::: Dragon Tail :::

본 글은 스스로에게 어디까지 기술력을 보유해야 한다고 생각하는 건지 자문하는 글로써,
정리되지 않던 글들은 다시 정리하여 공개합니다. 문제가 되는 부분들은 언제든지 얘기해 주십시오.

말 그대로, 시스템 엔지니어로써 갖춰야 할 기술력은 어느정도일까??

2월 3일부터 모 사이트에서 발생한 장애로 인하여, 2월 한달 내내 사람이 살듯 살고있지 못했다. ㅠㅠ

가상화 위에 올라가 있던 RHEL3 (kernel 2.4 smp - 16G) 시스템이 아무런 이유 없이 Hang up 에 빠진것.

우리측의 초기 대처는 일단 전반적인 시스템 메시지 및 로그를 살펴 보는 것..

메시지는 갑자기 파워오프된 서버들에서 흔히 볼 수 있게, 특별한 메시지 없이 뚝 떨어져 있다가,

restart 되는 것들만 있었고, sar 데이타 역시 특별한 이상유무를 찾을 수 없을 정도로

자원 상황은 원할한 상황이였다.
( 특별한 로그가 없이 죽으면 정말 난감할 수 밖에 없다 )

가상화 측 분석 요청도 한 상태였는데, 가상화측에서는 아무런 메시지가 남겨져 있는게 없다는 말...

결국 발칵 뒤집혀 지기 시작했다. OS 측의 문제인 것 아니냐는 식으로 몰려가기 시작한다.

sar 데이타는 디폴트 10분이기 때문에 물론 정확하지 않다는게 맞는 말이긴 하지만,

이 상황에서 장애 원인을 찾기란 힘든 상황이었다.

고객이 설정들을 직접 살펴본 결과, threads-max 커널파라메터가 다른 일반 서버들보다 낮게 설정되어

62327인가 라는 값으로 올려논 상태라고 하였고, 그 후로 모니터링 중이라고 하였다.

이차 분석을 하려고 방문 한 날, 고객측에서 테스트 (장애재현) 를 하게 되었고,

몇가지 간단한 시나리오를 바탕으로 테스트에 들어갔다.

주요 테스트는 단순한 Thread 생성 테스트를 통한 부하 테스트..
( sysrq 로그나 응용프로그램 로그등에 찍힌 fork(): not allocate memory 뭐 이런 로그로 인하여 )

테스트 프로그램을 실행 시키자, 순식간에 서버가 뻗는다.

아하 이거구나! 라고 생각한 전부는 threads-max 의 적절한 값을 정하지 못해서 그런것으로 판단,

R 사 에 문의 하기로 한다. ( 그상황에서 VMware 와 Diskdump 의 지원문제로 netdump 설정 함 )

간단한 R 사 의 답변은 SMP 커널의 경우 메모리가 어느정도이든,

프로세스나 스레드 생성을 위해서는 1G/3G 스플릿 모델에 의해 1G 영역에서 관리할 수 있게 되고,

소스상의 최대 생성가능 수는 32000 개로 정해져 있다는 것.

고로 이 시스템에선 1G / 8 * (8192/4096) = 14336 이라는 것. ( default threads-max 값 )

가상화 이전엔 Hugemem 이였던 시스템이였으나, VMware 의 hugemem 미지원으로 인해

smp 를 사용 하였다는 정보 추가. ( smp = Max 16G Ram ).

뭐, 결국 원점이 되버린건데, 장애의 원인은 결국 못찾았다는것이다.

그래서 다시 테스트를 해 보았고, 테스트 시점에서 netdump 와 sysrq 를 통해 core dump 를 받아

R 사 에 다시 문의 하였다.

R 사 에서 돌아오는 답변은 간략하게, 정확히 행업상태의 덤프가 아니라, 스냅샷식의 덤프라 의미가 없다는것.

분석 내용에서는 메모리가 부족하여 Hang-up 으로 보였을 뿐 Hang-up  은 아니라는 것이였다.

아차.. 그럴 수도 있었겠군... 그러나 몇일 뒤 다시 Hangup!! 게다가 netdump 문제로 not dump...

대략 여러가지 살펴보았고, 또다시 뜬 메모리 부족 및 fork 에러를 기반으로 다시 시나리오를 작성.

문제는 메모리할당이나 스레드 등등 이지 않을까 싶어 R 사 엔지니어 방문요청! 테스트를 해보았다. (와우~)

- 계속 -