Практический случай JVM-тюнинг, чтобы избежать полного GC

Question

У меня есть read и read, но они только объясняют сборку мусора теоретически, я думаю, что это должно быть очень сложно объяснить, как решить практическую проблему.

Моей конфигурация

export JAVA_HOME=/usr/java/jdk6 
JAVA_OPTS="-Xms272m -Xmx272m -XX:MaxPermSize=272m -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails" 

При запуске сервера, все идет гладко, как шелк

29.846: [GC 29.846: [DefNew: 74109K->1940K(83520K), 0.0125820 secs] 106982K->34813K(269248K), 0.0126230 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
30.002: [GC 30.002: [DefNew: 76016K->1502K(83520K), 0.0092930 secs] 108889K->34375K(269248K), 0.0093380 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
31.745: [GC 31.745: [DefNew: 75443K->4722K(83520K), 0.0369630 secs] 108316K->37595K(269248K), 0.0370130 secs] [Times: user=0.02 sys=0.00, real=0.04 secs] 
33.122: [GC 33.122: [DefNew: 78962K->6065K(83520K), 0.0444350 secs] 111835K->39481K(269248K), 0.0444850 secs] [Times: user=0.03 sys=0.00, real=0.04 secs] 
34.183: [GC 34.183: [DefNew: 80258K->4880K(83520K), 0.0371350 secs] 113674K->41044K(269248K), 0.0371830 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] 

объем памяти, который не собирается растет, а иногда некоторые полный дс выполняется, но система восстанавливается из этих

356.210: [Full GC 356.210: [Tenured: 74012K->66067K(185728K), 0.2215880 secs] 126231K->66067K(269248K), [Perm : 70207K->70207K(70208K)], 0.2216510 secs] [Times: user=0.22 sys=0.00, real=0.22 secs] 

В конечном счете, он выполняет только gc

61587.386: [Full GC 61587.386: [Tenured: 185728K->185728K(185728K), 0.4045190 secs] 269107K->188117K(269248K), [Perm : 85394K->85394K(85504K)], 0.4045860 secs] [Times: user=0.40 sys=0.00, real=0.41 secs] 
61587.820: [Full GC 61587.820: [Tenured: 185728K->185728K(185728K), 0.4075960 secs] 268851K->187688K(269248K), [Perm : 85394K->85394K(85504K)], 0.4076610 secs] [Times: user=0.40 sys=0.00, real=0.41 secs] 
61588.258: [Full GC 61588.258: [Tenured: 185728K->185727K(185728K), 0.4184530 secs] 269042K->187217K(269248K), [Perm : 85394K->85248K(85504K)], 0.4185420 secs] [Times: user=0.41 sys=0.00, real=0.41 secs] 
61588.702: [Full GC 61588.702: [Tenured: 185727K->185727K(185728K), 0.4054800 secs] 269129K->187216K(269248K), [Perm : 85248K->85248K(85504K)], 0.4055560 secs] [Times: user=0.40 sys=0.00, real=0.41 secs] 
61589.145: [Full GC 61589.145: [Tenured: 185727K->185727K(185728K), 0.4042100 secs] 269048K->187247K(269248K), [Perm : 85248K->85248K(85504K)], 0.4042770 secs] [Times: user=0.40 sys=0.00, real=0.41 secs] 

и исключения возникают

Jun 10, 2015 5:12:24 PM org.apache.catalina.core.ApplicationDispatcher invoke 
SEVERE: Servlet.service() for servlet jsp threw exception 
java.lang.IllegalStateException: Cannot create a session after the response has been committed 

Веб-приложение работает с Java 1.6 на Tomcat 7 сервера и использует Struts 2 (2.3.24) Любая помощь будет так высоко ценится, потому что я просто ява программист, и я не знал, что у java были эти большие предостережения под капотом. Благодаря

Answer 1

Существует две стратегия, чтобы предотвратить полный дс:

1) минимизирует количество долгоживущих объектов. Совершенно к нулю. Если вы храните ссылку на какой-либо объект на время, что больше, чем молодой интервал gc, объект будет находиться в куче до полного gc. Обычно невозможно полностью создать приложение java без долгоживущих объектов, но вы можете уменьшить его количество.

Худшая ситуация, когда ваше приложение производит долгоживущие объекты и никогда не освобождает его, он работает как утечка памяти и привести к OutOfMemory ошибки

2) увеличить кучу и молодой размер поколения (первый даст вам больше времени, прежде чем дс, второй увеличенный интервал между молодыми gc (менее долгоживущими объектами). Предотвратите полное gc путем перезагрузки приложения (например, на основе размера кучи). Будьте осторожны: большой молодой ген приводит к большей паузе на молодых gc.

современный G1 gc (по умолчанию в Java 8?) следует уменьшить количество полных вызовов gc

У меня есть опыт работы с приложением, используйте 10G молодую кучу Gen 60G при старте и максимальный размер кучи более 200 ГБ. Полный gc никогда не вызывался (мы перезагружаем его каждые 2-5 дней). Молодой gc пауза 0,1-0,3 секунды каждые 1-5 минут.

Answer 2

Ваша проблема намного более фундаментальна, чем полный GC. Вы даже не пытались понять, что происходит прямо сейчас, то есть какие текущие настройки по умолчанию применяются, не говоря уже об изменении значений по умолчанию.

Также полные GC не обязательно плохи сами по себе.

-Xmx272m

Это максимальный размер кучи. То есть максимальное количество кучи, которое приложение может использовать. Связанные с вами руководства содержат несколько глав по этой теме.

Какую часть руководств вы не поняли?

DefNew

Это серийный молодой коллекционер поколения. Это singlethreaded (читай: медленный)

[Times: пользователь = 0.41 SYS = 0.00, реальные = 0.41 Секунды]

пользователь == реального времени подразумевает также singlethreaded старые коллекции поколения.

экспорт JAVA_HOME =/USR/Java/JDK6

Java 6 уже давно достигли конца жизни. Обновление Java 8, обеспечивает новые и улучшенные коллекторы

Я прочел и читать, но они только объясняют Сборка мусора в теоретически способ

направляющие вы связаны объяснить множество доступных вариантов, а не только академические теория. Похоже, вы даже не экспериментировали ни с одним из вариантов.

потому что я просто программист на Java, и я не знал, что у java были эти большие предостережения под капотом.

GC эффективно является частью java. Как программист вам нужно это понять, потому что игнорирование этого приведет к сбою приложения или сбою в работе.

Если вы считаете, что вам не нужно знать, что вы не правы.