멀티프로그래밍 블로그

소음과 디스크 성능

(CS) — Mon, 05 Jan 2009 16:43:22 +0900

보통 데이터센터는 에어컨디셔너를 비록한 각종 장비들로 매우 시끄럽습니다. 그런데, 이러한 소음이 디스크 latency를 증가시키는 것을 실제로 보여주는 흥미로운 비디오가 있어 아래 소개합니다.

http://blogs.sun.com/brendan/entry/unusual_disk_latency

이 사람은 디스크 가까이에서 비명 소리를 지르는 것으로 디스크 latency가 증가하는 것을 보여주고 있습니다.

우연히 하드디스크 고정 브라킷의 나사가 제대로 조여지지 않은 상태에서 디스크가 높은 latency를 보인 것을 발견하고 소음과 진동이 디스크 성능에 영향을 미친다는 것을 발견하였다는군요.

데이터센터에 디스크를 설치할 때는 되도록 모든 나사를 꼭 조이고 소음을 줄이는 것이 좋겠습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

메모리와 디스크 지연시간 (latency)

(CS) — Mon, 05 Jan 2009 16:35:08 +0900

아래 링크는 바로 전 포스팅에서 소개한 메모리 지연시간(latency)에 관해 아주 잘 정리된 문서를중에 실생활에 비유한 내용을 번역 정리해보았습니다.

what-your-computer-does-while-you-wait

성능 혹은 최적화를 생각할 때 항상 염두해 두어야할 것.

최신 CPU는 엄청나게 빠르다. 대부분의 심플한 연산을 수행하는 데에 단, 1 클럭 싸이클 밖에 소요되지 않는다(Core 2 CPU 기준). 이는 3GHz CPU 속도라면 1/3 나노초에 해당한다, (1/3 나노초동안 빛은 10cm 정도 진행할 수 있을 뿐이다)

메모리와 디스크 latency를 실생활에 비유한다면 다음과 같다.

1. L1 cache: 책상 위에서 종이 한 장을 잡기 (3초)

2. L2 cache: 책장에서 책 한 권을 꺼내기 (14초)

3. 메인 메모리: 복도로 걸어 나가 자판기에서 커피 한 잔을 뽑기 (4분)

4. 하드디스크: 건물을 나와서 1년 3개월 동안 세계일주 하기.

프로그램 최적화를 위해 무엇을 해야하는지 확실히 보여주는 좋은 비유인 것 같습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

2008년 한 해를 마감하며

(CS) — Wed, 31 Dec 2008 11:09:51 +0900

2008년 한 해도 벌써 끝나가고 있습니다. 지난 2주 동안 잠시 가족들과 한국을 방문하였는데, 정신없이 시간이 지나가더군요. 오랜만에 서울에서 운전했는데, 여기 시애틀에서보다 5배는 힘든 것 같았습니다. 그런데, 운전중에 DMB TV를 시청하는 택시 운전사를 보고 기가 막혔습니다. 사람들은 여전히 무척 복잡하고 바쁘게 움직이고 있었으며, 다이나믹한 에너지가 느껴졌습니다. 아마도 제가 살고 있는 곳이 서울과 같은 대도시에 비교하면 워낙 시골같은 분위기라 그런것 같더군요. 한국의 경제가 벌써 많이 어려워지고 있는 것 같아 걱정스러웠습니다. 주변에 주식이나 펀드로 돈을 잃은 사람이 많았습니다. 물론 저도 좀 잃었긴합니다.

크리스마스 선물로 회사로 부터 Amazon Kindle 을 받았는데, 처음으로 구입한 책이 The Return of Depression Economics and the Crisis of 2008 입니다. 내년엔 경제가 더 어려울 것이라는 전망이 나오는 상황에서 이 책을 읽고, 현 경제 위기가 왜 발생했는지 조금이나마 이해할 수 있기를 바랍니다. Kindle은 무엇보다도 다른 부가 비용없이 어디서나 무선 데이터 통신을 할 수 있다는 점이 마음에 듭니다. 물론 책값에 무선 이용료가 포함되었을 것이라 생각합니다.

휴가에서 돌아와 내년에 할 일들을 생각하니 어께가 무거워 집니다. 마지막으로 아래 최근에 발견한 (특히 고성능 프로그래밍에 관련된) 좋은 문서들이 있어 링크를 복사해 두었습니다.

what-your-computer-does-while-you-wait

Real-World Concurrency

BASE (basically available, soft state, eventually consistent)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

널티코어 (Nullticore) 현상

(CS) — Tue, 09 Dec 2008 05:22:27 +0900

인텔이 80개 코어를 가진 CPU의 시제품을 선보였고, 8코어, 16코어가 CPU 코어가 곧 발매될 것이라고 기대되고 있습니다. 그런데, 최근 미국에서 실시된 연구 결과에 따르면 이른바 메모리 벽 (Memory wall) 때문에 16개 이상의 코어는 무용지물이 될수도 있다고 합니다.

IEEE Spectrum의 11월 기사의 그래프를 보면 8코어 이상부터는 오히려 성능이 저하되고 16코어 이상은 더욱 심각한 성능저하가 발생하고 있습니다. 물론 이 실험결과는 슈퍼컴퓨팅 분야에서 다루는 데이터량이 엄청나게 많은 문제들을 시뮬레이션한 것 입니다. (예를 들면, 기상예측, 물리시스템 시뮬레이션 등)

데이터 벽이라 함은 CPU의 처리속도를 따라잡지 못하는 메모리 속도가 병목현상을 일으키는 것을 말하는데 코어수가 증가할수록, 그 문제가 더욱 심각해집니다. 코어가 많아지면, 동시에 많은 데이터를 처리하기 위해 메모리(RAM)도 기하급수적으로 늘어나게 되는데, 문제는 각각의 CPU가 다음에 처리하게 될 데이터가 어디에 있는지 알기가 힘들다는 것 입니다. 현재의 CPU 메모리 구조로는 이러한 병목현상을 해결하기가 어렵습니다. 위 기사에서는 이 문제에 대한 해결 방안으로 CPU상에 메모리를 쌓아올리는 방법이 제시되고 있습니다.

8코어이상의 코어는 오히려 기존에 존재하는 코어를 무효화 시키는 것을 널티코어(Nullticore) 현상이라고 부르고 있습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Sysinternals Tool

(CS) — Thu, 27 Nov 2008 07:37:35 +0900

윈도우즈 횐경에서 서버나 시스템과 밀접한 프로그램을 개발할 때 가장 자주 사용되는 유틸리티 모음이 Sysinternals tool 입니다. 다름 아닌 Windows Internals 의 저자인 Mark Russinovich 가 대부분 개발한 것인데, 보통 Microsoft 자체에서 개발된 것 보다 훨씬 낫습니다. Mark는 결국 현재 Microsoft에서 일하고 있습니다.

아래 링크를 보면 모든 Sysinternals tool이 업로드 되어 있어 쉽게 다운로드 받을 수 있습니다.
http://live.sysinternals.com/tools/

최근 추가된 Coreinfo.exe는 멀티코어 CPU 정보를 보기 쉽게 텍스로 출력해 주기도 하더군요.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

PDC 2008 Performance 관련 문서

(CS) — Fri, 31 Oct 2008 02:21:17 +0900

현재 PDC 2008이 진행되고 있습니다. 직접 참가하지는 못하지만 여러 자료들이 이미 온라인에 올라와 있어 살펴볼 수 있습니다. 아래 Performance에 관련된 PPT 슬라이드 파일들이 올라와 있군요.

http://blogs.msdn.com/vancem/archive/2008/10/30/slides-for-our-all-day-pdc-2008-talks-on-performance-by-design.aspx

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

윈도우즈 보안 패치 적용을 위한 서버 정검

(CS) — Wed, 29 Oct 2008 14:17:59 +0900

바로 전 글에서 언급한 심각한 윈도우즈 보안 핫픽스를 적용하기 위해 3시간 가량 길드워 서비스를 중단하였습니다. 물론 이번 기회에 그동안 적용하지 못한 모든 업데이트를 한꺼번에 적용하였습니다.

한 서버의 업타임을 보니 아래와 같이 무려 552일 동안 리부팅되지 않고 사용하고 있었습니다. 그러니까 이 하나의 서버만을 놓고 보면, 윈도우즈 업데이트 적용과 리부팅에 약 40분 정도 소요되었으므로 99.99% 이상의 업타임을 가졌다고 볼 수 있겠습니다. "five nines"는 아니라도 "four nines"는 되는 것 같습니다.

\\XXXX-AA00-001 has been up for: 552 day(s), 18 hour(s), 55 minute(s), 17 second(s)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

윈도우즈 보안 핫픽스

(CS) — Fri, 24 Oct 2008 14:49:52 +0900

오늘 상당히 심각한 보안 문제에 대한 패치가 마이크로소프트에서 발표되었습니다. 아래 블로그에 보다 자세한 내용이 있습니다. 아무런 인증절차 없이도 리모트로 임의의 코드를 실행할 수 있다는 것은 상당히 심각한 문제입니다.

http://blogs.technet.com/swi/archive/2008/10/23/More-detail-about-MS08-067.aspx

마이크로소프트사는 Security Development Lifecycle (SDL)이라는 이름으로 보안 문제가 있는 코드를 미리 발견하고, 공격에 취약한 부분을 미리 막는다고 하지만, 이번 예와 같은 이런 심각한 문제가 여전히 발견되고 있다는 것은 소프트웨어의 보안이 얼마나 어려운 것인가를 보여주는 예제라 하겠습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

More Programmers = More Code

(CS) — Wed, 08 Oct 2008 04:12:29 +0900

아래 블로그 글이 재밌기도 하지만 상당히 실제 상황과도 맞는 얘기인 것 같습니다. 나중에 시간이 나면 한국어로 번역해 올리겠습니다.

http://semanticvector.blogspot.com/2008/10/more-programmers-more-code.html

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

서버 크래시 (스택 보호 페이지)

(CS) — Thu, 02 Oct 2008 01:56:34 +0900

최근에 구글은 Chrome 웹브라우저를 발표하였습니다. 그런데 흥미로운 점은 Chrome의 장점을 만화로 설명하는 온라인 책을 만들었는데, 그 내용은 전산학 OS강의를 방불케 합니다. 메모리 단편화(fragmentation)과 스레딩에 대해 설명하고 있으며 Chrome이 성능향상과 안정성을 위해 각각의 탭이 독립적인 프로세스에서 돌아간다고 합니다.

오랜동안 실행 중인 서버 프로그램이 갑자기 아무 이유없이 크래시를 일으키는 경우를 가끔 볼 수 있습니다. 그 이유 중 하나가 마찬가지로 메모리 단편화일 것입니다. 충분한 물리 메모리가 있음에도 불구하고 가상메모리가 단편화 되어 더 이상 메모리 할당이 불가능해질 수 있다는 것이지요.

그런데, 최근에 저는 또 한가지 이유를 발견하였는데 바로 스택 보호 페이지가 리셋되는 경우입니다. "단순히 정상인 메모리를 읽기만 함"으로써도 프로그램을 크래시 시킬 수 있다는 약간은 놀라운 사실입니다.

윈도우즈의 각각의 스레드 스택은 기본으로 1MB가 예약되어 있습니다. 하지만, 1MB전부가 commit (물리메모리로 매핑)된 것은 아니며, 스택 보호 페이지라는 것을 만들어 스택 크기가 커져 이 보호페이지를 액세스하게되면 예외(exception)가 발생하며, 이 때 OS 커널은 해당페이지를 Commit하고 새로운 보호페이지를 설정합니다. 아래 그림을 참고하시기 바랍니다.

이러한 방법으로 처음부터 모든 스레드에 1MB의 물리메모리를 스택으로 할당하지 않아도 되기 때문에 메모리 낭비를 상당히 줄일 수 있습니다.

문제는 어떤 특정 스레드의 스택 보호 페이지를 다른 스레드나 프로세스에서 읽기를 시도하는 것만으로도 보호 페이지가 리셋되어 사라지게 되며 이 경우 재설정이 되지 않고 스택크기도 늘어나지 않습니다.

보호 페이지가 사라진 상태에서 당장 문제가 나타나지는 않으나, 나중에 스택 보호 페이지가 없는 스레드가 스택을 많이 사용하게 되어 보호 페이지와 그 위의 commit되지 않은 페이지를 액세스하게 되면 Access Violation나며 어플리케이션이 종료될 가능성이 높습니다. 어플리케이션의 예외처리기 (unhandled exception handler)를 사용하여 오류 분석을 해봐도 원인을 찾기는 쉽지 않습니다.

이 문제를 실제로 보여주는 예제가 아래에 있습니다. 아래 코드를 복사하여 BrokenGuardPage.cpp라는 이름으로 저장한 다음, "cl BrokenGuardPage.cpp"와 같이 컴파일하면 예제 실행파일을 만들 수 있습니다.

AccessStackGuardFromOtherThread 함수는 새로운 스레드 하나를 생성하고 있으며 지역변수의 포인터를 새로운 스레드에 전달합니다. 새로 생성된 스레드는 전달된 지역변수 메모리값에 -0x2000을 하여 스택보호 페이지에 대해 읽기 만을 시도합니다.

이 프로그램을 실행하면 프로그램 STATUS_GUARD_PAGE_VIOLATION 예외가 먼저 발생합니다. 이 때 Unhandled exception handler가 설정되어 있어 프로그램은 종료하지 않고 계속실행이 됩니다. 다음으로 Crash 함수가 main 스레드로 부터 호출되는데, Crash는 단순히 큰 지역변수를 가지고 이를 초기화하려고 시도하고 있습니다. Crash 함수에 잘못된 코드는 전혀 없습니다만, Access Violation을 발생하며 프로그램이 종료되어 마지막의 "printf("End of Program.\n")"는 실행되지 않습니다.

////////////////////////////////////////////////////////////////
//
//  BrokenGuardPage.cpp
// 
//  Just use following commands for compile:
//      cl BrokenGuardPage.cpp
//
//  www.devnote.net (9/26/2008)
//
////////////////////////////////////////////////////////////////

#include <stdio.h>
#include <process.h>
#include <windows.h>

//--------------------------------------------------------------
void Crash () {
    printf("Crash\n");

    // This function simply allocate a big local array and initalizes first element
    char test[32000];
    test[0] = 0;
}

//--------------------------------------------------------------
static unsigned __stdcall ThreadProc (LPVOID param) {
    printf ("ThreadProc\n\tTry to access Stack Guard Page\n");

    // main thread's local variable
    char * ptr = (char *)param;

    ptr -= 0x2000;

    // Just try to read stack guard page
    volatile char ch = *ptr;

    return 0;

}

//--------------------------------------------------------------
static void AccessStackGuardFromOtherThread () {
    printf("AccessStackGuardFromOtherThread\n");

    unsigned localVar;  
    HANDLE exceptionThread = (HANDLE)_beginthreadex(
        NULL,
        0,          // stack size
        ThreadProc,
        &localVar,  // Pass local variable pointer
        0,          // suspended = false
        NULL
    );
    
    // Wait for the thread finish
    WaitForSingleObject(exceptionThread, INFINITE);
}

//--------------------------------------------------------------
static LONG WINAPI OurUnhandledExceptionFilter (EXCEPTION_POINTERS * ep) {
    printf ("OurUnhandledExceptionFilter: exception code = %X\n", ep->ExceptionRecord->ExceptionCode);  
    if (ep->ExceptionRecord->ExceptionCode == STATUS_GUARD_PAGE_VIOLATION)
        printf("STATUS_GUARD_PAGE_VIOLATION :%0X\n", ep->ExceptionRecord->ExceptionInformation[1]);
    return EXCEPTION_EXECUTE_HANDLER;
}

//--------------------------------------------------------------
void main () {
    SetUnhandledExceptionFilter(OurUnhandledExceptionFilter);
    AccessStackGuardFromOtherThread();
    Crash();

    printf("End of Program.\n");   // This will never be called
}

인터넷을 검색해보니 이미 이 문제에 관해 아래와 블로그 글들이 올라와 있군요.

http://blogs.msdn.com/oldnewthing/archive/2006/01/17/513779.aspx

같은 프로세스에서 뿐만 아니라, 읽기 메모리 권한(

PROCESS_VM_READ)을 다른 프로세스에 부여하는 것만으로도 똑같이 프로그램 크래시를 유발할 수 있습니다. 또한 예외처리 핸들러에서 가끔 사용되는 IsBadxxxPtr API들도 똑같은 문제를 유발시킵니다. 아래 블로그를 참고하시기 바랍니다.

http://blogs.msdn.com/larryosterman/archive/2004/05/18/134471.aspx

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.