Este team de trabajo ha estado mucho tiempo investigando soluciones a tu pregunta, te compartimos la solución por eso deseamos serte de mucha ayuda.
Solución:
Solución 1:
Con una investigación más profunda, parece que el problema de rendimiento se debe principalmente a una gran cantidad de llamadas de red entre dos sistemas (Oracle SSXA y UCM). Las llamadas son rápidas pero abundantes y serializadas, de ahí el bajo uso de CPU (principalmente esperando E / S), el alto promedio de carga (muchas llamadas esperando ser procesadas) y especialmente los largos tiempos de respuesta (por acumulación de pequeños tiempos de respuesta).
¡Gracias por tu información sobre este problema!
Solución 2:
Cuando dice ‘Promedio de carga alta’, supongo que quiere decir que prstat muestra ‘promedio de carga’ en la parte inferior de las cifras de salida de
Total: 135 processes, 3167 lwps, load averages: 54.48, 62.50, 63.11
Estos números son similares a los que proporciona la parte superior y probablemente se refieren al tamaño de cola promedio del proceso en ejecución. Este no es el porcentaje de tiempo del procesador que se usa, sino cuántas ‘cosas’ están acosando a la CPU para que se ejecute. Es cierto que estos se ven bastante altos, pero todo depende de la aplicación que esté ejecutando; Es posible que los procesos no estén haciendo mucho una vez que obtengan su espacio. Consulte aquí para obtener una buena explicación sobre top.
No estoy familiarizado con WebLogic pero he notado que, en general, con Apache Tomcat se pueden generar muchos subprocesos de Java simultáneamente para lo que parece no ser muchas solicitudes. Podría ser esto lo que está causando esos altos números de carga promedio. Asegúrese de que está utilizando la agrupación de conexiones cuando sea apropiado para conectarse al backend y considere aumentar la cantidad de subprocesos inactivos que están disponibles para su aplicación para manejar las conexiones (no estoy seguro de cómo hacer esto en WebLogic; Tomcat tiene un grupo de subprocesos por conector o un grupo de subprocesos ejecutor general). Si no hace esto, es posible que se generen nuevos hilos para procesar las solicitudes.
En cuanto al rendimiento, debes concretar qué parte de tu aplicación está sufriendo. ¿Es el procesamiento que está sucediendo en el lado de WebLogic / Java de las cosas, el acceso a la base de datos, las búsquedas de DNS (si se están haciendo por alguna razón …), problemas de red o algo en el sistema operativo?
El 99% de las veces será su código y cómo se comunica con la base de datos lo que está reteniendo las cosas. Luego será la configuración de la aplicación web. Más allá de este punto, estará trabajando para exprimir los últimos milisegundos de su aplicación o buscando proporcionar una mayor concurrencia con el mismo hardware. Para este ajuste de rendimiento más detallado, necesita métricas.
Para Java, sugiero instalar Java Melody. Puede proporcionar una gran cantidad de información sobre lo que está haciendo su programa y ayudar a reducir dónde está pasando el tiempo. Solo lo he usado con Tomcat, pero debería funcionar bien con cualquier contenedor / servlet Java EE.
Hay varias formas de ajustar Java, así que eche un vistazo a sus pautas de rendimiento (estoy seguro de que probablemente lo haya hecho) y asegúrese de que está configurando el tamaño de pila correcto, etc., adecuado para su programa. Java Melody puede ayudarlo a rastrear el tamaño del montón de Java que está consumiendo, así como qué tan duro está trabajando el recolector de basura / con qué frecuencia interrumpe su programa para borrar objetos.
Espero que te haya sido de ayuda. Si proporciona más información, es posible que pueda actualizar esta respuesta y adaptarla más a sus necesidades.
Solución 3:
Como nota al margen, el promedio de carga también incluye las cosas que esperan la actividad del disco (es decir, el acoso del disco), así como las que esperan la CPU, es una suma de ambas … por lo que es posible que tenga problemas en una u otra.
Consulte http://en.wikipedia.org/wiki/Load_(computing) “Linux también incluye [in its load average] procesos en estados de suspensión ininterrumpida (generalmente esperando la actividad del disco) “
Como nota al margen, el problema particular con el que me encontré fue que tenía un promedio de carga alto, pero también mucha CPU inactiva y bajo uso del disco.
Parece que, al menos en mi caso, a veces los subprocesos / procesos que esperan E / S aparecen en el promedio de carga, pero no no provocar un aumento en la columna “aguardar”. Pero todavía están vinculados a E / S.
Puede decir que este es el caso con el siguiente código, si lo ejecuta en jruby (solo hace 100 subprocesos con muchas E / S cada uno):
100.times Thread.new loop f
Lo que da un resultado superior como este:
top - 17:45:32 up 38 days, 2:13, 3 users, load average: 95.18, 50.29, 23.83
Tasks: 181 total, 1 running, 180 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.5%us, 11.3%sy, 0.0%ni, 85.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32940904k total, 23239012k used, 9701892k free, 983644k buffers
Swap: 34989560k total, 0k used, 34989560k free, 5268548k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31866 packrd 18 0 19.9g 12g 11m S 117.0 41.3 4:43.85 java
912 root 11 -5 0 0 0 S 2.0 0.0 1:40.46 kjournald
Entonces puede ver que tiene mucha CPU inactiva, 0.0% wa, pero un promedio de carga muy alto.
iostat muestra de manera similar el disco básicamente inactivo:
avg-cpu: %user %nice %system %iowait %steal %idle
9.62 0.00 8.75 0.00 0.00 81.62
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 49.00 0.00 6.40 0.00 221.60 69.25 0.01 0.81 0.66 0.42
sda1 0.00 49.00 0.00 6.40 0.00 221.60 69.25 0.01 0.81 0.66 0.42
sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
ver también http://linuxgazette.net/141/misc/lg/tracking_load_average_issues.html
Como nota adicional, esto también parece implicar que (al menos en este caso, ejecutando CentOS) el promedio de carga incluye cada hilo por separado en el total.
Solución 4:
Tuve el mismo problema hoy. Después de algunas investigaciones y diagnósticos, me di cuenta de que mi pequeño VPS estaba quedando sin disco.
En shell / prompt (Linux / Unix) escriba
df -h
ver el disco libre en su máquina. Si se está quedando sin disco, ese puede ser el problema / problema.
Solución 5:
Otra herramienta útil que ayudará en esta situación es nmon.
Incluye una variedad de formas de ver los mismos datos presentados por las otras herramientas, en un pequeño paquete.
Si se trata de contenido que no se puede almacenar en caché, recomendaría colocar varios servidores detrás de un equilibrador de carga como haproxy en modo tcp para distribuir la carga.
Comentarios y calificaciones
Si guardas alguna cuestión y forma de aumentar nuestro crónica te recomendamos añadir una disquisición y con mucho placer lo observaremos.