5 votos

Ubuntu Server 12.04 Carga de la CPU

Tengo un Servidor (2x Hexa-Core Xeon E5649 2.53 GHz w/HT con 32GB de RAM y 20000 GB de ancho de Banda) con Ubuntu Server 12.04 LTS. Ejecuta el servidor de la LÁMPARA y que sirve a un único sitio web, el número estimado de los usuarios es de alrededor de 15.000 al mismo tiempo.

En el momento tengo alrededor de 2000 usuarios en línea cada uno de ellos se ejecuta 50 las consultas de MySQL (valores pequeños en su mayoría seleccionar e insertar) desde el principio hasta el final de la sesión. Servidor de la Carga de la CPU es alta en este número de conexiones, mientras que el uso de RAM es casi 1GB de 32GB vale la pena mencionar que el servidor estaba corriendo muy rápido con ningún problema en absoluto, pero estoy preocupado por el promedio de carga. http://s12.postimage.org/z7hi6mz3h/photo.png

top - 03:02:43 up 9 min,  2 users,  load average: 50.83, 30.14, 12.83
Tasks: 432 total,   1 running, 430 sleeping,   0 stopped,   1 zombie
Cpu(s):  0.1%us,  0.2%sy,  0.0%ni, 66.5%id, 33.1%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  32939992k total,  3111604k used, 29828388k free,    84108k buffers
Swap:  2048280k total,        0k used,  2048280k free,  1621640k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                          
 2860 root      20   0 25820 2288 1420 S    3  0.0   0:11.18 htop                                                                                             
 1182 root      20   0     0    0    0 D    2  0.0   0:01.46 kjournald                                                                                        
 1935 mysql     20   0 12.3g 161m 7924 S    1  0.5 102:31.45 mysqld                                                                                           
   11 root      20   0     0    0    0 S    0  0.0   0:00.38 kworker/0:1                                                                                      
 1822 www-data  20   0  247m  25m 4188 D    0  0.1   0:01.81 apache2                                                                                          
 2920 www-data  20   0     0    0    0 Z    0  0.0   0:01.20 apache2 <defunct>                                                                                
 2942 www-data  20   0  247m  23m 3056 D    0  0.1   0:00.20 apache2                                                                                          
 3516 www-data  20   0  247m  23m 3028 D    0  0.1   0:00.06 apache2                                                                                          
 3521 www-data  20   0  247m  23m 3020 D    0  0.1   0:00.09 apache2                                                                                          
 3664 www-data  20   0  247m  23m 3132 D    0  0.1   0:00.09 apache2                                                                                          
 3674 www-data  20   0  247m  23m 3252 D    0  0.1   0:00.06 apache2                                                                                          
 3713 www-data  20   0  247m  23m 3040 D    0  0.1   0:00.09 apache2                                                                                          
    1 root      20   0 24328 2284 1344 S    0  0.0   0:03.09 init                                                                                             
    2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd                                                                                         
    3 root      20   0     0    0    0 S    0  0.0   0:00.01 ksoftirqd/0                                                                                      
    6 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/0                                                                                      
    7 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/0                                                                                       
    8 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/1                                                                                      
    9 root      20   0     0    0    0 S    0  0.0   0:00.00 kworker/1:0


root@server:~/codes# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
19  0      0 29684012  86112 1689844    0    0    19   590  254  231 48  0 47  5
23  0      0 29704812  86128 1697672    0    0     4   320 11100 8121 77  1 22  0
33  0      0 29671044  86156 1705308    0    0     0  5440 13190 9140 95  1  4  0
33  3      0 29670088  86160 1706288    0    0     0 32932 12275 7297 99  0  1  0
35  0      0 29693456  86188 1710724    0    0     4   676 12701 7867 98  1  1  0
^C

Yo no he cambiado ninguna de las configuraciones por defecto que viene con Ubuntu. Es esta carga normal para tan potente servidor ? hay alguna optimización puedo hacer para Apache/MySQL, para minimizar la carga ? ¿Qué recomienda usted ?

EDIT: CARGA MEDIA en la 52!!!!!!! http://zertux.com/IMG_0117.PNG

*ACTUALIZACIÓN* Resulta que el DBA no agregar los índices de las tablas, después de la adición de los índices de la Carga promedio dramáticamente bajó de 93 a 1.2 :) Todo es super impresionante, gracias a todos por la ayuda!

6voto

Pablo Venturino Puntos 1660

Se ve bien para mí.

Tienes 12 núcleos.. a través de 2x 6-core Cpu. Así que al 100% de rendimiento, el promedio de carga debe ser de 12.

Promedio de carga es divertido. No creo que significa lo que creo que significa.

Promedio de carga es realmente una indicación de cómo muchos de los procesos que se están ejecutando en cualquier momento, con un promedio de más de 1, 5 y 15 minutos de windows.

A mí me parece que estás un poco sobrecargadas, pero no drásticamente.

Tal vez el uso de http://mysqltuner.pl/mysqltuner.pl para tener una idea de cómo su mysqld configuración de equiparar a la real, el uso de cantidades.

El siguiente paso lógico de curso es independiente de MySQL y Apache en diferentes cajas. No estoy seguro de que usted está en ese nivel, sin embargo, porque todavía tienes un pantload de RAM libre para MySQL a la que aspirar. Usted podría encontrar algún beneficio de realizar la consulta cachés y clave de búferes más grande, y, probablemente, tienen una mirada más profunda a MySQL lento registro de consultas, y ver si se puede optimizar las tablas .

Hay un montón de información acerca de cómo leer la carga de los promedios, y realmente es más sensible a dividir la carga promedio por el número de núcleos, por lo que tienes alguna idea de cómo se utiliza el servidor es en realidad.

Ahora puedo ver que tienes un 33% iowait. Sospecho.. que tienes una bastante escribir-pesado de la base de datos, y esto está causando tablas para bloquearse cuando estás escribiendo, lo que significa que concurrente escribe no puede suceder.

De haber tenido una aspiración a mi.cnf, parece que el max_connections es bastante alto, pero eso no es una gran preocupación, pero no significa que si usted está utilizando todos ellos, usted necesitará 27GB de RAM para permitir esto. Que es un montón, pero no una gran preocupación, de nuevo.

Considere la posibilidad de inflexión en PHP APC código de operación de almacenamiento en caché.

** Edit **

Después de haber visto a la consulta del registro de ahora, estoy inclinado a pensar que hay un par de cosas que podrían beneficiar el servidor.

  1. PHP APC código de operación de almacenamiento en caché (apache más eficiente en general)
  2. Convertir todas las tablas InnoDB a menos que tengas una muy buena razón. SI la razón de que es texto de búsqueda, encontrar una mejor manera de hacerlo, y mover a InnoDB.
  3. Comprar otro servidor, y hacer de él un dedicado DB host. Ajuste con discos SAS, y separarlos en particiones para que el registro y los datos están en distintos ejes (o más bien, matrices RAID).

Sin mucho más que mirar en qué diablos está pasando, es difícil decir.

Podría ser digno de una prueba de funcionamiento con NewRelic para PHP. Es gratis por un mes, y no tiende a dar buena penetración en el código de malo olores.

Alternativamente, estoy disponible para la consultoría ;)

2voto

Soham Chakraborty Puntos 2587

Hay un sorprendente punto de int a su salida superior y que es el número de procesos en D estado. Una buena parte de apache2 y aún kjournald es incluso en D estado. D el estado de los procesos son conocidos a increse carga de la CPU.

La mayoría de los casos, un proceso que va en D estado cuando se espera en IO. Después de conseguir el IO, que de nuevo viene a estado R o S del estado de D. La siguiente cosa que usted puede hacer para realizar la depuración live es comprobar cuánto tiempo estos D estado de los procesos se están ejecutando. Si durante bastante tiempo, un problema.

De todos modos, el problema, si es de alta carga promedio se encuentra en IOwait como 33.1% es el valor de iowait reportado por la parte superior. %usr y %sys no son mucho, por lo que podemos ignorar que los procesos van de mal en peor o CPU es de bajo rendimiento o hay un cuello de botella con la memoria. El problema es iowait, al parecer. Trabajo principalmente con RHEL, así que no estoy 100% seguro de ubuntu, y si cualquier incorporado herramientas están ahí.

Lo que hago principalmente es recoger, de varias iteraciones de la parte superior, vmstat durante algún tiempo, iostat por algún tiempo (con modificadores adecuados que muestran dispositivo de romper), una iteración de ps y ps-xv, y su comprobación. A menudo, el primer nivel de depuración se puede hacer a partir de esta cantidad. A continuación, puede recoger algunos de oprofile, perf salidas dependiendo de la versión de RHEL, pero eso es otra historia.

Independientemente, por favor marque todos los comandos de depuración al mismo tiempo para obtener la más finamente granular vista.

1voto

sandeep.s85 Puntos 669

He tenido este tipo de situación antes cuando, básicamente, en un mínimo de la carga del servidor de la página web parece estar respondiendo muy lento.

La parte superior no se espectáculo cualquier proceso que está consumiendo demasiado de ram o cpu. Pero el alarmante cosa era Servidor de Laod y el tiempo de espera de la cpu. Como en su caso, del 33%.

En mi caso el problema resultó ser en el Servidor de la Compañía de Hosting. Su SAN ha estado actuando muy lento durante semanas antes de que finalmente decidió cambiar su almacenamiento. Sólo después de mi servidor empezó a funcionar bien.

El mío fue un VPS no es un servidor dedicado.

0voto

Gerard Puntos 2340

Yo tuve un problema similar con la versión de escritorio de Ubuntu 12.04 (que estaba siendo utilizado como un servidor (no es mi elección)) .

Si usted tiene instalado un gestor de escritorio en su caja, usted puede encontrar que el vsync es el problema.

La unidad de dm que me estaba causando un permanentemente elevado de la CPU de la carga de conmutación vsync off al instante fijo de este. No sé si otros de dm son la causa de este problema también.

0voto

Naai Sekar Puntos 389

Sospecho que el proceso tal vez esperando en IO que tal vez causando la carga media a alta. Después de toda la carga promedio se basa en la cola de procesos ejecutables para la cpu. ¿Ve usted alguna alto valor en el comando iostat ?

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: