Sử dụng bộ nhớ cao với hồ bơi ứng dụng w3wp IIS 7

Question

Tôi có một ứng dụng trang web chạy trong nhóm ứng dụng riêng của nó trên IIS 7.0. Ứng dụng này là một trang web ASP.NET MVC 3.

Tôi đã nhận thấy việc sử dụng bộ nhớ cho các ứng dụng này tương ứng với dịch vụ nhân viên IIS w3wp khá cao (800 MB, với một số biến động).

Tôi cố gắng để chẩn đoán vấn đề và đã thử như sau:

tôi đã vô hiệu hóa bộ nhớ đệm trang đầu ra cho các trang web ở cấp IIS và sau đó tái chế hồ bơi ứng dụng. Điều này làm cho quá trình w3wp khởi động lại. Việc sử dụng bộ nhớ cho quá trình này sau đó từ từ leo lên đến khoảng 800 MB, phải mất khoảng 30 giây để làm như vậy. Không có yêu cầu trang nào được xử lý tại thời điểm này. Khi tôi khởi động lại trang web từ IIS, kích thước bộ nhớ của quá trình không thay đổi.

Tôi đã thử chạy bản sao gỡ lỗi của ứng dụng từ VS 2010, không có vấn đề với việc sử dụng bộ nhớ.

Một số ý tưởng tôi có/câu hỏi là:

là vấn đề này liên quan đến mã trang web? - Cho rằng các tên lửa bộ nhớ trước khi bất kỳ yêu cầu trang đã được gửi/xử lý, tôi sẽ giả định đây không phải là một vấn đề mã?

Ứng dụng được xây dựng trong MVC không xử lý bộ nhớ đệm được ghi vào đó.

Trang web sử dụng hiển thị dữ liệu theo thời gian thực, nó sử dụng định kỳ yêu cầu ajax và thường được để 'mở' trong một thời gian dài.

Tại sao tên lửa sử dụng bộ nhớ tăng lên sau khi ứng dụng được tái chế và không có yêu cầu nào của người dùng được gửi? Có phải vì nó đang tải thông tin bộ nhớ cache cũ vào bộ nhớ của nó từ đĩa?

Ứng dụng này không sụp đổ, tôi chỉ quan tâm đến việc sử dụng bộ nhớ, nó không phải là lớn của một trang web ...

Bất kỳ ý tưởng/giúp với nhận để dưới cùng của vấn đề này sẽ được đánh giá .

Answer 1

Tôi chỉ cần xem máy chủ và các hồ bơi của mình sử dụng bộ nhớ kích thước ảo 900-1000MB và bộ làm việc 380MB. Các trang web của tôi chạy trơn tru với vấn đề trong vài năm nay và tôi đã kiểm tra chúng từ mọi phía. Hồ bơi của tôi không bao giờ tái chế và máy chủ chạy cho đến khi bản cập nhật tiếp theo tiếp tục với bộ nhớ vật lý miễn phí ổn định 40%.

Nếu bộ nhớ của bạn không tiếp tục phát triển thì bộ nhớ này là mã cộng với dữ liệu bạn đặt là tĩnh, const, chuỗi và bộ nhớ cache có thể có bên trong ứng dụng của bạn.

Bạn có thể sử dụng process explorer để xem bộ nhớ kích thước hoạt động và bộ nhớ ảo.

Bạn cũng có thể nghĩ để chạy hồ sơ đối với mã của mình để xem liệu bạn có bất kỳ "rò rỉ bộ nhớ" hay sự cố nào khác không. Tìm một từ google: https://www.google.com/search?hl=en&q=asp.net+memory+profiler.

Answer 2

Điều tốt nhất để làm nếu bạn có thể đủ khả năng để sử dụng trình gỡ lỗi là cài đặt Windows Debugging Tools và sử dụng một cái gì đó như WinDbg và SOS.dll để tìm ra chính xác nó là gì trong bộ nhớ.

một khi bạn đã cài đặt các công cụ sau đó bạn có thể:

1. Launch Windbg.exe chạy cao (as Administrator)
2. Sử dụng "File-> Attach To Process" và chọn w3wp.exe cho ứng dụng bạn đang cố gắng tìm ra. Nếu bạn có nhiều bạn có thể sử dụng Task Manager và thêm cột dòng lệnh để xem PID hoặc sử dụng IIS Manager-> Processer Worker để tìm ra nó, và sau đó chọn quá trình đó trong WinDBG.
3. chạy:
4. .loadby sos clr
5. dumpheap -stat

Vào thời điểm đó bạn sẽ có thể nhìn thấy tất cả các loại được sắp xếp theo mức tiêu thụ bộ nhớ nhất, do đó bạn có thể bắt đầu với những người ở đáy. (Tôi sẽ khuyên bạn nên loại trừ Strings, và Object vì chúng thường là một tác dụng phụ chứ không phải nguyên nhân). Sử dụng "! Dumpheap-type type-here" để tìm các trường hợp và sử dụng! Gcroot cho những người tìm ra lý do tại sao chúng nằm trong bộ nhớ, có thể do trường tĩnh hoặc bộ xử lý sự kiện bị rò rỉ, kênh WCF không được xử lý hoặc mọi thứ như vậy là những nguồn thông thường.

Answer 3

Nó có thể không áp dụng ở đây nhưng nghĩ rằng tôi sẽ ném nó vào cho biện pháp tốt. Gần đây tôi đã có một vấn đề mà bộ nhớ của tôi sẽ đi lên và tối đa ra khi nó thực sự có thể làm sạch lên 80% của nó. Vấn đề: Nó nghĩ rằng nó khoảng 2 buổi biểu diễn nhiều hơn nó thực sự đã làm như vậy GC là khá lười biếng. (Đó là do một cửa sổ lỗi máy ảo đã báo cáo 8 Gig nhưng về mặt vật lý chỉ có 6.4). Xem blog. http://www.worthalook.net/2014/01/give-back-memory/

Answer 4

Điều gì đó có thể hữu ích: nếu bạn "viết lại" (mở/lưu) web.config, thì ứng dụng của bạn sẽ đặt lại, bạn nên theo dõi việc sử dụng bộ nhớ từ thời điểm đó. Nếu nó tiếp tục phát triển trong quá trình sử dụng, điều này có nghĩa là bộ nhớ bị rò rỉ hoặc bộ nhớ đệm điên. Bạn có thể xác định những hành động nào trên trang web của bạn dẫn đến tăng bộ nhớ. Trong một thời gian dài việc sử dụng bộ nhớ của một ứng dụng phải ổn định.