Управление распределением памяти с Java 1.8 в Tomcat 6 и Tomcat 8

Связанный вопрос: Использование сборщика мусора при обновлении с Java 6 + Tomcat 6 до Java 8 + Tomcat 8

У меня есть набор webapps, скомпилированный с Java 8. Если я запускаю их в Tomcat 8, я получаю много небольших коллекций GC со случайным распределением памяти. В Tomcat 6 распределение памяти более линейно и стабильно (в обоих случаях - бездействующий).

Eden Space Tomcat 8:

введите описание изображения здесь

введите описание изображения здесь

Eden Space Tomcat 6:

введите описание изображения здесь

введите описание изображения здесь

Вы знаете, почему это происходит?

РЕДАКТИРОВАТЬ 1:

Это данные из производственной среды с jdk 1.8 и Tomcat 8. Процессор действительно высок почти всегда из-за циклов GC. Любые комментарии по этому поводу?

введите описание изображения здесь введите описание изображения здесь

ИЗМЕНИТЬ 2:

Это аналитический анализ (сброс 1.8 гигабайта):

введите описание изображения здесь

Ответы

Ответ 1

Это пространство, а не пространство. Таким образом, это только хорошие новости.

Но этот шаг памяти, похоже, является tomcat8, выделяя что-то сразу после молодого GC. Может быть, это какая-то техника "шара"? (Выделение большого слабо буфера, на который ссылается на "Deflate" быстро, чтобы обеспечить некоторое пространство в случае давления памяти). Он также может скрываться в NIO-коннекторах, как и в параметре "oomParachute" (по умолчанию 1 Мбайт), но есть ли он в потоке httpprocessor? Если у вас было 200-минутные потоки, которые соответствовали бы 200 МБ).

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

ТАКЖЕ: вы должны запустить tomcat6 в своем jdk8, чтобы убедиться, что это действительно ошибка tomcat8. Эденское пространство может быть увеличено, на случай, если G1GC настолько агрессивен, что он чувствует себя обязанным к GC, когда используется только 200 МБ.

Ответ 2

Спасибо, ребята, за ваше время. В конце концов, проблема связана с ошибкой в ​​tomcat 8.0_23. Используя Javosize, я видел поток, потребляющий почти все время процессора:

введите описание изображения здесь

Глядя на интернет, я нашел это Tomcat AJP Bug

В adittion я протестировал tomcat 8.0_32 и этот поток Poller даже не существует, поэтому проблема решена.

Привет