Esta sección solo presenta la parte de combate real. Para parámetros teóricos específicos, por favor Baidu.
Herramientas requeridas: Linux Server JMeter Test Tool Xshell Una aplicación web
Los parámetros JVM de Tomcat se pueden configurar en Catalina.sh, y si está en la ventana, puede configurar el archivo .bat.
Configuración 1:
Aquí configuré una ruta de registro GC como /home/log/gc.log para imprimir el registro GC, el montón inicial y la memoria máxima del montón se establecen en 50 m, y cuando el archivo de volcado de salida se desborda, utiliza un recolector de basura en serie y el tamaño de generación permanente es de 50 m.
Ponga la aplicación web en el directorio correspondiente, configure server.xml (la configuración no se introduce aquí) e inicie TomCat.
Las pruebas de rendimiento se realizan utilizando una herramienta de prueba de presión (JMeter). Los estudiantes que nunca lo han usado pueden descargarlo y aprenderlo en el sitio web oficial http://jmeter.apache.org/
Cree un grupo de usuarios (10 subprocesos, cada subproceso solicita 1000 veces), configure la información de la solicitud HTTP, genere un informe agregado y un registro de GC
Echemos un vistazo al registro de GC primero:
GC completo en la pantalla, finalmente verifique el informe agregado:
El rendimiento se mantiene a 122.7 por segundo. Desde este caso podemos ver que la antigua generación está básicamente llena, y después de FULLGC, a la nueva generación le quedará un poco. En general, el tiempo de pausa de GC completo es el más largo y ocurre con tanta frecuencia, obviamente, dicha configuración no es razonable.
Configuración 2:
Esta configuración aumenta principalmente la memoria de montón máximo. Para expandir automáticamente la máquina virtual y obtener un tamaño de memoria de montón estable.
Simplemente preste atención a la memoria de montón máximo de 82924K es de aproximadamente 80 m, lo que significa que la máquina virtual expande automáticamente la memoria de montón a 80m y la estabiliza. Esta prueba de configuración es solo para encontrar una memoria de montón estable para la siguiente prueba.
Configuración tres:
Establezca la memoria inicial del montón en 128 m.
A partir de los resultados de la configuración 2, se puede ver que la memoria del montón finalmente es estable a alrededor de 80 m, por lo que es probable que una memoria de montón menor de 80 m cause una gran cantidad de reacciones GC, por lo que aquí configuré la memoria de montón en 128 m, lo que puede reducir la cantidad de GC.
Puede ver que el rendimiento ha aumentado ligeramente, el número de GC ha disminuido significativamente y los intervalos de tiempo de GCS se han vuelto más largos.
Configuración 4:
Actualmente, utilizando ParallalGC Recycler, que es un reciclador paralelo multiproceso.
El rendimiento de GC Recycler usando paralelo multiproceso ha mejorado ligeramente. (ParallalGC y SerialGC tienen poco efecto sobre el rendimiento sin presión de GC).
Configuración 5:
Configuración 6:
Según la conclusión de la configuración 3, GC ocurrirá con frecuencia en la memoria de montón por debajo de los 80 m. Combinado con la conclusión obtenida en la configuración 4, cuando hay una cierta presión de GC, el rendimiento de ParallElGC y SerialGC mostrará ciertas diferencias. Si la memoria del montón de 5 y 6 está configurada con 64m <80m, se producirá GC frecuente. Al usar diferentes recicladores de GC, teóricamente habrá una gran diferencia en el rendimiento, pero ¿por qué la diferencia en mi experimento no es muy grande y por qué? Oye, mi familia es pobre. Yo uso una CPU de un solo núcleo. En el caso de un solo núcleo, los cambios de rendimiento de ParallElGC no son obvios. Se recomienda serialGC cuando las capacidades de un solo núcleo o paralelo son débiles. ¡Los estudiantes que tienen las condiciones pueden probarlo con un servidor de múltiples núcleos!
Configuración 7:
Intente usar parnewgc. La nueva generación utiliza ParnewGC para reciclar, mientras que la antigua generación todavía usa serialgc para reciclar. ¿Ves cómo es la actuación?
Tiene un mejor rendimiento que usar un reciclador en serie, pero peor rendimiento que usar un reciclador paralelo todo.
Además, la actualización de la versión JDK también puede mejorar un poco el rendimiento, pero la actualización de la versión JDK viene con ciertos riesgos, y algunos errores desconocidos pueden introducirse en la nueva versión de JDK.
Finalmente, enumeré algunos parámetros de configuración JVM de uso común para referencia:
1. Parámetros relacionados con el período de recuperación en serie
• -xx:+useerialgc: use coleccionistas en serie en las generaciones nuevas y antiguas
• -xx: SurvivorRatio: establezca el tamaño del área del Edén y la proporción del área de sobrevivientes
• -xx: PretENesizeThreshold: establezca el umbral para objetos grandes para ingresar directamente a la vejez. Cuando el tamaño del objeto excede este valor, se asignará directamente en la vejez
• -xx: Maxtenuring Throrthold: establece el valor de edad máximo del objeto que ingresa a la vejez. Después de cada GC menor, la edad del sujeto se agrega en 1. Cualquier objeto mayor que esta edad definitivamente entrará en la vejez.
2. Parámetros paralelos relacionados con GC
• -xx:+UseParNewGC: use coleccionistas paralelos en la nueva generación.
• -xx:+useParalleloldgc: use coleccionistas paralelos en la vejez
• -xx:+parallelgcthreads: establece el número de hilos utilizados para la recolección de basura, que generalmente se puede establecer igual al número de CPU. Cuando hay una gran cantidad de CPU, también es posible establecer un valor relativamente pequeño.
• -xx:+maxgcpausemillis: establezca el tiempo máximo de pausa de recolección de basura. Su valor es un entero mayor que 0. Cuando funciona el colector, ajustará el tamaño del montón de Java o algunos otros parámetros, y controlará el tiempo de pausa a Maxgcpausemillis tanto como sea posible.
• -xx: +USeadaptiveSizePolicy: enciende la estrategia de GC adaptativa. En este modo, los parámetros como el tamaño de la nueva generación y la relación de Survivio, y la edad del objeto en la generación anterior se ajustarán automáticamente para lograr el punto de equilibrio entre el tamaño del montón, el rendimiento y la pausa.
• -xx:+gcTimeratio: establezca el tamaño de rendimiento. Su valor es un certificado entre 0 y 100. Suponiendo que el valor de GcTimeratio es n, el sistema no gastará más de 1/(1+N) de tiempo en la recolección de basura.
3. Parámetros relacionados con CMS Collector
• -xx:+useConcmarkSweepGC: la nueva generación usa coleccionistas paralelos, mientras que la antigua generación usa coleccionistas CMS+seriales.
• -xx: ParallElCMSThreads: Establezca el número de subprocesos para CMS.
• -xx: cmsinitiatingCupancyfraction: establezca cuánto se desencadena el colector CMS después de que se usa el espacio de vejez, por defecto 68%
• -xx: usecmsCompActatfullCollection: establezca si CMS necesita desfragmentarse una vez después de completar la recolección de basura
• -xx: cmsfullgcbeforecompacts: establezca cuántas veces se realiza la recolección de basura CMS y se realiza la compresión de memoria.
• -xx:+cmsclassOnloadingEnabled: permite la recuperación de metadatos de clase
• -xx: CMSInitiatingPermoccupancyfracción: cuando la relación de ocupación permanente alcanza este porcentaje, inicie la recuperación de CMS (siempre que -xx:+cmsClassOnloadingEnabled se activa)
• -xx: USECMSInitiatingCupancyonly: significa que la recuperación de CMS solo se realiza cuando se alcanza el umbral.
• -xx:+CMSIncrementalMode: Utilice el modo incremental, que es más adecuado para la CPU única. El modo incremental se marca como se descarta en el medio y se eliminará por completo en JDK9.
4. Parámetros relacionados con el período de recuperación G1
• -xx:+useG1GC: use G1 Recovery
• -xx:+maxgcpausemillis: establezca el tiempo máximo de pausa de recolección de basura
• -xx:+GCPauseIntervalMillis: Establezca el intervalo de tiempo de pausa.
5. TLAB RELACIONADO
• -xx:+USETLAB: active la asignación de TLAB.
• -xx:+printtlab: Imprimir información de asignación relacionada con TLAB
• -xx: tlabsize: establecer el tamaño de TLAB
• -xx:+resizetLab: ajuste automáticamente el tamaño de TLAB
6. Algunos otros parámetros
• -xx:+disableexplicitgc: deshabilitar GC explícito
• -xx:+explicitgcinvokescurrent: use concurrencia para manejar gc explícito
El JVM Tomcat Performance práctico (recomendado) anterior es todo el contenido que comparto con usted. Espero que pueda darle una referencia y espero que pueda apoyar más a Wulin.com.