Maystyle :
Catergories
|
Recent Articles
Recent Comments
Recent Trackbacks
Calendar
Archive
Link
Search Catergories
|
Recent Articles Recent Comments Recent Trackbacks Calendar Archive Link Search|
기본 개념과 용어
. Windows API Windows에서 제공하는 기능을 모아 놓은 함수의 집합 카테고리 - 기본 서비스들 - 구성 요소 서비스들 - 사용자 인터페이스 서비스들 - 그래픽스및 멀티미디어 서비스들 - 메세징 및 협업 - 네트워킹 - 웹 서비스 . .NET Framework 자바 Runtime (JRE) 와 동일한 역활을 하는 응용 프로그램 구동 환경 . 서비스, 함수 루틴 - Windows API 함수 : Windows API에서 문서화되고 호출 가능한 서브 루틴 CreateProcess, CreateFile... - 네이티브 시브템 서비스 : 문서화 되지 않은 서비스들 NtCreateProcess 와 같은 Windows 의 CreateProcess 함수가 호출하는 내부 시스템 서비스 - 커널 지원 함수 : 커널 모드에서만 호출 될 수 있는 Windows 서브 루틴 ExAllocatePool - Windows 서비스 : SCM (Service Control Manager)에 의해 시작되는 프로세스 - DLL (Dynamic-Link Library) . 프로세스, 스레드 및 작업 프로세스는 프로그램의 인스턴스를 실행할때 사용되는 리소스 집합에 대한 컨테이너 실제로는 메모리 공간 - 전용 가상 공간 : 프로세스가 사용할 수 있는 가상 메모리 주소들의 집합 - 실행 프로그램 : 초기의 코드와 데이터 및 프로세스의 가상 주소공간 매핑된 것 - 핸들 : 스레드 액세스가 가능한 세마포어, 통신 포트, 파일등의 시스템 리소스 핸들 목록 - 엑세스 토큰 - 프로세스 ID - 최소 하나의 스레드 스레드는 Windows가 실행하는 프로세스 내의 실체 - 프로세스의 상태를 표시하는 CPU 레지스터 집합의 내용 - 커널 모드 와 유저 모드에서 실행 되는 동안 사용될 2개의 스텍 - TLS for use by subsystems, Run-time libraries, DLLs - Thread ID - Security Context (항상 가지는 것은 아니다.) 추가) VAD 는 Linked List 형태의 메모리 집합 Tread는 CPU의 한 클럭을 의미  . 가상 메모리  프로세스가 Access 하는 선형의 주소 공간 실제는 물리적으로 불연속 적인 공간에 위치함 대부분의 시스템에서 가상 메모리는 실제 메모리 보다 크기 때문에 메모리의 일부 Page를 디스크로 옮긴다. 데이터의 페이징 작업을 통해 단일 프로세스의 물리 메모리 점유를 방지 한다. 보통의 32bit 운영체제의 CPU는 32bit의 어드레스 버스 즉 2의 32승 bit에 대한 메모리 어드레싱 밖에 못하게 된다. 하지만 Boot.ini 에 /PAE 옵션을 통해 4G 이상의 메모리에 대한 Access도 지원 하긴 한다. 본디 OS는 CPL을 이용하여 실행 가능한 명령어를 제한한다. 거기에 Windows 아에 커널 단과 유저 단에서 접근할 수 있는 메모리 영역을 분리하여 안정성을 보안 하였다. 기본 적으로 2G / 2G 로 총 4G 의 공간을 나눠 쓰게 된다. 즉 Kernel의 최대 메모리 사용 한계도 2G 유저 프로세스의 최대 메모리 한계도 2G가 된다. 그런데 위에서 말한 것 처럼 /PAE를 이용하면 4G 이상의 메모리를 어드레싱 할 수 있게 된다. (물론 커널은 2G만 사용한다.) 그렇다면 프로세스가 2G 이상을 쓰는 것인가...?? 결론만 말하자면 쓸 수 있다. 물론 모든 Application이 그렇지 않고, SQL의 경우에만 지원하고 있으며, 실제로 2G 이상의 영역은 버퍼로만 사용하게 된다. 그렇다면 4G 일때 유저 Process가 너무 무거워서 2G 이상 주고 싶다면 어떻게 해야할까? 이때는 /3GB 옵션을 주게 된다. 이때 /Userva 한정자를 주는데 이는 /3GB를 주면서 작아지는 PTE (나중에 설명하겠다.) 의 크기를 고정해준다. 왜 PTE가 작아질까? 이유는 간단하다. /3GB를 주면 User Process는 3G를 사용하는 대신 kernel은 1G만 사용하게 되기 때문이다. 물론 64 비트 머신의 경우 2의 64승의 Address 영역을 지원한다. (이론적으로... 현재 기술상 8T/6T 수준으로 지원하는 것으로 알고 있다.) .커널 모드와 사용자 모드 방금전에 언급 했지만 실행 가능 명령어는 CPL과 DPL을 비교하여 이루어 진다. 참조 : http://maystyle.tistory.com/entry/동작-레벨-CPL-Current-Privilege-Level 거기에 Windows의 가장 큰 차이는 바로 메모리 Address 영역이 분리 되는 것이다. 즉 4G의 메모리 가상 메모리 주소 공간이 있다고 할때 0x0000 0000 ~ 7FFF FFFF 는 User Process 가 8000 0000 ~ FFFF FFFF 는 Kernel이 사용하며, CPL이 3일때는 User 영역을 CPL이 0일때는 Kernel 영역의 메모리의 데이터를 실행 할 수 있고, 실제 실행 되는 명령어 또한 각 Level에 맞춰 시스템 영역을 컨트롤 할 경우 CPL 0 에 해당하는 함수가 실행 되게 된다. |
|
폰 노이만의 ISA의 CPU 구조는 다음과 같다.
 - MBR(Memory Buffer Register) : 메모리로부터 읽어 들인 데이터를 저장한다. - MAR(Memory Address Register) : MBR으로 읽어 들일 메모리 주소를 저장한다. - IR(Instruction Register) : 실행된 명령어를 저장하고 있다. - IBR(Instruction Buffer Register) : 메모리로부터 읽어 들인 명령어의 내용을 임시로 저장하고 있다. - PC(Program Counter) : 다음번 실행 명령어의 메모리 주소를 저장하고 있다. - AC, MQ(ACcumulator, Multiplier Quotient) : 산술연산부(ALU)로부터 계산되어진 내용을 임시로 저장하고 있다. CPU의 처리 Cycle은 Fetch Cycle 과 Execution Cycle로 나뉘며, Fetch Cycle에서는 명령을 메모리로 부터 가져오고, Execution Cycle 에서는 해당 명령을 실행 하게 된다. |
|
요즘 Windows 2008 서버의 Windows Server Virtualazation 이나오면서 CPL에 대한 애기를 한다.
종합해 보면 0레벨은 OS 3레벨은 User 로 나뉘는데 -1레벨을 두고 해당 레벨에서 Hyper Visor를 구동해 OS의 성능을 보장한다는 애기다. Anyway~ CPU는 상태에 따라 접근 Address의 범위 제한하는 특권 레벨이 존제한다. 본디 특권 레벨은 0~3 까지 4개의 레벨이 존제 하지만, Windows의 경우 0, 3 두가지 레벨만 존제한다. (2, 3 레벨은 장치 드라이버가 사용하지만, Windows 는 장치 드라이버가 0 레벨을 사용함으로 실제는 0 과 3 레벨만 존제 한다.) 그리고 특권 레벨이 높을 수록 머신을 컨트롤 하는 명령을 수행 할 수 있으며, 예를 들어 CPU를 중지 시키는 HLT 명령을 0 레벨 이외에서 실행 시키면 CPU는 예외을 발생 시킨다. x86 CPU는 4G (2의 32승)의 주소공간을 세그먼트라는 몇개의 영역으로 분활 관리하는데, 각각의 세그먼트는 DPL 값을 설정할 수 있다. 즉 Windows 에서 DPL 값은 0과 3이고, CPU는 자신의 CPL 이하의 DLP을 갖는 세그먼트는 읽을 수 없다. 물론 CPL이 높은 경우 DLP이 낲은 코드를 읽거나 쓸순 있지만 실행은 불가능하다. * API로 배우는 Windows 구조와 원리 |
|
1946년 최초의 컴퓨터 Eniac은 프로그램을 수행하기 위해서 수많은 switch와 cable을 조작하여야 했다.
이에 폰 노이만 프로그램 내장 방식을 제안 하고 1952년 프린스턴 대학에서 실제 ISA (Instruction Set Architecture) 란 이름으로 완성 하였다. Word 의 구조  ISA 는 1000개의 기억 장소를 가지고 있었으며, 각 기억 장소는 위와 같은 40bit 로 이루어진 Word로 구성되어 있었다. 데이터의 경우 1bit의 부호 bit와 39개의 bit를 이용하여 데이터를 표현 하였고, 명령어의 경우 보통 2개의 word를 동시에 포함 할 수 있었는데, 각 명령어는 8bit의 연산 코드와 12bit의 Address 로 구성 되어 있었다. * Windows 구조와 원리 os를 관통하는 프로그래밍의 원리 |
|
경쟁력 있는 문화 가꾸기
부정적 기업문화를 긍정적인 문화로 바꾸는 데는 2-6년이라는 시간이 걸린다. 반면 직원들의 사기와 생산성을 떨어뜨리는 데는 5분도 채 안 걸린다. 또한 고객만족이 아니라 상사만족을 중시하는 문화가 정착하는 데는 백만분의 1초면 된다. - 찰스 B. 다이저트 - |
|
요즘에 시간이 나는 대로 나름 "Windows Internals" 를 열심히 읽고 있습니다.
음음... 그건 그렇고... 자 이벤트 메세지에 풀이 비었다 뭐 이런 메세지가 뜨면서, 보안 탭이 사라지는가 하면 시스템이 굼뜨게 움직입니다... 거의 행 상태...ㅡㅡ;; 이벤트 로그는 아래와 같죠...  보통 File 숫자가 많고 ( 보통 소스를 저장하는 파일 서버 ) 사용량이 많은 경우 발생합니다. 물론 leak 일 가능성도 농후 합니다. (보통 바이러스 백신이나 DRM 툴들이 일으키는 경우가 많습니다.) 어차피 원론적인 해결을 위해서 성능 로그를 수집해서 handle table 과 pool memory를 보면 됩니다만... 전 leak일 가능성을 배제 하고 말씀 드리겠습니다. ------------------------------------------------------------------------------------ File의 object handle은 Kernel 영역 메모리 중 Nonpaged Pool에 저장됩니다. (내일 중에 올리는 Process 까보기를 참조하시면 됩니다.) 본디 운영체제 (ntoskernel.exe) 도 역시 하나의 Process 입니다. 즉 이말은 자신의 object handle table을 지닌다는 말과 같습니다. 즉 이 file 이라는 object의 handle을 저장할려는데 공간을 모두 사용하게 된거죠. ------------------------------------------------------------------------------------ 그런데 보통 PoolMemory는 32Bit 머신의 경우 부팅시 스스로 결정합니다. 일반 적인 경우 다음과 같이 PoolMemory 사이즈가 결정 됩니다. Windows 2003 SP1의 RAM 크기에 따른 Pool Size RAM NonPaged Max Paged Max 0512 MB 125 MB 184 MB 1024 MB 202 MB 168 MB 1536 MB 254 MB 352 MB 2048 MB 252 MB 352 MB 즉 실제 메모리 크기에 맞춰 자동으로 결정하게 됩니다. 즉 어쩔 수 없이 32Bit 운영체제에서는 Pool의 한계를 가질 수 밖에 없습니다. 결론적으로 위와 같이 Pool이 부족하지 않게 하려면 서버의 File 갯수를 정기적으로 점검하여, 미연에 예방 하거나 x64 (64Bit) 운영체제로 업그래이드 하여 Pool Size를 늘리는 수밖에 없습니다. 버전에 따른 Pool Memory 한계 Region IA-64 x64 x86 Process Address Space 7152 GB 8192 GB 2 to 3 GB* Paged Pool 128 GB 128 GB 470 to 650 MB NonPaged Pool 128 GB 128 GB 256 MB |
|
Process Explorer 를 통해 Pool Memory를 확인 하는 방법
보통 Pool 크기를 여러가지로 추정하긴 하지만 가장 좋은 방법은 직접 확인 하는 거겠죠...^^ 그래서 직접 확인 하는 그래도 제가 볼때 젤루 쉬운 방안을 알려드립니다...^^ Process Explorer:
|
|
처음으로 개발과 관련된 이야기를 합니다.
종종 ASP로 개발한 웹 페이지가 5XX 대 Error를 일으키는 경우가 있습니다. 보면 랜덤 하게 발생하나 주기적으로 발생합니다. 자 서버를 볼까요??  ---------------- 아래 처럼 처음에는 생각 했습니다. IIS 6.0 부터는 Worker Process 가 여러게 돌게 됩니다. 이게 w3wc.exe 인데, 프로세스는 핸들 테이블 이라는 것을 가지고 있습니다. 자 테이블이 5개 까지 저장이 가능합니다. 1. 2. 3. 4. 5 까지 썼습니다. 자 6을 쓸려면 어떻게 될까요?? 바로 다시 1을 참조하게 되는 겁니다. 즉 어디선가 개발 단에 leak 있었다는 것을 추정할 수 있습니다. 위의 경우에는 MS 버그 같은 느낌이 진하게 들지만 제가 본 경우는 server.createObject 구문으로 인해 발생했었습니다. 즉 해당 페이지들을 실행 시키는 w3wp.exe의 object 핸들 테이블이 꽉 찬거죠... 보통 저런 경우에는 Server. 을 빼고 createObject로 변경하면 Fix가 가능하며, Windows 2003 SP2를 적용할 경우에도 Fix가 가능한 것으로 보입니다. 아니면 Work Process 의 재생 주기를 줄이는 방법도 있겠죠~~~^^ ----------------- 하지만 아니더군요... 죄송합니다. 일단 해당 Process 는 MTS 입니다. 옛날 버전의 COM+, DCOM 이죠...^^ 이 녀석의 Leak은 확인은 가능하지만, 고칠려면 개발자가 직접 고쳐야 합니다. 자 위의 경우에는 간단합니다. 솔직히 MTS (미들웨어) 사용하는 경우가 있을까요?? 그것두 옛날 버전의 ASP의 MTS를... 그럼... 간단하게 해당 구문의 Server.CreateObject > CreateObject 로 변경해주면 Fix 됩니다. |
