Chúng tôi đang nhìn thấy rất nhiều phân mảnh bộ nhớ ảo và lỗi bộ nhớ và sau đó nó đạt đến giới hạn 3 GB.debug = true trong web.config = Điều BAD?
Trình gỡ lỗi biên dịch được đặt thành true trong web.config nhưng tôi nhận được các câu trả lời khác nhau từ mọi người tôi yêu cầu, gỡ lỗi được đặt thành đúng khiến mỗi aspx biên dịch vào các vùng ngẫu nhiên của ram, do đó phân mảnh ram đó và cuối cùng gây ra vấn đề bộ nhớ?
AFAIK "debug = true" không gây ra tình huống bạn đã đề cập.
Tôi đã gặp phải sự cố tương tự với ứng dụng ASP.NET đã tạo hình ảnh khi đang di chuyển.
vì vậy tôi nghĩ rằng bạn có vấn đề với tài nguyên không được xử lý.
Nếu bạn triển khai tệp aspx của mình bằng các tệp mã-đằng sau đến máy chủ. Nó sẽ được biên dịch một lần khi yêu cầu đến một aspx. sau đó nó sẽ được lưu vào bộ nhớ cache cho đến khi tập tin thay đổi.
Cờ gỡ lỗi phải được đặt thành false trong web.config, trừ khi bạn thực sự cần gỡ lỗi ứng dụng.
Chạy trong chế độ gỡ lỗi có thể tăng mức sử dụng bộ nhớ một chút, nhưng không có khả năng xảy ra trường hợp nghiêm trọng như bạn đang nói đến. Tuy nhiên, bạn nên đặt nó thành sai để loại bỏ hiệu ứng của nó và xem liệu bạn có thể nhận thấy bất kỳ cải tiến nào không.
Khi chạy ở chế độ gỡ lỗi, bộ sưu tập rác hoạt động khác nhau. Thời gian sống của các biến được mở rộng từ việc sử dụng thực tế đến phạm vi của biến (để có thể hiển thị giá trị trong trình gỡ lỗi). Điều này làm cho một số vật thể sống lâu hơn trước khi chúng được thu gom rác.
Trình biên dịch không tối ưu hóa mã khi biên dịch trong chế độ gỡ lỗi và thêm một số lệnh nop để mỗi dòng mã có ít nhất một lệnh nơi có thể đặt điểm ngắt.
Việc ném ngoại lệ mất nhiều thời gian hơn trong chế độ gỡ lỗi. (Tuy nhiên, thông thường mã không nên ném ngoại lệ thường xuyên.)
Scott Guthrie (người quản lý của nhóm phát triển ASP.NET) có số interesting post about it.
Những điểm quan trọng nhất tại sao bạn không nên để debug = "true" là:
Ông cũng đề cập đến cờ <deployment retail=”true”/> trong machine.config, cho phép ghi đè toàn cầu cờ gỡ lỗi = "true" của tất cả các ứng dụng đang chạy trên máy (ví dụ: trên một máy chủ sản xuất).
Cập nhật: triển khai các ứng dụng web với debug="true" vẫn còn xấu, như bạn có thể đọc trong Scott Hanselman's recent blog post:
Dưới đây là lý do tại sao debug = "true" là xấu. Nghiêm túc, chúng tôi không đùa đâu.
Lưu ý quan trọng: Ngược lại với những gì đôi khi được tin tưởng, đặt bán lẻ = "true" trong phần tử không phải là thuốc giải độc trực tiếp để gỡ lỗi = "true"!
Trên hệ thống sản xuất luôn đặt Debug = false. Vì cờ cho thấy nó chỉ nên được đặt thành true khi gỡ lỗi một hệ thống phát triển.
Cờ này không liên quan gì đến vấn đề phân mảnh bộ nhớ của bạn.
Nó hoàn toàn có thể ảnh hưởng đến bộ nhớ, chỉ cần nhìn vào một số bộ đếm nước hoa và chạy so sánh với cả hai cấu hình.
Nếu trang web của bạn có nhiều tệp, tôi sẽ quan tâm hơn đến đĩa io trong thư mục tạm thời asp.net.
Câu hỏi Couple ...
Tại sao không sử dụng nhiều cấu hình?
Web.Debug.Config - đã gỡ lỗi bật Web.UAT.Config - Dù sở thích của bạn Web.Release.Config - Có Debugging tắt
Bằng cách này bạn có thể hạn chế tối đa lỗi cấu hình hồi quy như một nhà phát triển kiểm tra web.config bằng debug = "true"
Chính sách tiêu chuẩn của công ty tôi là tất cả các máy chủ web sản xuất đều có thẻ triển khai được đặt trong machine.config. Điều này giúp tiết kiệm rất nhiều đau đầu. – Chris