Problemas de Servidor o Problemas de Programación?

Hola, actualmente estoy teniendo problemas de carga con mi servidor actual y los administradores se limitan ha decirme que hay una sobrecarga en el servidor.No me dicen qué esta haciendo esa sobrecarga y porqué puede estar ocasionada.

Lo que me choca es que las visitas de las páginas webs no han experimentado un crecimiento como para que de golpe el servidor empiece a estar sobrecargado, pues semanas anteriores no lo estaba. Incluso en las horas más bajas de tráfico.

Mi pregunta es, cómo puedo saber si mi problema es de programación o del servidor?? Los del servidor le echan la culpa a la programación siempre de forma sistemática. Después tras insitir dicen que han hecho cambios en el servidor para optimizarlo y empieza a ir mejor...

Uso cpanel y whm. No tengo acceso al servidor, simplemente a estas dos herramientas. Al whm como root en este caso. ¿Dónde debo mirar? En los procesos de MYSQL me salen 3-4 procesos nada mas. Con solamente 3-4 procesos puede esta cargando el servidor tanto para relentizarlo?

El server load es del 22.10 (14 CPUs) incluso llega a picos de 55

Tampoco comprendo que mi servidor tenga 14 CPUS????

Las webs con más cargas son de 400 visitas al DIA y no tengo más de 3 en este servidor.

La maquina que tengo contratada es:

Dell R300 - CPU: Intel Xeon L5410 Harpertown 2.33Ghz Quad Core
RAM: 2GB
Discos:250GB SATAII (7.2k rpm)+250GB SATAII (7.2k rpm)
SATA - Raid 1 (requiere 2 discos duros)
SO: CentOS 4.x 64bit
Puerto: 10Mbit
Tarjetas de Red: 1 (1 pública)


Esto me está empezando a volver loco...

 

tienes que tener algun sitio que esta consumiendo muchos recursos usas cpanel ?

 

Has probado con el comando top en consola o con ps -aux? Tampoco te recomiendo un OS de 64 bits en 2GB de RAM. Máximo a partir de 4GB.

 

Si, si te fijas ha dicho que usa cPanel/WHM.

 

Que te parece si propones algo para ayudar antes de corregir se un poco mas inteligente

Primer paso hay que buscar que esta ocasionado el problema

Por ssh realize el comado top -c

o

Ingresa por whm System Health-Process Manager

y copia los resultados

 

Hola, no tengo acceso a consola. Si a WHM como root. Ahora el servidor está calmado. Por lo que el Process Manager creo que no podrá aportarnos mucho pero lo pego:

0246 (Trace) (Kill) mysql 0 19.7 2.8 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/empresahosting.com.pid --skip-external-locking --socket=/var/lib/mysql/mysql.sock
29685 (Trace) (Kill) root 0 4.0 1.8 whostmgr2 - top ./top
14401 (Trace) (Kill) root 0 0.4 3.1 spamd child
3086 (Trace) (Kill) root 0 0.4 0.0 [kjournald]
28937 (Trace) (Kill) root 0 0.3 0.0 [pdflush]
28637 (Trace) (Kill) root 0 0.2 0.0 [pdflush]
6383 (Trace) (Kill) root 0 0.1 6.1 /usr/sbin/clamd
21459 (Trace) (Kill) root 0 0.1 0.9 /usr/local/apache/bin/httpd -DSSL
29637 (Trace) (Kill) nobody 0 0.1 0.0 [httpd] <defunct>
29641 (Trace) (Kill) nobody 0 0.1 0.0 [httpd] <defunct>
26422 (Trace) (Kill) root 0 0.0 2.3 spamd child
6412 (Trace) (Kill) root 0 0.0 2.0 /usr/bin/spamd -d --allowed-ips=127.0.0.1 --pidfile=/var/run/spamd.pid --max-children=5
29648 (Trace) (Kill) nobody 0 0.0 0.8 /usr/local/apache/bin/httpd -DSSL
29528 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29532 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29647 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29649 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29668 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29669 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29670 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29671 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29672 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29673 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29674 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29677 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29678 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29679 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29680 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29681 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29682 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29683 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
29684 (Trace) (Kill) nobody 0 0.0 0.6 /usr/local/apache/bin/httpd -DSSL
28891 (Trace) (Kill) root 0 0.0 0.4 whostmgrd - serving 80.xx.xx.xx
28901 (Trace) (Kill) root 0 0.0 0.4 whostmgrd - serving 80.xx.xx.xx
28945 (Trace) (Kill) root 0 0.0 0.4 whostmgrd - serving 80.xx.xx.xx
28946 (Trace) (Kill) root 0 0.0 0.4 whostmgrd - serving 80.xx.xx.xx
28948 (Trace) (Kill) root 0 0.0 0.4 whostmgrd - serving 80.xx.xx.xx
7112 (Trace) (Kill) named 0 0.0 0.3 /usr/sbin/named -u named
29593 (Trace) (Kill) 32006 0 0.0 0.3 webmaild - serving 88.20.xx.xx
29654 (Trace) (Kill) 32006 0 0.0 0.3 webmaild - serving 87.217.xxx.xxx
29657 (Trace) (Kill) 32006 0 0.0 0.3 webmaild - serving 87.217xxx.xxx
29658 (Trace) (Kill) 32006 0 0.0 0.3 webmaild - serving 87.217.xxx.xxx
29659 (Trace) (Kill) 32006 0 0.0 0.3 webmaild - serving 87.217.xxx.xxx
29660 (Trace) (Kill) 32006 0 0.0 0.3 webmaild - serving 87.217.xxx.xxx
29663 (Trace) (Kill) 32006 0 0.0 0.3 webmaild - serving 87.217.xxx.xxx
32111 (Trace) (Kill) root 0 0.0 0.3 /usr/bin/perl /usr/local/cpanel/bin/leechprotect
6913 (Trace) (Kill) root 0 0.0 0.2 tailwatchd
6971 (Trace) (Kill) root 0 0.0 0.2 cpsrvd - waiting for connections
7032 (Trace) (Kill) mailman 6 0.0 0.2 /usr/local/bin/python2.4 /usr/local/cpanel/3rdparty/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s
7035 (Trace) (Kill) mailman 6 0.0 0.2 /usr/local/bin/python2.4 /usr/local/cpanel/3rdparty/mailman/bin/qrunner --runner=OutgoingRunner:0:1 -s
7036 (Trace) (Kill) mailman 6 0.0 0.2 /usr/local/bin/python2.4 /usr/local/cpanel/3rdparty/mailman/bin/qrunner --runner=VirginRunner:0:1 -s
19006 (Trace) (Kill) root 0 0.0 0.1 /etc/authlib/authProg
19881 (Trace) (Kill) root 0 0.0 0.1 /etc/authlib/authProg
20151 (Trace) (Kill) root 0 0.0 0.1 /etc/authlib/authProg
24945 (Trace) (Kill) root 0 0.0 0.1 /etc/authlib/authProg
25734 (Trace) (Kill) root 0 0.0 0.1 /usr/sbin/snmpd -Lsd -Lf /dev/null -p /var/run/snmpd.pid -a
26047 (Trace) (Kill) root 0 0.0 0.1 /etc/authlib/authProg
1 (Trace) (Kill) root 0 0.0 0.0 init [3]
2 (Trace) (Kill) root - 0.0 0.0 [migration/0]
3 (Trace) (Kill) root 19 0.0 0.0 [ksoftirqd/0]
4 (Trace) (Kill) root - 0.0 0.0 [migration/1]
5 (Trace) (Kill) root 19 0.0 0.0 [ksoftirqd/1]
6 (Trace) (Kill) root - 0.0 0.0 [migration/2]
7 (Trace) (Kill) root 19 0.0 0.0 [ksoftirqd/2]
8 (Trace) (Kill) root - 0.0 0.0 [migration/3]
9 (Trace) (Kill) root 19 0.0 0.0 [ksoftirqd/3]
10 (Trace) (Kill) root -10 0.0 0.0 [events/0]
11 (Trace) (Kill) root -10 0.0 0.0 [events/1]
12 (Trace) (Kill) root -10 0.0 0.0 [events/2]
13 (Trace) (Kill) root -10 0.0 0.0 [events/3]
14 (Trace) (Kill) root -10 0.0 0.0 [khelper]
15 (Trace) (Kill) root -10 0.0 0.0 [kthread]
16 (Trace) (Kill) root -10 0.0 0.0 [kacpid]
57 (Trace) (Kill) root -10 0.0 0.0 [kblockd/0]
58 (Trace) (Kill) root -10 0.0 0.0 [kblockd/1]
59 (Trace) (Kill) root -10 0.0 0.0 [kblockd/2]
60 (Trace) (Kill) root -10 0.0 0.0 [kblockd/3]
61 (Trace) (Kill) root 0 0.0 0.0 [khubd]
98 (Trace) (Kill) root 0 0.0 0.0 [kswapd0]
99 (Trace) (Kill) root -10 0.0 0.0 [aio/0]
100 (Trace) (Kill) root -10 0.0 0.0 [aio/1]
101 (Trace) (Kill) root -10 0.0 0.0 [aio/2]
102 (Trace) (Kill) root -10 0.0 0.0 [aio/3]
246 (Trace) (Kill) root 0 0.0 0.0 [kseriod]
494 (Trace) (Kill) root 0 0.0 0.0 [scsi_eh_0]
495 (Trace) (Kill) root -10 0.0 0.0 [HotP_wq0]
517 (Trace) (Kill) root -10 0.0 0.0 [ata/0]
518 (Trace) (Kill) root -10 0.0 0.0 [ata/1]
519 (Trace) (Kill) root -10 0.0 0.0 [ata/2]
520 (Trace) (Kill) root -10 0.0 0.0 [ata/3]
521 (Trace) (Kill) root -10 0.0 0.0 [ata_aux]
527 (Trace) (Kill) root 0 0.0 0.0 [scsi_eh_1]
528 (Trace) (Kill) root 0 0.0 0.0 [scsi_eh_2]
533 (Trace) (Kill) root 0 0.0 0.0 [scsi_eh_3]
534 (Trace) (Kill) root 0 0.0 0.0 [scsi_eh_4]
548 (Trace) (Kill) root 0 0.0 0.0 [kjournald]
1200 (Trace) (Kill) root -10 0.0 0.0 [kauditd]
1502 (Trace) (Kill) root 0 0.0 0.0 udevd
3085 (Trace) (Kill) root 0 0.0 0.0 [kjournald]
3402 (Trace) (Kill) root -10 0.0 0.0 [ib_mcast]
3403 (Trace) (Kill) root -10 0.0 0.0 [ib_inform]
3404 (Trace) (Kill) root -10 0.0 0.0 [local_sa]
3409 (Trace) (Kill) root -10 0.0 0.0 [ib_cm/0]
3410 (Trace) (Kill) root -10 0.0 0.0 [ib_cm/1]
3411 (Trace) (Kill) root -10 0.0 0.0 [ib_cm/2]
3412 (Trace) (Kill) root -10 0.0 0.0 [ib_cm/3]
3440 (Trace) (Kill) root -10 0.0 0.0 [ib_addr]
3448 (Trace) (Kill) root -10 0.0 0.0 [iw_cm_wq]
3458 (Trace) (Kill) root -10 0.0 0.0 [rdma_cm]
3526 (Trace) (Kill) root -10 0.0 0.0 [ipoib]
3534 (Trace) (Kill) root -10 0.0 0.0 [sdp]
4245 (Trace) (Kill) root 0 0.0 0.0 syslogd -m 0
4249 (Trace) (Kill) root 0 0.0 0.0 klogd -x
4262 (Trace) (Kill) root 0 0.0 0.0 irqbalance
4279 (Trace) (Kill) root 0 0.0 0.0 /usr/sbin/courierlogger -pid=/var/spool/authdaemon/pid -facility=mail -start /usr/libexec/courier-authlib/authdaemond
4280 (Trace) (Kill) root 0 0.0 0.0 /usr/libexec/courier-authlib/authdaemond
4310 (Trace) (Kill) root 0 0.0 0.0 /usr/libexec/courier-authlib/authdaemond
4311 (Trace) (Kill) root 0 0.0 0.0 /usr/libexec/courier-authlib/authdaemond
4312 (Trace) (Kill) root 0 0.0 0.0 /usr/libexec/courier-authlib/authdaemond
4313 (Trace) (Kill) root 0 0.0 0.0 /usr/libexec/courier-authlib/authdaemond
4314 (Trace) (Kill) root 0 0.0 0.0 /usr/libexec/courier-authlib/authdaemond
4315 (Trace) (Kill) root 0 0.0 0.0 rpc.idmapd
4403 (Trace) (Kill) root 0 0.0 0.0 /usr/sbin/acpid
5520 (Trace) (Kill) root 0 0.0 0.0 /usr/lib/courier-imap/bin/couriertls -server -tcpd /usr/lib/courier-imap/sbin/imaplogin /usr/lib/courier-imap/bin/imapd Maildir
5528 (Trace) (Kill) biotec 6 0.0 0.0 /usr/lib/courier-imap/bin/imapd /home/biotec/mail/dominio1.com/arodri
6192 (Trace) (Kill) root 0 0.0 0.0 /usr/sbin/sshd
6205 (Trace) (Kill) root 0 0.0 0.0 xinetd -stayalive -pidfile /var/run/xinetd.pid
6274 (Trace) (Kill) root 0 0.0 0.0 /usr/sbin/courierlogger -pid=/var/run/imapd.pid -start -name=imapd /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=50 -maxperip=30 -nodnslookup -noidentlookup 143 /usr/lib/courier-imap/sbin/imaplogin /usr/lib/courier-imap/bin/imapd Maildir
6275 (Trace) (Kill) root 0 0.0 0.0 /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=50 -maxperip=30 -nodnslookup -noidentlookup 143 /usr/lib/courier-imap/sbin/imaplogin /usr/lib/courier-imap/bin/imapd Maildir
6280 (Trace) (Kill) root 0 0.0 0.0 /usr/lib/courier-imap/bin/couriertls -server -tcpd /usr/lib/courier-imap/sbin/imaplogin /usr/lib/courier-imap/bin/imapd Maildir
6281 (Trace) (Kill) root 0 0.0 0.0 /usr/sbin/courierlogger -pid=/var/run/imapd-ssl.pid -start -name=imapd-ssl /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=50 -maxperip=30 -nodnslookup -noidentlookup 993 /usr/lib/courier-imap/bin/couriertls -server -tcpd /usr/lib/courier-imap/sbin/imaplogin /usr/lib/courier-imap/bin/imapd Maildir
6282 (Trace) (Kill) root 0 0.0 0.0 /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=50 -maxperip=30 -nodnslookup -noidentlookup 993 /usr/lib/courier-imap/bin/couriertls -server -tcpd /usr/lib/courier-imap/sbin/imaplogin /usr/lib/courier-imap/bin/imapd Maildir

Toque un indice ayer de una tabla (una de las webs que tienen 90 visitas al dia) y parece que ayudo algo.

Cuando esté nuevamente en 30, 34, 37 de carga vuelvo a pegar el process manager.

 

Con la ram que tiene ahora, aveces da unos pico de usarla toda pero por lo general solo usa un 70% aproximadamente.

 

hace esto yum update y yum upgrade luego si estas usando algún cms actualiza a la ultima versión

 

Sin tener acceso a la consola se te puede complicar un poco pero bueno si solo tienes acceso al WHM ( espero no sea un reseller por que nada podras hacer en ese caso ) puedes ir a la configuraciòn de apache y hacer un poco de tunning alli, veo tienes varios procesos HTTP Server ( la cantidad puedes configurarla en el httpd.conf del servicio )

Prueba algo de eso y me dices que tal te va.

Recuerda que puedes limitar la cantidad de memoria que consume tu apache y cuantos recursos de CPU.. eso ayuda mucho cuando no tienes muchos recursos.

Consejo : Juega un poco con el TimeAlive de cada conexiòn, si bien sacrificas un poco de CPU la memoria utilizada se puede optimizar de mejor forma.

consejo2 : podrìas utilizar un cache para tu apache ( o pide utilizar algun proxy reverso que haga uso del cache hacia tu apache ) el cual va a reducir considerablemente el uso de memoria y CPU.

Saludos

 

Os informo. Hemos actualizado los indices y suerpvisado las tablas. Por ahora la carga del servidor va bien. Aunque la MYSQL consume gran parte de los recursos. Estoy a la espera de que empice a ir lento para postear mas información.

 

Axo primero de todo le deberías pedir a tu proveedor una captura del comando top para ver que es lo que está consumiendo recursos antes de ponerte a tocar valores o configuraciones por WHM.

Si es problema de la optimización de MySQL y Apache con MySQL Tuner puedes reducir la carga de MySQL considerablemente. Se trata de un script en perl que puedes encontrar en http://mysqltuner.pl/mysqltuner.pl

Si el servidor es manejado contactaria con tu proveedor.

 

Hola. El servidor es manejado. "no puedo tocar nada". Antes de ponerme con mysql y apache intento optimizar al máximo las programaciones.

respecto alo que me pasas f.villalba, ¿con darle esa url ya sabe ellos que tienen que hacer? con ese script se encargará de la optimización ?

 

Axo entonces si es manejado ellos deberían de encargarse al completo. Pide que te realicen una optimización al Apache y MySQL. Ellos sabrán como hacerlo seguro. No les tienes por que decir nada.

 

No sé hasta qué punto se le puede exigir al proveedor de hosting.
Una cosa es que el proveedor se encargue del mantenimiento, las herramientas, las actualizaciones y demás, y otra cosa es que optimicen el funcionamiento y rendimiento de tu aplicación, como parece necesario en este caso.

Lo que sí es cierto es que deberían hacer al menos un par de pruebas, algo tan simple como un top o un slow_query_log podría ser de gran ayuda.

Mientras esperas, ya estás tardando en instalar el "Munin Server Monitor addon module" en WHM y en menos de 24 horas al menos sabrás de dónde viene el exceso de consumo.

 

Aclaro, el primer paso normalmente que dan es la notificación de que el servidor está cargado (sin decirte dónde o porque). Ya cuando le preguntamos porqué nos dan las alternativas de slow query y a posterior al insistirle nos dicen que han optimizado el apache. Pero siempre le echan la culpa a la programación y a que ampliemos recursos.... no me entra en la cabeza si se ha tirado casi un año con las mismas visitas el servidor, que ahora de golpe y porrazo vaya mal... por eso creo que no es cuestión de programación, sino de optimización.

egrueda. Si pago por un servicio, tienes que indicarme dónde está el problema si procede de mi parte para poder solventarlo yo. En ningún momento hemos hablado de que ellos entren en mi código ni similar. Pero sique nos faciliten averiguar el problema. si gestionas 100 webs es complicado revisar todas una a una.



como no se ven bien, os pongo los procesos que consumen mas recursos. Ahora la maquina está con cargas de * Load Averages: 42.69 39.30 33.46

29164 (Trace) (Kill) nobody 6 61.5 0.8 /usr/local/apache/bin/httpd -DSSL
29119 (Trace) (Kill) nobody 6 60.4 0.8 /usr/local/apache/bin/httpd -DSSL
2912 (Trace) (Kill) nobody 0 42.8 0.8 /usr/local/apache/bin/httpd -DSSL
2748 (Trace) (Kill) nobody 0 40.4 0.8 /usr/local/apache/bin/httpd -DSSL
31818 (Trace) (Kill) nobody 6 39.7 0.8 /usr/local/apache/bin/httpd -DSSL
31832 (Trace) (Kill) nobody 6 39.2 0.8 /usr/local/apache/bin/httpd -DSSL
301 (Trace) (Kill) nobody 6 37.6 0.8 /usr/local/apache/bin/httpd -DSSL
32557 (Trace) (Kill) nobody 6 37.3 0.8 /usr/local/apache/bin/httpd -DSSL
343 (Trace) (Kill) nobody 6 36.8 0.8 /usr/local/apache/bin/httpd -DSSL
3514 (Trace) (Kill) nobody 0 34.1 0.8 /usr/local/apache/bin/httpd -DSSL
20246 (Trace) (Kill) mysql 6 19.2 3.7 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/162.hostxtremdns.com.pid --skip-external-locking --socket=/var/lib/mysql/mysql.sock
4088 (Trace) (Kill) root 0 6.0 1.8 whostmgr2 - top ./top
1411 (Trace) (Kill) root 0 0.7 2.3 spamd child
3086 (Trace) (Kill) root 0 0.4 0.0 [kjournald]
2367 (Trace) (Kill) root 0 0.2 2.2 spamd child
21459 (Trace) (Kill) root 0 0.2 0.9 /usr/local/apache/bin/httpd -DSSL
6383 (Trace) (Kill) root 0 0.1 2.0 /usr/sbin/clamd
4077 (Trace) (Kill) nobody 0 0.1 0.8 /usr/local/apache/bin/httpd -DSSL
3942 (Trace) (Kill) root 0 0.1 0.0 [pdflush]
4005 (Trace) (Kill) root 0 0.1 0.0 [pdflush]
4028 (Trace) (Kill) prinsa 0 0.1 0.0 /usr/lib/courier-imap/bin/pop3d /home/prinsa/mail/grupoprinsa.com/administracion
3816 (Trace) (Kill) nobody 0 0.0 0.8 /usr/local/apache/bin/httpd -DSSL
4048 (Trace) (Kill) nobody 0 0.0 0.8 /usr/local/apache/bin/httpd -DSSL

 

Wow! peazo de apache! xD
Pero es bueno, viendo que el servidor web se come tantos procesos podemos usar el server-status de apache para que nos diga, en tiempo real, las peticiones, los dominios y la carga puntual. Con eso reducirás mucho las posibilidades y acotarás la causa.

Con mod_status verás algo como esto (baja hasta la tabla de procesos):
http://www.apache.org/server-status

 

Apache server status for empresahosting.com
Server Version: Apache
Server Built: Feb 15 2011 11:39:48
Current Time: Tuesday, 03-May-2011 17:44:49 CEST
Restart Time: Tuesday, 03-May-2011 17:37:43 CEST
Parent Server Generation: 0
Server uptime: 7 minutes 6 seconds
Total accesses: 2769 - Total Traffic: 17.4 MB
CPU Usage: u.13 s.01 cu0 cs0 - .0329% CPU load
6.5 requests/sec - 41.9 kB/second - 6.4 kB/request
68 requests currently being processed, 31 idle servers

 

Habilita el ExtendedStatus para que te muestre el listado de procesos:
http://httpd.apache.org/docs/current/mod/mod_status.html#extendedstatus

 

Vale, creo que he dado con el error !!

Creo que se debe a que tenemos un banner.gif enlazado desde otras páginas que tienen un tráfico altísimo y están haciendo continuamente peticiones desde sus webs a nuestro dominio para mostrar ese banner. ¿esto puede ocosionar esta lentitud?