Проблема с производительностью в продакшене

Привет, я работаю над веб-инструментом Java. У нас есть два экземпляра нашего инструмента, развернутые на двух отдельных серверах: один в производстве (используется одновременно многими клиентами) и один в среде разработки, который я редко использую. Оба экземпляра, dev и production, развернуты на точно эквивалентных серверах с одинаковыми характеристиками оборудования, имеют точный код, размер кучи, сервер приложений, версию и т. д.

Но я наблюдаю большую медлительность в рабочем экземпляре по сравнению с экземпляром разработки даже в нечетные часы ночи, когда использование клиентов равно нулю (у нас есть инструменты для мониторинга использования клиентов в производстве). Это удивительно, потому что все факторы идентичны. Я предполагаю, что, поскольку производственный экземпляр активно используется, куча там почти заполнена и фрагментирована, в то время как куча в dev относительно свободна и не фрагментирована. Вот почему экземпляр dev намного быстрее, хотя все идентично. Разумно ли это предположение, поскольку фрагментированная почти полная куча будет тратить больше времени на создание объекта и, таким образом, снизит производительность?


java performance garbage-collection heap-memory
person user496934    schedule 13.07.2011    source источник
comment
Этот шаблон может помочь rationaljava. ком/2015/02/   -  person Dan    schedule 11.02.2015

Ответы (2)


arrow_upward
0
arrow_downward

Почему предполагалось, что куча фрагментирована? Вы можете использовать VisualGc, плагин для визуальной виртуальной машины, чтобы анализировать статистику сборщика мусора в режиме реального времени. Вы можете вывести один из рабочих серверов из трафика и также профилировать его.

http://java.sun.com/performance/jvmstat/visualgc.html

Есть много факторов, которые следует учитывать при анализе. Задержка, сетевой/дисковый ввод-вывод, записи базы данных и их размер + индексы и т. д., и это лишь некоторые из них.

person Deepak Bala    schedule 14.07.2011

arrow_upward
5
arrow_downward

Большинство сборщиков мусора выполняют копирование и сжатие, что позволяет избежать фрагментации. Только Concurrent Mark Sweep может получить некоторую фрагментацию, однако в большинстве случаев это не должно быть проблемой.

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

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

Вы уверены, что ваши серверы не сканируются веб-сканерами? (Они, как правило, не спят и могут быть активны в любое время дня и ночи)

person Peter Lawrey    schedule 13.07.2011
comment
У YourKit есть бесплатная 10-дневная пробная версия. Это очень, очень легко использовать - person matt b; 13.07.2011
comment
Одним из преимуществ YourKit по сравнению с VisualVM является то, что он не использует Java для мониторинга. то есть вы не столкнетесь с проблемой, когда наибольшая нагрузка на ЦП/память приходится на саму VisualVM. - person Peter Lawrey; 13.07.2011