Pregunta

Estoy intentando resolver problemas de rendimiento con una aplicación web java de tomcat compleja y grande. El mayor problema en este momento es que, de vez en cuando, el uso de la memoria aumenta y la aplicación deja de responder. He arreglado todo lo que puedo arreglar con los perfiladores de registro y el análisis bayesiano de los archivos de registro. Estoy considerando ejecutar un generador de perfiles en el servidor tomcat de producción.

Una nota para el lector con delicadas sensibilidades:

Entiendo que a algunos les puede parecer ofensiva la idea de perfilar una aplicación de producción. Tenga la seguridad de que he agotado la mayoría de las otras opciones. La razón por la que estoy considerando esto es que no tengo los recursos para duplicar completamente nuestra configuración de producción en mi servidor de prueba, y no he podido causar las fallas de interés en mi servidor de prueba.

Preguntas :

Estoy buscando respuestas que funcionen bien para una aplicación web de java que se ejecute en Tomcat o responda esta pregunta de una manera independiente del lenguaje.

  • ¿Cuáles son los costos de rendimiento del perfilado?
  • ¿Alguna otra razón por la que es una mala idea conectar y crear un perfil de una aplicación web en producción (modos de falla extraños, problemas de seguridad, etc.)?
  • ¿En qué medida afecta el perfil a la huella de memoria?
  • Específicamente, ¿existen herramientas de creación de perfiles Java que tienen costos de rendimiento muy bajos?
  • ¿Alguna herramienta de creación de perfiles Java diseñada para crear perfiles de aplicaciones web?
  • ¿Alguien tiene puntos de referencia sobre los costos de rendimiento de los perfiles con visualVM?
  • ¿A qué tamaño de aplicaciones y conjuntos de datos puede escalar visualVM?
¿Fue útil?

Solución

OProfile y su ancestro DPCI se desarrollaron para perfilar sistemas de producción. La sobrecarga de estos es muy baja, y perfilan su sistema completo , incluido el kernel, por lo que puede encontrar problemas de rendimiento en la VM y en el kernel y las bibliotecas.

Para responder a sus preguntas:

  1. Overhead: son perfiladores muestreados , es decir, generan un temporizador o contador de rendimiento interrumpe en algún intervalo regular, y observan qué código se está ejecutando actualmente. Lo utilizan para crear un histograma de donde pasa su tiempo, y la sobrecarga es muy baja (1-8% es lo que reclaman ) por intervalos de muestreo razonables.

    Eche un vistazo a este gráfico de la frecuencia de muestreo en comparación con la sobrecarga para OProfile. Puede ajustar la frecuencia de muestreo para una menor sobrecarga si los valores predeterminados no son de su agrado.

  2. Uso en producción: La única advertencia al usar OProfile es que necesitará instalarlo en su máquina de producción. Creo que hay soporte del núcleo en Red Hat desde RHEL3, y estoy bastante seguro de que otras distribuciones lo admiten.

  3. Memoria: No estoy seguro de cuál es la huella de memoria exacta de OProfile, pero creo que mantiene buffers relativamente pequeños alrededor y los descarga en archivos de registro de vez en cuando.

  4. Java: OProfile incluye agentes de perfiles que admiten Java y que conocen el código que se ejecuta en los JIT. Por lo tanto, podrá ver las llamadas de Java, no solo las llamadas de C en el intérprete y JIT.

  5. Aplicaciones web: OProfile es un generador de perfiles a nivel de sistema, por lo que no es consciente de cosas como sesiones, transacciones, etc. que tendría una aplicación web.

    Dicho esto, es un perfilador de sistema completo , por lo que si su problema de rendimiento se debe a malas interacciones entre el sistema operativo y el JIT, o si se encuentra en alguna biblioteca de terceros, usted ' Podré ver eso, porque OProfile perfila el kernel y las bibliotecas. Esta es una ventaja para los sistemas de producción, ya que puede detectar problemas debidos a configuraciones erróneas o detalles del entorno de producción que podrían no existir en su entorno de prueba.

  6. VisualVM: No estoy seguro de esto, ya que no tengo experiencia con VisualVM

Aquí hay un tutorial sobre el uso de OProfile para encontrar cuellos de botella de rendimiento .

Otros consejos

He utilizado YourKit para crear perfiles de aplicaciones en un entorno de producción de alta carga, y aunque ciertamente hubo un impacto, fue fácilmente aceptable. Yourkit hace un gran problema de poder hacer esto de una manera no De manera invasiva, como desactivar selectivamente ciertas funciones de creación de perfiles que son más caras (en realidad es una escala móvil).

Mi aspecto favorito es que puede ejecutar la máquina virtual con el agente YourKit en ejecución, y tiene un impacto cero en el rendimiento. solo cuando se conecta la GUI y se comienza a perfilar, tiene efecto.

No hay nada de malo en perfilar aplicaciones de producción. Si trabaja en aplicaciones distribuidas, hay ocasiones en que se produce una excepción fuera de la memoria en un escenario de probabilidad muy singular que es muy difícil de reproducir en un entorno dev / stage / uat.

Puede intentar usar perfiladores personalizados, pero si tiene prisa y está conectando / configurando un perfilador en un cuadro de producción, tomará tiempo, también puede usar el jvm para tomar un volcado de memoria (el volcado de memoria jvms también le proporciona un hilo) volcado)

  1. Puede activar la generación automática en la línea de comandos de la JVM, usando la siguiente opción: -XX: + HeapDumpOnOutOfMemoryError

  2. El proyecto Eclipse Memory Analyzer tiene una característica muy poderosa llamada & # 8220; agrupar por valor & # 8221 ;, que hace posible construir una consulta de objeto y reagrupar las instancias por un valor de campo. Esto es útil en el caso de que haya muchas instancias que contienen un conjunto más pequeño de valores posibles, y puede ver qué valores se utilizan más. Esto realmente me ha ayudado a entender algunos volcados de memoria complejos, así que te recomiendo que lo pruebes.

También puede considerar utilizar uno de los modernos HotSpot JVM - Java Flight Recorder y Java Mission Control . Es un conjunto de herramientas que le permiten recopilar información de tiempo de ejecución de bajo nivel con una sobrecarga de la CPU de aproximadamente el 5% (no puedo probar la última afirmación de todos modos, esta es la declaración del ingeniero de Oracle que presentó la característica y la demostración en vivo). p>

Puede utilizar esta herramienta siempre que su aplicación esté ejecutando 1_7u40 o JVM. Para habilitar la recopilación de información de tiempo de ejecución, debe iniciar JVM con indicadores particulares:

  

De forma predeterminada, JFR está deshabilitado en la JVM. Para habilitar JFR, debe iniciar su aplicación Java con la opción -XX: + FlightRecorder . Debido a que JFR es una característica comercial, disponible solo en los paquetes comerciales basados ??en Java Platform, Standard Edition (Oracle Java SE Advanced y Oracle Java SE Suite), también tiene que habilitar las características comerciales utilizando -XX: + UnlockCommercialFeatures opciones.

(citado http: // docs. oracle.com/javase/8/docs/technotes/guides/jfr/about.html#sthref7 )

Agregué esta respuesta, ya que esta es una opción viable para crear perfiles en la IMO de producción.

También hay un complemento Eclipse que admite JFR y JMC y es capaz de mostrar información fácil de usar.

Las herramientas han mejorado enormemente a lo largo de los años. En estos días, la mayoría de las personas que tienen necesidades como estas utilizan una herramienta que se enlaza con la API de instrumentación de Java en lugar de la API de creación de perfiles. Seguramente hay más ejemplos, pero NewRelic y AppDynamics vienen a la mente. Las soluciones basadas en instrumentación generalmente se ejecutan como un agente en la JVM y recopilan datos constantemente. Informan los datos a un nivel superior (transacción comercial, transacción web, transacción de base de datos) que el enfoque de perfiles anterior y le permiten profundizar (hasta el método o la línea) si es necesario. Incluso puede configurar el monitoreo y las alertas, por lo que puede realizar un seguimiento / alerta de métricas como el tiempo de carga de la página y el rendimiento en relación con los SLA. Con estas excelentes herramientas, realmente no debería tener ninguna razón para ejecutar un perfilador en producción por más tiempo. El costo de ejecutarlos es insignificante.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top