2010-06-15 3 views
12

Wir haben eine Web-Java-basierte Anwendung auf JBoss mit maximal zulässigen Heap-Größe von etwa 1,2 GB ausgeführt (insgesamt Maschinenspeicher ist 2 GB). Zu einem bestimmten Zeitpunkt reagiert die Anwendung für einige Minuten nicht mehr auf Clients. Nach einigen Analysen fanden wir heraus, dass der Täter der Full GC ist. Hier ist ein Auszug aus der ausführlichen GC-Log:Vollständige GC Echtzeit ist viel mehr als Benutzer + sys Zeiten

74477,402: [Full GC [PSYoungGen: 3648K-> 0K (332160K)] [PSOldGen: 778476K-> 589497K (819200K)] 782124K-> 589497K (1151360K) [PSPermGen: 102671K-> 102671K (171328K)], 646,1546860 sec] [Zeiten: user = 3,84 sys = 3,72, real = 646,17 Sekunden]

Was ich nicht verstehe, ist, wie es möglich ist, dass die Echtzeit Auf Full-GC ausgegeben ist etwa 11 Minuten (646 Sekunden), während Benutzer + sys Zeiten nur 7,5 Sekunden sind. 7,5 Sekunden klingen für mich viel mehr logische Zeit für die Reinigung < 200 MB aus der alten Generation zu verbringen. Wohin geht die andere Zeit?

Vielen Dank.

Antwort

10

Wohin geht die ganze Zeit?

Es ist sehr wahrscheinlich, dass Ihre Anwendung virtuellen Speicher Thrashing verursacht. Im Grunde benötigt Ihre Anwendung wesentlich mehr Seiten virtuellen Speichers als es physische Seiten gibt, auf denen sie gespeichert werden können. Daher verbringen sie die meiste Zeit damit, dass vm-Seiten von der CD gelesen und auf die CD geschrieben werden. Für weitere Informationen lesen Sie this wikipedia page.

Die Abhilfe besteht entweder darin, die Nutzung des virtuellen Speichers zu reduzieren oder die Menge an physischem Speicher auf dem System zu erhöhen. Zum Beispiel könnten Sie:

  • läuft weniger Anwendungen auf dem Computer,
  • Java Application-Heap Größen reduzieren, oder
  • , wenn Sie in einem virtuellen ausgeführt werden, die Zuweisung des physischen Speichers der virtuellen erhöhen.

(Beachten Sie jedoch, dass die JVM-Heap-Größe zu reduzieren kann ein zweischneidiges Schwert sein. Wenn Sie die Heap-Größe zu viel die Anwendung entweder von OutOfMemoryErrors sterben reduzieren, verbringen zu viel Müll Sammelzeit, oder leiden an nicht in der Lage, Dinge effektiv zu cachen.)

+0

Ein anderer Ansatz könnte darin bestehen, langlebige Objekte zu reduzieren, da kurzlebige Objekte viel schneller recycelt werden. Object-Pooling zum Beispiel ist eine schlechte Übung in Java. –

+0

Wahr. Ich konzentrierte mich auf Dinge, die das OP schnell tun konnte, um das Problem anzugehen. –

+0

Sind Sie sich sicher? Ich würde erwarten, dass ein JVM-Prozess, der auf einen Seitenzugriff wartet, die Zeit in sys = verbracht hat. – eckes