2008 R2 터미널 서버 :“요청한 서비스를 완료하기에 시스템 리소스가 부족합니다”

vSphere 환경에서 구성된 비정상적인 Windows 2008 R2 터미널 서버로 작업하고 있습니다. 현재 4 개의 vCPU와 32GB RAM이 있습니다. 과도한 헌신이 없습니다.

이 서버의 동시 사용자 수는 최근 몇 개월 동안 (~ 70) 급격히 증가했으며 권장 수준을 초과 할 수 있습니다. 이 시스템의 사용자가 사용하는 응용 프로그램으로 인해이 서버를 여러 서버로 나누는 것은이 질문의 범위를 벗어나는 문제가됩니다.

그러나 주중 (현재는 거의 매일)의 특정 지점에서 새 사용자 로그온은 다음 오류를 생성합니다. 이벤트 ID 1500

프로필을로드 할 수 없으므로 Windows에서 로그온 할 수 없습니다. 네트워크에 연결되어 있고 네트워크가 올바르게 작동하는지 확인하십시오.

세부 사항-요청한 서비스를 완료하기에 시스템 자원이 부족합니다.

일부 사용자가 로그 오프하거나 세션 연결이 수동으로 끊어 지거나 시스템이 완전히 재부팅 될 때까지 유지됩니다.

알고 싶습니다 :

• 이 오류 메시지는 어떤 리소스를 참조합니까? 실제로 무엇이 제한됩니까?
• 이를 도울 수있는 OS 레벨 조정 가능 또는 구성이 있습니까?
• 사용자는이 오류 메시지의 빈도 증가를 제외하고 성능에 만족합니다. 여기에 다른 것이 있습니까?
• 터미널 서버가 수용 할 수있는 사용자 수에 대한 절대 제한이 있습니까? 터미널 서버의 특정 조정 안내서에 150 명 이상의 사용자가 설명되어 있습니다.

이것은 해결되었습니다.

가상 컴퓨터의 CPU 및 RAM 리소스를 늘려도 문제가 해결되지 않아 레지스트리를 검사하기 시작했습니다.

레지스트리 크기를 추정 하기 위해 Microsoft의 dureg 도구를 지적했습니다 . regedit를 통해 탐색 할 때에서 키를 여는 데 문제가 발생했습니다 HKEY_USERS\.Default\PRINTERS. 을 사용하여 dureg해당 계층에서 조사를 시작했습니다.

프린터가 문제였습니다. 원인과 수정 내용은 다음에 자세히 설명되어 있습니다.
"HKEY_USERS.DEFAULT"레지스트리 하이브의 크기는 Windows Server 2008 R2 SP1 기반 서버에서 지속적으로 증가합니다

핫픽스 : http://support.microsoft.com/kb/2871131

이것은 분명히 성장을 멈추지 만 공간을 확보하기 위해 키와 레지스트리를 압축해야합니다.

팽창 된 레지스트리 압축 : http://support.microsoft.com/kb/2498915

1)  Boot from a WinPE disk.
2)  Open regedit while booted in WinPe, load the bloated hive under HLKM. (e.g. HKLM\Bloated)
3)  Once the bloated hive has been loaded, export the loaded hive as a "Registry Hive" file with a unique name.
4) Unload the bloated hive from regedit.
5) Rename the hives so that you will boot with the compressed hive.
e.g.
c:\windows\system32\config\ren software software.old
c:\windows\system32\config\ren compressedhive software

흠, 몇 걸음 ... 생산 시간 동안 원격으로하기가 좀 까다 롭습니다. 나는 나의에게 도달하려고 상주 마이크로 소프트 전문가 완료하려면하지만 그는이었다 일부 SCCM 또는 SCVMM 문제의 어딘가에 아래로 바쁜 쫓는 . Citrix 관련 포럼을 통해 적은 단계로 위의 작업을 수행 할 수있는 도구에 주목했습니다.

그래서 나는 가상 머신 스냅 샷을 찍어 프리웨어 레지스트리 압축 소프트웨어 (Tweaking.com) 를 다운로드하여 실행했다 . 모든 Microsoft 시스템 엔지니어들의 신음 소리에 압도적 인 소리 에도 불구 하고 ...

1.4GB는 기본 구성에 저장되어 있습니다 ...

재부트하십시오!

재부팅 후 모든 것이 정상이었습니다. 사용자 수는 86 개에 달하며 아무런 영향도없고 프로필 관련 오류도 없습니다. 프린터 레지스트리 하이브를 모니터링했으며 안정적으로 유지됩니다.

Windows Server 2003에서이 오류는 커널 메모리 소진의 결과였습니다. Windows Server 2008 R2를 다루고 있기 때문에 문제의 원인이 W2K3의 원인과 얼마나 밀접한 관련이 있는지는 확실하지 않지만 사용자와 프로세스 수로 인해 메모리 문제라고 확신합니다. 가능한 원인으로 비 페이징 풀 메모리 소진을 살펴 보겠습니다. 또한, 프로세서 수는 거의 800 명으로 상당히 높습니다. MS는 아마도 프로세스 수를 줄 이도록 지시 할 것입니다. 프로세스 수는 사용자로드를 줄임으로써 만 가능합니다.

이 문서에는 Windows의 메모리 사용량과 비 페이징 풀 제한을보고 문제의 원인인지 확인하는 방법에 대한 유용한 정보가 있습니다.

https://blogs.technet.com/b/markrussinovich/archive/2009/03/26/3211216.aspx

Windows 성능 모니터를 시작하여 다양한 카운터를 모니터링하십시오.

• 컨텍스트 스위치
• 페이지 테이블 항목
• GDI 요소
• 핸들
• … (무엇을 찾을 수 있는지)

로그인에 실패했을 때이 피크 중 하나가 나타나는지 확인하십시오.

또한 : 시스템에서 커널 CPU %를 높이는 원인이 있습니다. 관련 문제를 일으키는 지 확인해야합니다.

사용자 프로필 하이브 정리 는 "사용자가 로그 오프 할 때 사용자 세션이 완전히 종료되도록하는 데 도움이됩니다"라고 서비스는 여기에 도움이 될 수 있습니다.

Server 2008 R2의 RDS 용량 계획에 대해 읽은 내용을 보면 사용중인 사용자 수에 따라 부족한 리소스로 부족한 터미널 서버를 실행하고있을 수 있습니다. 특히 4 개의 vCPU에 80 명의 사용자가 있으며 MS는 15 명의 사용자 당 1 개의 코어를 권장합니다.

제목은 TechNet 블로그에서 RDS 크기 조정 및 용량 계획 지침 :

We always felt the need of Hardware capacity guidance and sizing information for Terminal Services or Remote Desktop services for Server 2008 R2, Whenever I am engaged in any architectural guidance discussion for RDS deployment i always get a question what needs to be taken into consideration while deciding the hardware configuration and to do capacity planning.

Here are some bullet points which I recommend to my partners and customers to consider:

• 2GB 메모리 (RAM)는 CPU의 각 코어에 대한 최적 한계입니다. 예를 들어 RAM이 4GB 인 경우 최적의 성능을 위해서는 듀얼 코어 CPU가 있어야합니다.
• 2 듀얼 코어 CPU는 싱글 쿼드 코어 프로세서보다 성능이 뛰어납니다.
• LAN은 30 명, WAN은 20 명입니다. 대역폭 (b) = 대기 시간이 100Mbps 인 초당 Mbps (l) 5 밀리 초 미만.
• 터미널 서버에서 사용자 당 64MB는 GP에 이상적인 메모리 (RAM) 요구 사항입니다. OS Eg (100 명 * 64) + 2000 = 8.4GB, 즉 8GB RAM의 경우 + 2GB 만 사용하십시오.
• 더 많은 응용 프로그램 (예 : Office, CAD Apps 등)을 사용하려면 사용자 당 64MB 기본 메모리보다이 계산에 사용자 당 더 많은 메모리를 추가해야합니다.
• CPU 코어 당 15 TS 세션은 터미널 서버의 최적 성능 한계입니다.
• 네트워크는 5 홉을 초과하지 않아야하며 대기 시간은 100ms 미만이어야합니다.
• 64kbps는 사용자 세션 당 이상적인 대역폭입니다. (256 색, 스위치 네트워크, 비트 맵 캐싱 만 해당)
• 코어 당 프로세서 시간이 지속적으로 65 %를 초과하면 CPU 성능이 저하됩니다.
• 터미널 서버 성능은 X64 HW 및 OS에서 실행될 때 두 배가됩니다.

In addition to that, Microsoft has just released a whitepaper on Capacity Planning in Windows Server 2008 R2.

여기에서 다운로드하십시오

나는 시간이 거의 없기 때문에 스케치 답변을하고 나중에 그것을 육체적으로 살피겠습니다.

시트릭스 팀에서 철자를 할 때 서버 당 15-20 명의 사용자를 레벨링하려고했지만 그 중 일부는 무거운 앱이 실행되고있었습니다. x64의 요즘에는 더 많은 사용자를로드하지만 70+ 이상이 많이 들립니다.

perfmon 카운터가 최대로 전환되는 것은 거의 컨텍스트 전환이 아니며 RAM, CPU 등과 같은 다른 카운터는 좋아 보였지만 서버를 플로어링했습니다. 아마도 그 이유 일 수 있습니다 (과도한 컨텍스트 전환으로 인해 시간이 초과되기 전에 서버가 리소스를 할당 할 수 없음). 컨텍스트 전환을 모니터링 하는 두 가지 방법 은 다음과 같습니다 .

The System\Context Switches/sec counter in 
System Monitor reports systemwide context 
switches.

The Thread(_Total)\Context Switches/sec  
counter reports the total number of context 
switches generated per second by all threads.

또한 용량 계획 안내서에서 유용한 정보를 찾을 수 있으며이 블로그 게시물 에서 링크를 찾을 수 있습니다.

이 답변에 대한 시간을 확보 할 수 있으면 vSphere 가상 시스템 내의 모든 시간 기반 측정에주의를 기울여 여기에 추가하겠습니다.

vCPU가 물리적 CPU에서 추상화 된 방식으로 인해 vCPU는 몇 시인 지에 대한 실마리를 갖지 못합니다 (가상 1 초는 실제 1 초보다 크거나 작을 수 있음). perfmon 카운터 (CPU 시간, 컨텍스트 스위치 / 초 등)는 매우 거친 입자 표시기 역할을하더라도 정확하지 않은 경우가 있습니다 (때로는 매우 격렬함).

이를 확인하려면 VM 내의 기본 시간 기반 CPU 카운터와 해당 VM의 vSphere 호스트에있는 해당 CPU 카운터를 비교하십시오. 이러한 이유로 VMware는 VMware 도구를 통해 CPU에 대한 일부 카운터 (및 게스트 관점에서 부정확 한 메모리)를 두 개의 VMguest perfmon 객체에 게시합니다.

따라서 게스트 perfmon 내에서 올바른 시간 기반 값을 사용할 수 있지만 VMware에서 게시 한 개체 카운터를 보는 경우에만 가능합니다.

필자는 지금까지 답변이 vSphere 가상 머신 내에서 시간 기반 측정에 중점을두기 때문에이 기본 정보가 약간 관련이 있다고 생각했습니다. 여기서는 올바른 분석을위한 중요한 상황입니다. 물론이 특정 (미완성) 답변의 주제와 그 의견과 직접 관련이 있습니다. 누군가에게 유용 할 수 있습니다.

시간이 되 자마자이 백서 등에 대한 링크와 정확한 카운터 경로 / 이름을 편집합니다. 당연히 구글도 마찬가지입니다.

WSRM (Windows System Resource Manager)을 구현하는 것이 좋습니다. 하나의 호스트에서 실행되는 수많은 앱, 연결, 서비스가있는 경우 시스템은 모두가 함께 놀아야한다는 것을 알지 못합니다. Windows Server는 자연스럽게 WSRM을 입력하지 않으면 모든 리소스를 사용하여 모든 것을 항상 완성하려고합니다.

WSRM을 구현하면 모든 종류의 변형에 따라 리소스 제한을 설정하여 실행 중이거나 사용자가 연결된 모든 항목에 고른 운동장이 있는지 확인할 수 있습니다. 노트에서 이것은 ESX / vSphere 문제가 아닌 것처럼 모든 것에 끊임없이 경쟁하는 연결된 사용자가 너무 많은 것 같습니다. WSRM을 테스트하여 모든 리소스간에 균형 잡힌 리소스를 찾아야하지만 모든 사람이 익숙해 진 성능 수준에도 영향을 미치지 않아야합니다.

WSRM 개요 : http://technet.microsoft.com/en-us/library/cc732553.aspx