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

Question

Hemos migrado recientemente una aplicación web grande y de gran demanda a Tomcat 5.5 de Tomcat 4 y hemos notado un comportamiento peculiar de desaceleración 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:

• huella de memoria de aplicaciones es alrededor de 1 GB, probablemente un poco más.
• CPU no es un problema - todas las máquinas servir a la aplicación (carga equilibrada) son < 30% de la CPU
• Las porciones de espacio libre en la 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ó).
• se ejecuta en Java 1.6, el sistema operativo 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

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 que ha tomado la bifurcación incorrecta en el camino es cuando establece explícitamente un valor y luego da un sugerencia para la ergonomía de GC Otra pista es si no tienes una razón válida para ajustar una configuración. Y simplemente porque un experto dice que esta configuración funciona mejor es solo ruido, no sonido y ciertamente no es una razón.

Cita 2 "Como he indicado 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 usando solo aquellos que ayudan a la ergonomía y no aquellos que angostan la capacidad ergonómica para cumplir con sus objetivos de tiempo de pausa y rendimiento. "

Entonces, le sugiero que vuelva a plain
-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

encontrar si eso le da un mejor rendimiento Si es así, se adhieren a ella
Por cierto, hizo -XX:.? MaxPermSize = 378m tener ningún problema
Java 1.6 tiene mucha mejor ergonomía que 1.4. Es posible que desee sintonizar menos de 1.4
BTW, ¿ha probado Tomcat 6? Tomcat 6 funciona mucho mejor en Java 6 que Tomcat 5.5.

P.S: 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 2

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 es probable que hayas visto, es aquí:

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

Sin embargo, es una muy larga lista de parámetros de JVM, lo que sugiere que hay parámetros probablemente innecesarios conjunto, sobre todo teniendo en cuenta que usted tiene varias depuración opciones 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 predeterminado pero no hará ningún daño.

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

Answer 3

acabo de encontrar un seminario web de los desarrolladores de tomcat en tuning tomcat: http://springsource.com/node/555. un seguimiento de la webinar: http://blog.springsource.com/2008/10/14/optimising-and-tuning-apache-tomcat-part-2/

BR,
~ Un

Answer 4

También puede ser que desee echar un vistazo a cambiar el número mínimo/máximo de hilos que Tomcat va a utilizar para manejar las solicitudes de conf/server.xml:

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

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

Answer 5

También puede ser vale 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.