Управление распределением памяти с 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 даже не существует, поэтому проблема решена.
Привет