Trong những trường hợp nào thì các quy trình .NET và AppDomains chia sẻ các assembly được nạp trong bộ nhớ?

Question

Tôi đang tìm thêm thông tin chi tiết về thời gian và cách thức các ứng dụng .NET chia sẻ các assembly được nạp. Tôi quan tâm đến việc chia sẻ giữa các quá trình hệ điều hành, mà còn giữa các AppDomain trong cùng một quá trình. Việc chia sẻ các hội đồng làm giảm việc sử dụng bộ nhớ hệ thống bằng cách tránh có nhiều bản sao của cùng một bộ nhớ trong bộ nhớ, tôi cho rằng đó là lợi ích chính nhưng sẽ được quan tâm để biết nếu có những lợi ích và/hoặc tác động khác.

Một bản tóm tắt về những gì tôi đã học được cho đến nay ...

1. Sysinternals process explorer có thể được sử dụng để liệt kê AppDomains một quá trình .NET và các assembly được nạp vào mỗi AppDomain.

2. Quá trình .NET dường như luôn tải cụm từ 'cốt lõi' vào một AppDomain được gọi là 'SharedDomain' (Điều này là hợp lý để giả định điều này được chia sẻ giữa AppDomains trong quá trình hiện tại).

3. Báo cáo Trình quản lý tác vụ và Trình khám phá quy trình không sử dụng số lượng bộ nhớ không đáng kể cho 'Bộ làm việc được chia sẻ' và 'Bộ làm việc có thể chia sẻ', nhưng không rõ những gì đang được chia sẻ. (Đây có phải là cụm từ 'cốt lõi' trong Shared AppDomain không? Các cụm khác [không phải cốt lõi] được chia sẻ không?

4. Trong một thử nghiệm đơn giản, tôi đã khởi chạy hai bản sao của một ứng dụng .NET độc lập và đính kèm trình gỡ rối Visual Studio vào Mỗi mô-đun được nạp được đặt tại cùng một địa chỉ trong hai tiến trình. nhất thiết phải chia sẻ?)

5. ASP.NET 4.5 hỗ trợ chia sẻ của hội thông qua một cơ chế gọi là lắp ráp thực tập (Xem Look at Sharing Common Assemblies in ASP.NET 4.5, Sharing Common Assemblies, Sharing common assemblies with aspnet_intern.exe). Nó dường như được làm việc bằng cách thiết lập hệ thống tập tin Các liên kết tượng trưng (symlink) để các ứng dụng web khác nhau trỏ đến một thư mục bin chia sẻ, do đó điều này đặt ra câu hỏi liệu ASP.NET có đơn giản sử dụng các liên kết để kích hoạt hành vi chia sẻ chuẩn trong .NET hay không. .NET và IIS AppPools đang diễn ra.

Lưu ý. Trên một máy với Visual Studio 2013 được cài đặt, aspnet_intern.exe có thể được tìm thấy trong:

C: \ Program Files (x86) \ Microsoft SDKs \ Windows \ v8.1A \ bin \ NETFX 4.5.1 Tools \

Đã có những cải thiện hơn nữa về thời gian khởi động ASP.NET và mức sử dụng bộ nhớ trong các phiên bản sau của .NET và Windows Server; Xem ASP.NET App Suspend – responsive shared .NET web hosting, Performance Improvements for ASP.NET Shared Hosting Scenarios in .Net 4.5, nhưng tôi không chắc các thay đổi có liên quan như thế nào đối với câu hỏi này.

Chia sẻ lắp ráp ASP.NET cũng được đề cập trong sách Introducing .NET 4.5.

Cũng tự hỏi liệu mã JITted có được chia sẻ hay không, vì một hội đồng được nạp bao gồm MSIL, tài nguyên, siêu dữ liệu, v.v. và bộ nhớ tiếp theo phải được cấp phát khi mã được JITted.

Ngoài ra còn có cuộc thảo luận này về chia sẻ lắp ráp trong khuôn khổ nhỏ gọn (We Believe in Sharing, MSDN Blogs, Abhinaba Basu)

--- Cập nhật ---

tôi đã sử dụng sysinternals VMMap tool để kiểm tra hai AppPools , một với tổ chức lắp ráp asp.net được thiết lập, người kia không có. Tôi cũng 'xúc động' một trang aspx thử nghiệm để gây ra ASP.NET để tải tất cả các hội đồng (và một global.asax chạy một số lượng nhỏ mã, do đó gây ra một số JITting).

Số liệu sử dụng bộ nhớ được báo cáo cho hai AppPool rất giống nhau, Bộ làm việc, WS Private và WS Shareable về cơ bản là giống nhau. Tuy nhiên, WS Shared lại lớn hơn nhiều trong AppPool 'interning'. Điều này là bất ngờ (với tôi) vì không có Process khác để chia sẻ với, nhưng VMMap cho thấy các khối bộ nhớ (được đánh dấu là '.text' và với Execute/Read protection) được hiển thị như là bộ nhớ chia sẻ trong AppPool interning, trong khi cùng một hội đồng trong AppPool khác không chia sẻ. Giải thích của tôi về điều này là các khối bộ nhớ ảo trong tiến trình đang được ánh xạ tới cùng một bộ nhớ vật lý, và sau đó được báo cáo là 'WS Shared'.

ASLR

Về hội Space Layout Randomization. Công cụ VMMap hiển thị nhiều khối bộ nhớ với một loại 'Hình ảnh (ASLR)'. ASLR ngẫu nhiên vị trí của các hội đồng trong bộ nhớ để ngăn chặn phần mềm độc hại, và tôi tự hỏi liệu điều này có ngăn cản việc lắp ráp interning không hoạt động chính xác hay không. Việc vô hiệu hóa ASLR cho máy bằng cách sử dụng EMET tool đã khiến địa chỉ lắp ráp trở nên thường xuyên hơn nhưng không thay đổi số bộ nhớ được báo cáo, vì vậy nó dường như không ảnh hưởng đến việc lắp ráp interning. Cần lưu ý rằng VMMap vẫn hiển thị hình ảnh với 'ASLR' chống lại chúng, điều mà tôi nghi ngờ đơn giản có nghĩa là một assembly/hình ảnh được đánh dấu là hỗ trợ/cho phép ASLR, không phải ASLR có hiệu lực.

Answer 1

Một trường hợp trong đó chia sẻ lắp ráp xảy ra là các tập hợp được biên dịch thành mã gốc với ngen.exe. Hãy để tôi trích dẫn "CLR thông qua C#" (Chương 1)

Công cụ ngen.exe là thú vị trong hai kịch bản:

...

Giảm thiết lập làm việc của một ứng dụng - nếu bạn tin rằng một assembly sẽ được nạp vào nhiều tiến trình đồng thời, chạy NGen.exe trên assembly đó có thể làm giảm bộ làm việc của ứng dụng. Lý do là vì công cụ NGen.exe biên dịch IL thành mã gốc và lưu đầu ra trong một tệp riêng biệt . Tệp này có thể được ánh xạ bộ nhớ vào nhiều không gian địa chỉ nhiều lần đồng thời, cho phép mã được chia sẻ; không phải mọi quá trình đều cần bản sao mã của riêng nó.