Как определить, почему Java-приложение работает медленно

Question

У нас есть приложение типа Java ERP. Связь между сервером и клиентом осуществляется через RMI. В часы пик может быть зарегистрировано до 250 пользователей, и около 20 из них работают одновременно. Это означает, что в любой момент времени в часы пик работают около 20 потоков. Сервер может работать часами без каких-либо проблем, но внезапное время отклика становится все выше и выше. Время ответа может быть в минутах.

Мы работаем на Windows 2008 R2 с Sun JDK 1.6.0_16. Мы использовали perfmon и Process Explorer, чтобы увидеть, что происходит. Единственное, что мы находим странным, это то, что, когда сервер начинает работать медленно, число открытых дескрипторов процесса java.exe составляет около 3500. Я не говорю, что это актуальная проблема.

Мне просто любопытно, есть ли какие-то рекомендации, которым я должен следовать, чтобы иметь возможность точно определить проблему. Какие инструменты я должен использовать? ....

Answer 1

Можете ли вы получить доступ к конфигурации журнала этого приложения.

Если вы можете, вы должны изменить уровень журнала на «DEBUG».Отслеживание журналов DEBUG запроса может дать вам полезную информацию о точке конфликта.

Если вы не можете, инструменты профилировщика могут помочь вам:

• VisualVM (бесплатный и хороший продукт)
• Eclipse TPTP (бесплатный, но более сложный, чем VisualVM)
• JProbe (не бесплатно, ноочень мощный. Это мой любимый профилировщик Java, но он дорогой)

Если приложение было разработано с контрольными точками JMX, вы можете подключить JMX-просмотрщик для получения информации ...

Если вы хотите подчеркнуть приложение, чтобы вызвать проблему (если вы хотите проверить, является ли это проблемой с зарядом), вы можете использовать такие инструменты стресса, как JMeter

Answer 2

Звучит так, будто сборка мусора не может идти в ногу, и по какой-то причине начинается сборка "остановка мира".

При запуске включите jvisualvm в JDK и посмотрите на собранные данные, когда производительность упадет.

Answer 3

Для таких острых проблем быстрое jstack <pid> должно быстро указать на проблемную область. Скорее всего, не нужно все это придумывать.

Если бы мне пришлось угадывать, я бы сказал, что Hotspot вскочил и тщательно оптимизировал какой-то плохо написанный код. Netbeans останавливается, когда он использует WeakHashMap с недавно созданными объектами для кэширования данных файла. При оптимизации записи могут быть удалены с карты сразу после добавления. Очевидно, что если на кеш полагаться, большая часть файловой активности следует. Вероятно, вы не увидите, как загорается диск, потому что он все будет кэшироваться ОС.

Answer 4

Помимо ГХ, о которых упоминали другие, попробуйте делать дампы потоков каждые 5-10 секунд в течение примерно 30 секунд во время замедления. Возможен случай, когда вызовы БД, веб-службы или другие зависимости становятся медленными. Если вы посмотрите на протекторные свалки, вы сможете увидеть нити, которые, кажется, не двигаются, и таким образом вы можете сузить вашего преступника.

С точки зрения ГХ, вы отслеживаете использование своего ЦП в это время? Если ГХ работает часто, вы увидите скачок общего использования ЦП.

Если бы это была коробка Solaris, prstat был бы вашим другом.

Answer 5

В аналогичной ситуации я сам кодировал простой код профилирования. В основном я использовал ThreadLocal, в котором есть «StopWatch» (основанный на LinkedHashMap), и затем я вставляю такой код в различные точки приложения: watch.time("OperationX");

затем, после того как поток завершит задачу, я вызову watch.logTime();, и класс напишет журнал, который выглядит следующим образом: [DEBUG] StopWatch time:Stuff=0, AnotherEvent=102, OperationX=150

После этого я написал простой парсер, который генерирует CSV из этого журнала (для пути кода). Лучшее, что вы можете сделать, - это создать гистограмму (это легко сделать с помощью Excel). Средние, средние и даже режимы могут вас обмануть .. Я настоятельно рекомендую создать гистограмму.

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

Таким образом, вы можете быть на 100% уверены, какая именно операция занимает время. Если вы не можете определить виновника, бинарный поиск - ваш друг (детализируйте события).

Звучит действительно примитивно, но работает. Также, если вы сделаете из нее библиотеку, вы можете использовать ее в любом проекте. Это также круто, потому что вы можете легко включить его в производство ..

Answer 6

Проблема, которую вы описываете, довольно типична, но также и общая.Причины могут варьироваться от утечек памяти, разногласий по ресурсам и т. Д. До неправильных политик GC и выделения кучи / PermGen-пространства.Чтобы указать точные проблемы с вашим приложением, вам нужно его профилировать (мне известны такие инструменты, как Yourkit и JProfiler).Если вы профилируете свое приложение мудро, только некоторые циклы приложения выявят проблемы, иначе профилирование само по себе не очень легко.