Может ли текущее приложение Java / Tomcat 6 использовать преимущества 64-битной платформы Windows в плане производительности и использования памяти - PullRequest
Новая
       5

Может ли текущее приложение Java / Tomcat 6 использовать преимущества 64-битной платформы Windows в плане производительности и использования памяти

0 голосов
/ 01 декабря 2010

В настоящее время мы разработали приложение с использованием Java 6 на основе Windows 32bit (Dual Core и 3G Ram). Если мы установим в 64-битную операционную систему Windows, будет ли она работать лучше из-за того, что имеет преимущество в ресурсах по сравнению с 64-битной (та же разница в ОС) 64-битная машина имеет четырехъядерный процессор и Ram более 4g. Различается ли для JVM разница между 32 и 64 битами.

Заранее благодарим вас за отзыв.

Дополнительная информация

Я занимаюсь информационной системой управления событиями безопасности (SIEM) - управление журналом. У нас есть 4 важные части,

  • Collector - для сбора логов с устройств / системы,
  • Агрегатор - для объединения системного журнала в метаданные для отчетов,
  • Мониторинг в реальном времени - для отображения в реальном времени аналитических отчетов / диаграмм и информационной панели, которая должна запускаться каждую секунду
  • GUI - приложения Struts2. который запускает веб-интерфейс, аналитику журнала, резервное копирование и другие вещи

Пока что большинство ресурсов процессора и памяти используются 1-Collector, 2-RealTime, 3-Aggregator. Прямо сейчас в 32-битном, сборщик может получать до 2000 фунтов в секунду. Если больше, то это приведет к краху памяти. Поэтому мы использовали программное обеспечение tanuki для автоматического перезапуска службы коллектора. Мы используем Tanuki для разделения использования памяти и автоматического перезапуска после обнаружения кучи памяти.

Наша цель - увеличить число событий в секунду с 2000 логов до максимального, если это возможно, используя 64-битные преимущества. Для GC мы позволяем Java обрабатывать автоматически, более важно, что мы можем обрабатывать больше журналов за 1 секунду без каких-либо проблем.

Ответы [ 2 ]

4 голосов
/ 01 декабря 2010

Переключение на 64-битную JVM не гарантирует каких-либо различий в производительности.Однако вы увидите огромную разницу в объеме ОЗУ, которое можно выделить.В 32-битной Windows максимальный объем ОЗУ, который может быть выделен для кучи, составляет максимум 1,6 ГБ.

Если вы видите, что ваше приложение загружается на 32-битной машине, то переключитесьна 64-битной машине и добавление достаточного объема ОЗУ, вероятно, улучшит вашу производительность.Возможно, вам также удастся сделать выбор в пользу более быстрого, но более требовательного к памяти алгоритма, где такие варианты существуют.

На момент написания этой статьи вы, вероятно, не увидите существенной разницы между запуском приложения в 32-битной средеJVM и 64-разрядная JVM на одном и том же оборудовании.В конце концов, поддержка 32-битных операционных систем и JVM, вероятно, будет прекращена, но это не проблема производительности.

Я настоятельно рекомендую начать с профилирования приложения, чтобы увидеть, где находятся горячие точки производительности.

Это распространенное заблуждение, что 64-битная автоматически означает лучшую производительность, чем 32-битная.См., Например, этот JVM faq и этот MS Windows 7 FAQ .

1 голос
/ 01 декабря 2010

Это действительно зависит от характера вашего приложения и от того, где находятся ваши узкие места в производительности.

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

Является ли ваше приложение многопоточным, как большинство веб-серверов?Если это так, переход от 2 до 4 ядер очень вероятно поможет, если у вас нет существенных проблем с блокировкой / конфликтами.

Если вы посмотрите на настройку GC, вы можете попробовать параллельный GC на 4-ядерном процессоре,Это может значительно сократить время паузы GC, в то же время вызывая дополнительные издержки.Для приложения, чувствительного к задержке, над которым я работал, это определенно стоило.

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

...