Archivo

Posts Tagged ‘performance’

¿Problemas de configuración del storage en entornos Linux?

Lynux storage_avanttic

by Maura Condrick

En esta entrada intentaré describir un problema común de configuración del storage en entornos Linux x86_64 antiguos. Un problema que en los peores casos puede deteriorar el rendimiento de la entrada/salida a disco hasta un 10%.

Este defecto lo causa la combinación entre las particiones usadas en los discos y el propio sistema de discos, independientemente del uso al que destinemos la máquina, o de si ejecutamos o no una BBDD.

Las máquinas con una entrada/salida intensiva advertirán más el problema, el cual puede aparecer de repente al actualizar la cabina de discos (sin haber modificado nada en el servidor). En estos casos la mejora del rendimiento de la nueva cabina tiende a enmascarar el problema.

En primer lugar os comentaré las suposiciones que doy por hechas:

  • Supongo que usamos discos o luns presentados al servidor mediante iSCSI, FC o FCoE, no aplicaría, por ejemplo, en el caso de NFS.
  • Supongo que la cabina que presenta los discos es relativamente moderna, esto es que usa bloques de 4Kb (los discos y cabinas antiguas usan bloques de 512 bytes).

Leer más…

Análisis de thread dumps en WebLogic: ThreadLogic

marzo 29, 2016 Deja un comentario

icono threadlogicSiguiendo con el tema de análisis de thread dumps, que se empezó en este otro post, vamos a centrarnos en la utilización de la aplicación ThreadLogic, que ha sido desarrollada por el equipo de arquitectos de Oracle FMW orientándola a dumps de servidores de aplicaciones. Se puede descargar aquí.

Al igual que Samurai y Thread Dump Analyzer (TDA), se trata de una aplicación libre que se arranca lanzando: java -jar <path fichero jar>

Comentar que para las pruebas se han utilizado las mismas aplicaciones que en el post anterior.

Diferencias con Thread Dump Analyzer (TDA)

El desarrollo de esta herramienta se ha realizado a partir de TDA:

  1. La información se muestra de una forma mucho más visual.
  2. La información está más categorizada:

threadlogic categorias dumps

  1. Está muy orientada al análisis de thread dumps de Oracle WebLogic Server:

threadlogic categorias dumps WLS

  1. Se puede filtrar por el estado del thread:

threadlogic filtro health

Stuck threads

Los stuck threads se marcan con este estado a nivel de servidor de aplicaciones cuando un thread está corriendo durante más de X segundos.

Leer más…

Análisis de thread dumps en WebLogic

marzo 3, 2016 5 comentarios

Hace unos meses escribí este post donde os explicaba qué son los stuck threads y cómo detectarlos.

En el post de hoy os voy a presentar algunas herramientas que os pueden ser útiles para realizar el análisis de thread dumps, necesarios para la detección de stuck threads, deadlocks, etc.

Sin embargo, no hay que perder de vista el hecho de que como administradores únicamente podremos saber dónde está el problema, no solventarlo.

 

Ejecución de pruebas

Por si tenéis interés en realizar vuestras propias pruebas, aquí podéis encontrar una aplicación para provocar deadlocks, gentileza de nuestro compañero Àngel Ollé.

Una vez desplegada en una instancia WebLogic, se puede provocar un deadlock realizando peticiones a http://ip:puerto/DeadLockServlet/dl

Para generar stuck threads podéis utilizar la aplicación StuckThreadForFree realizando llamadas a http://ip:puerto/StuckThreadForFree sobre la instancia WebLogic.

Se definen cuántos threads levantar, cuántos segundos mantenerlos levantados y qué operación estarán ejecutando durante ese tiempo:

stuckthreadforfree prueba

¿Qué herramienta utilizar?

Hay muchas herramientas en el mercado pero las más comúnmente utilizadas, que además son libres, son:

  1. Samurai
  2. Thread Dump Analyzer (TDA)
  3. ThreadLogic

Todas consisten en un JAR, por lo que su ejecución es tan simple como lanzar ‘java -jar <path fichero jar>’. La diferencia reside en cómo se muestra la información en la interfaz.

Una vez se ha iniciado la aplicación, abrimos el fichero de texto donde tenemos el thread dump.

Comentar que las aplicaciones pueden interpretar ficheros con varios thread dumps.

 

1. Samurai

Descarga: http://yusuke.homeip.net/samurai/en/samurai.jar

Es una aplicación muy intuitiva donde se identifican con facilidad bloqueos:

Samurai threads bloqueados

Leer más…

Problemas de rendimiento en una JVM

agosto 20, 2015 1 comentario

java

Si te dedicas a la administración de sistemas Middleware, tarde o temprano acabas encontrando problemas de rendimiento sobre las aplicaciones. Hay muchos factores que pueden afectar al rendimiento, como puede ser una aplicación mal desarrollada, consultas en base de datos con tiempo de ejecución elevado, latencias de comunicaciones y un largo etcétera.

En el caso de WebLogic, las instancias no son otra cosa que un proceso Java y, como tal, una mala configuración también puede empeorar el rendimiento.

En este post nos vamos a centrar en la configuración de la memoria de procesos Java.

¿Qué información necesitamos?

Para poder analizar el comportamiento de la memoria de procesos Java es imprescindible recoger las trazas de Garbage Collector (GC). Esto se configura en el arranque del proceso Java mediante unas variables.

Estas trazas aportan datos sobre:

  • Tiempo de ejecución de GC.
  • Estado de la memoria (young, old y permanent) antes y después de las limpiezas.
  • Si se han ejecutado Full GC (FGC) y cuánto han estado ejecutándose: este dato es especialmente importante puesto que durante un FGC la instancia se queda congelada.

Un ejemplo de esta información sería (en esta traza de ejecución no se han realizado FGC):

2015-08-19T00:49:03.965+0200: 9,759: [GC pause (young), 0,0176360 secs]
   [Parallel Time: 15,7 ms, GC Workers: 2]
      [GC Worker Start (ms): Min: 9759,0, Avg: 9759,3, Max: 9759,6, Diff: 0,6]
      [Ext Root Scanning (ms): Min: 3,2, Avg: 3,5, Max: 3,7, Diff: 0,5, Sum: 7,0]
      [Update RS (ms): Min: 0,0, Avg: 0,0, Max: 0,0, Diff: 0,0, Sum: 0,0]
         [Processed Buffers: Min: 0, Avg: 6,5, Max: 13, Diff: 13, Sum: 13]
      [Scan RS (ms): Min: 0,0, Avg: 0,1, Max: 0,1, Diff: 0,1, Sum: 0,1]
      [Object Copy (ms): Min: 11,8, Avg: 11,8, Max: 11,8, Diff: 0,0, Sum: 23,6]
      [Termination (ms): Min: 0,0, Avg: 0,0, Max: 0,0, Diff: 0,0, Sum: 0,0]
      [GC Worker Other (ms): Min: 0,0, Avg: 0,0, Max: 0,0, Diff: 0,0, Sum: 0,1]
      [GC Worker Total (ms): Min: 15,1, Avg: 15,4, Max: 15,7, Diff: 0,6, Sum: 30,8]
      [GC Worker End (ms): Min: 9774,7, Avg: 9774,7, Max: 9774,7, Diff: 0,0]
   [Code Root Fixup: 0,1 ms]
   [Clear CT: 0,1 ms]
   [Other: 1,8 ms]
      [Choose CSet: 0,0 ms]
      [Ref Proc: 1,6 ms]
      [Ref Enq: 0,1 ms]
      [Free CSet: 0,1 ms]
   [Eden: 89,0M(89,0M)->0,0B(89,0M) Survivors: 13,0M->13,0M Heap: 102,2M(2048,0M)->15,0M(2048,0M)]
 [Times: user=0,03 sys=0,00, real=0,02 secs]

¿Cómo interpretamos esta información?

A pesar que las trazas de GC se pueden abrir con cualquier editor de texto, analizar estas trazas manualmente es muy tedioso y lento.

Hay varias herramientas que permiten ver esta información gráficamente y que, además, muestran estadísticas. La más comúnmente utilizada es GCViewer. Es un proyecto opensource que se mantiene vivo.

Antes de empezar

Explicar cómo ver si hay algún problema y cómo solucionarlo es un tema para el que se han escrito libros enteros, por lo que es imposible explicarlo en un post.

Aunque va a gustos, dejo algún libro que he utilizado como referencia (para mi opinión, de obligada lectura si te dedicas al sector):

  • Java Performance: The Definitive Guide“, de Scott Oaks
  • Java Performance“, de Charlie Hunt y Binu John (chapter 7: Tuning the JVM, Step by Step)

Antes de empezar, hay que tener muy en cuenta que:

  1. Realizar un buen análisis es una tarea que no se realiza en un momento. En la mayoría de los casos estamos hablando de una semana de trabajo exhaustivo.
  2. Una mala configuración puede empeorar el rendimiento. Puede llegar a ser peor el remedio que la enfermedad.

Resumiendo: ármate de paciencia y de buena documentación.

Ideas generales

  1.  ¿Cada vez que se ejecuta un FGC es realmente necesario? En versiones anteriores de JDK, cada 60 segundos se ejecutaba, de forma sistemática, un FGC. Este comportamiento no es el deseado, pero se puede evitar añadiendo unas variables en el arranque del proceso Java.
  2. Ampliar el tiempo entre ejecuciones de FGC puede sacar a la luz otros problemas. Los FGC ejecutados sin necesidad pueden estar ocultando leaks de memoria, que acabarían degradando aún más el rendimiento del proceso Java.
  3. Aumentar los espacios de memoria (sea cual sea) provoca un aumento en el tiempo de ejecución de GC y FGC. A veces, menos es más.
  4. La solución no tiene por qué venir únicamente del tuning de la VM. En algunos casos, pasa por el desarrollo de la aplicación que corre por encima (reducir los objetos en memoria y/o el tiempo de permanencia de estos objetos en memoria).
  5. Si se observa que el espacio de memoria young se llena con facilidad y estos objetos se van promocionando a la old, para al poco tiempo borrarse de la old, una solución podría ser aumentar el tamaño de la zona Young en detrimento de la old con el objetivo de disminuir estas promociones a la zona old, además de disminuir el tiempo y frecuencia de los FGC.
  6. Cada vez que se modifica un parámetro de configuración en el arranque, hay que volver a recolectar logs de GC para realizar una comparativa y ver si el cambio ha sido positivo.

avanttic primer partner nacional especializado en Oracle Database Performance and Tuning

julio 29, 2015 Deja un comentario

avanttic consigue ser el primer partner nacional (el cuarto de EMEA y el quinto del mundo) que obtiene la especialización en Oracle Database Performance and Tuning. Con esta nueva certificación avanttic ya tiene acreditadas 25 especializaciones en tecnología Oracle.

Oracle Database Performance and Tuning
automates monitoring and collection of data, performance troubleshooting and analyzing it to find the source of problems, provide recommendations for corrective action and tuning that can be reviewed and executed. This certification differentiates candidates by providing a competitive edge through proven knowledge and expertise.

avanttic obtuvo hace 3 años la especialización en Oracle Database 11g Performance Tuning y ahora, con esta nueva acreditación, amplia su especialización en análisis de rendimiento y ajustes a la versión 12c de Oracle Database.

Revise en este link las 25 certificaciones actuales de avanttic.

Estadísticas de tiempo de un servicio en el ESB 10gR3

A veces, querremos obtener una pequeña estadística de tiempos de llamada a nuestros servicios. Si hemos publicado y consumimos estos servicios en Oracle Enterprise Service Bus 10g, éste nos ofrece la posibilidad de darnos el tiempo en milisegundos que ha consumido cada uno de los servicios implicados en el servicio:

Ver los tiempos de proceso del ESB

Por tanto, a través de la consola podríamos hipotéticamente filtrar todas las llamadas a servicios de nuestro interés e, instancia a instancia, recopilar los tiempos que cada una de ellas ha tardado en procesarse y sacar la estadística a partir de estos datos. Es decir, un proceso largo y tedioso.

¿Es posible obtener estos datos de una forma más automatizada? La respuesta es que . Hay que ir a la fuente de los datos.

Leer más…