Загрузка сервера Java на 100% после двух дней непрерывной работы около 110 пользователей - PullRequest
Новая
       16

Загрузка сервера Java на 100% после двух дней непрерывной работы около 110 пользователей

6 голосов
/ 09 октября 2009

У меня есть tomcat 6.0.20, апрель 1.2, jdk 1.6.0_15 с mysql 5.1.38, работающий на RHEL-боксе с 4 ГБ оперативной памяти. На нем есть одно простое приложение jsp / servlet с 5 пользователями, одно - 1.2.0.9 с 64 пользователями и одно приложение 2.0 с 35 пользователями. Пользователи Struts 2.0 делают запись каждую секунду, около 900 записей в день. Я также использую toplink для постоянства в последних двух приложениях. В коде я объявил все объекты без ссылок на null, применил производственные значения для файлов конфигурации с сайта Struts 2 и с сайта Tomcat. Применено кеширование потоков в mysql, уменьшите wait_timeout и interactive_timeout, чтобы оно было эквивалентно тайм-ауту сеанса tomcat. Увеличены дескрипторы файлов в linux. Переработанные запросы. Изучил дамп потока, посмотрел статистику gc, применил вышеуказанные изменения на основе этого,

ЕЩЕ все еще сталкивается с ошибкой "java.lang.OutOfMemoryError".

в разное время это для разных вещей, иногда это Servlet.service (), иногда его image.servlet, иногда это яшма, которая его вызывает.

крайне разочаровывает, так как ошибки не постоянны, а постоянно меняются со временем

Любая помощь, пожалуйста, будет очень оценили !!!

JAVA_OPTS = -сервер -XX: + UseConcMarkSweepGC -XX: + CMSClassUnloadingEnabled -XX: + CMSPermGenSweepingEnabled -XX: + CMSParallelRemarkEnabled (менеджер tomcat сообщает, что 34 мб пусто, поэтому не использовали permsize, mx, mn и т. д.)

persistence.xml 

 <property name="toplink.jdbc.url" value="jdbc:mysql://localhost:3306/dbname?autoReconnect=false"/>

server.xml 

<Connector port="80" protocol="HTTP/1.1" connectionTimeout="2000" redirectPort="8443" compression="on" compressableMimeType="application/octet-stream,text/html,text/xml,text/plain,application/x-javascript,image/gif,text/css,image/gif,application/vnd.ms-excel,application/pdf" enableLookups="false"/>

context.xml 

<Context reloadable="false" delegate="false" privileged="false">

Ответы [ 4 ]

5 голосов
/ 09 октября 2009

Во-первых, вы должны убедиться, какой процесс потребляет весь процессор. Это действительно Java-программа? Попробуйте top(1), чтобы понять это, если вы еще этого не сделали.

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

Если это не так, у вас недостаточно памяти (независимо от того, что говорит менеджер tomcat). Запустите консоль JMX и проверьте различные области памяти. Я предполагаю, что permgen довольно полон (есть много больших JAR-файлов на вашем пути к классам? Или вы где-то используете cglib?) Когда это происходит (и так как у вас включен perm gen GC), Java VM попытается освободить память постоянное пространство все время.

Если вы не используете что-то, что создает файлы классов во время выполнения (например, язык сценариев, такой как Groovy), это не будет работать: в обычных программах Java классы никогда не могут быть GC-файлами. Если вы все еще делаете это, ГХ будет работать и работать и ничего не добьется, кроме как сжечь всю мощность процессора.

1 голос
/ 22 апреля 2010

Возможно, это та же проблема, которую решают 1 и 2 . Попробуйте создавать только небольшие транзакции.

0 голосов
/ 09 октября 2009

ваша проблема в том, что у вас в коде что-то вроде этого: 

       new Thread(){
          public void run(){
             //something
          }
       }.start();

, который, в свою очередь, каждый раз создает новый файл определения класса в кэше Tomcat - и это занимает место, поэтому у вас есть исключение PermGenSpace ...

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

      class MyJobDoer extends Thread{
          public void run(){
             //something
          }
       }

      MyJobDoer mjd=new MyJobDoer();
      mjd.start();
0 голосов
/ 09 октября 2009

Я бы рекомендовал использовать jstat для мониторинга памяти tomcat и шаблонов сборки мусора.

Вы говорите, что сталкиваетесь с ошибками perm gen, но не увеличили количество perm gen. Перезагрузка приложений tomcat может вызвать утечку perm gen, но вы, вероятно, наблюдаете за тем, как вы используете, прежде чем открывать все свои страницы, что приводит к загрузке большего количества классов в perm gen.

...