Poprawne jest stosowanie GC.Collect (); GC.WaitForPendingFinalizers ();?

Jest rzecz, którą można łatwo zrozumieć: uruchamianie GC automatycznie czyści wiele obiektów na run (powiedzmy 10000). Wywołanie go po każdym zniszczeniu czyści około jednego obiektu na run.

Ponieważ GC ma duże obciążenie (musi zatrzymywać i uruchamiać wątki, musi skanować wszystkie obiekty żywe) połączenia wsadowe są wysoce zalecane.

Również, co Dobre może wyjść z sprzątania po każdym obiekcie? Jak może to być bardziej wydajne niż dozowanie?

Twój punkt numer 3 jest technicznie poprawny, ale może się zdarzyć tylko wtedy, gdy ktoś zablokuje podczas finalizatora.

Jest kilka razy, kiedy wywołanie GC.Collect() naprawdę pomaga w wydajności.

W przypadkach, gdy przechodzisz przez setki lub tysiące megów pamięci w krótkim okresie czasu, a następnie przechodzisz na znacznie mniej intensywne korzystanie z pamięci przez długi okres czasu, jawne gromadzenie może być ogromnym lub nawet istotnym ulepszeniem. To się tu dzieje?

Gdziekolwiek indziej, w najlepszym razie będą wolniej pracować i zużywać więcej pamięci.

Zobacz moją drugą odpowiedź tutaj:

Do GC.Zbierać czy nie?

Dwie rzeczy mogą się zdarzyć, gdy zadzwonisz do GC.Collect () yourself: W końcu spędzasz więcej czasu na robienie kolekcji (ponieważ normalne Kolekcje tła nadal będą się zdarzać oprócz podręcznego GC.Collect ()) i będziesz trzymać się pamięci dłużej (ponieważ wymusiłeś pewne rzeczy na generacjach wyższego rzędu, które nie musiały tam iść). Innymi słowy, używając GC.Collect () to prawie zawsze zły pomysł.

Użyłem tego tylko raz: aby wyczyścić pamięć podręczną po stronie serwera dokumentów Crystal Report. Zobacz moją odpowiedź w wyjątku Crystal Reports: maksymalny limit zadań przetwarzania raportów skonfigurowany przez administratora systemu został osiągnięty

WaitForPendingFinalizers był dla mnie szczególnie pomocny, ponieważ czasami obiekty nie były odpowiednio czyszczone. Biorąc pod uwagę stosunkowo powolne wykonanie raportu na stronie internetowej - każde niewielkie opóźnienie GC było znikome, a poprawa zarządzania pamięcią dała mi ogólnie lepszy serwer.

Napotkaliśmy podobne problemy do @Grzenio, jednak pracujemy z dużo większymi tablicami 2-wymiarowymi, w kolejności od 1000x1000 do 3000x3000, to jest w webservice.

Dodanie większej ilości pamięci nie zawsze jest właściwą odpowiedzią, musisz zrozumieć swój kod i przypadek użycia. Bez pobierania GC wymagamy 16-32GB pamięci (w zależności od wielkości klienta). Bez niego potrzebowalibyśmy 32 - 64GB pamięci i nawet wtedy nie ma gwarancji, że system nie ucierpi. . NET Śmieciarz nie jest idealny.

Nasz webservice posiada pamięć podręczną w kolejności 5-50 milionów znaków (~80-140 znaków na parę klucz / wartość w zależności od konfiguracji), Dodatkowo przy każdym żądaniu klienta konstruujemy 2 macierze, jedną podwójną, jedną boolean, które następnie przekazywane są do innej usługi w celu wykonania pracy. Dla "macierzy" 1000x1000 (macierz 2-wymiarowa) jest to ~25MB, na żądanie. Boolean powie, które elementy potrzebujemy (na podstawie naszej pamięci podręcznej). Każdy wpis cache reprezentuje jedną "komórkę" w "macierzy".

Odkryliśmy, że jeśli nie będziemy mieli jawnego GC, garbage collector. NET nigdy nie "oczyści" zmiennych przejściowych, dopóki nie będziemy w zakresie 90-95%, w którym to momencie wydajność pamięci podręcznej Uległa drastycznemu pogorszeniu.

Ponieważ proces down-stream często trwał długo (3-900 sekund), wydajność spadła z kolekcji GC był neglible (3-10 sekund na zbiórkę). Zainicjowaliśmy tę zbiórkę po tym, jak zwróciliśmy już odpowiedź klientowi.

Ostatecznie skonfigurowaliśmy parametry GC, również z. Net 4.6 są dalsze opcje. Oto kod. NET 4.5, którego użyliśmy.

if (sinceLastGC.Minutes > Service.g_GCMinutes)
{
     Service.g_LastGCTime = DateTime.Now;
     var sw = Stopwatch.StartNew();
     long memBefore = System.GC.GetTotalMemory(false);
     context.Response.Flush();
     context.ApplicationInstance.CompleteRequest();
     System.GC.Collect( Service.g_GCGeneration, Service.g_GCForced ? System.GCCollectionMode.Forced : System.GCCollectionMode.Optimized);
     System.GC.WaitForPendingFinalizers();
     long memAfter = System.GC.GetTotalMemory(true);
     var elapsed = sw.ElapsedMilliseconds;
     Log.Info(string.Format("GC starts with {0} bytes, ends with {1} bytes, GC time {2} (ms)", memBefore, memAfter, elapsed));
}

Po przepisaniu do użytku z. Net 4.6 podzieliliśmy zbiór śmieci na 2 kroki-prosty zbiór i zbiór zagęszczający.

    public static RunGC(GCParameters param = null)
    {
        lock (GCLock)
        {
            var theParams = param ?? GCParams;
            var sw = Stopwatch.StartNew();
            var timestamp = DateTime.Now;
            long memBefore = GC.GetTotalMemory(false);
            GC.Collect(theParams.Generation, theParams.Mode, theParams.Blocking, theParams.Compacting);
            GC.WaitForPendingFinalizers();
            //GC.Collect(); // may need to collect dead objects created by the finalizers
            var elapsed = sw.ElapsedMilliseconds;
            long memAfter = GC.GetTotalMemory(true);
            Log.Info($"GC starts with {memBefore} bytes, ends with {memAfter} bytes, GC time {elapsed} (ms)");

        }
    }

    // https://msdn.microsoft.com/en-us/library/system.runtime.gcsettings.largeobjectheapcompactionmode.aspx
    public static RunCompactingGC()
    {
        lock (CompactingGCLock)
        {
            var sw = Stopwatch.StartNew();
            var timestamp = DateTime.Now;
            long memBefore = GC.GetTotalMemory(false);

            GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
            GC.Collect();
            var elapsed = sw.ElapsedMilliseconds;
            long memAfter = GC.GetTotalMemory(true);
            Log.Info($"Compacting GC starts with {memBefore} bytes, ends with {memAfter} bytes, GC time {elapsed} (ms)");
        }
    }

Nadzieję, że to pomoże komuś innemu, jak my spędziłem dużo czasu na badaniu tego.