http://technet.microsoft.com/en-us/library/cc966425.aspx

This paper explains how batches are cached and reused in SQL Server 2005, and suggests best practices on maximizing reuse of cached plans. It also explains scenarios in which batches are recompiled, and gives best practices for reducing or eliminating unnecessary recompilations.

본 문서에서는 SQL 2005 서버에서 배치들이 어떻게 캐쉬 되고 재 사용되는 지를 설명합니다, 그리고 캐쉬된 플랜들의 재사용을 최대화 하는데 최상의 예를 제시합니다. 이 문서는 또한 배치들이 리컴파일 되는 예를 통해서 불필요한 리컴파일을 줄이고 제거하는 최상의 예를 전달합니다.

TPC-E 는 2007년 2월에 소개된 OLTP (일반 RDB) 을 위한 성능 측정 자료 입니다.
TPC-H 는 업무에 특성화된 ad-hoc 쿼리나 Concurrent 데이터의 변경에 대한 성능 측정 자료 입니다.

자세한 내용은 아래 자료를 참고하시기 바랍니다.
http://www.microsoft.com/sqlserver/2008/en/us/benchmarks.aspx

You can not install a application with this message “Windows cannot access the specified device, path, or file.  You may not have appropriate permissions to access the file."

It is caused by IE 7’s enhanced security option.
To solve this problem. simply set this option IE 7 > Internet option > security tab > internet > custom level > Launching applications and unsafe files to verify or unused.

IE 7을 사용하는 경우 아래의 보안 옵션이 “사용 안 함”으로 되어 있는 경우 믿을 수 없는 모든 exe 설치 파일을 거부하게 됩니다.

출처 : Windows Internals 5th Edition

Root Partition

VM Service
- MMC를 통한 Child Patition 관리를 위한 WMI 인터페이스 제공
- Root Partition의 어플리케이션과 Hyper –v 및 Child Patition 과의 통신을 책임 짐
- Device Visible 여부 및 CPU Memory 할당

VM Work Porcess
- 스냅 샷이나 상태 전환, Hypervisor에서 전달하는 여러가지 알림 (디바이스의 노출과 같이 VM Service의 설정과 함께 움직이는 일들)과 같은 전형적인 모놀릭 Hypervisor에서 수행 했던 일들을 수행
- vmwp.exe 로 표현되며, 가상화 스택상에서 터미널 서버의 RDP와 비슷한 역활(View, 인터페이스)을 수행

Virtualization Service Providers
- Child Patition에 노출된 장치들의 고속 에뮬레이션을 담당 (VM 서비스와는 역활이 다름)

VM Infrastructure Driver
- Hyper – v 와 유저 모드 어플리케이션인 VM Service 간의 직접 통신이 불가능 하기 때문에 사용하는 커널 모드 디바이스 드라이버 (VID)
- MIMIO 및 ROM 과 같은 Lowmemory 장치 서비스 제공

Hypervisor API Library
- Hypervisor 와 Child Partition 간의 인터페이스 역확 (Hyper call)
- winhv.sys 디바이스 드라이버로 구현 되어 있음

Hyper – V
- 부팅 시 hvboot.sys 로딩 후 AMD의 경우 Hvax64.exe 인텔인 경우 Hvix64 로딩 (가상화 구현 방식이 약간 다르기 때문)

Child Partition

Hypervisor에 의해 관리되는 자신의 Guest Virtual Address Space (GVA)로 제약 됨

Virtualization Service Clients (VSCs)
- Child Partition에 디바이스의 에뮬레이션을 담당 (실제 디바이스는 에뮬레이션 디바이스와 Synthetic 디바이스로 나눠지며, 후자가 성능이 우수함)

Enligthements
- 윈도우 가상화 성능 향상의 키라고 할 수 있는 것으로 윈도의 커널 코드를 가상화에 맞게 변경한 것
- 일반적인 윈도 커널과는 다른 방식으로 동작하며 하드 웨어에 종속적이며, 결과적으로는 Hypercall 로 가공됨을 의미 (예 : Hypervisor는 오랫동안 지속되는 루프가 실행 될 때, 해당 루프를 모두 추적하는 것이 아니라 변경되는 사항만을 확인 더욱 구체적으로 이야기 하자면 Child Partition에서 APIC 가 실행 중일 때 H/W 적인 인터럽트가 발생 하면 당연히 해당 인터럽트가 처리되는게 정상이나 해당 Child Partition에 이런 인터럽트가 해당 되지 않으면 차단하는 역활도 하며, 메모리 관리의 경우 TLB를 Flushing 하는 경우 CPU에서 이 명령 셋이 모든 Child Partition에 적용 되게 되는데 이를 방지하는 역활도 진행)

원문 : http://blogs.msdn.com/ntdebugging/archive/2009/12/11/pool-fragmentation.aspx
모든 권리는 원문 저작자에 있습니다.

안녕하세요. 제 이름은 스태판입니다. 저는 Microsoft의 Global Escalation Service Team에서 Escalation engineer로 근무하고 있습니다. 오늘은 제가 최근에 경험했던 풀 메모리의 단편화에 대해서 이야기 하겠습니다. 자 덤프파일을 보도록 하겠습니다.

아래는 !vm에 대한 결과 입니다.

!poolused /t5 2 명령어를 통해 nonpaged pool 사용량이 많은 유저들을 확인해 보았습니다.

!vm 의 결과는 101MB 의 사용을 표기 하고 있으나 !poolused 는 65MB 의 사용이 확인 됩니다. 이는 바로 풀 메모리 단편화를 의미합니다. 조사 결과 저는 많은 풀 페이지들이 아래와 같은 패턴으로 구성되어 있음을 확인하였습니다.

페이지 fa808000 은 0x18 = 24 byte 크기 입니다.  fa808000 과 fa808a38의 모든 페이지들은 freed 되어 이고, 다른 목적을 위하여 재사용 될 것입니다. 위의 페이지에서는 4096 Bytes 중 24 Bytes 만 사용 중입니다.

이런 상황은 fa550000 과 f8feb000 에서도 동일하게 나타나고 있습니다. 자 우리의 질문은 왜 이런 일들이 일어나고 어떻게 하면 이런 상황을 미연에 방지 할 수 있는가? 입니다.

이 덤프에서 저는 많은 MmCm 의 Pool 메모리 사용 현황을 확인 하였습니다.

다음은 일반적으로 단편화가 발생 하기 위한 상황 입니다.

1) 드라이버가 0xF18 크기의 풀 블럭을 요구합니다.  위의 3개의 풀 모두 Free 된 공간의 총합은 충분히 0xF18 크기 이상이 됩니다. 하지만 전체 페이지 4K는 3개로 분활 되어 있고, 이중 이 Free 된 공간은 꼭대기와 밑쪽에 위치하고 있습니다. 그리고 둘 모두 0xF18 크기를 할당 할 만큼 크지 못합니다.
2) 그래서 OS는 드라이버의 요청에 대한 새로운 풀 페이지를 제공합니다. 그리고 역시 밑쪽의 공간은 Freed pool 로 표시 됩니다.
3) 자 아주 작은 크기의 Pool에 대한 요청이 진행 됩니다. OS는 위에서 할당한 풀의 밑쪽 공간을 제공하게 됩니다.
4) 드라이버 MmCm이 사용하던 Pool을 해제 합니다. 하지만 해당 풀 페이지의 하단 부분은 아직도 사용 중이고, 그래서 해당 페이지가 전체는 Freed 되지 못합니다. 그리고 시간이 흘러서 이 공간은 다른 목적을 위해 할당 되게 됩니다.
5) 자 또 0xF18 크기의 풀 블럭을 요청됐습니다. 이전의 풀 블럭은 다른 용도로 이미 할당되어 사용되고 있어 새로운 요청에 사용할 수 없습니다. 그래서 OS는 다시 새로운 페이지를 할당하여 풀 블럭을 제공합니다.
6) 위와 같은 일들로 인해 풀 메모리는 점점 단편화 되게 됩니다. 그리고 그 증거가 바로 이 crash memory dump 죠.

이와 같은 이슈를 피하기 위해서는 0xF18 사이즈의 요청 대신에 전체 풀을 커버할 수 있는 4K 사이즈의 메모리를 요청하는 것이 좋습니다. 물론 할당된 페이지의 약간의 잔여 공간을 활용하지 못하긴 합니다. 하지만 그 대신에 위와 같은 단편화 현상은 방지 할 수 있습니다. 참고로 MSDN에서는 드라이버의 MmCm ( MmAllocateContiguousMemory ) 이용은 충분히 길게 사용하도록 권고 하고 있습니다. 라이브 디버깅을 할 때, 여러분은 연속적으로 할당 되고 해제 된 MmCm을 볼 것 입니다.

참고 링크
http://msdn.microsoft.com/en-us/library/ms801986.aspx
http://blogs.msdn.com/ntdebugging/archive/2006/12/18/Understanding-Pool-Consumption-and-Event-ID_3A00_--2020-or-2019.aspx

* 아직은 많이 부족하기 때문에 제가 자신이 생길 때 까지 본 글은 제 블로그에 대한 링크만 허용합니다.

드디어 돌고 돌아 커널에 대한 설명을 시작합니다. 아직도 절반을 못 왔군요…ㅜㅜ

Privilege Level

윈도상에서 동작하는 모든 실행 코드들은 Privilege Level 을 할당 받습니다. 이 Privilege Level 이란 컴퓨터의 안정성을 위하여 임의로 설계 해 놓은 권한으로써 0레벨이 가장 높은 권한에 해당합니다. 실제로 CPU가 메모리를 참조하는 단위인 세그먼트에는 이 권한을 명시해 놓은 DPL flag가 있습니다.

그래서 어떤 메모리를 참조하게 되면 우선은 DPL을 검사한 다음 PDE 및 PTE의 User/Supervisor bit를 검사하게 됩니다.
하지만 윈도우즈의 경우 가상 메모리 상에서 커널레벨과 유저레벨이 분리가 되어 있어 DPL 검사는 생략하고 PDE와 PTE의 User/Supervisor bit 검사를 통해 해당 메모리의 접근 가능 유무를 판단하게 됩니다.

앞에서 설명한 것과 같이 0 레벨은 가장 권한이 높습니다. 이는 가장 신뢰를 할 수 있다는 의미로써, OS Kernel의 실행 영역이며, 레벨 3은 가장 신뢰가 낮은 영역으로 이 영역에서 동작하는 Application의 문제로 인한 영향의 정도를 줄일 수 있습니다.

이와 같은 신뢰성 확보를 위해 3레벨에서는 실행 가능한 명령어를 제한 하고 있습니다.
이렇게 커널에서만 실행 되는 명령어는 시스템과 관련된 명령어들 (예 : 인터럽트 처리 / cli, sti , IO 처리 / in, out ) 등이 있으며, 이를 통해 우리는 커널의 가장 중요한 역활은 인터럽트 처리라는 것을 확인 할 수 있습니다.

* 아직은 많이 부족하기 때문에 제가 자신이 생길 때 까지 본 글은 제 블로그에 대한 링크만 허용합니다.

쓰래드의 상태 변화

윈도우에서 실행 되는 쓰래드들은 실제로 위의 8가지 상태 중 한 가지의 상태가 됩니다.
먼저 init 단계를 쓰래드의 생성 단계입니다. 이렇게 생성된 쓰래드는 먼저 우선 순위가 설정되지 않은 상태 Deferred Ready에서 대기하다 우선 순위가 결정 되면, Ready 상태에서 대기하게 됩니다. 그리고 이중 우선 순위가 가장 높은 쓰래드를 선택하고 다음 번에 실행 하도록 합니다. 이렇게 스케줄러에 의해 다음 번에 실행하도록 결정된 쓰래드는 Standby 상태가 됩니다. 이 Standby 상태의 쓰래드는 현재 Running 중인 쓰래드와 우선 순위를 비교하여 자신이 우선 순위가 높은 경우 해당 스래드를 디스패치 시킨 후 자신이 실행 (Running 상태) 되게 되고, 우선 순위가 낮은 경우 해당 쓰래드가 실행 하도록 할당 받은 시간 (퀀텀) 을 다 소비할 때 까지 기다리게 됩니다. 이렇게 실행 중인 쓰래드는 대부분 동기화 객체 WaitForSingleObject나 Sleep 에 의해 자발적으로 대기하거나 예를 들어 페이지 아웃된 페이지를 찾아 메모리에 올리는 것과 같이 시스템에 의해 일시 정지하게 되는데, 이 상태를 Wait 라 합니다. 또한 대기 상태 중 쓰래드의 커널 스택이 디스크로 페이지 아웃되어 바로 준비 상태로 가지 못하는 상태를 Transition 이라 하며, 쓰래드의 실행이 종료 된 경우는 Terminate 상태라 합니다.

스레드의 우선 순위

Windows 의 스레드 스케줄링은 스레드 우선 순위와 라운드 로빈 방식을 조한한 형태 입니다. 위 그림과 같이 실시간 처리가 필요한 스레드의 경우 우선 순위를 높게 주고, 다소 느린 처리가 가능한 경우에는 우선 순위를 낮게 준 후 동일 우선 순위 사이에서는 큐의 가장 앞에 있는 스레드를 처리하게 됩니다.

스레드가 CPU를 점유하는 시간 간격을 앞서 설명한 것처럼 퀀텀이라고 합니다. Windows 2000 이후의 OS에서는 퀀텀 부스팅이 가능 합니다. 이는 퀀텀 시간을 늘려 주는 것으로 예를 들어 활성 윈도우에서 실행 되는 스레드의 경우 해당 스레드의 퀀텀 부스팅을 통해서 유저 엑션에 대한 응답속도를 높이고 있습니다.

스레드는 퀀텀 기간 동안 CPU를 점유하게 됩니다. 하지만 아래와 같은 경우 스레드의 실행은 잠시 멈추게 됩니다.

1. 자발적으로 세마포 및 뮤텍스 와 같은 객체를 획득하기 위해 대기하는 경우 (WaitForSingleObject 등 ) : 대기 상태로 전환
2. 더 높은 우선 순위의 스레드 처리를 위한 대기 : 큐의 맨 앞에서 대기 (선점)
3. 퀀텀 시간 소모 : 큐의 맨 뒤에서 대기

위의 그림과 같이 스레드의 우선 순위는 0 ~ 31 까지의 32단계의 값을 갖습니다. 이 중 16이상의 값을 갖는 스레드를 실시간 수준으로 15이하 1이상의 스레드를 가변 수준이라 부릅니다.

우선 순위가 1 ~ 15인 경우 스레드는 처음 프로세스의 우선 순위에 준한 기본 우선 순위를 갖으나, 시스템에 의해 우선 순위가 올라갈 수 있습니다. 예를 들어 실행 준비가 끝난 스레드가 일정 시간 동안 실행 기회를 얻지 못한 경우 Window는 일시적으로 해당 스레드의 우선 순위를 높여 줍니다. 하지만 16이상인 경우에는 고정된 일정한 우선 순위값을 갖게 됩니다.

우선 수위 수준
실시간 : 24
높음 : 13
보통 이상 : 10
보통 : 8
보통 이하 6
Idle : 4

우선 순위가 올라가는 경우
I/O 연산의 완료
실행 이벤트 및 세마포를 기다린 경우
포어 그라운드 프로세스의 스레드들이 Wait를 완료한 직후
GUI 스레드가 윈도우 활동에 의해 깨어난 경우
실행 준비가 완료된 스레드가 한동안 실행 되지 못할 때

동기화

Windows에서 제공하는 동기화 방법은 아래와 같습니다.

동기화 객체	용도	사용 방법
Critical_Section	동일 프로세스내 스래드간 배타적 동기화	InitializeCriticalSection EnterCriticalSection LeaveCriticalSection DeleteCriticalSection
뮤텍스	리소스 배타적 제어	CreateMutex WaitForSingleObject ReleaseMutex ClosedHandle
세마포어	뮤텍스와 비슷하며 카운터를 관리 (해당 카운터 만큼 공동 소유함)	CreateSemaphore OpenSemaphore WaitForSingleObject ReleaseSemaphore
이벤트	다른 스레드에 이벤트를 알림	CreateEvent OpenEvent SetEvent ResetEvent PulseEvent

이전에는 메모리 영역의 구분이네 뭐네 복잡하게 이야기 했는데…
생각해보니 단순한거 같다.

그저… 사용할 수 있는 명령어의 한계가 없다 = 커널 그리고 한계가 있다 = 유저 모드…
다시 말해서 CPU에서 이미 의도된 설계를 통해 구분하는 것이 옮을 듯 하다.

물론 Windows의 경우 가상 메모리 주소의 영역이 분리되어 있는 것은 맞다.
하지만 이는 Windows 디자인에 대한 부분이고, 실제로 커널 권한이라고 하면 바로 CPU구조… 일반적으로 Privileged Level 에 기인한다고 보겠다.

이러한 Priviledged Level 이 높은 명령어를 실행 하는 방법은 3가지가 있다.
1. 인터럽트
2. 시스템 콜 (파일을 쓴다든지 하는 일들…)
3. 콜 게이트 (유저 모드에서 권한을 획득하여 필요한 명령어 수행)

정상적인 상태에서 커널에 일을 시키는 방법은 바로 위의 3가지 이고, 이는 높은 권한이 필요한 명령어를 수행 할때 필요한 것이라고 하겠다.