Máy chủ đầu cuối 2008 R2: Có nguồn tài nguyên hệ thống không đủ để hoàn thành dịch vụ được yêu cầu

Tôi đang làm việc với Máy chủ đầu cuối Windows 2008 R2 không lành mạnh được định cấu hình trong môi trường vSphere. Nó hiện có 4 vCPUs và 32GB RAM. Không thừa thãi.

Số lượng người dùng đồng thời trên máy chủ này đã tăng mạnh trong những tháng gần đây (~ 70) và có thể vượt quá mức được đề xuất. Do các ứng dụng được sử dụng bởi người dùng trên hệ thống này, việc chia nhỏ ứng dụng này thành nhiều máy chủ sẽ là một thách thức vượt ra ngoài phạm vi của câu hỏi này.

Tuy nhiên, tại một số điểm nhất định trong tuần (và bây giờ, gần như hàng ngày), đăng nhập người dùng mới tạo ra các lỗi sau: ID sự kiện 1500

Windows không thể đăng nhập bạn vì hồ sơ của bạn không thể được tải. Kiểm tra xem bạn đã kết nối với mạng chưa và mạng của bạn có hoạt động chính xác không.

CHI TIẾT - Tài nguyên hệ thống không đủ tồn tại để hoàn thành dịch vụ được yêu cầu.

Điều này vẫn còn cho đến khi một số người dùng đăng xuất, các phiên bị ngắt kết nối thủ công hoặc hệ thống được khởi động lại hoàn toàn.

Tôi muốn biết:

• Thông báo lỗi này đề cập đến tài nguyên nào? Điều gì thực sự bị hạn chế?
• Có một điều chỉnh hoặc cấu hình cấp hệ điều hành có thể giúp với điều này?
• Người dùng có nội dung với hiệu suất, ngoại trừ tần suất tăng của thông báo lỗi này. Có cái gì khác chơi ở đây?
• Có giới hạn tuyệt đối cho số lượng người dùng mà máy chủ đầu cuối có thể đáp ứng không? Tôi thấy hơn 150 người dùng được mô tả trong các hướng dẫn điều chỉnh nhất định cho Máy chủ đầu cuối.

Điều này đã được giải quyết.

Tôi bắt đầu kiểm tra sổ đăng ký vì việc tăng tài nguyên CPU và RAM trên máy ảo không giải quyết được vấn đề.

Tôi đã được chỉ đến công cụ dureg của Microsoft để ước tính kích thước của sổ đăng ký. Duyệt qua regedit, tôi gặp phải vấn đề khi mở các phím bên dưới HKEY_USERS\.Default\PRINTERS. Sử dụng dureg, tôi bắt đầu thăm dò theo hệ thống phân cấp đó.

Máy in là vấn đề. Nguyên nhân và cách khắc phục được nêu chi tiết trong:
Kích thước của sổ đăng ký "HKEY_USERS.DEFAULT" tăng liên tục trên máy chủ chạy Windows Server 2008 R2 SP1

Hotfix: http://support.microsoft.com/kb/2871131

Điều này rõ ràng ngăn chặn sự tăng trưởng, nhưng các khóa và đăng ký cần phải được nén để lấy lại không gian.

Nén registry cồng kềnh: 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

Hmm, một vài bước ... hơi khó để làm từ xa trong giờ sản xuất. Tôi đã cố gắng liên hệ với chuyên gia Microsoft thường trú của mình để hoàn thành, nhưng anh ấy đang bận rộn theo đuổi một số vấn đề SCCM hoặc SCVMM ở đâu đó . Đọc qua một số diễn đàn liên quan đến Citrix, tôi đã lưu ý đến một công cụ có thể thực hiện các thao tác trên với ít bước hơn ...

Vì vậy, tôi đã chụp ảnh máy ảo, sau đó tải xuống và chạy phần mềm nén registry miễn phí (Tweaking.com) ; bất chấp âm thanh tràn ngập tiếng rên rỉ tập thể của các kỹ sư hệ thống Microsoft ở khắp mọi nơi ...

lưu ý 1,4 GB được lưu trong Cấu hình mặc định ...

HÃY KHỞI ĐỘNG LẠI!

Sau khi khởi động lại, tất cả đều tốt. Số lượng người dùng đạt 86 mà không có hiệu ứng xấu và không có lỗi liên quan đến hồ sơ. Tôi đã theo dõi trung tâm đăng ký máy in và nó được giữ ổn định.

Trong Windows Server 2003, lỗi đó là kết quả của việc cạn kiệt bộ nhớ kernel. Vì bạn đang xử lý Windows Server 2008 R2 Tôi không chắc nguyên nhân của sự cố liên quan đến nguyên nhân trong W2K3 như thế nào, nhưng tôi cá rằng đó là vấn đề về bộ nhớ do số lượng người dùng và quy trình. Tôi sẽ xem sự cạn kiệt bộ nhớ của Nonpaged Pool là nguyên nhân có thể xảy ra. Ngoài ra, số lượng mua sắm là gần 800, khá cao. MS có thể sẽ bảo bạn giảm số lượng tiến trình, điều này chỉ có thể được thực hiện bằng cách giảm tải người dùng.

Bài viết này có một số thông tin tốt về việc sử dụng bộ nhớ trong Windows và cách bạn có thể xem giới hạn nhóm Nonpaged để xem đó có phải là nguyên nhân của sự cố không:

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

Khởi động Windows Performance Monitor để theo dõi các bộ đếm khác nhau:

• Chuyển mạch bối cảnh
• Mục nhập bảng
• Các yếu tố GDI
• Xử lý
• Càng (bất cứ điều gì bạn có thể tìm thấy)

Và xem nếu một trong những đỉnh này khi bạn đăng nhập thất bại.

Ngoài ra: một cái gì đó đang gây ra% CPU nhân cao trên hệ thống của bạn - bạn nên điều tra xem liệu nó có dẫn bạn đến một vấn đề liên quan không.

Các Hồ sơ người dùng Hive Cleanup dịch vụ có thể giúp ra ở đây vì nó "giúp đảm bảo phiên người dùng được hoàn toàn chấm dứt khi người dùng log off".

Chà, từ những gì tôi đã đọc về lập kế hoạch dung lượng RDS trong Server 2008 R2, bạn có thể đang chạy máy chủ đầu cuối kém của mình với không đủ tài nguyên cho số lượng người dùng bạn đang sử dụng. Đặc biệt, tôi nhận thấy rằng bạn có 80 người dùng trên 4 vCPUS và MS khuyến nghị 1 lõi trên 15 người dùng.

Từ blog kỹ thuật có tiêu đề Hướng dẫn lập kế hoạch năng lực và định cỡ 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:

• Bộ nhớ 2GB (RAM) là giới hạn tối ưu cho mỗi lõi của CPU. Ví dụ: Nếu bạn có RAM 4 GB thì để có hiệu năng tối ưu, nên có CPU lõi kép.
• 2 CPU Dual Core hoạt động tốt hơn sau đó là bộ xử lý Quad core đơn.
• Băng thông được đề xuất cho LAN của 30 người dùng và WAN của 20 người dùng. Băng thông (b) = 100 megabit mỗi giây (Mbps) với Độ trễ (l) Dưới 5 mili giây.
• Trên Terminal Server 64 MB cho mỗi người dùng là yêu cầu Bộ nhớ lý tưởng (RAM) cho GP Chỉ sử dụng + 2 GB cho HĐH Eg (100 người dùng * 64) + 2000 = 8.4 GB tức là RAM 8GB.
• Nhiều ứng dụng được sử dụng (ví dụ Office, Ứng dụng CAD, v.v.) sẽ cần thêm bộ nhớ cho mỗi người dùng để thêm vào tính toán này trên bộ nhớ cơ sở 64 MB cho mỗi người dùng.
• Phiên 15 TS trên mỗi lõi CPU là giới hạn hiệu suất tối ưu của Máy chủ đầu cuối.
• Mạng không được có quá 5 bước và độ trễ phải dưới 100ms.
• 64 kbps là Băng thông lý tưởng cho mỗi phiên người dùng. (256 màu, mạng chuyển đổi, chỉ bộ nhớ đệm bitmap)
• Hiệu suất CPU suy giảm nếu% thời gian xử lý trên mỗi lõi liên tục trên 65%.
• Hiệu suất của các máy chủ đầu cuối tăng gấp đôi khi nó chạy trên X64 CT và HĐH.

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

Tải về tại đây

Tôi có rất ít thời gian vì vậy tôi sẽ chỉ làm một câu trả lời sơ sài và hy vọng nó sẽ được đưa ra sau.

Khi tôi làm phép trong các đội Citrix, tôi nhớ chúng tôi đang cố gắng tăng cấp tới 15-20 người dùng cho mỗi máy chủ, nhưng những ứng dụng này có một số ứng dụng nặng đang chạy. Những ngày này của x64, chúng tôi tải nhiều người dùng hơn, nhưng 70+ nghe có vẻ rất nhiều.

Bộ đếm perfmon tối đa hóa không phải là hiếm khi chuyển đổi ngữ cảnh, nó sẽ tạo ra một máy chủ trong khi các bộ đếm khác như RAM, CPU, v.v. Có thể đó là một lý do (máy chủ không thể phân bổ tài nguyên trước khi hết thời gian do chuyển đổi ngữ cảnh quá mức). Dưới đây là hai cách để theo dõi chuyển đổi ngữ cảnh :

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.

Ngoài ra, bạn có thể tìm thấy một cái gì đó sử dụng trong hướng dẫn lập kế hoạch năng lực, bạn tìm thấy một liên kết đến nó trong bài viết trên blog này .

Khi tôi có thể kéo dài thời gian cho câu trả lời này, tôi sẽ làm như vậy, tôi sẽ chỉ thận trọng thêm vào các phép đo dựa trên mọi thời gian trong một máy ảo vSphere.

Do cách vCPU được trừu tượng hóa từ các CPU vật lý, vCPU không có manh mối về thời gian (một giây ảo có thể nhiều hơn hoặc ít hơn một giây thực (hoặc ít nhất là vật lý). bộ đếm perfmon (thời gian CPU, công tắc ngữ cảnh / giây, v.v.) không chính xác (đôi khi thậm chí rất dữ dội), ngay cả khi chúng có thể đóng vai trò là các chỉ số hạt rất thô.

Để xác minh điều này, hãy so sánh bất kỳ bộ đếm CPU dựa trên thời gian riêng nào trong VM với đối tác của nó trên máy chủ vSphere cho VM đó. Vì lý do này, VMware xuất bản một số bộ đếm cho CPU (và Bộ nhớ cũng không chính xác từ góc độ khách) thông qua các công cụ VMware thành hai đối tượng perfmon VMguest.

Do đó, các giá trị dựa trên thời gian chính xác được cung cấp từ bên trong perfmon khách, nhưng chỉ khi người ta nhìn vào bộ đếm đối tượng được công bố của VMware.

Tôi chỉ nghĩ rằng thông tin cơ bản này có một chút liên quan vì các câu trả lời cho đến nay đang tập trung vào các phép đo dựa trên thời gian từ bên trong một máy ảo vSphere, trong đó trong một số trường hợp là một tình huống quan trọng để phân tích chính xác. Tất nhiên nó cũng liên quan trực tiếp đến chủ đề của câu trả lời cụ thể (chưa hoàn thành) này và các bình luận của nó. Nó có thể được sử dụng cho một ai đó.

Ngay khi tôi có thời gian, tôi sẽ chỉnh sửa các liên kết đến các trang trắng, v.v., chi tiết về điều này và các đường dẫn truy cập chính xác \ tên. Tự nhiên nó cũng là tất cả.

Tôi sẽ đề nghị triển khai WSRM (Trình quản lý tài nguyên hệ thống Windows). Khi có rất nhiều ứng dụng, kết nối, dịch vụ chạy trên một máy chủ, hệ thống không biết rằng mọi người cần chơi tốt với nhau. Windows Server tự nhiên cố gắng sử dụng tất cả các tài nguyên của nó để hoàn thành mọi thứ mọi lúc trừ khi được biết ... nhập WSRM.

Bằng cách triển khai WSRM, bạn có thể đặt giới hạn tài nguyên theo tất cả các loại biến thể để đảm bảo có một sân chơi đồng đều cho mọi thứ đang chạy hoặc người dùng được kết nối. Từ ghi chú của bạn, điều này dường như không phải là vấn đề ESX / vSphere mà là quá nhiều người dùng được kết nối, những người liên tục cạnh tranh cho mọi thứ. Bạn sẽ phải kiểm tra WSRM để tìm một phương tiện hạnh phúc để cân bằng tài nguyên giữa mọi thứ nhưng cũng không ảnh hưởng đến mức hiệu suất mà mọi người đã quen với.

Tổng quan về WSRM: http://technet.microsoft.com/en-us/l Library / cc732553.aspx