Ajuste de Tomcat
El problema del procesamiento de Tomcat que requiere mucho tiempo se debe principalmente a la cantidad de concurrencia en ese momento, la cantidad de sesiones, la memoria y los ciclos de memoria, y varios otros aspectos. Después de que ocurre un problema, es importante analizarlo.
1. Número de sesiones de Tomcat
Esto se puede ver directamente desde la interfaz de administración web de Tomcat
o con la ayuda de una herramienta de terceros Lambda Probe. que en comparación con el propio Tomcat. Tiene un poco más de funciones de gestión, pero no muchas
Puedes tomar Tomcat como ejemplo.
2. Supervise el uso de la memoria de Tomcat
Usando la jconsole que viene con el JDK, puede verificar el uso de la memoria, el estado del hilo, el número total de clases cargadas actualmente, etc.
También puede utilizar JDK para descargar complementos JVM (como GC, etc.) para ver información más completa. Si está analizando Tomcat local, también puede realizar un muestreo de memoria para ver el uso de cada clase
3. Imprimir el estado de carga de clases y reciclaje de objetos
Esto se puede hacer configurando el inicio de la JVM Parámetros a configurar para imprimir esta información (impresa en la pantalla (también impresa en catalina.log por defecto) o en un archivo), los parámetros específicos son los siguientes:
-XX:+ PrintGC: formato de salida: [GC 118250K->113543K(130112K), 0,0094143 segundos] [GC completo 121376K->10414K(130112K), 0,0650971 segundos 0,0650971 segundos]
-XX:+PrintGCDetails: el formato de salida es [GC [DefNuevo: 8614K->781K(9088K), 0,0123035 segundos] 118250K->113543K(130112K), 0,0124633 segundos] [GC [DefNuevo: 8614K->8614K(9088K), 0,0000665 segundos] Titular: 112 761K- >10414K(121024K), 0,0433488 segundos] 121376K->.
-XX:+PrintGCTimeStamps -XX:+PrintGC: PrintGCTimeStamps se puede mezclar con los dos anteriores para obtener un resultado del formulario: 11.851:[GC 98328K->. 93620K (130112K), 0.0082960 segundos]
-XX:+PrintGCApplicationConcurrentTime: imprime el tiempo de ejecución ininterrumpida del programa antes de cada recolección de basura. Se puede mezclar con lo anterior. Salida: Tiempo de aplicación: 0,5291524 segundos
-XX:+PrintGCApplicationStoppedTime: Imprime la hora en que se detuvo el programa durante la recolección de basura. Se puede mezclar con lo anterior. Formato de salida: Tiempo total en que se detuvo el subproceso de la aplicación: 0,0468229 segundos
-XX:PrintHeapAtGC: imprime información detallada de la pila antes y después de la recolección de basura
-Xloggc:nombre de archivo Se utiliza junto con el. funciones anteriores, registra la información en un archivo analizable
-verbose:class: monitorea el estado de las clases cargadas
-verbose:gc: muestra la salida en el caso de reciclaje de memoria de la máquina virtual Información del dispositivo
-verbose:jni: muestra información de llamadas a métodos locales: muestra información de llamadas a métodos locales
-verbose:jni: muestra información de llamadas a jni, generalmente utilizada para diagnosticar llamadas a jni.
4. Agregue monitoreo remoto JMS
Para Tomcat implementado en otras máquinas en la LAN, puede abrir el puerto de monitoreo JMX para que otras máquinas en la LAN puedan ver algunos parámetros comunes ( Pero algunas funciones más complejas no son compatibles). La configuración en los parámetros de inicio de JVM es la siguiente:
-Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
- Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote .authenticate =falseDjava.rmi.server.hostname=192.168.71.38 Establece la dirección IP para el monitoreo JVM JMS, principalmente para evitar el monitoreo incorrecto de la dirección de intranet 127.0.0.1
-Dcom.sun.management.jmxremote .port= 1090 Configure el puerto de monitoreo JMS de la JVM
-Dcom.sun.management.jmxremote.hostname=192.168.71.38 Configure la dirección IP de monitoreo JMS de la JVM, principalmente para evitar un monitoreo incorrecto de la dirección de intranet 127.0. 0.1
Referencia: /blog/1848665 (fijación de sesión de Tomcat)
nginx no incluye el módulo de fijación de sesión de forma predeterminada y necesita ser recompilado (no sé cómo recompilar en Windows) )
La ventaja es que la eficiencia del procesamiento es mayor, pero la desventaja es que no es adecuado para requisitos de sesión estrictos.
Esta es la primera vez que la rigidez de la sesión El módulo se incluye en nginx y también es la segunda vez que se incluye en el módulo de rigidez de sesión.
3. Resumen
Los anteriores son los puntos clave de la implementación de un clúster, entre los cuales 1 y 2 se pueden usar en combinación. Analice los escenarios específicos.
El propio Tomcat todavía se ejecuta en la JVM. Al ajustar los parámetros de la JVM, podemos darle a Tomcat un mejor rendimiento. La optimización de JVM se centra actualmente en dos aspectos:
1. Ajuste de la memoria
El modo de memoria se establece en catalina.sh, simplemente ajuste la variable JAVA_OPTS, porque más tarde Los parámetros de inicio procesará JAVA_OPTS como parámetros de inicio de JVM.
La configuración es la siguiente:
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4"
Los parámetros son los siguientes:
- Xmx3550m: Establezca la variable JAVA_OPTS en Xmx3550m: Establezca la memoria JVM máxima disponible en 3550M.
-Xms3550m: establece la memoria de sugerencias de JVM en 3550 m. Este valor se puede establecer en el mismo valor que -Xmx para evitar que la JVM reasigne memoria después de cada recolección de basura.
-Xmn2g: Establece el tamaño de la generación joven en 2G. Tamaño del montón = tamaño de la generación joven + tamaño de la generación anterior + tamaño de la generación persistente. El tamaño de la generación persistente suele fijarse en 64 m, por lo que aumentar la generación joven reducirá el tamaño de la generación anterior. Este valor tiene un gran impacto en el rendimiento del sistema y Sun recomienda oficialmente configurarlo en 3/8 del montón total.
-Xss128k: establece el tamaño de pila de cada subproceso después de JDK5.0, el tamaño de pila de cada subproceso es 1 M, y antes de eso, el tamaño de pila de cada subproceso es 256 K. Ajuste la cantidad de memoria requerida por subprocesos de aplicaciones más relevantes. Reducir este valor puede generar más subprocesos en la misma memoria física. Sin embargo, el sistema operativo todavía tiene un límite en la cantidad de subprocesos en un proceso y no se puede generar infinitamente. El valor de la experiencia es de aproximadamente 3000 ~ 5000.
-XX:NewRatio=4: establece la proporción entre la generación joven (incluido el Edén y las dos áreas de supervivientes) y la generación anterior (excluida la generación persistente). Cuando se establece en 4, la proporción entre la generación joven y la generación anterior es 1:4, y la generación joven representa 1/5 de toda la pila
-XX:SurvivorRatio=4: Establece el Edén Zona de Jardín y Superviviente en la proporción de tamaño de la generación joven. Cuando se establece en 4, la proporción entre dos áreas de supervivientes y un área del Edén es de 2:4, y un área de supervivientes representa 1/6 de toda la generación joven.
-XX:MaxPermSize=16m: durará durante generaciones El tamaño se establece en 16 metros.
-XX:MaxTenuringThreshold=0: establece la edad máxima de la basura. Si se establece en 0, los objetos de la generación joven no pasan por el área de supervivientes sino que van directamente a la generación anterior. Esto puede mejorar la eficiencia de aplicaciones con una gran cantidad de generación antigua. Si este valor se establece en un valor mayor, el objeto de la generación joven se copiará varias veces en el área Survivor, lo que puede extender el tiempo de supervivencia del objeto en la generación joven y aumentar la probabilidad de ser reciclado en la generación joven.
2. Ajuste de la estrategia de recolección de basura
La recolección de basura también se puede configurar en catalina.sh ajustando la variable JAVA_OPTS.
-XX:+UseSerialGC:SetSerialCollector
ParallelCollector (rendimiento primero)
Ejemplo:
java -Xmx3550m -Xms3550m - Xmn2g - Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100
-XX:+UseParallelGC: seleccione el recolector de basura como recolector paralelo. Esta configuración sólo es válida para la generación más joven. Es decir, bajo la configuración anterior, la generación joven usa la recolección concurrente, mientras que la generación anterior todavía usa la recolección en serie.
-XX:ParallelGCThreads=20: configura el número de subprocesos del recolector paralelo, es decir, cuántos subprocesos realizarán la recolección de basura juntos al mismo tiempo. Preferiblemente, este valor debería ser igual al número de procesadores.
-XX:+UseParallelOldGC: configure el método de recolección de basura de la generación anterior para que sea paralelo; JDK 6.0 admite la recolección paralela de la generación anterior
-XX:MaxGCPauseMillis=100: configure cada basura colección El tiempo máximo para la generación joven, si no se puede cumplir con este tiempo, la JVM cambiará automáticamente el tamaño de la generación joven para cumplir con este valor. Si no se puede cumplir este requisito de tiempo, la JVM cambiará automáticamente el tamaño de la generación joven para cumplir con este valor.
-XX:+UseAdaptiveSizePolicy: después de configurar esta opción, el recopilador paralelo seleccionará automáticamente el tamaño del área de la generación joven y la proporción del área de supervivientes correspondiente para cumplir con el tiempo de respuesta mínimo o la frecuencia de recolección especificada por el sistema objetivo. etc. Se recomienda activar siempre este valor cuando se utiliza el colector paralelo.
Recopilador concurrente (prioridad de tiempo de respuesta)
Ejemplo: java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC
-XX:+UseConcMarkSweepGC : Establecer generación joven para la recolección simultánea. Después de configurar en la prueba, la configuración -XX:NewRatio=4 falló por motivo desconocido.
Por lo tanto, es mejor utilizar -Xmn para establecer el tamaño de la generación joven en este momento.
-XX:+UseParNewGC: configura la generación joven para la recopilación paralela.
-XX:+UseParNewGC: establece la colección paralela de generación joven, que se puede usar junto con la colección CMS. La JVM de JDK5.0 y superior establecerá este valor por sí misma de acuerdo con la configuración del sistema, por lo que no es necesario volver a establecer este valor.
-XX:CMSFullGCsBeforeCompaction: debido a que los recopiladores concurrentes no comprimen ni organizan el espacio de memoria, se "fragmentarán" después de un período de tiempo, lo que reducirá la eficiencia. Este valor establece cuántas veces se ejecuta el GC antes de compactar y desfragmentar el espacio de memoria.
-XX:+UseCMSCompactAtFullCollection: activa la compresión de versiones anteriores. Esto puede afectar el rendimiento, pero puede eliminar la fragmentación
3. Resumen
La configuración de la memoria requiere compensaciones
1) Cuanto mayor sea la memoria, mayor será el procesamiento eficiencia, pero al mismo tiempo, la recolección de basura lleva más tiempo. Cuanto mayor sea la memoria, mayor será la eficiencia del procesamiento en general.
2) En la mayoría de los artículos en línea, se recomienda configurar Xmx y El efecto es desigual, por lo que esto depende de la situación real.
El conector de Tomcat es un módulo clave para que Tomcat reciba solicitudes HTTP. Podemos configurarlo para especificar el modo IO, la cantidad de subprocesos para procesar las solicitudes recibidas a través del conector y algunas otras estrategias HTTP de uso común. Los principales parámetros de configuración son los siguientes:
1. Especifique el uso del modo NIO para aceptar solicitudes HTTP
protocolo="org.apache.coyote.compression="on" activar la función de compresión
compresiónMinSize="10240" Habilite la compresión del tamaño de salida, el valor predeterminado es 2 KB
noCompressionUserAgents="gozilla, traviata" Los siguientes navegadores no habilitan la compresión
compressableMimeType="text/html, text/xml, text/javascript, text/css, text/plain" Qué tipos de recursos deben comprimirse
5.
Acerca de Tomcat Nio y ThreadPool, su introducción aumenta el proceso. Debido a su complejidad inherente, es necesario verificar cuánta mejora tiene en términos de eficiencia.
6. Ejemplo de configuración
maxThreads="150" minSpareThreads="25" maxSpareThreads="75" aceptarCount="100" conexiónTimeout="20000" protocolo="HTTP/1.1" maxHttpHeaderSize=" 8192" URIEncoding="UTF-8" enableUploadTimeout="true" enableLookups="false" compression="on" compresionMinSize="10240" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/html ,text/xml,text/ javascript,text/css,text/plain"> ... Finalmente, comparta la serie de notas de estudio y preguntas de entrevistas de Spring, que incluyen preguntas de la entrevista de Spring, preguntas de la entrevista de Spring Cloud, preguntas de la entrevista de Spring Boot, notas del tutorial de Spring, notas del tutorial de Spring Boot, el último Manual para desarrolladores de Alibaba (resumen en PDF de 63 páginas), Manual de entrevistas de Java 2022. **** Documento PDF organizado de 1184 páginas. Mensaje privado al blogger (777), deseo que todos lleguen a un nivel superior!!!!