que - servlets java

¿Parámetros de arranque apropiados de Tomcat 5.5 para sintonizar JVM para una aplicación web de gran demanda y gran demanda?

Question

Recientemente hemos migrado una aplicación web grande y de gran demanda a Tomcat 5.5 de Tomcat 4 y hemos notado un comportamiento de desaceleración peculiar que parece estar relacionado con las pausas de JVM. Para ejecutar nuestra aplicación y soportar una mayor carga a lo largo del tiempo en Tomcat 4, se configuraron y ajustaron muchos parámetros de JVM no tan estándar como se muestra a continuación, y espero que alguien con experiencia de ajuste de JVM de Tomcat pueda comentar cualquier cosa que pueda ser perjudicial a una instalación de Tomcat 5.5. Tenga en cuenta también que algunos de estos podrían ser transferidos de versiones anteriores de Java (estábamos ejecutando Tomcat 4 en Java 1.6 con estos parámetros con éxito durante algún tiempo, pero algunos pueden haberse introducido para ayudar a la recolección de basura en Java 1.4 que fue la base de nuestro Tomcat 4 se instala durante mucho tiempo, y ahora puede hacer más daño que bien).

Algunas notas:

• La huella de la memoria de la aplicación es de alrededor de 1GB, probablemente un poco más.
• La CPU no es un problema: todas las máquinas que atienden la aplicación (carga equilibrada) son <30% CPU
• Mucho espacio libre en memoria física en las máquinas.
• -XX: MaxPermSize = 512m fue el único parámetro agregado como parte de la actualización 5.5 y fue reactivo a un problema de espacio permgen fuera de memoria (que resolvió).
• Ejecutando en Java 1.6, SO Solaris

-server -Xms1280m -Xmx1280m -XX: MaxPermSize = 512m -XX: ParallelGCThreads = 20 -XX: + UseConcMarkSweepGC -XX: + UseParNewGC -XX: SurvivorRatio = 8 -XX: TargetSurvivorRatio = 75 -XX: MaxTenuringThreshold = 0 -XX: + AggressiveOpts -XX: + PrintGCDetails -XX: + PrintGCTimeStamps -XX: -TraceClassUnloading -Dsun.io.useCanonCaches = false -Dsun.net.client.defaultConnectTimeout = 60000 -Dsun.net.client.defaultReadTimeout = 60000

Answer 1

También puede valer la pena experimentar con una JVM alternativa (como JRockit) para ver si las diferencias en el modelo de recolección de basura son adecuadas para su aplicación.

Answer 2

Acabo de encontrar un seminario web de los desarrolladores de Tomcat en tuncat tomcat: http://springsource.com/node/555 . una continuación del webinar: http://blog.springsource.com/2008/10/14/optimising-and-tuning-apache-tomcat-part-2/

BR,
~ A

Answer 3

Como alguien que también está metiéndose con esto, ciertamente no tengo ninguna respuesta definitiva, especialmente dado lo específico de la aplicación de este tipo de cosas. Una buena referencia, que probablemente haya visto, está aquí:

http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html

Sin embargo, es una lista bastante larga de parámetros jvm, lo que sugiere que probablemente haya parámetros innecesarios, especialmente dado que tiene varias opciones de depuración en (PrintGCDetails, PrintGCTimeStamps, TraceClassUnloading) que no pueden ser buenas en una aplicación de producción. 60 segundos de tiempo de espera también pueden estar consumiendo recursos. "servidor" es el predeterminado pero no hará ningún daño.

¿Cómo se ejecuta la aplicación con parámetros mínimos de ajuste (tamaño jvm, MaxPermSize)?

Answer 4

Uno de los campeones de Java, el blog de Kirk Pepperdine: http://kirk.blog-city.com/how_to_cripple_gc_ergonomics.htm .
Cita 1 "La documentación del GC le dirá a qué afecta la configuración, pero a menudo sin indicar cuál será el efecto. La mayor pista de que ha tomado la bifurcación equivocada en el camino es cuando establece explícitamente un valor y luego da una pista a la GC ergonomía. Otra pista es si no tiene un buen motivo para ajustar una configuración. Y simplemente porque un experto llamado dice que esta configuración funciona mejor es solo ruido, no sonido y ciertamente no es un motivo ".

Cita 2 "Como lo indiqué en una entrada de blog de prevous, no toque las perillas a menos que tenga una muy buena razón para hacerlo. Si debe tocar las perillas, apriete ligeramente solo usando las que ayudan a la ergonomía y no aquellas que anula la habilidad ergonómica para cumplir con los objetivos de tiempo de pausa y rendimiento ".

Entonces, sugiero que vuelvas a la normalidad
-server -Xms1280m -Xmx1280m -XX: MaxPermSize = 512m -XX: + UseConcMarkSweepGC -XX: + PrintGCDetails -XX: + PrintGCTimeStamps -XX: -TraceClassUnloading -Dsun.io.useCanonCaches = false -Dsun.net.client.defaultConnectTimeout = 60000 -Dsun.net.client.defaultReadTimeout = 60000

Encuentre si eso le da un mejor rendimiento. Si es así, mantenlo
Por cierto, did -XX: MaxPermSize = 378m tiene algún problema?
Java 1.6 tiene mucha mejor ergonomía que 1.4. Es posible que desee ajustarlo a menos de 1.4
Por cierto, ¿has probado Tomcat 6? Tomcat 6 funciona mucho mejor en Java 6 que Tomcat 5.5.

PD: He estado usando Tomcat por un tiempo y por lo general trato de dar rienda suelta al JDK del sol con poca afinación aquí y allá.

Answer 5

También puede consultar la modificación de la cantidad mínima / máxima de subprocesos que Tomcat utilizará para gestionar las solicitudes en conf/server.xml :

<Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" ...

Una regla general que había escuchado en un trabajo anterior era que maxThreads debería ser igual a la cantidad de conexiones simultáneas que espera manejar. No estoy seguro de cuán científica es esa afirmación, aunque ciertamente creo que tiene sentido ya que no quiere que los clientes queden bloqueados esperando que un hilo se libere para manejar su solicitud.