윤지네 홈쇼핑 있었을때였습니다. RAC 오라클 서버였는데 언제부터인가 오라클이 차지하는 메모리를 제외하고 점점 메모리 사용율이 높아져만 갔었습니다. 작업관리자를 열어봐도 오라클 이외에 딱히 쓰는게 보이지가 않았던? 희안한 증상이였죠.
그럼 커널쪽에서 뭔가 먹고 있나 싶었습니다.
 위 그림으로만 봤을때는 딱히 문제시 될만한 프로세스가 없습니다. 그냥 정상처럼 보일뿐입니다.

그런데 실제 사용 메모리는 거의 끝까지 사용하고 있다는겁니다. 뭐 친절하게도 커널에 넌페이지 메모리가 보통 이상을 잡아먹는것이 보입니다. 흠 그럼 커널에서 누수를 일으키고 있는게 확실하단 말이네? 좋았어 그럼 이 범인을 반드시 잡아주마 하고 poolmon을 실행시켰습니다.
바이트로 정렬했더니 Proc 와 Thre 즉 프로세스와 쓰레드가 많은 메모리를 먹고 있다는걸 보여주고 있습니다. 지금까지 커널메모리 누수는 sys 같은 커널에 상주하고 있는 드라이버나 백신같은것들이 대부분이였는데 이증상은 의외였습니다. 한번도 경험해보지 않은 특이케이스중 X-File 같은 증상이였습니다. 이때까지만 해도 저 프로세스와 쓰레드가 정확히 무었인지 밝혀내지 못한 단계였기 때문에 추측으로 메모리 누수가 발생했던 시점을 유추해서 그당시 프로그램 설치했던 상황으로 용의자를 뽑았습니다. 딱 하나가 걸렸습니다. DB 모니터링을 하는 맥스게이지가 그당시 에이젼트를 설치했던 날이였습니다. 하지만 맥스게이지는 아무런 죄가 없는 프로그램이였습니다. 정황상 맥스게이지가 그 시점과 거이 동일했기 때문에 당신네 프로그램 때문에 지금 난리가 났다고 당장 직원보내라고 협박성 덤탱이를 씌웠던 그런날이 있었고 그 죄없는 어린직원은 얼굴이 잔뜩 겁먹고 온 상태여서 딱히 니탓내탓할 그런 액션을 취하지 않았습니다. 그런데 혹시나 싶어서 내가 헛다리 짚었으면 어뜩하지?라는 불안감에 다시 제대로 분석해보기로 했습니다. 실제 커널의 메모리 상태를 확인하기 위해서는 윈도우는 디버깅 모드를 활성화 시켜야 됩니다. 기본값은 보호를 위해 비활성 되었습니다.
bcdedit /debug on
위명령어로 디버깅 모드를 진행할수 있습니다. 그리고 재부팅후에 다시 증상이 발생했을때 WinDBG 유틸을 이용하여 커널디버그 모드를 들어갑니다.
!vm 명령을 사용하면 커널에 사용되는 메모리 정보가 주르륵 나옵니다

왠걸? 정말로 범인이 밝혀졌습니다. 역시나 poolmon에서 출력해서 보여줬던 결과처럼 프로세스가 무수히 많이 점유하고 있었던 것이였습니다. 이게 또 0kb 용량으로 점유하고 있었기 때문에 프로세스명이 메모리를 차지하고 있다고 출력을 못해주고 객체의 갯수만 많이차지하여 누수를 발생한 현상이였고 이 결과값이 출력되자마자 죄없는 맥스게이지는 누명을 벗게되는 그런날이 있었습니다. 하필 왜 그때 프로그램 설치해가지고...ㅋㅋㅋ
그럼 저 프로세스가 뭐냐면 파로스라는 DB모니터링 프로그램입니다.

그럼 왜 저증상을 불러일으켰냐면 저 문제를 불러일으킬 시점에 라이센스가 만료가 되었습니다. 만료가 되었으면 서비스를 중지를 하던가 삭제를 하던가 해야되는데 그런 통보를 전달해주지 않았기에 그냥 살려둔체로 메모리 누스를 일으켰던 분석하기도 정말 희안했던 케이스중 하나였습니다.

정상적인 커널메모리였을때는 위그림과 같이 넌페이지 커널메모리가 정상적인 값을 보여주고 있습니다.
대부분의 커널메모리 누수는 커널에 상주하는 드라이버,  그리고 백신 필터드라이버 나머지는 운영체제의 핵심들입니다. 운영체제는 특별히 버그이슈나 커널이슈가 존재하지 않는한 거이 메모리 누수가 발생하지 않습니다.(이제까지 그런 문제는 못봤습니다) 벤더사의 초기 드라이버들이 문제를 일으키는 케이스가 흔했었고 두번째로 멀쩡한 드라이버 핸들링하고 놔주지 않는 백신들이 두번째로 치명적인 문제를 보여줬었습니다. 리부팅하면 그런증상이 없어졌기 때문에 대부분의 엔지니어들은 윈도우가 원래 이렇다?리눅스 유닉스는 안그런데 윈도우랑은 호환성이 안맞는다?라고 도피성 결론을 내리고 덮어두는게 대부분입니다.
커널을 사용하지 않는 프로그램들은 유저모드에서 전부 모니터링이 되기때문에 누수에 대한건 금방 분석하고 결과를 유추할수 있습니다.

It is necessary to start SQL Server in single user mode before master database can be restored. It is very easy to start SQL Server server in single user mode. Follow the tutorial SQL SERVER – Start SQL Server Instance in Single User Mode.

Once SQL Server instance is running in single user mode, immediately connect it using sqlcmd and run following command to restore the master database.


RESTORE DATABASE master FROM DISK = 'C:\BackupLocation\master.bak' WITH REPLACE;
GO

MSSQL master 데이터베이스를 리빌드 하고 난후 백업을 복원해야되는 일이 발생했을때 찾아봤던 내용입니다. mater 데이터 베이스가 초기화 되어버리면 계정이나 운영되는 DB 리스트들이 안보이기에 일일이 계정등록하고 매핑 시켜주는 일이 번거로워서 master 백업을 복원해 봤습니다. 시스템 데이터 베이스가 아닌 DB들은 UI 관리도구에서 복원이 가능하지만 master 는 위 내용처럼 싱글유저 모드로 서비스를 시작하고 난후 커맨드로 복원을 진행해야 됩니다.
예전에 클러스터가 떨어졌을때 master 데이터베이스가 크래쉬 나서 서비스가 시작이 안되어 리빌드하고 계정을 일일이 넣어주고 매핑해줬었는데 복원하는 방법이 위와같이 절차만 알고 있으면 복원이 쉽습니다. 모를때는 노가다라도 하면서 일일이 넣어주곤 하는데 이게 DB리스트가 많아지고 계정이 많아지고 그리고 각각의 DB계정들 암호를 모르고 있다면 재앙수준이죠.

미제사건이 될수밖에 없던 사건이였습니다. 제주경찰의 오만한 결과물이였죠.
변사체로 발견되고 부검결과 발견된 시점과 오래지 않아 살아 있었다고 제주대학교 교수가 발표를 했음에도 불구하고 제주경찰들은 니말은 알겠다만 인정못하겠다고 조까라고 몇일전에 죽은거라고 밀어부쳤습니다. 하의가 벗겨진채로 발견되었기 때문에 초동수사를 용의자를 남자한테만 집중했습니다. 성폭행 흔적은 없고 옷은 벗겨져 있고 그러면 범인은 왜 남자야 여자로 봐야지. 어느 선량한 남자생뀌가 옷 다벗기고 반항도 못하는 여자가 술이 떡이되었는데 범행을 저지를려다 안하고 그냥 죽이기만 했다? 하여튼 제주 경찰 아저씨들 동화속 시나리오는 참 잘써요.
이당시 경찰들이 오만하지 않고 신중했다면 미제사건이 될수가 없었습니다. 그런데 부검교수의 전문소견도 생까고 지들 멋데로 벌인 결과였기 때문에 억울한 사망자만 발생했던겁니다. 실종되던날밤 술김에 남자친구집 찾아갔는데 대판 싸웠다는 말도 있는데 대판싸운이유? 거기에 다른여자랑 쿵덕 거리던걸 걸렸는지 알게 뭡니까. 그 다른 여자가 있었다는 물증만 증명되도 사건이 술술 풀릴뻔 했는데 이 사건만 보면 정말 빡쳤습니다.
18 견찰 생퀴들 옷벗기고 아무짓도 안했으면 남자일 확률은 거이 없다고 봐야지 병신들...

이  뉴스를 구리에서 일다닐때 회사 동료들과 저녁식사하다가 다른 부서 직원이 이 뉴스를 보고 한마디를 던졌습니다. 옷벗기고 아무짓 안하면 그게 남자야? 사건 수사를 흐리게 남자로 몰아세우게 하는 작전을 펼치는 여자잖아라고...(그때 어머  그러네...)

블로그 검색에서 여교사 실종사건 검색어 순위가 너무 높아서 사건을 재정리 해봤습니다.