Мой сервер JBoss работает на 100% процессоре SYS в Linux; что может вызвать это?

Question

Мы уже давно отлаживаем эту проблему с сервером JBoss. Примерно после 10 часов работы сервер переходит в 100% -ную панику ЦП и просто останавливается. В течение этого времени вы не можете запускать новые программы, поэтому вы даже не можете kill -quit получить трассировку стека. Эти высокие 100% загрузки процессора SYS длятся 10-20 секунд и повторяются каждые несколько минут.

Мы работали над этим довольно долго. Мы подозреваем, что это как-то связано с GC, но не можем подтвердить это меньшей программой. Мы работаем на 32-битном i386, RHEL5 и Java 1.5.0_10, используя -client и ParNew GC.

Вот что мы уже пробовали:

1. Мы ограничили привязку ЦП, чтобы мы могли реально использовать сервер при высокой нагрузке. С strace мы видим бесконечный цикл SIGSEGV и затем возвращаем sig.

2. Мы попытались воспроизвести это с помощью программы на Java. Это правда, что SYS CPU% поднимается высоко с WeakHashMap или при доступе к нулевым указателям. Проблема заключалась в том, что fillStackTrace занимал много пользовательского процессора%, и поэтому мы никогда не достигали 100% SYS CPU.

3. Мы знаем, что после 10 часов стресса, GC сходит с ума, и полный GC иногда занимает 5 секунд. Поэтому мы предполагаем, что это как-то связано с памятью.

4. jstack в течение этого периода показывал все потоки как заблокированные. pstack в течение этого времени время от времени показывал трассировку стека MarkSweep, поэтому мы не можем быть уверены в этом. Отправка SIGQUIT ничего не дала: Java сбросила трассировку стека ПОСЛЕ окончания периода загрузки SYS%.

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

Если вы знаете, что является причиной этого, пожалуйста, дайте нам знать. Мы открыты для идей и не имеем понятия, любая идея приветствуется:)

Спасибо за ваше время.

Answer 1

Спасибо всем за помощь.

В итоге мы обновили (только половину java-серверов) до JDK 1.6, и проблема исчезла. Только не используйте 1.5.0.10:)

Нам удалось воспроизвести эти проблемы, просто получив нулевые указатели (повышает SYS вместо США и убивает весь linux.)

Еще раз спасибо всем.

Answer 2

Если вы уверены, что проблема с GC (и она звучит , как на основе вашего описания), то добавление флага -XX: + HeapDumpOnOutOfMemoryError в настройки JBoss может помочь (в JBOSS_HOME /bin/run.conf).

Подробнее об этом флаге можно узнать здесь . Первоначально он был добавлен в Java 6, но позже был перенесен обратно в Java 1.5.0_07.

По сути, вы получите «файл дампа», если возникнет ошибка OutOfMemoryError, которую затем можно открыть в различных инструментах профилирования. Нам повезло с Eclipse Memory Analyzer .

Это не даст вам никаких «бесплатных» ответов, но если у вас действительно есть утечка памяти, то это поможет вам ее найти.

Answer 3

Вы можете попробовать добавить параметр командной строки -verbose: gc, который должен выводить GC и размеры кучи в стандартный вывод. направить стандартный поток в файл и посмотреть, совпадают ли высокие времена процессора с основным gc.

Я помню, что у меня были похожие проблемы с JBoss в Windows. Периодически процессор шел на 100%, и Windows сообщала, что использование памяти внезапно падает до 2,5 МБ, намного меньше, чем возможно для запуска JBoss, и через несколько секунд восстанавливается. Как будто весь сервер вышел из строя и перезапустился сам. В конце концов я отследил свою проблему до подготовленного кеша операторов, который никогда не истекает в Apache Commons.

Если кажется, что это проблема с памятью, вы можете начать брать периодические дампы кучи и сравнивать их, или использовать что-то вроде JProbe Memory profiler для отслеживания всего.

Answer 4

У меня была похожая проблема с JBoss (JBoss 4, Linux 2.6) в прошлом году. Я думаю, в конце концов, это оказалось связано с ошибкой приложения, но это было определенно очень сложно выяснить. Я продолжал бы пытаться отправить 'kill -3' процессу, чтобы получить какую-то трассировку стека и выяснить, что блокирует. Может быть, добавить операторы регистрации, чтобы увидеть, если вы можете выяснить, что отключает его. Вы можете использовать 'lsof', чтобы выяснить, какие файлы открыты; это скажет вам, если есть утечка какого-либо ресурса, кроме памяти.

Кроме того, почему вы используете JBoss с -client вместо -server? (Не то чтобы я думаю, что это поможет в этом случае, просто общий вопрос).

Answer 5

Вы пробовали профилирование приложений. Есть несколько хороших профилирующих приложений, которые могут работать на производственных серверах. Это должно дать вам, если у GC возникли проблемы и с какими объектами