Tại sao ngay cả tái chế một hồ bơi ứng dụng?

Question

Có thể ai đó có thể làm sáng tỏ một số câu hỏi đơn giản này:

Tôi có một ứng dụng web .NET đã được xem xét kỹ lưỡng. Nó tải một bộ nhớ cache cho mỗi appdomain (quá trình) bất cứ khi nào một bắt đầu và không thể trả lời đầy đủ các yêu cầu cho đến khi nó hoàn thành tải bộ nhớ cache này.

Tôi đã kiểm tra cài đặt trên hồ bơi ứng dụng của mình và đã bắt đầu tự hỏi tại sao tôi thậm chí tái chế thường xuyên (một lần mỗi 1.000.000 cuộc gọi hoặc 2 giờ).

Điều gì sẽ ngăn tôi đặt chu kỳ tự động thành 24 giờ một lần hoặc thậm chí lâu hơn? Tại sao không hoàn toàn loại bỏ các tùy chọn và chỉ tái chế nếu bộ nhớ quay ngoài tầm kiểm soát cho appdomain?

Answer 1

Lý do họ làm điều đó là một ứng dụng có thể "không hoạt động" ngay cả khi CPU và bộ nhớ của nó là tốt (nghĩ bế tắc). Việc tái chế ứng dụng là một biện pháp không an toàn cuối cùng có thể bảo vệ mã thiếu sót khi chết.

Ngoài ra, bất kỳ mã nào không triển khai IDisposable sẽ chạy finalizers trên recycle mà có thể sẽ phát hành tài nguyên được tổ chức.

Answer 2

Có thể bạn đang xem xét việc tái chế từ quan điểm về độ tin cậy. Dựa trên dữ liệu lịch sử, bạn nên có ý tưởng về số lượng bộ nhớ, CPU và ứng dụng của bạn sử dụng cũng như các mẫu lịch sử và khi sự cố bắt đầu xảy ra. Biết rằng, bạn có thể cấu hình tái chế để chống lại những vấn đề đó. Ví dụ: nếu bạn biết ứng dụng của mình có mẫu sử dụng bộ nhớ ngày càng tăng * dẫn đến ứng dụng hết bộ nhớ sau một khoảng thời gian vài ngày, bạn có thể định cấu hình ứng dụng đó để tái chế trước khi điều đó xảy ra.

* Rõ ràng, bạn cũng sẽ muốn giải quyết lỗi này nếu có thể, nhưng tái chế có thể được sử dụng để tăng độ tin cậy cho khách hàng

Answer 3

Nếu ứng dụng của bạn chạy ổn lâu sau đó ngưỡng thiết để tái chế hồ bơi ứng dụng, sau đó bằng mọi cách tăng ngưỡng. Không có nhược điểm nếu ứng dụng của bạn ổn định.

Đối với chúng tôi, chúng tôi đã tái chế hoàn toàn, và thay vào đó có nhiệm vụ tải trang thử nghiệm mỗi phút và chạy một iisreset nếu nó không tải năm lần liên tiếp.