Веб-приложение очень медленно в Tomcat 7

Ответ 1

Недостаточно информации. Нужна дополнительная информация: (

Используйте htop или top для поиска памяти и использования ЦП на каждый процесс и на поток.

CPU

Постоянное 25% использование ЦП в системе с четырьмя ядрами может указывать на то, что одноядерное приложение/поток использует 100% процессор на единственном ядре, которое оно может использовать.

Какое приложение использует процессор?

Память

20% памяти ~ 1,6 ГБ. Это немного больше, чем я ожидаю, если на холостом сервере работает только tomcat + mysql. -Xms1024 сообщает tomcat предварительно распределить память 1 ГБ, чтобы объяснить это.

Измените параметры tomcat на -Xms512 и -Xmx2048. Наблюдайте за использованием памяти tomcat, пока вы бросаете на нее некоторых пользователей. Если он продолжает расти, пока не достигнет 2 ГБ... затем замерзает, что может указывать на утечку памяти.

Диск

Используйте df -h для проверки использования диска. Полный раздел может решить проблемы, которые вы испытываете.

Filesystem    Size  Used Avail Usage% Mounted on
/cygdrive/c     149G  149G  414M 100%   /

(Если вы только что обнаружили в этом примере, что у моего ноутбука не хватает места. Вы делаете это правильно: D)

Журналы

Журналы потрясающие. Однако у них есть плохая привычка заполнять диск. Проверьте использование дискового пространства. Правильно ли записываются/стираются/вращаются журналы при подключении новых пользователей? Исправляет ли журнал удаление журнала? (скопируйте их где-нибудь для будущего анализа, прежде чем удалять их)

Если нет. Журналы STILL awesome. У них хорошая привычка помочь вам отслеживать ошибки. Проверка журналов tomcat. Вы можете настроить уровень ведения журнала для отладки. Что происходит, когда сайт умирает? Любое полезное сообщение об ошибке? Домены пользователя все еще принимаются и принимаются tomcat?

Применение

Я полагаю, что 25% процессор переходит к tomcat (а не к mysql). Tomcat не терпит неудачу сам по себе. Запуск приложения на нем должен быть неудачным. Попробуйте удалить приложение из tomcat (в конце концов вы можете поставить мир привет). Может ли tomcat работать без выходных без вашего заявления? Вероятно, это может произойти, и в этом случае ошибка присутствует в приложении.

Включить полное отладочное ведение журнала в вашем приложении и попытаться отслеживать проблему. Запустите его прямо из затмения в режиме отладки и бросьте на него пользователей. Неужели это происходит одинаково одинаково?

Если да, нажмите "пауза" в отладчике eclipse и проверьте, что делает приложение. Посмотрите на фрагмент кода, в котором каждый поток работает + его стек вызовов. Повторите это несколько раз. Если есть тупик, бесконечный цикл или аналогичный, вы можете найти его таким образом.

Теперь вы найдете проблему, если вам повезет. Если нет, вы несчастны и это сложная ошибка, которая может быть глубоко внутри приложения. Это может оказаться сложным для отслеживания. Определение приведет к успеху. Удачи =)

Ответ 2

Мы столкнулись с аналогичной проблемой, причина была "catalina.out". Это стандартный файл журнала назначения для "System.out" и "System.err". Его размер продолжал расти, замедляя темпы и, в конечном счете, разбился кот. Эта проблема была решена путем вращения "catalina.out". Мы использовали redhat, поэтому мы сделали оболочку script для вращения "catalina.out".

Вот несколько ссылок: -

Статья Mulesoft о каталине (также содержит два метода вращения):

Введение в Tomcat Catalina

Если "catalina.out" не проблема, попробуйте это вместо: -

Статья Mulesoft по оптимизации tomcat: Настройка производительности Tomcat для оптимальной скорости

Ответ 3

Для проблемы, связанной с производительностью, мы должны следовать приведенным правилам:

• Вы можете выравнивать и подчеркивать размер xms и xmx для эффективности.

  -Xms2048m
  -Xmx2048m

2. Вы также можете включить PermGen для сбора мусора.

-XX: + UseConcMarkSweepGC -XX: + CMSPermGenSweepingEnabled -XX: + CMSClassUnloadingEnabled

3. Если страница изменяется слишком часто, чтобы сделать эту опцию логической, попробуйте временно кэшировать динамический контент, чтобы он не нуждался в повторном обновлении. Любые методы, которые вы можете использовать для работы с кешем, которые уже были выполнены, вместо того, чтобы делать это снова, должны использоваться - это ключ к достижению наилучшей производительности Tomcat.

4. Если возникла проблема с базой данных, можно выполнить настройку производительности sql-запроса

5. вращение файла журнала Catalina.out, without restarting Tomcat.

В деталях, Есть два пути.

Первый, который является более прямым, заключается в том, что вы можете повернуть Catalina.out, добавив простой инструмент в инструмент вращения журнала по вашему выбору в командной оболочке Catalina script. Это будет выглядеть примерно так:

"$CATALINA_BASE"/logs/catalina.out WeaponOfChoice 2>&1 &

Просто замените "WeaponOfChoice" вашим любимым инструментом поворота журнала.

Второй способ менее прямой, но в конечном итоге лучше. Лучший способ справиться с вращением Catalina.out - убедиться, что ему никогда не нужно вращаться. Просто установите для свойства "swallowOutput" значение true для всех контекстов в "server.xml".

Это будет маршрутизировать System.err и System.out в любую конфигурацию Logging, которую вы настроили, или JULI, если вы не настроили.

• Подробнее см.: Tomcat Catalina Out

Ответ 4

У нас была проблема, которая похожа на вашу. Tomcat медленно отвечал, но журнал доступа показывал только миллисекунды для ответа. Проблема была в потоковой передаче ответов. Один из наших сервисов возвращал данные в реальном времени, на которые пользователь мог подписаться. EPOLL становились раздутыми. Сетевые запросы не могли попасть в Tomcat. И что еще интереснее, процессор в основном простаивал (поскольку никто не мог попросить сервер сделать что-либо), а потоки акцептора/опроса находились в состоянии WAIT, а не в режиме RUNNING или IN_NATIVE.

В то время мы просто ограничивали количество таких запросов, и все стало нормально.

Ответ 5

Я испытал очень медленную стоковую панель Tomcat на чистой установке Centos7 и нашел следующую причину и решение:

Медленное время запуска Tomcat часто связано с реализацией Java SecureRandom. По умолчанию он использует /dev/random в качестве источника энтропии. Это может быть медленным, поскольку для сбора энтропии используются системные события (например, чтение с диска, нажатие клавиш и т.д.). Как говорится на странице руководства urandom:

When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

Источник: https://www.digitalocean.com/community/info/tomcat-8-5-9-restart-is-really-slow-on-my-centos-7-2-droplet

Исправьте это, добавив следующий параметр конфигурации в ваш tomcat.conf или (предпочтительно) в пользовательский файл в /tomcat/conf/conf.d/:

JAVA_OPTS="-Djava.security.egd=file:/dev/./urandom"