멀티프로그래밍 위키로 바로가기 → http://www.devnote.net/wiki

구글 Public DNS 발표

기타/잡담 2009/12/06 16:37
구글이 Public DNS 서비스를 발표하였습니다. 보다 빠른 인터넷 환경을 만들기 위한 것이라고 합니다. 기존에 존재하는 DNS서버를 사용한 것이 아니라 자체 제작한 서버를 사용하며, 구글이 이미 가지고 있는 전세계 네트웍 인프라를 이용해 다른 어떤 DNS서버보다 빠르고 안정적인 서비스를 제공 할 수 있다고 합니다.

DNS 서버하면, 2003년에 우리나라 에서 일어난 이른바 인터넷 대란이 생각이 나는군요. DNS는 인터넷에서 상당히 중요한 존재이지만 웜바이러스의 공격이나 보안에 취약한 문제를 가지고 있습니다. 저도 집에 있는 라우터의 DNS 주소를 Open DNS에서 구글의 Public DNS로 바꾸었습니다.

구글은 검색 엔진을 통해 수익을 만드는 Open DNS와는 달리, DNS 표준 프로토콜에 충실하며 당장 이를 이용해 어떠한 수익을 만들 것 같지는 않습니다. Wired에 난 기사를 보면 구글의 Public DNS에 부정적 반응을 나타내고 있기도 합니다.

하지만, 조금 생각해 보면, 지금 당장 밝히지는 않고 있으나 OpenDNS가 제공하는 것과 같은 DNS를 이용한 다른 서비스를 제공하는 것은 충분히 가능한 일입니다. 예를들면 피싱 (Phising) 싸이트차단과 같은 것 입니다. URL이름을 기존의 유명 은행이나 회사 URL과 비슷하게 만들어 놓은 피싱싸이트는 별도의 크라이언트 모듈을 거치지 않고도 DNS 검색에서 걸러질 수도 있습니다.  구글 입장에서는 자신이 하면 더 잘 할 수 있고, 잠재적인 수익도 기대할 수 있고, 추가 비용도 크지 않다면 하지 않을 이유가 없는 것 입니다. 이것은 또한 인터넷에서 구글의 파워와 제어권을 키우는 하나의 수단일 수도 있습니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
인터넷
트랙백 0 : 댓글 0

64비트 OS의 적절한 메모리 크기는?

분류없음 2009/09/08 14:44
얼마전 Windows 2003 Server (64비트 버전) 에서 실행 중인 테스트용 파일 서버가 매우 느려지며 시스템 리소스 부족현상이 나타났습니다. 이 서버는 4GB의 메모리를 가지고 있었으며, 파일서버 서비스 프로그램은 이중 최대 3.5GB의 메모리를 자체 캐쉬 메모리로 사용할 수 있도록 프로그램되어 있었습니다. 그런데, 문제는 64비트 윈도우즈가 파일 시스템 캐쉬로 모든 물리 메모리를 사용하려 한다는 하는 것이었습니다. 아래 SQL 서버와 관련하여 비슷한 문제가 이미 알려져 있었습니다.

http://sqlblogcasts.com/blogs/grumpyolddba/archive/2009/03/18/x64-memory-problems.aspx

윈도우즈와 어플리케이션이 메모리를 가지고 서로 경쟁하는 상황이 발생하는데, 윈도우즈는 어플리케이션의 워킹셋(working set)을 스왑파일로 페이지 아웃시킬 수도 있다는 것입니다. 이 시점에서 윈도우즈의 시스템 파일 캐쉬는 의미가 없어집니다. 왜냐하면, 어플리케이션이 사용하는 메모리가 하드디스크로 페이징 되면, 페이징 하는 시간 뿐만 아니라, 이 메모리를 액세스하기 위해 많은 시간이 소요됩니다. 특히, 수학적 데이터 프로세싱(수치해석, 이미지 프로세싱, 3D 랜더링과 같은)을 다루는 프로그램에서 이런 현상이 생기게되면, 프로그램의 속도는 엄청나게 떨어지게 됩니다. (메모리와 HDD속도 비유를 참고하시기 바랍니다.)

이 문제는 Windows 7에서 향상되었다라고 하는데 얼마나 어떻게 향상되었는지는 아직 알 수 없습니다. 다행히, SetSystemFileCacheSize()를 사용하여 시스템 캐쉬 메모리 크기를 조정할 수 있습니다. 그리고 SysInternals의 Cacheset.exe라는 유틸리티를 사용하여 변경 확인 가능합니다.

그런데, 여기서 좀 더 생각해보면, 64비트 Windows는 약 8TB라는 엄청난 메모리 주소공간을 가지기 때문에 64비트 OS나 어플리케이션이 한꺼번에 많은 물리메모리를 사용할 가능성은 얼마든지 있다는 것 입니다. (32비트 프로그램은 64비트 윈도우즈에서 4GB의주소공간을 가짐)

그럼 128GB를 가진 64비트 윈도우즈가 있다고 합시다. 처음드는 생각은 엄청난 메모리라는 것인데, 단순히 메모리 주소공간을 생각하면, 이는 32비트 윈도우즈에 48MB의 메모리를 설치한 정도 밖에는 되지 않습니다. 128GB 메모리는 거대 공룡에게 사과 한 쪽을 먹으라고 주는 것에 불과합니다. 물론, 아직 이렇게 많은 메모리를 사용할 프로그램은 드물 것이라 생각할 수도 있지만, 위의 파일서버 문제와 같이 윈도우즈가 파일 시스템 캐쉬를 계속 메모리에 쌓아두거나, 어떤 64비트 프로그램이 의도했든 아니면 버그이든 메모리를 많이 사용하기 시작하면 128GB는 아무 것도 아니라는 것 입니다.

여기서, 얻을 수 있는 점은 64비트 운영체제와 64비트 어플리케이션을 제작 (특히 서버 프로그램)함에 있어, 시스템메모리의 크기에 따라 실제 최대 얼마 만큼의 메모리를 사용할 것인지, 미리 잘 정해야만 한다는 것 입니다. 특히 파일 액세스가 많은 프로그램의 경우 윈도우즈 시스템의 파일 캐쉬도 염두해 두어야만 합니다. 하나에 1TB 싸이즈의 DIMM 메모리가 나온다면 상황은 달라지겠지만 말입니다.

크리에이티브 커먼즈 라이센스
Creative Commons License
64bit, 메모리
트랙백 0 : 댓글 0

낙관적 동기화(Optimistic synchronization) 혹은 lock-free가 의미하는 것은?

멀티스레드 프로그래밍/Lock-Free 자료구조 2009/08/14 04:14
“The Art of Multiprocessor Programming” 을 다시 읽기 시작하면서, 낙관적 동기화(Optimistic synchronization) 혹은 lock-free에 대한  재미있는 비유를 발견하였습니다. 아래 원문과 제가 이것을 번역한 것을 복사하여 놓았습니다. 어딘가 잡지에서 나왔을 법한 유머지만, 멀티프로세서에서 lock-free 프로그래밍을 하는 것에 대한 적절한 비유가 아닐까 생각합니다.

A tourist takes a taxi in a foreign town. The taxi driver speeds through a red light. The tourist, frightened, asks “what are you are doing?” The driver answers: “Do not worry, I am an expert.” He speeds through more red lights, and the tourist, on the verge of hysteria, complains again, more urgently. The driver replies. “Relax. relax. you are in the hands of an expert.” Suddenly, the light turns green, the driver slams on the brakes, and the taxi skids to a halt. The tourist picks himself off the floor of the taxi and asks “For crying out loud, why stop now that the light is finally green?” The driver answers “Too dangerous. could be another expert crossing.”


한 여행자가 외국 도시에서 택시를 탔다. 택시기사는 빨간 신호등을 무시하고 속도를 내며 지나갔다. 여행자가 불안해하며 "뭐하시는 겁니까?"라고 물었다. 택시기사는 "걱정 마세요. 저는 전문가입니다." 라고 대답했다. 택시기사는 몇 개의 빨간 신호를 더 지나갔고 여행자는 겁에 질려, 보다 다급히 불평했다. 택시기사는 "당신은 전문가의 손 안에 있으니, 편하게 있으세요"라고 대답했다. 갑자기 신호가 녹색으로 바뀌자 택시기사는 급제동했고 택시는 미끄러지며 정차했다. 여행자는 택시 바닥에서 몸을 일으키며 큰 소리로 물었다. "이제 마침내 녹색불이 켜졌는데 왜 정차합니까?" 택시기사는  "너무 위험하오. 다른 전문가가 지나갈수 있습니다."라고 답했다.

크리에이티브 커먼즈 라이센스
Creative Commons License
멀티스레딩
트랙백 0 : 댓글 0

웜 바이러스의 DDoS 공격

기타/잡담 2009/07/11 16:46
서버 소프트웨어의 보안 설계를 함에 있어 가장 골치아픈 것 중의 하나가 요즘 한국을 떠들썩하게 하고 있는 DDoS 공격입니다. 그런데, 이러한 DDoS 공격은 항상 있어 왔고 전혀 새로운 것이 아니기 때문에, 이번에 갑자기 한국에서 큰 이슈로 등장한 이유가 매우 궁금하여 이리 저리 검색을 해보았습니다.

이번에 퍼지고 있는 웜 바이러스는 W32.Dozer 라는 것으로 감염이 되면 Trojan.Dozer 를 설치하는 것으로 알려져 있습니다. 이 트로이 목마 프로그램이 DDoS로 공격하는 주목표는 한국의 정부, 은행과 미국 정부 싸이트이기 때문에, 한국 싸이트들을 마비시키며 이슈화되지 않았나 생각이 드는군요.

우연히도 이틀전 하나의 수상쩍은 메일을 받았는데 임의로 작성된 제목에 하나의 URL 링크만 달랑 있는 메일이었습니다. 이 URL이 가르키는 페이지의 내용을 다운로드하여 잠시 분석해 보니 역시나, MyDoom과 비슷한 웜바이러스 였습니다. 아마도 Dozer에 감염된 PC에서 2차적으로 전파시킨 웜 바이러스가 아닌가 생각이 됩니다. 이 웜 바이러스는 아래와 같이 기존에 이미 알려진 윈도우즈의 보안 취약점을 이용한 공격을 시도하고 있었습니다.

  1. MDAC vulnerability  http://www.microsoft.com/technet/security/Bulletin/MS06-014.mspx
  2. Yahoo WebCam ActiveX vulnerability http://www.kb.cert.org/vuls/id/949817
  3. Zero day Flash vulnerability using http://www.roaster.kr/branch/br_img/upsa.jpg
  4. IE vulnerability   http://www.microsoft.com/technet/security/bulletin/ms06-057.mspx

이들 공격에 사용된 두 싸이트는 www.roaster.kr, www.om108.com 로 한국과 중국의 웹싸이트인 것이 좀 특이하였습니다.

그런데 이러한 공격방법은 이미 수년전부터 알려진 것으로 최신 보안 패치를 적용한 경우, 쉽게 감염되지 않습니다. 특히 많은 공격 수법이 ActiveX의 보안 취약점을 이용한다는 것인데, ActiveX를 지원하지 않는 FireFox를 쓰거나, IE에서 ActiveX 사용을 disable함으로써 많은 공격을 차단할 수 있다는 점입니다. 한국의 경우 정부를 비롯해 금융기관까지 ActiveX를 많이 사용하고 있기 때문에 ActiveX의 실행을 disable 시키기 힘들다는 점에서, 한국이 상대적으로 웜 바이러스의 공격에 더 취약하다고 하겠습니다.


오늘 우연히 7월 6일에 MS싸이트에 올라온 또 다른 ActiveX 관련 보안 경고를 보게 되었습니다. 이 보안 취약에 대한 보안 패치는 다음 주 화요일에 발표될 예정이라고 합니다. 그런데, 이 보안 취약점을 살펴보면 IE의 Microsoft Video ActiveX Control을 이용하여 임의의 원격 코드 실행(Remote Code Execution)을 할 수 있다는 것입니다. 이 ActiveX 컨트롤이 얼마나, 또 어떻게 자주 사용되는 지는 알 수 없으나,  이 취약점을 악용하도록 조작된 비디오 파일을 IE에서 플레이 하는것 만으로도 웜바이러스에 감염이 된다는 것, 즉 다시 말해 감염된 웹싸이트를 단순히 방문하는 것 만으로 웜바이러스에 감염되고 이 바이러스가 내 컴퓨터를 마음대로 제어할 수 있다는 것으로 상당히 심각해 보입니다. 이번 한국에 W32.Dozer이 퍼진 시기와 이 보안 취약점이 알려진 시기가 거의 같은 것은 우연의 일치일까요 아니면 이것이 진짜 주범이었을까요?


크리에이티브 커먼즈 라이센스
Creative Commons License
DDoS, 웜 바이러스
트랙백 0 : 댓글 0

MS-SQL GUID index

데이터베이스 2009/06/23 15:38
MS-SQL로 만든 DB에서 UniqueIdentifier 칼럼을 만들어 Index를 설정하거나 이를 Primary key로 사용하면, 말 그대로 GUID 즉, 쉽게 글로벌 유일성(Global Uniqueness)를 보장해 주게 됩니다. DB에서 UniqueIdentifier 즉 UUID 혹은 GUID를 인덱스로 사용하느냐 아니면 int, bigint, number 등의 정수형을 사용하느냐에는 따른 많은 장단점이 있습니다.

GUID 값은 이른바 Pseudo Random 값으로, 16 bytes 크기로 상당히 큰 싸이즈이며, index를 크게 단편화(fragmentation)시킬 수 있다는 단점이 있습니다. 아래 블로그에서 보듯이 Windows 7 RC 다운로드 싸이트가 다운된 원인이 클라이언트에서 제공하는 GUID 값을 SQL DB 인텍스로 사용한데 기인한 것이라고 합니다. 이것은 결국 SQL의 성능을 급격히 저하시켜 웹페이지를 매우 느리게 만들었다는 것 입니다.

http://www.sqlskills.com/BLOGS/PAUL/post/Why-did-the-Windows-7-RC-failure-happen.aspx

SQL 2005에서 추가된 NEWSEQUENTIALID() 는 상당히 fragmentation을 줄여주는 것으로 나타나 있습니다. NEWSEQUENTIALID()는 내부적으로 UuidCreateSequential Windows API를 사용하는데 이는 컴퓨터 MAC 주소를 가지고 있어, 여전히 유일성을 보장해주고 있습니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
SQL
트랙백 0 : 댓글 0

멀티코어는 멀티코어다

멀티스레드 프로그래밍/일반 2009/06/12 05:25
아래 마이크로소프트사의 KB를 보면 2의 배수가 아닌 멀티코어 CPU에서는 SQL 서버 2005를 설치할 수가 없다고 합니다. 최근에 AMD를 시작으로 3-Core, 6-Core 등이 발표되고 있는 시점에서 문제가 발견되었다고 생각되는군요.

http://support.microsoft.com/kb/954835

SQL 버그라고 웃어 넘길려고 하다가 잠시, 내가 짠 코드에도 비슷한 문제는 없는지 다시 보게 되었습니다. 또, CPU 개수가 2의 배수라고 가정하고 개발된 프로그램들이 아마도 또 있을 것이라는 추측을 하게 됩니다. 같은맥락에서 32비트 unsigned int 값을 가지고 비트연산하여 각각의 비트를 하나의 CPU로 연관지어 프로그램하는 예는 흔히 있는 일 입니다. 이경우 32개 이상의 CPU지원은 불가능하게 됩니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
트랙백 0 : 댓글 0

C++ Volatile keyword

멀티스레드 프로그래밍/참고 자료 2009/06/04 15:34
C++ Volatile 에 관해 아주 잘 정리된 문서를 아래에 발견하였습니다.

http://blogs.msdn.com/ericeil/archive/2007/10/26/fun-programming-problem-a-simple-lock-free-algorithm.aspx
크리에이티브 커먼즈 라이센스
Creative Commons License
트랙백 0 : 댓글 0

Windows 7 XP Mode

기타 2009/05/06 03:14
이른바 가상화 (Virtualization) 기술은 이미 Windows에 적용되어 사용되고 있습니다. VMware가 선두주자이며 Microsoft는 Hyper-V를 서버 2008부터 채용하고 있는데, 특히 최근에 이들 두 회사는 기본적인 Virualization 소프트웨어를 무료로 공급하기 시작했습니다.

제 경우에는 Virtual PC 2007을 사용하여 가상 Windows XP를 Vista 컴퓨터에서 사용하고 있습니다. 가상화 기술로 VM (Virtual Machine)을 만들었을 때 장점은 여러 가지가 있습니다만, 제 경우는

1. 여러 가지 OS (언어별 버전별)의 호환성 테스트에 매우 유용합니다. 미리 만들어진 VM 디스크 이미지를 이용 쉽게 여러 OS를 하나의 컴퓨터에서 실행할 수 있습니다. 이 디스크 이미지는 하드웨어에 종속되지 않아 다른 컴퓨터로 복사 실행이 자유롭습니다.

2. 호스트 OS를 변경하지 않고 프로그램을 설치/제거 할 수 있다는 점. 가장 대표적인 예로는 인터넷 뱅킹을 위해 IE에 여러 개의 ActiveX 모듈을 설치해야만 하는 경우, 저는 XP VM을 실행하여 이 곳에서만 인터넷 뱅킹을 합니다. 초기 Virtual Disk 이미지를 백업해 놓으면 언제든지 아무런 프로그램도 설치되지 않은 깨끗한 상태의 Windows XP로 부터 다시 시작할 수 있습니다. 더 나아가 Virtual Disk 이미지를 암호화시키면 (TrueCrypt 등의 유틸리티 사용) 이곳에 저장된 데이터도 안전하게 보관할 수 있습니다.

3.오래되어 사용하지 않는 컴퓨터에 있던 Windows XP 라이센스를 다시 사용할 수 있습니다.

최근 Windows 7의 XP모드는 다름 아닌 Virtual PC를 탑재한 것 입니다. 이러한 방법으로 비스타에 이슈가 되었던 호환성 문제를 피하겠다는 것이지요. (XP 호환성 100% 지원은 이미 포기하였기 때문이기도 합니다.)

CPU나 메모리를 상당히 많이 사용하는 어플리케이션이나 고화질의 3D그래픽을 사용하는 게임을 제외하고는 VM에서 아무런 문제가 없이 실행됩니다.

이 가상화 기술은 서버 분야에서도 매우 유용합니다. 강력한 멀티코어 CPU가 보편화되어가는 요즘, 여려 개의 VM을 하나의 서버에 설치함으로써 하나의 컴퓨터를 마치 여러 대의 컴퓨터처럼 사용할수 있는 것 입니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
Virtualization
트랙백 0 : 댓글 0

INTRODUCTION TO ALGORITHMS

멀티스레드 프로그래밍/참고 자료 2009/05/01 02:57
제 책장에도 유명한 알고리즘 책 중의 하나인 Introduction to Algorithms 의 첫번째 에디션이 아직 꽂혀 있습니다. 대학원 다닐 때 구입한 것인데, 부분 부분 참고로 읽었던 기억이 납니다.

이 책의 3번째 에디션에 "Multithreaded Algorithm" 챕터가 추가된 모양인데, 아래 링크에서 샘플로 다운로드 받아 볼 수가 있습니다. 좋은 셀프 스터디 자료가 되지 않을까 생각합니다.

http://www.cilk.com/resources/multithreaded-algorithms-textbook-chapter/
크리에이티브 커먼즈 라이센스
Creative Commons License
멀티스레딩
트랙백 0 : 댓글 0

쓰레드 퀀텀 (quantum)

멀티스레드 프로그래밍 2009/04/29 15:28
학창시절 운영체제(OS) 시간에 쓰레드 퀀텀 (quantum) 혹은 시분할 (time slice)에 관해 배운 적이 있습니다. 최근 우연히 팀 프로그래머 중 한 명이 윈도우즈 서버에서 퀀텀의 크기가 상당히 크다는 것을 다시 상기시켜 주었습니다.

Windows Internals 책에 따르면 윈도우즈 XP의 경우는 6, 윈도우즈 서버의 경우는 36의 퀀텀 값을 갖는다고 합니다. (3 퀀텀이 1 클럭에 해당함)

보통 인텔의 멀티프로세서 시스템은 1 클럭 간격이 15ms 이므로, XP는 30ms, 서버는 180ms의 시간이 (한 번의 쓰레드 스케줄링으로)  하나의 쓰레드에 할당되는 것 입니다.
 물론 쓰레드가 대기(wait)상태로 들어간다면, 이 퀀텀을 다 사용하지 못하고 context switch가 일어 날 수 있습니다.

이러한 퀀텀 값은 또한 윈도우즈의 Performance Option 에서 변경 가능 합니다. (Application = 6 퀀텀 혹은 Background Service = 36 퀀텀 둘 중 선택 가능)

원도우즈 서버가 180 ms라는 상당히 큰 퀀텀 값을 가지는 이유는 서비스 어플리케이션 쓰레드에게 작업을 수행할 충분한 시간을 주기 위함입니다. 또 잦은 context switch는 전체 성능을 저하시킬 수 있기 때문입니다. 하지만 XP와 같은 Client OS의 경우 사용자에게 빠른 응답을 하는 것이 중요하므로 (예를 들면 UI 쓰레드) 작은 퀀텀 값을 갖는 것입니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
멀티스레딩
트랙백 0 : 댓글 0
◀ PREV : [1] : [2] : [3] : [4] : [5] : ... [10] : NEXT ▶