2012-04-06 20 views
10

Mam aplikację, która jest odpowiedzialna za archiwizację starych aplikacji, która będzie wykonywać wiele aplikacji jednocześnie, więc będzie musiała działać przez kilka dni.Ile czasu należy poświęcić na zbieranie śmieci?

Kiedy moja firma opracowała to zrobili sporo testów wydajności i wydawało się, że otrzymali przyzwoite dane, ale ostatnio korzystam z archiwum dla klienta i wydaje się, że działa bardzo wolno i Wydajność wydaje się pogarszać jeszcze dłużej.

Wygląda na to, że nie ma wycieku pamięci, ponieważ od czasu monitorowania go za pomocą jconsole nadal dostępna jest duża ilość pamięci i nie wydaje się, że kurczy się.

Zauważyłem jednak, że przestrzeń dla ocalałych i uparty gen sterty może bardzo szybko zapełnić się, dopóki nie pojawi się zbiór śmieci i wyczyści to, co zdarza się często, czego nie jestem pewien, czy to może być źródło pozornego spowolnienia.

Aplikacja działa już przez 7 dni 3 godziny i według jconsole spędził 6 godzin wykonując kopiowanie śmieci (zbiory 772, 611) oraz 12 godzin i 25 minut na znakach kompaktowych (145 940 zbiorów).

Wydaje się, że poświęcasz dużo czasu na zbieranie śmieci i zastanawiam się, czy ktoś wcześniej sprawdził coś podobnego i czy jest to normalne czy nie?

Edits

przetwarzanie lokalne wydaje się być powolny, na przykład szukam w jednej części w dziennikach, które miały 5 sekund, aby wyodrębnić pewne XML z koperty SOAP za pomocą XPath, które następnie dołącza do łańcucha bufor wraz ze znacznikiem głównym ... to wszystko, co robi. Nie profilowałem go jeszcze, ponieważ jest on uruchomiony w produkcji, albo musiałbym wyciągnąć dane przez sieć, albo ustawić dużą bazę testową w naszym środowisku deweloperskim, co może się skończyć.

Running Java HotSpot VM Client w wersji 10.0-B23

Naprawdę wystarczy wysoką przepustowość, nie skonfigurowano żadnych konkretnych parametrów zbiórki śmieci, byłby uruchomiony, co zawsze domyślnie będzie. Nie wiesz, jak znaleźć kolektory w użyciu?

Fix

skończyć się coraz profilera dzieje na nim, okazało się przyczyną spowolnienia był jakiś kod, który był stale przycinania linii off polu statusu wpisywanie oświadczenia rejestrowania który został całkiem źle zrobione. Powinienem się domyślić, że odśmiecanie było objawem ciągłego kopiowania tekstu stanu do pamięci, a nie rzeczywistej przyczyny.

Pozdrawiam facetów.

+0

Cokolwiek rozkazał sędzia? – ZenMaster

+0

* (nie jest to odpowiedź na twoje pytanie, stąd komentarz) * ... * ", który będzie robił wiele aplikacji jednocześnie, więc będzie musiał działać przez kilka dni." * ... [sic ] Masz na myśli, że twoja aplikacja nie może zostać zamknięta i uruchomiona ponownie bez potrzeby rozpoczynania wszystkiego od zera !? – TacticalCoder

+0

Cóż, jeśli go zatrzymasz, to zapisze listę tego, co pozostało, wraz z aplikacjami, których nie udało się zarchiwizować, które można załadować i uruchomić ponownie. To jest nasz plan, jeśli nie możemy przyspieszyć tego stanu w ciągu kilku następnych dni, aby rozbić nasze flagi archiwum na mniejsze partie. – Dan675

Odpowiedz

4

Według twoich danych, całkowity czas zbierania śmieci wynosił około 18 godzin z 7 dni czasu wykonania. Około 10% całkowitego czasu wykonania jest nieznacznie podwyższone, ale nawet jeśli udało ci się obniżyć to do 0%, zaoszczędzisz tylko 10% czasu wykonania ... więc jeśli szukasz znaczących oszczędności, powinni lepiej zajrzeć do pozostałych 90%, na przykład za pomocą profilera.

2

Bez odpowiedniego profilowania, jest to gra zgadująca. Jednak jako anektod kilka lat temu aplikacja internetowa, z którą byłem zaangażowany, nagle po zwolnieniu JDK nagle zwolniła (czas odpowiedzi) 10 razy.Skończyliśmy na gonitwie do wyraźnej inwokacji GC dodanej przez genialnego, który nie był już z firmą.

2

Istnieje saldo, które należy zachować i zachować pomiędzy śladami stosu maszyn JVM i czasem GC. Innym pytaniem może być to, że masz stertę (i generacje) (nie-) przydzieloną w taki sposób, który nakazuje zbyt częste GCing. Podczas wdrażania JVM muti-tenant w tych systemach starałem się utrzymać równowagę poniżej 5% całkowitego czasu GC wraz z agresywnym kurczeniem się sterty, aby utrzymać niski poziom śladu (ponownie, wielu dzierżawiących). Sterty i pokolenia zwykle ZAWSZE wypełniają, aby uniknąć częstego GCing do tego, co zostało ustawione. Usuń parametr -Xms, aby zobaczyć bardziej realistyczny stan ustalony (jeśli ma dowolny czas bezczynności).

+1 do sugestii dotyczącej profilowania; może to być coś niezwiązanego z GC, ale kod.

Powiązane problemy