Что может привести к тому, что Tomcat (v8) будет периодически нагружаться процессором

Question

На сервере TEST для Windows 2012 RT (x64) мы запускаем установку Tomcat 8, и загрузка ЦП сбивает с толку регулярностью использования пиковых значений.

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

На сервере имеется 2 виртуальных процессора, и каждые ~20 секунд загрузка ЦП будет увеличиваться (на одном процессоре, на котором работает Tomcat) до 100% в течение 10 секунд (дать или взять). Увидеть ниже:

Регулярность шаблона показывает мне, что что-то не так в установке или настройках Tomcat 8.

Я установил YourKit Java Profiler (по рекомендации SO), который, как я надеялся, мог пролить некоторый свет на причины этих всплесков, но не смог понять причину запуска потоков - по крайней мере, отчасти из-за моей новизны в ваш комплект. Я прикрепил его к файлу запуска Tomcat, и он, похоже, отслеживает его поведение.

Журналы каталины молчат во время появления всплесков (как и журналы моего приложения), но когда я остановил Tomcat, были некоторые сообщения о начале работы ThreadLocals, но они не могли быть удалены, а затем: "... Потоки будут обновляться с течением времени до постарайтесь избежать возможной утечки памяти."

Я оставил сервер включенным в течение выходных, и паттерн продолжался до сегодняшнего дня, поэтому я не думаю, что мои симптомы исчезнут. Все, что запускается, теперь потребляет всю доступную оперативную память в системе только после запуска этих потоков (и / или YourKit) каждые 20 секунд.

Каков возможный подход, чтобы изолировать эту аберрантную деятельность Tomcat и, надеюсь, остановить или исправить ее?

В YourKit много графиков и вкладок, поэтому я не решаюсь перечислить все, что может быть полезным. Спасибо, что помогли мне сузить проблему с тем, что YourKit (или другие инструменты) могут предложить мне.

Информация из журнала каталины о запуске:

Apache Tomcat/8.0.23
Architecture: amd64
Java Home: C:\Program Files\Java\jre1.8.0_65
CATALINA_BASE: C:\Program Files\Apache Software Foundation\Tomcat 8.0

2015-12-08 Обновление

По запросу Гергели приложение является локальной установкой DSpace. Это Java-приложение с базой данных Postgres SQL. Мы настраиваем его версию с открытым исходным кодом отсюда: http://www.dspace.org/introducing. Я не совсем уверен, что еще может быть полезным, и я думаю, что трассировка стека более показательна относительно того, что работает (и не работает) - см. Ниже.

При включении стековой телеметрии в YourKit "Оценка ЦП" стала доступной путем перетаскивания курсора по периоду истории профилировщика. Мне кажется, что все, что делает процессор, вращается без дела. Файлы Java изображены ниже подпрограмм Tomcat? Они не кажутся мне относящимися к DSpace (хотя я не эксперт), и при этом не похоже, что какая-либо работа выполняется, пока процессор достигает пика.

Следует отметить: трассировка стека идентична в периоды бездействия - единственная разница заключается в том, что время ЦП (мс) исчисляется сотнями, а не тысячами миллисекунд. Для более прямого сравнения, чем то, что показано ниже, горб представляет собой ~8000 мс в Thread.run(), а периоды бездействия занимают ~125 мс времени процессора (хотя и охватывают примерно такое же количество времени).

Наконец, когда запрашиваются страницы приложения, в дереве вызовов появляется следующая ветвь кода. Если это произошло во время всплеска, загрузка всей страницы может занять всего 400 мс времени процессора. Откроется ветвь кода ApplicationFilterChain.java как отдельная ветвь вместе с PooledExecutor$Worker.run() - оба в иерархии под java.lang.Thread.run().

При попытке интерпретировать трассировку стека: EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run() ответственность?

Пики процессора без какой-либо известной связанной активности

2015-12-08 Обновление № 2

YourKit поставляется предварительно настроенным для скрытия определенных шаблонов имен классов Java, которые скрывают детализацию на java.lang.Thread. Очистка фильтров позволила сделать следующие снимки экрана, показывающие, что подавляющее большинство времени обработки во время события выброса происходит посредством вызова следующих 3 методов:

• java.io.WinNTFileSystem.canonicalize0
• java.io.WinNTFileSystem.getBooleanAttributes (inFile.exists ())
• StardardRoot.java

Приношу свои извинения за то, что еще не знал достаточно о Tomcat или DSpace, чтобы знать, кто запускает эти задачи. (В случае, если это имеет значение, строка непосредственно над первой строкой java.lang.Thread.run() а потом <All threads>)

Answer 1

Спасибо тем, кто просмотрел и ответил на этот запрос. Как предположили различные люди, проблема была связана с нашими настройками и использованием Tomcat - не проблема с самим Tomcat (скорее всего).

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

При установке приложения DSpace в каталогах конфигурации Tomcat есть некоторые свойства установки, которые определяют, следует ли разрешать немедленное отражение изменений в файлах кодирования без перезапуска Tomcat. Эти настройки для нас были ранее в каталоге [tomcat]/conf/Catalina/localhost/ и каждый из трех файлов содержал небольшой незначительный XML-файл, например (например, oai.xml):

<?xml version='1.0'?>
<Context docBase="E:/dspace/webapps/oai"
    reloadable="false"
    cachingAllowed="true"/>

Документацию по этим свойствам можно найти по следующей ссылке: https://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace

В этой документации содержится рекомендация о reloadable а также cachingAllowed свойства. Поиск "Настройки контекста Tomcat в производстве". Вот выдержка (выделено мной):

Эти параметры чрезвычайно полезны, когда вы только начинаете работать с DSpace, поскольку они позволяют настраивать XMLUI DSpace (XSLT или CSS) или JSPUI (JSP) и видеть, что ваши изменения автоматически перезагружаются Tomcat (без перезапуска Tomcat), Однако стоит отметить, что в документации Apache Tomcat рекомендуется, чтобы производственные сайты оставляли значения по умолчанию на месте (reloadable="false" cachingAllowed="true"), так как разрешение Tomcat автоматически перезагружать все изменения может привести к "значительным накладным расходам во время выполнения".

Вам решать, сохранять ли эти настройки Tomcat на месте. Мы просто рекомендуем начать с них, чтобы вам было проще настраивать свой сайт без необходимости перезапуска Tomcat. Небольшие сайты DSpace могут не замечать каких-либо проблем с производительностью при сохранении этих настроек в производственной среде. Большие сайты DSpace могут пожелать, чтобы производительность Tomcat была более рациональной.

Когда я переключил эти логические флаги на reloadable="false" а также cachingAllowed="true" скачкообразный процессорный процесс сразу остановился. Я не знаю, относится ли к нам предупреждение о "крупных сайтах" или "оптимизированная производительность" может указывать на негативную активность, которую я наблюдал.

Я предполагаю, что могут быть другие проблемы с нашей установкой, которые позволили это конкретное проявление; один зловещий ключ в том, что наш производственный сервер работает с этими флагами в reloadable="true" конфигурации. Java, Tomcat, Windows и DSpace ВСЕ получают новые версии одновременно, поэтому довольно сложно определить, почему похожий Tomcat <context> настройки дают такие разные результаты.

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

Обновить

Кстати, атрибуты - это настройки, которые напрямую управляют Tomcat, и они менялись между версиями. Например, cachingAllowed был удален в версии 8, что означает, что он может быть удален из Context элементы. Для сравнения:

https://tomcat.apache.org/tomcat-8.0-doc/config/context.html https://tomcat.apache.org/tomcat-7.0-doc/config/context.html

И для хорошей меры, вот текст справки для reloadable в документации Tomcat 8:

Установите значение true, если вы хотите, чтобы Catalina отслеживала классы в /WEB-INF/classes/ и /WEB-INF/lib на предмет изменений, и автоматически перезагружала веб-приложение в случае обнаружения изменений. Эта функция очень полезна при разработке приложений, но требует значительных затрат времени выполнения и не рекомендуется для использования в развернутых производственных приложениях. Вот почему по умолчанию для этого атрибута установлено значение false. Однако вы можете использовать веб-приложение Manager для запуска перезагрузки развернутых приложений по требованию.

Поэтому может показаться, что окончательный ответ заключается в том, что Tomcat 8 в Windows 2012-R2 с флагом reloadable='true' опрашивает изменения в классах WEB-INF / lib и WEB-INF /. Объем папок и файлов для просмотра вполне может быть причиной этих интенсивных скачкообразных событий ЦП. Сейчас я буду полагаться на reloadable='false', который определенно устраняет для нас симптом.

Answer 2

Не точный ответ, но слишком длинный для комментария

После просмотра обновления по этому вопросу и прочтения немного, я подозреваю, что эта повторяющаяся проблема вызвана CuratorTask. Причины:

• Полученная вами трассировка стека ясно показывает, что WorkerThread, управляемый библиотекой DSpace (так что Tomcat не виноват) использует процессор в то время.

• Прочитав немного о самом DSpace, похоже, что он имеет функцию, которая позволяет пользователям определять задачи куратора, которые должны периодически выполняться.

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

• Кроме того, этот разговор показывает по крайней мере 1 задачу курирования, которая активируется каждые 10 секунд.

Все это вместе указывает в одном направлении. Я бы предложил использовать пользовательский интерфейс DSpace (возможно, в режиме администратора), чтобы осмотреться, найти активные задачи курирования и проверить, соответствует ли их планирование тому, что вы наблюдали.