Tôi nên làm gì để đảm bảo rằng IIS không tái chế ứng dụng của tôi?

Tôi có một ứng dụng dịch vụ WCF được lưu trữ trong IIS. Khi khởi động, nó đi và lấy một tài nguyên thực sự tốn kém (về thời gian và cpu) để sử dụng làm bộ đệm cục bộ.

Thật không may, IIS dường như tái chế quá trình trên cơ sở khá thường xuyên. Vì vậy, tôi đang cố gắng thay đổi cài đặt trên Nhóm ứng dụng để đảm bảo rằng IIS không tái chế ứng dụng. Cho đến nay, tôi đã thay đổi như sau:

• Giới hạn khoảng dưới CPU từ 5 đến 0.
• Hết giờ nhàn rỗi trong Mô hình quy trình từ 20 đến 0.
• Khoảng thời gian thường xuyên theo Tái chế từ 1740 đến 0.

Điều này sẽ là đủ? Và tôi có câu hỏi cụ thể về các mục tôi đã thay đổi:

1. Cụ thể cài đặt Giới hạn khoảng trong CPU có nghĩa là gì? Có nghĩa là nếu vượt quá mức sử dụng CPU nhất định, nhóm ứng dụng sẽ được tái chế?
2. Chính xác thì "tái chế" nghĩa là gì? Là ứng dụng hoàn toàn bị phá hủy và bắt đầu lại?
3. Sự khác biệt giữa "Tắt quy trình công nhân" và "Tái chế nhóm ứng dụng" là gì? Tài liệu về Hết giờ nhàn rỗi trong Mô hình quy trình nói về việc tắt quy trình công nhân. Trong khi các tài liệu về Khoảng thời gian thường xuyên trong Tái chế nói về tái chế nhóm ứng dụng. Tôi không hiểu được sự khác biệt giữa hai điều này. Tôi nghĩ rằng w3wp.exe là quá trình worker chạy pool ứng dụng. Ai đó có thể giải thích sự khác biệt cho ứng dụng giữa hai?

Lý do để có thẻ IIS7 và IIS7.5 là vì ứng dụng sẽ chạy trong cả hai và hy vọng các câu trả lời giống nhau giữa các phiên bản.

Hình ảnh để tham khảo:

Tái chế

Tái chế thường là * trong đó IIS bắt đầu một quy trình mới như một thùng chứa cho ứng dụng của bạn và sau đó cung cấp quy trình cũ cho ShutdownTimeLimit để loại bỏ ý định của chính nó trước khi nó bị giết.

* - thường: xem DisallowOverlickingRotation / "Tắt cài đặt tái chế chồng chéo"

Nó là phá hoại , trong đó quá trình ban đầu và tất cả các thông tin trạng thái của nó bị loại bỏ. Sử dụng trạng thái phiên ngoài quy trình (ví dụ: Máy chủ trạng thái hoặc cơ sở dữ liệu hoặc thậm chí là cookie nếu trạng thái của bạn nhỏ) có thể cho phép bạn giải quyết vấn đề này.

Nhưng theo mặc định, nó bị chồng chéo - có nghĩa là thời gian ngừng hoạt động được giảm thiểu do quá trình mới bắt đầu và được nối với hàng đợi yêu cầu, trước khi thông báo cũ "bạn có [ShutdownTimeLimit] mất vài giây. Hãy tuân thủ."

Cài đặt

Đối với câu hỏi của bạn: tất cả các cài đặt trên trang đó kiểm soát tái chế theo một cách nào đó. "Tắt máy" có thể được mô tả là "tái chế chủ động" - trong đó chính quá trình quyết định đã đến lúc phải đi và thoát ra một cách có trật tự.

Tái chế phản ứng là nơi WAS phát hiện vấn đề và bắn quá trình (sau khi thiết lập W3WP thay thế phù hợp).

Bây giờ, đây là một số thứ có thể gây ra việc tái chế dạng này hay dạng khác:

• một ISAPI quyết định nó không lành mạnh
• bất kỳ sự cố mô-đun
• thời gian chờ
• hạn chế CPU
• điều chỉnh thuộc tính nhóm ứng dụng
  • vì mẹ của bạn có thể đã hét lên tại một thời điểm: "Dừng chọn nó, hoặc nó sẽ không bao giờ tốt hơn!"
• "ping" thất bại * không thực sự ping mỗi se, vì nó sử dụng một đường ống có tên - thêm "phát hiện sự sống"
• tất cả các cài đặt trong ảnh chụp màn hình ở trên

Phải làm gì:

Nói chung là:

• Vô hiệu hóa thời gian chờ nhàn rỗi . 20 phút không hoạt động = bùng nổ! Quy trình mới về yêu cầu đến tiếp theo. Đặt nó thành không.

• Vô hiệu hóa khoảng thời gian thông thường - mặc định 29 giờ đã được các bên khác nhau mô tả là "điên rồ", "khó chịu" và "thông minh". Thật ra, chỉ có hai trong số đó là sự thật.

• Tùy chọn bật DisallowRotationOnConfigChange (ở trên, Vô hiệu hóa Reycling để thay đổi cấu hình ) nếu bạn không thể ngừng chơi với nó - điều này cho phép bạn thay đổi bất kỳ cài đặt nhóm ứng dụng nào mà không báo hiệu ngay lập tức cho các tiến trình công nhân mà nó cần phải bị giết. Bạn cần tái chế thủ công Nhóm ứng dụng để các cài đặt có hiệu lực, cho phép bạn cài đặt trước các cài đặt và sau đó sử dụng cửa sổ thay đổi để áp dụng chúng thông qua quy trình tái chế của bạn.

• Như một nguyên tắc chung, để lại ping kích hoạt . Đó là mạng lưới an toàn của bạn. Tôi đã thấy mọi người tắt nó đi và đôi khi trang web bị treo vô thời hạn, dẫn đến hoảng loạn ... vì vậy nếu cài đặt quá mạnh đối với ứng dụng phản hồi rõ ràng rất rất chậm của bạn, hãy lùi lại một chút và xem những gì bạn nhận được, thay vì tắt nó đi. (Trừ khi bạn có chế độ bán phá giá chế độ tự động được thiết lập cho W3WP treo thông qua quy trình giám sát của riêng bạn)

Điều đó đủ để khiến một quá trình cư xử tốt để sống mãi mãi. Nếu nó chết, chắc chắn, nó sẽ được thay thế. Nếu nó bị treo, ping nên chọn đó lên và một cái mới nên bắt đầu trong vòng 2 phút (theo mặc định; trường hợp xấu nhất calc nên: lên đến tần số ping + ping timeout + Thời hạn khởi động trước khi yêu cầu bắt đầu hoạt động trở lại).

Giới hạn CPU thường không thú vị, vì theo mặc định, nó bị tắt và dù sao nó cũng được cấu hình để không làm gì cả; nếu nó được cấu hình để giết quá trình, chắc chắn, đó sẽ là một trình kích hoạt tái chế. Bỏ nó đi. Lưu ý cho IIS 8.x, CPU Throttling cũng trở thành một tùy chọn.

AppPool (IIS) không phải là AppDomain (.Net) (nhưng có thể chứa một / một số)

Nhưng ... sau đó chúng tôi vào vùng đất .Net và tái chế AppDomain, điều này cũng có thể gây mất trạng thái. (Xem: https://bloss.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variabled-and-appdomain-rec đua / )

Phiên bản ngắn, bạn thực hiện điều đó bằng cách chạm vào tệp web.config trong thư mục nội dung của mình (một lần nữa bằng cách chọn!) Hoặc bằng cách tạo thư mục trong thư mục đó hoặc tệp ASPX hoặc .. những thứ khác ... và đó là về có sức tàn phá như tái chế Nhóm ứng dụng, trừ chi phí khởi động mã gốc (hoàn toàn là khái niệm mã được quản lý (.Net), do đó, chỉ có các công cụ mã được quản lý xảy ra ở đây).

Antivirus cũng có thể kích hoạt điều này khi nó quét các tệp web.config, gây ra thông báo thay đổi, gây ra ....

Vui lòng kiểm tra,

Tại sao chúng tôi tái chế hồ bơi ứng dụng của chúng tôi?

nếu bạn duyệt web để tìm lý do tại sao nhóm ứng dụng được định cấu hình để tự động tái chế định kỳ, bạn sẽ khó tìm được câu trả lời hợp lý không liên quan đến các vấn đề về bộ nhớ. Giống như cộng đồng nói chung đã chấp nhận khá nhiều thực tế là các ứng dụng web của chúng tôi (hoặc các lớp dịch vụ được lưu trữ trong IIS) sẽ cần phải được tái chế để tránh các vấn đề về bộ nhớ.

Tôi luôn có quan điểm rằng nếu mã của bạn yêu cầu khởi động lại định kỳ để tiếp tục hoạt động chính xác, thì rõ ràng có gì đó không đúng. Có một lỗi trong mã của bạn ở đâu đó và bạn cần khắc phục điều đó, thay vì thỉnh thoảng khởi động lại quy trình để làm cho vấn đề 'biến mất'.

Thực sự cần phải bắt đầu tập trung nhiều hơn vào quản lý bộ nhớ trong .NET và đảm bảo rằng các ứng dụng của chúng tôi có thể tiếp tục chạy mà không gặp vấn đề gì.

Dựa trên kịch bản OP (khởi tạo dài khi khởi động / khởi động), một điều cần kiểm tra là giới hạn thời gian khởi động (giây) có giá trị mặc định là 90 giây. Nếu quá trình khởi tạo mất nhiều hơn giới hạn thời gian khởi động, quy trình worker có thể bị chấm dứt.