rein’s world

사실 쓰면서 "내가 이 이야기를 어디서 본게 아닐까"하고 고민했었는데, 어제 IRC 채널에서 대화하다 원전(?)을 발견했음. Raymond Chen의 The Old New Thing†에서 본 내용이었다.

요약하자면 "서버에서 페이징(=하드디스크 스왑핑) = 죽음"이라는 내용인데,

서버가 10시간 마다 죽는 경우를 발견했는데, 원인을 발견할 수 없어서 아예 클러스터링으로변경
변경하고나니 마치 시계처럼(…) 각 클러스터가 주기적으로 시간에 맞춰서 딱딱 사망
결굴 발견한 원인은 서버에서 동작하던 프로그램 중 하나에서 매 요청마다 발생한 1바이트의 메모리 릭이었고, 이 메모리 릭 때문에 서버가 메모리가 부족해서 하드디스크로 페이지들을 스왑하기 시작했고 이로 인해서 사망했다

라는 이야기.

…뭔가 비슷하면서도 좀 다르긴하네(…).

*

† Windows 개발자로 Joel 의 블로그 29선에 소개되기도 했다. 읽다보면 윈도우 내부 구조나 소프트웨어 개발에 관한 깊이있고도 재미있는 지식들을 얻을 수 있다. 영어이긴 하지만 대체로 평이한 문체이니 한 번 구독해볼 것을 권한다.

…밑의 글에서 정리 못한 얘기 몇 가지.

MSXML 버젼 문제인듯도한데, MSBuild 의 출력을 해석하는 경우(compile-msbuild.xsl 과 msbuild.xsl 활용) xsl 파싱 에러를 몇 가지 낸다.

• DTD 를 사용할 수 없다는 문제 -  를 재정의한 부분이 있는데, 적당히 고쳐주자( 으로)
• <xsl:choose> 가 비어있다는 문제 - 해당 줄을 지우면 해결

사실 이걸 찾아서 고치는 것보다 이걸 수정하고나면 반영이 안되서 IIS와 CruiseControl.NET으로 등록된 서비스를 재시작하는게 좀 더 귀찮았다. (내 방법에 문제가 있는 것인지는 모르겠지만 제대로 반영이 안된다)

MSBuild 출력 해석 문제. 전체적으로 출력이 좀 난잡하고 잘 정의된 순서없이 출력된다. 그래서 다시 배치파일로 갈아탈까를 심사숙고하다가(…), 최종적으로는 변형된 MSBuild 해석 dll을 구해서 설치했다. (http://confluence.public.thoughtworks.org/display/CCNETCOMM/Improved+MSBuild+Integration 참조)

여기에 ccnet.config이외에 웹 대쉬보드 설정(dashboard.config) 수정 문제 같은 것도 잘 기술되어 있으니 따라가자. (이걸 모르면 한동안 MSBuild 출력을 대쉬보드에서 볼 수 없다)

ps. 근데 CC.NET에서 설정해주는 값을 MSbuild.xml 에서 쓰고 있었더니 MSbuild.exe를 이용한 빌드 설정 유효성 확인(validation)이 동작하지 않는다. 뭔가 아시는 분?

대충 어제를 기점으로 삽질은 완전히 끝난듯한데, 그 동안 CruiseControl.NET을 처음 깔아보는 프로그래머(=rein)가 할만한 삽질들을 정리해보겠다. 우선 설치 과정 전체는 KAISTIZEN 님의 CruiseControl.NET 설치 일지 를 따라 갔다. 전체 과정이 잘 정리되어있으니 매우 유용한 페이지다.

IIS 설정 삽질

IIS 설정에서 ASP.net 의 버젼을 1.1.x 대신에 2.0.x 이상을 사용해야 한다. 그렇지 않으면 IIS에 등록한 파일 형식이 이상하다는 식의 에러를 뱉는다(그것도 로컬 접속에서만 볼 수 있는 형태로 -_-;; )

통계 기능 사용하기

기본적으로 이 기능이 꺼져있는데,, 이 기능을 통해서 구현되는 페이지 - 각 프로젝트(ccnet.config의 Project 섹션에 대응)의 Statistics 페이지 - 의 경우 예쁘지 않은(…) 예외;exception을 던지면서 죽는다. 프로젝트 설정에

<publishers>
  <xmllogger/>  <!–for CC.NET–>
  <statistics/> <!–for statistics page–>
</publishers>

이런 부분이 들어가 줘야 한다.  문제는 작업할 때 메일링 리스트만 보고 <statistics /> 항목만 추가 해줬더니 이젠 전체 히스토리 페이지에서 예외가 발생하는 것(…).  xmlloger 를 발행하는 부분이 CC.NET 전체의 히스토리나 로그 뷰를 제공하기 때문에 저 부분이 빠지면 제대로 안되는 것에 주의.

UnitTest++ 연동

이 부분은 전혀 감이 안잡혔는데, 이 역시 KAISTIZEN 님의 UnitTest++ 연동 부분을 따라했다. 여기서도 삽질한 부분이 있다. 위의 연속이긴 한데, 로그 파일 합치는 부분(merger)을 나중에 추가 했다고 publishers 부분의 뒷부분에 붙였더니 제대로 출력이 되질 않는다. 즉, 다음과 같은 순서가 되야 한다.

<publishers>
    <merge>
        <files>
            <file>Path_To_UnitTest++\Output\XmlFile.xml</file>
        </files>
    </merge> <!-- merge가 xmllogger보다 앞임 -->
    <xmllogger/>
    <statistics/>
</publishers>

실제 xmllogger가 처리하는 부분이 우리가 실제로 보게되는 페이지 - 에 해당하는 xml 출력이 - 라서 그 부분 이전에 빌드 결과가 xmllogger에 의해 처리되어버리면 UnitTest++결과를 볼 수 없게 된다(…). 그러니 순서에 주의.

다만 전체 통계 페이지에서도 통계를 보고싶은데 오늘 수정한 xsl이 제대로 동작하지 못하는 것인지 통계를 제대로 못 얻어내더라(테스트 결과에 대한 것들에 대해서).  이건 해결하게되면 다시 포스팅을 하던가 해야.

C++ 빌드 방식에 대한 첨언

이건 삽질했다기보단 Visual C++ 기반으로로 빌드를 해야해서 좀 선택하거나 고민할게 많아서 써보는 얘기다. CruiseControl.NET이 C#을 위해서는 정말 완벽한 지원 - 특히 NAnt와 NUnit 지원이 멋짐 - 이지만 C++의 경우엔 저렇게 널리 쓰인다고 할만한 빌드 팩키지가 없다. 그래서 그런지 몇 가지 대안으로 쓸만한 것들이 존재한다.

• <exec> task - 말그대로 커맨드라인에서 뭔가 실행시켜주는 태스크다. 처음엔 batch 파일을 이걸 이용해서 실행시켜서 빌드했다 - 이전에 trc / svn / XML-RPC를 모두 결합시켜서(…) post-commit 훅으로 빌드했었기에. Batch 파일 하나 실행시키면 되는 거기 때문에 상대적으로 빌드를 테스트하기도 쉽고 설정 부담도 적지만, 언제나 그렇듯 batch 파일은 유지보수가 힘들다[...].
• <devenv> task - DevEnv.com은 VisualStuiod.Net 을 실행시켜주는 쉘 비슷한 녀석이다. 이놈을 직접 호출해서 빌드하는 방식 - 예를 들어 devenv.com some_solution.sln /build DEBUG - 을 쓸 수 있게 해준다. 다만 이 녀석은 기본값이 rebuid 라서 빌드 트리 일부에 있는 라이브러리 부분 등을 모두 다시 빌드하는건 좀 짜증나기도하고 nightly-build도 아닌 CI로만 활용할 때엔 좀 괴롭기 떄문에 잘 취사 선택해야한다.

  별로 설정할게 없어서 편하긴한데, ccnet.config 에 추가해야할 줄이 무지 많다. 솔루션이 추가될 때마다 CruiseControl의 설정을 건드려야 하는 것도 문제고, 빌드 자체가 안될 때 디버깅 하기도 좀 난감하다.

• <MSBuild> task - devenv를 좀 찔러보다가(…) 일단 현재 도착한 장소가 여기. MSbuild 는 .NET 프레임웍에 포함되어있는 툴인데 XML 기반 메이크 파일(…보다는 좀 더 MS Windows 스러운)이다. C# 같은 것은 소스 기반에서도 빌드할 수 있는 룰들을 제공한다. 그리고 이 안의 설정들의 경우 CruiseControl.NET에서 지정할 수 있는 것보다 좀 더 유연한 룰들을 제공하는데다가(조건부 컴파일이라거나…), 상대적으로 테스트하기가 쉽다. (MSBuild 의 메이크파일에 해당하는 XML 파일만 시험해보면 되니) 그리고 문서화가 잘되어있는 XML 형식이라 배치 파일보다 유지/관리가 쉽다.

뭐 이 정도가 지금 당장(…) 생각나는 설정 삽질이다. 이 이후에도 뭔가 삽질을 하면 포스팅 해보도록 하겠다(…).

빌드 스크립트를 테스트하는 동안 쌓인 스팸이나 지울까해서 블로그에 로그인하고 보니 어제 저녁에 올린 책 리뷰가 300번째 포스팅이더라[...]

2005년 6월 21에 블로그를 개설한지도 어언 951일이 지났고, 대충 3일에 1개씩 한셈치고(물론 전체적으로 봤을 때 작년 7월부터 포스팅 수가 급격히 증가했지만) 300개나 되는 포스팅이 쌓인 상태.

그 동안 블로깅 툴도 한 번 갈아타고(+계속해서 WP의 버전이 올라가긴 했지만), 블로그 주제도 학교+게임에서 책이랑 프로그래밍 포스팅이 늘어나는 등 변화도 있었다. 금년 목표인 1일 1포스팅을 달성하고나면 포스팅 량이 대충 2배가 되겠지만[...] 여튼 그런 의미에서라도 한동안 바쁜 틈틈히도 글을 쓰려고 노력하는 생활을 해야.

토요일에 하카다 분코에 돈코츠라멘을 먹고 + 홍대입구역에서 만화책 / 라이트노벨 몇 권을 구입하고 돌아왔다. 전번에 썼던 것처럼 이동시간이 슬퍼할만큼 길어져서 손도 안댄책을 한 권 꺼내서 가지고 갔다. …갔다왔다 했더니 한 권을 다 읽을 수 있더라 -_-; 여튼그렇게 읽었던 책이 스티브 워즈니악의 자서전인 iWoz의 한국어판.

역사상 가장 성공적인 주식 공개 중에 하나였던 Apple 의 주식공개를 이끌어냈던 Apple II 컴퓨터의 설계를 수행했던 엔지니어인 스티브 워지니악의 이야기인데, 약간의 자기자랑이 섞여있긴하지만[...] 재능있는 엔지니어의 행복한 엔지니어링이랄까. 북미 전화망을 프릭킹해서 공짜전화를 걸기도하고, 가장 적은 수의 부품만으로 “컴퓨터”를 설계하는(도면 위에서) 취미를 가져보기도하고 …

스티브 워즈니악은 결국엔 우리가 사용하는 개인용 컴퓨터들의 시작이라 할 수 있는 Apple II 를 만들어내게 된다. (그리고 이 제품이 모태인 Apple I을 통해 워즈니악과 스티브 잡스는 애플을 시작하게 된다) 워즈니악 자서전이 재밌었던 점은 아마 이런 “성공” 때문이 아니라 “그 자신이 행복하게 일(엔지니어링)을 했다는 것”에 있었다. 그는 즐겁게 컴퓨터를 만들어냈고, 같이 회사를 시작한 일반직원들에게 주식을 나눠주고, 공용 리모콤을 만들고, 음악 페스티벌을 열고, …

길지 않은 책이었지만 “행복한 엔지니어”에 관해서 좀 더 생각할 기회를 얻은 듯 하다 (사실 이게 내 희망사항이기도하고).

어제 저녁부터 헬게이트: 런던의 오픈베타를 해보고 있다. 디아블로의 향수로 하고 있긴한데 아직은 만족스럽다고하기엔 2% 부족했다. 뭐 이게 중요한 것은 아니고 내 개인 컴퓨터(집에서 쓰는)에서 헬게이트 런던을 구동시키면 다음과 같은 일들이 발생한다.

1. 게임 시작 (7xx메가의 메모리 사용)
2. 메모리 사용량이 지속적으로 증가(10분 후면 프로그램 자체가 약 2기가 정도를 차지한다)
3. 스왑 공간역시 지속적으로 증가(시작시에 부팅 후 기본설정이 4GiB에서 시작해서 약 10GiB까지 상승)
4. 물리 메모리 공간이 고갈되기 시작한다(물리 메모리 사용량 3.8GiB+로 증가)
5. 하드 디스크 페이징(=thrashing)이 계속해서 발생

…대충 이런 과정이 약 2시간 정도 주기로 발생하는데 원인을 파악하기가 힘들다 -_-;;

일단 플레이 환경이 x86-64/Windows Vista/라데온 3870/라데온 드라이버 1. 17일 업데이트인데, 의심이 가는 것은

• 프로그램 자체의 메모리 릭 (특히 지역 이동 시) - 이건 비슷한 환경인 Dish 의 경우엔 일어나지 않는다함
• 그래픽 드라이버 버그 - 가장 의심가는 곳. rein의 AMD에 대한 신뢰란건 거의[...] 그렇지만 뜯어보거나 디버거를 붙여본건 아니니 -_-;
• DX 디바이스를 재생성(restore) 할 때 릭이 있는 경우 - IRC 클라이언트를 쓴다고 자주 프로그램 포커스를 바꾸기 때문에 그 때마다 릭이 생기는건 아닐까 하는 중

여튼 메모리 릭은 하드디스크 페이징을 발생시키고, 이건 응용 프로그램엔 치명타라는 고전적인 문제를 집에서 경험하고나니 참 -_-;;

프로그램 - 경우에는 해당하지않지만 고전적인 서버/클라이언트 응용에서 서버 쪽 - 은 아주 단순화 시켜서보면,

• 일정 형태(아주 일반적으로 보면 푸아송 분포)로 입력이 들어오고
• 특정 형태(아주 일반적으로 보면 역시 푸아송 분포)로 작업을 처리하게 된다

즉 고전적인 큐잉 시스템이 되는데, 하드디스크 페이징(thrashing)이 메모리 릭 같은 이유로 유발되면,

• 입력으로 계속해서 클라이언트 요청이 들어오는 것은 변하지 않는다
• 작업처리율은 디스크 페이징으로 인해서 매우 낮아진다

와 같은 상태가되고, 큐 자체가 급격히 길어지면서 붕괴한다.

뭐 진짜 안되면 32bit 호환모드를 찾아오거나 DX9 드라이버 모드로 돌린다거나 해야 -_-

현재 개발하는데 사용하는 환경이 svn+trac이고 Windows 서버를 사용하고 있다(물론 XP이후의 Win32 환경이면 다 사용할 수 있는 상태지만…).

빌드가 자동으로 이루어지기 위해서 다음과 같은 구성을 쓰고 있다 (가장 효율적인 집합이랑은 거리가 좀 멀 것 같지만 )

• Machine A : svn 서버. trac 도 같은 서버를 사용한다 - trac 서버가 svn과 원격으로 있게 하는건 좀 어렵다.
• Machine B : 빌드를 수행한다. 

이런 개념으로 접근했었다. 실제로 빌드가 이뤄지는 시나리오는,

1. 누군가 소스를 수정하고 svn commit
2. A의 svn 서버의 post-commit 에 걸려있는 훅;hook 이 실행
3. 훅은 Machine B의 XML-RPC 서비스에 빌드 요청을 전달
4. Machine B에서 빌드를 시작
5. …미래의 어느 시점엔가 Machine A의 trac wiki의 빌드 상태 페이지를 누군가 열면 현재 상태를 B의 XML-RPC 서비스에 요청하고 현재까지 알려진 최신 빌드의 정보를 출력한다.

라는 것이다. 만약 강제 리빌드를 실행하게 되면 trac wiki에서 특정 페이지를 열면 해당 페이지의 trac-macro가 실행되고 그 매크로에서 forced-build라는 메시지를 XML-RPC로 전달하게 했다. 그 이후는 4~5의 반복.

여기서 문제는 바로 3~4의 연결문제와 5의 과정이 사람이 직접 접근해서 확인해야하는 과정이라는 것. 즉, 저 부분은 자동화가 이루어지지 않았다.

원하는 것.

• XML-RPC 같이 내가 직접 수정해야하는 - 지금은 trac macro와 빌드 서버 밑단이 python 코드 - 부분이 없거나 나 이외의 사람도 관리하기 쉬울 것 (명확한 문서화, 예제 등등)
• 실패한 빌드에 대해서 명시적으로  알려줄 것 (trac-wiki를 일일이 열어봐야하는 것 같은 것 말고)
• 전체 빌드를 기술할 때 Visual C++ 기반 프로젝트의 설정을 바꾸거나 추가하거나 제거하는게 쉬울 것
• svn에서 다른 SCM을 사용해도 쉽게 전환할 수 있을 것 (가능하면 SCM 계층과 커플링이 적을 것)

과 같은 조건이었는데 Rica 네 팀에서 설치해봤다는 CruiseControl.net 을 써보기로 하고 설치. 잘 알려진 오픈소스 Continuous Integration 툴인 CruiseControl의 .net framework 포트다† .

설치 과정 자체는  IIS, 빌드툴(이 경우엔 Visual Studio 2005), svn 그리고 CruiseControl.net 자체만 설치하면 끝.

IIS에 등록하는 과정도 CC.net이 알아서 해주는지라 쉬웠다 (다만 IIS 에러 메시지를 하나도 해석할 수가 없어서 ASP 1.1.x대신에 2.0.x로 설정하면 끝날 문제를 반나절 헤맸다…). 띄우고나서는 CC.net에 동봉된 문서를 따라서 설정을 하고 빌드가 이루어지는 것을 볼 수 있었다. CC-Tray라는 Win32용 태스크 바에 뜨는 트레이 프로그램을 제공하는데 현재 등록된 빌드들이 빌드성공/실패 여부를 알려주고 + 실패한 경우 누군가 자원해서 고치나를 알려주기 때문에 유용할 것 같다.

그리고 툴 자체가 Win32환경(특히 .net framework)에 최적화 되어있고, VS 200x의 솔루션 파일을 바로 빌드할 수 있는 태스크를 제공하기 때문에, 스크립트로 빌드하던 시절에서 좀 더 편한 방식으로(아무나 설정하기 쉬운) 옮겨갈 수 있게 된 듯하다.

실제 사용 경험은 팀에 좀 적용된 이후에 글로 써보도록 하겠다.

ps. 이걸로 하루 일과 종료(…)

*

† 비슷하게 로깅 라이브러리 log4j의 포트인 log4net, 빌드툴 ant의 포트인 Nant, 유닛테스트 프레임웍인 JUnit 포트인 NUnit 같은 툴들을 쓴다(…). 뭐 그래봐야 C++이라서 테스트 툴은 UnitTest++을 쓸 듯 하지만…

어제 오후부로 2007년도의 연말 정산이 일단 가결산되었다. (몇가지 처리가 안 끝나서 최종?은 아닌 것 같지만)

2005/2006년도 소득이 있긴했지만 BK21 보조금이랑 프로젝트비만 겨우 받았던 - 그나마도 BK21은 2005년에만 받았고; 플젝은 4~11월 이라 -_- 2007년 초의 재정 상태는 진짜 눈뜨고 보기 힘든 상태가… - 지라 그 소득에 대한 소득세는 전액 환급[...]을 받았었다. (그래봐야 한달 복지비 수준 + 약간)

2007년은 나름대로 소득도 꽤 커졌고(…) 돈 쓴 것도 늘고 뜯긴 것(…)도 늘었는데 대충 가결산한걸 보니 평년(…)의 환급이더라 -_-;

근데 문제?라고 생각하는건, 어디의 rein처럼 혼자 사는데다가 / 부양가족으로 올릴 부모님도 없고 이런 상태면 (소수자 공제가 사라져서 이런거긴하지만 -_-) 돈 쓰는걸 줄여서 뭐하나 하는 생각이 마구마구 든다. 연초부터 google docs에 가계부를 쓰고있었는데 뭔가 계속 쓰기가 무진장 싫어지고 있다. 일단 올해 환급을 받을 수 있던 원인은,

• 2006년 12월의 카드 사용액 이전분 (이 때 컴 2대 만들었다) - 대충 3년 이상 주기로 발생할 일
• 올해 동생컴 1대, 집컴 1대 조립 - 2+ 년 주기
• 4주 훈련갔다오고 모니터 및 엑박360 등등 지름 - 4+ 년 주기

…같은 년 단위보다 긴 레벨에서나 있을 지름 이벤트들의 총합이 이거인데(특히나 2006년 12월 카드사용액이 올해 카드 총 사용액의 30%수준) 2008년 연말 정산을 하게되면 어떨지 참 기대가 된다 =,= 2MB 정부에 세금내기도 싫은데 유니세프에 기부나 팍팍할까 -_-

ps. 올 초부터의 컨셉(?)이 절약 / 돈모으기였었는데 뭔가 의욕 대폭 감소 중. 절약해봐야 같은 팀의 다른 형처럼 백만원 가까이 추가로 세금내야되고하면 -_- 정말 뭔가 세상이 미워질지도 모름[...]