Sử dụng bộ nhớ Core 2012 của Windows 2012 trên dịch vụ SVCHOST / Workstation


9

Chúng tôi có khoảng 200 máy chủ, Hyper V, File Cluster và IIS, tất cả đều gặp cùng một vấn đề, một sự kiện xảy ra trên máy chủ thông qua việc sử dụng bình thường tối đa hoặc gần hết tối đa RAM trên máy chủ. Khi điều này xảy ra, dịch vụ SVCHOST / Workstation, cụ thể (được loại bỏ bằng cách cách ly dịch vụ Workstation với SVCHOST của chính nó) dừng giải phóng tay cầm / luồng và bộ nhớ được sử dụng bởi dịch vụ đó sẽ không bao giờ được giải phóng. Trong một số trường hợp cực đoan, chúng tôi có các dịch vụ Workstation đang sử dụng tối đa 40 GB ram trên máy chủ 255 GB. Cũng tìm thấy lên tới 40 triệu tay cầm trong một số trường hợp.

Khi khởi động lại, tất nhiên, vấn đề sẽ biến mất và không xuất hiện lại cho đến khi tất cả bộ nhớ đã được sử dụng, theo quy trình W3 hoặc HyperV VM, sau đó, dịch vụ Workstation bắt đầu lấy hết RAM. Quá trình này rất chậm và có thể mất vài tuần / tháng tùy thuộc vào dung lượng RAM trên máy chủ.

Cả máy chủ Hyper V và máy chủ IIS của chúng tôi đều truy cập vào các chia sẻ cho các tệp đang hoạt động, các chia sẻ này nằm trên bộ lưu trữ SSD, vì vậy chúng có hiệu suất cao. Chúng tôi đã cài đặt tất cả các bản vá hiện tại nhưng chưa chuyển sang R2 vì chúng tôi có rất nhiều công cụ sẽ biến điều này thành một bước quan trọng và không thể tìm thấy bất kỳ dấu hiệu rõ ràng nào cho thấy điều này sẽ được khắc phục trong R2.

Chúng tôi đã chạy ProcMon và các công cụ khác nhưng trên các máy chủ có vấn đề nhất thì các công cụ đó thậm chí sẽ không chạy. Mặt khác, kết quả họ cung cấp chỉ cho thấy rằng thực sự có sự rò rỉ bộ nhớ trong quá trình đó.

Có cách nào chúng ta có thể giải phóng bộ nhớ khỏi quá trình này hoặc tránh lỗi cùng nhau không? Chúng tôi không muốn phải khởi động lại và chúng tôi không thể khởi động lại quá trình một khi nó ở trạng thái lỗi. Quá trình trở nên đóng băng.

Chúng tôi đang cố gắng tránh thực hiện khởi động lại thường xuyên để 'khắc phục' vấn đề này, vì vậy mọi câu trả lời sẽ được đánh giá cao.


Câu hỏi của bạn là gì?
Andrew Schulman

Thật vậy, chúng tôi làm, nhưng nó mơ hồ ở mức tốt nhất, chỉ cần hàng ngàn / triệu chủ đề mở. Trên các hệ thống có vấn đề nhất, chúng tôi thậm chí không thể chạy các công cụ đó, chúng chỉ làm sập máy chủ.
Craig

Chúng tôi muốn tìm ra một giải pháp tốt để giải quyết vấn đề ngoài việc khởi động lại hộp. Chúng tôi không thể dừng dịch vụ khi vấn đề này bắt đầu.
Craig

KB 2811660 đã được cài đặt chưa? Có phải các hệ thống này đang chạy trình quản lý máy chủ? support.microsoft.com/kb/2793908

Có, KB này đã được cài đặt một thời gian trước. Ngoài ra, rò rỉ này là dành riêng cho dịch vụ Workstation, KB áp dụng cho dịch vụ WMI.
Craig

Câu trả lời:


1

Tôi đã có một vấn đề tương tự kỳ lạ trong đó các Svchost đang phá hủy hiệu suất máy chủ.

Giải pháp: Hóa ra tôi đã có Nhật ký sự kiện đầy đủ. Tôi xóa nó đi và mọi thứ đã được sao lưu và chạy như chưa từng có gì xảy ra.

(Tôi cũng khuyên bạn nên thay đổi kích thước của nhật ký sự kiện từ mặc định, xem bên dưới)

Để đặt kích thước nhật ký tối đa bằng cách sử dụng giao diện Windows
- Khởi động Trình xem sự kiện.
- Trong cây điều khiển, điều hướng đến và chọn nhật ký sự kiện bạn muốn quản lý.
- Trên menu Hành động, bấm Thuộc tính.
- Trong Kích thước nhật ký tối đa (KB), sử dụng điều khiển spinner để đặt giá trị bạn muốn và nhấp OK.

Nghe có vẻ chính xác như những gì đang xảy ra ở đây, nhưng cuối cùng lại trở thành một sửa chữa thực sự dễ dàng. Một khởi động lại sẽ tạm thời giải quyết vấn đề, nhưng ngay khi mọi thứ cố gắng ghi vào nhật ký, mọi thứ sẽ vượt khỏi tầm kiểm soát và chỉ tiếp tục ăn hết tài nguyên.

Hi vọng điêu nay co ich!


-1
>Is there a way we can free up the memory from this process ?

Không có cách nào bạn có thể giải phóng bên ngoài (đúng cách) bộ nhớ được phân bổ hoặc xử lý các tài nguyên mà không làm hỏng ứng dụng vi phạm.

>or avoid the bug all together? 

Bạn đang gặp sự cố rò rỉ bộ nhớ và tài nguyên. Cách duy nhất bạn sẽ giải quyết vấn đề là tìm ra rò rỉ và tránh kích hoạt nó (nếu có thể) hoặc khắc phục rò rỉ ở cấp mã nguồn; Trong trường hợp cuối cùng, bạn cần trợ giúp của Microsoft để sản xuất bản vá, nhưng có vẻ như họ mong đợi bạn nói với họ "chính xác" vấn đề thực sự ở đâu.

Bạn có thể cố gắng tìm ra thủ phạm bằng cách xác định rò rỉ bộ nhớ / tài nguyên bằng cách sử dụng Trình xác minh ứng dụng MS


Kích hoạt là chia sẻ tập tin, mà chúng ta không thể tránh.
Craig

nếu bạn không thể tránh kích hoạt thì hãy tìm rò rỉ với "Trình xác minh ứng dụng" và liên hệ với MS với thông tin đó.
Pat

Các ứng dụng, như có nhiều, tất cả đều là Microsoft. Chúng tôi đã liên hệ với họ, chúng tôi đang tìm kiếm một giải pháp nhanh hơn vì họ nói rằng họ có thể mất vài tuần / tháng để sắp xếp việc này.
Craig

Xem xét MS sẽ không thực sự vội vàng trong việc giải quyết loại điều này trên một hệ điều hành không hiện tại Tôi không nghĩ bạn sẽ tìm thấy một giải pháp nhanh hơn. Một điều khác là nếu bạn nói với họ nơi rò rỉ được đặt.
Pat

Chúng tôi có một trường hợp mở và đã làm việc với họ trong một tháng. Sự rò rỉ theo nghĩa đen là trong dịch vụ Workstation.
Craig

-1

Crear RAM là dễ dàng nhưng không có giải pháp.

Tôi đề nghị Sysiternals RAMMAP hoặc VMMAP để điều tra sâu hơn. Với công cụ này, bạn có thể thấy rõ hơn những gì xảy ra. rất thường xuyên nó là một vấn đề siêu dữ liệu.

Kể từ Server 2008, chúng tôi gặp vấn đề này với tất cả các máy chủ đầu cuối hết bộ nhớ với mức tiêu thụ bộ nhớ không thể tin được theo thời gian khi bắt đầu các ứng dụng từ chia sẻ.

Giải pháp của chúng tôi là lưu trữ các ứng dụng đó trên Terminal Server riêng biệt và thường xuyên xóa mức tiêu thụ bộ nhớ.

Chúng tôi thực hiện điều này với một ứng dụng dòng lệnh c ++ tự thiết kế bằng cách sử dụng
SetProcessWorkingSetSize () với SeDebugPriv đặc quyền trên tất cả các quy trình

Rất khuyến khích không làm điều gì đó như thế này;)


Tại sao downvote? Chính xác những gì đã được yêu cầu! Thật không vui khi cố gắng giúp đỡ ở đây ...
Magnus
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.