Zrozumienie wycieków pamięci w ASP.net przy użyciu Profiler pamięci RedGate

Question

Używam dużej witryny ASP.net 4.0. Korzysta z popularnego systemu zarządzania treścią .Net, ma tysiące elementów treści, setki równoczesnych użytkowników - jest po prostu ciężką stroną internetową.

W ciągu jednego dnia wykorzystanie pamięci procesu roboczego IIS7 może wzrosnąć do 8-10 GB. Serwer ma 16 GB i jest obecnie skonfigurowany do recyklingu puli aplikacji raz dziennie.

Otrzymuję presję, aby zmniejszyć zużycie pamięci. Duża część wykorzystania pamięci wynika z buforowania dużych ciągów danych, ale interwał pamięci podręcznej jest ustawiony tylko na 5-10 minut, więc te ciągi powinny w końcu wygasnąć z pamięci.

Jednak po uruchomieniu programu RedGate Memory Profiler widzę, co uważam za wyciek pamięci. Przefiltrowałem wyniki mojej listy wystąpień za pomocą obiektów, które "są przechowywane w pamięci wyłącznie przez Unieaktywnione Obiekty" (czytałem na forum RedGate, że w ten sposób można znaleźć wycieki pamięci). To dało mi długą listę ciągów, które są przechowywane w pamięci.

Dla każdego łańcucha używam wykresu zatrzymania instancji, aby zobaczyć, co trzyma go w pamięci. Obiekty System.string wydają się być w pewnym momencie buforowane przez System.Web.Caching.CacheDependency. Jeśli śledzę cały wykres, przechodzi przez różne inne klasy, w tym System.Collections.Specialized.ListDictionary, aż osiągnie System.Web.FileMonitor. Ma to pewien sens, ponieważ łańcuchy są ścieżkami do pliku (obrazy/pliki PDF/itd.).

Wygląda na to, że CMS buforuje ścieżki do plików, ale te buforowane obiekty są następnie "wyciekane". Z biegiem czasu to buduje i zżera pamięć RAM.

Przepraszam, że to długo trwa ... Czy istnieje sposób, aby zatrzymać te wycieki pamięci? Czy możesz je wyczyścić bez konieczności recyklingu puli aplikacji? Czy mogę znaleźć klasę/kod robiący buforowanie, aby sprawdzić, czy mogę naprawić wyciek?

Answer 1

To brzmi jak bardzo powszechny problem pozostawania w pamięci jako część stanu sesji. Jeśli tak jest, jedynymi opcjami są: 1. nie umieszczaj zbyt wiele rzeczy w sesji każdego użytkownika, 2. Ustaw czas życia sesji na coś krótszego (domyślnie jest to 20 minut, jak sądzę) i 3. Okresowo odzyskuj pulę aplikacji .

W ramach 1. Stwierdziłem, że istnieją "dobre sposoby" i "złe sposoby" prezentowania danych w kontroli sieci danych. Możesz sprawdzić, czy kopiujesz tylko te dane, których potrzebujesz, a nie przypadkowo zachowując odniesienia do całego datagridu.