Por @Alvy — 28 de Julio de 2005

Esto es una consulta que lanzamos a otros webmasters que puedan estar en una situación similar, porque ya nos estamos volviendo locos.

Ayer tuvimos un rato de inestabilidad en el servidor web de Microsiervos hacia las 22.00-23.30 hora de Madrid. El síntoma era que las páginas se servían muy lentas. Recientemente ampliamos nuestro alojamiento a uno más potente. Que esto suceda esto nos parece un poco extraño, porque ya ampliamos el espacio en disco, la transferencia, incluso la RAM. De hecho en ese servidor tenemos otros webs alojados y todos van muy bien, pero cuando aparece el problema casi todas se quedan como atontadas. Este problema no coincide con que estemos enlazados sufriendo un efecto barrapunto (o «efecto yonkis» o «efecto escolar» ;-) desde ningún lado. El número de peticiones es el normal de muchos días. Incluso ha habido días con más peticiones y sin problemas. La carga de CPU tambíen parece normal: 0,08 a 0,20. Aun así algo extraño sucede. El síntoma es que el servidor Apache se vuelve más lento que una tortuga: no se muere del todo pero algunas peticiones tardan 10, 30 y hasta 60 segundos en servirse. En cambio el FTP, correo y otros servicios funcionan. Debido a esa lentitud el Apache a veces da algunos errores 408, que son timeouts HTTP. Es como si hubiera muchas peticiones a la vez y entraran en cola y tardaran más de lo normal, que debería ser una fracción de segundo o unos pocos segundos. Además, todo nuestro site es completamente estático: HTML y JPEGs, lo cual que tuviera algo que ver con la base de datos. (Todo esto ha sucedido alguna otra vez antes de tener el Wiki, así que hemos descartado que sea debido a eso. Y no hemos hecho muchos más cambios últimamente.)

Después de darle muchas vueltas hemos pensado que podría ser un robot haciendo peticiones de páginas ciertos días a ciertas horas, o alguna persona usando algún software de esos que «chupan» toda una web entera. Si cuando pasa esto reciniciamos el Apache, todo vuelve a funcionar. Pero al cabo de un rato se vuelve lento de nuevo, poco a poco. Hemos mirado en los logs del servidor y aparecen algunos user-agent extraños, como FunWebProducts que es una especie de plug-in para Explorer (parece spyware pero seguramente no lo sea) y .NET CLR 1.1.4322 que no sabemos lo que es pero tampoco parece ser el causante. Aparece el Googlebot, aparece Slurp que es la araña de Yahoo, pero no hacen demasiadas peticiones a la vez y además leen el robots.txt y lo respetan (de todos modos hemos ampliado ese archivo con muchos más bots, tomados de la Wikipedia). En fin, no hemos encontrado por desgracia muchas peticiones desde la misma IP lo cual podría indicar que había un robot araña o alguna persona concreta fastidiando. También hemos pensado en un ataque de algún tipo pero lo hemos descartado porque en los logs no se ve nada raro.

De momento todo vuelve a funcionar normalmente, el caso es que tras algunas horas de inestabilidad y lentitud todo termina y vuelve a funcionar 100% normal.

En fin, este es el expediente X que tenemos. Si a alguien que sepa sobre el tema se le ocurre algo, que comente, se lo agradeceremos mucho.

Compartir en Flipboard  Compartir en Facebook  Tuitear

59 comentarios

#1 — Abanico

Mmmm... no soy un superexperto en este tema, pero la verdad es que es raro de narices. ¿Has hablado con MT para ver si es algo de hardware? ¿Todas las webs que cuelgan de ese servidor son totalmente estáticas? (lo digo por descartar totalmente un problema de sobrecarga causada por algún script). Por cierto, que me di cuenta que efectivamente no se podía entrar a MS, pero a mi no es que me tardara 60 segundos, es que despues de un rato me daba error.

Los dos servidores de nuestra oficina han sufrido en lo que va de mes dos ataques "DOS" que los han dejado fritos, en plan que no servía absolutamente páginas web, ni peticiones DNS ni nada de nada. Bueno, es más, el sistema sacaba un mensaje como que no quedaban más sockets libres y ahí se quedaba. El lunes aprobamos la compra de un firewall de 3Com de estos portentosos para ver si conseguimos evitarlos.

Ya se sabe, con el veranito y el calor, los scripts kiddies y los lamers en general proliferan tanto como la salmonella en las ensaladillas.

#2 — Alvy

Sí, todas son más estáticas que la pata de palo del pirata Hook, aunque hay algunas zonas que lógicamente tiran de base datos por ejemplo al publicar en Movable Type, o el Wiki etc. pero digamos que sabiendo que nada de eso se está usando en un momento dado (ej. ayer) el problema aparece igual. Además lo raro es que si hubiera sobrecarga por otro lado (scripts, base de datos, etc), reiniciar el apache de Microsiervos no serviría de nada, en cambio reiniciándolo funciona bien durante unos minutos hasta que vuelve al modo "lento" (la sensación es que va bien hasta que empiezan a entrar peticiones que se encolan porque por alguna razón tardan mucho en servirse. Pero esas peticiones son de ficheros estáticos .html .jpg .gif etc). Más o menos sucede que si para una petición (ej. cualquier .html) el tiempo es de más de 120 segundos o 180 segundos creo que es cuando da el error timeout (HTTP 408). Lo del DOS/DNS no creo que sea por lo mismo de antes: reiniciando el Aache se arregla y va bien durante un rato.

#3 — Alvy

Ah: También hay peticiones a CGIs y base de datos cuando se postean comentarios, claro. Pero según los logs esas parece que se resuelven OK y rápido sin problemas.

#4 — Alvy

(+) También estamos mirando a ver si pudieran ser spammers de comentarios y trackbacks que envían muchas peticiones a través de formularios a nuestro Movable Type. Esas peticiones son detenidas sin problemas por el MT Blacklist y por eso no se ven, pero requieren esfuerzo para procesarlas, consultas a la BD, etc. Como utilizan IPs distintas cada vez pueden ser más difíciles de identificar, pero aparecerían "intentando comentar" supongo.

#5 — Yogui

Yo tuve un problema parecido en un cliente con un proxy inverso de apache, que no se si se podría aplicar en vuestro caso. El caso es que lo que nos pasaba es que habia muchas conexiones que no se finalizaban correctamente y ocupaban threads del apache, los cuales iban aumentando hasta que alcanzaban el limite parametrizado en apache, momento en el que todo empezaba a ir muuuccchoooo mas lento. La solución pasó por aumentar estos parametros y cerrar las conexiones muertas mediante un firewall.

#6 — lightme

Se muy poco de apaxhe y robots, mas bien mi topico es C y C++, pero a mi web aveces entrans bots que hacen en una hora una revisiòn de mas de 700 pagins de mi blog, asi te imaginaras que segun mis logs, el trafico se dispara por este robot.

generalmente se ponen a indexar comtenido, aunque hay algunos que parecerian querer averiguar mas decididamente los correos de los comentaristas del blos, ya que van directamente al contatco con el usuario, cabe decir que no tienen acceso a esa infromaciòn, no a su mail, pero es fastidioso que un solo bot haga unas 400 revisiones de profiles de los comentaristas.

En fin no se aporte algo, pero igual pdoria ser un bot de esos.

#7 — Esteban

Alvy, yo algunas veces (al entrar a microsiervos) he tenido problemas que no me resuelve el nombre (DNS) y por lo tanto no puedo entrar, sé que no tiene nada que ver, pero...

Yo tengo mi blog también en MT y, salvando la (gran) diferencia de número de visitas/páginas vistas, etc. no he tenido ni un solo problema. Todo va perfecto.

No sé, se me ocurre algo de algún plugin de MT, en definitiva algo temporal, que no ocurre siempre, sino cuando algo o alguien lo provoca bajo unas condiciones determinadas.

¿Sabéis cuando y durante cuanto pasa? (por las noches, por el día, 1 hora, etc.) También hay que pensar en la diferencia horaria con los servidores de MT. No sé quizás ellos lanzan algún proceso tipo backup que deja a la máquina frita ese tiempo... aunque por otro lado si dices que haciendo un reboot de Apache todo se soluciona, es raro.

Yo también haría un repaso minucioso del httpd.conf del servidor Apache por si hay algo.

Otra cosa es que la gente de MediaTemple os pueda dar algo de información sobre consumo de ancho de banda, picos, etc.

#8 — alex

Como bien dices parece que es un problema de gente que ripea webs.

.NET CLR no es más que un indicativo de que el usuario tiene instalado el .NET Framework de Microsoft.

Fíjate si ves alguna petición con un user agent parecido a este:

Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)

DigExt es una extensión de IE 5.0 para navegar offline que utiliza un método de ripear muy "abrasivo" para el servidor HTTP. Suele causar problemas, incluso Microsoft ha admitido que es un error.

Lo mejor que puedes hacer es analizar los logs y hacerte una aplicación que sea capaz de encontrar los picos. Por ejemplo, una aplicación que mida el número de peticiones en cada minuto.

#9 — Scila

asi, por dar palos de ciego, lo primero que me ha venido a la cabeza es la aplicación esa de ¡Salta! que no se como funcionará pero lo mismo coincide que cuando pida una determinada página erronea se espicha todo...

#10 — Alvy

#5  Pues si es eso a ver cómo se arregla (?!)

#6  Hemos aumentado nuestra lista de robots.txt para eliminar más.

#7  Lo del DNS no creo que sea porque no se ha tocado nada y siempre ha ido bien. De ser de plubins sería el Blacklist y el tema de los spammers de comentarios. Eso lo estamos mirando más a fondo ahora. Cuando sucede suele ser durate 30-60-90 minutos máximo, ayer entre 22.00 y 23.30 más o menos (GMT+2), algún otro día ha sucedido por las noches, pero tampoco tenemos una pauta ni muchas ocasiones en las que haya sucedido. Lo del backup tampoco puede ser porque aunque haya eso reinciando Apache se arregla.

#8 sí, lo del .NET CLR parece que no tiene nada que ver. Peticiones de DigExt sí que aparecen unas cuentas, ej: 62.15.116.xxx [27/Jul/2005:13:54:53 -0700] "GET /archivo/gadgets/impresionante-teclado.html HTTP/1.1" 200 133298 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; DigExt; SV1)". Tal vez hay unas 1.500 al día con "DigExt" (incluyendo html/jpg/gif/etc).

#11 — David

Varias cosas...

Algo muy practico en momentos de crisis como el comentado puede ser el modulo de Apache server-status, que te muestra en tiempo real, qué y para quién esta actuando cada proceso hijo, cuanta cpu se esta comiendo, etc... Mucho mas practico que analizar logs a posteriori (piensa que hay procesos de apache que si se les va la pinza, no escriben siquiera en el log antes de morir).

Por lo que cuentas (yo he tenido varias de esas) puede ser debido a un "memory leak" del propio apache bajo determinadas circustancias (normalmente peticiones raras de robtos, o ataques DOS hechos a posta). Eso explicaria que el problema se solucione al rearrancar el servidor Apache.

Ya diras...

#12 — Alvy

#9  El salta no parece que sea: lleva meses puesta y sin problemas, no la hemos cambiado recientemente, y hemos comprobado que no da errores de ningún tipo. (Es un PHP bastante sencillo, ni siquiera llama a la base de datos). Además sólo tiene 150 peticiones al día y según los logs son normales. Y no tuvo peticiones durante las horas del problema ayer.

#13 — Anonymous

Hola. Quizá os sirva saber que con frecuencia vuestra página no se carga en conexiones "Lentas" (poor ejemplo, un ADSL con el emule a tope). Mientras otras páginas terminan por cargar, microsiervos se queda en blanco y se interrumpe.

La lentitud en apache suele venir por procesos asociados, muy a menudo por scripts que esperan a recibir resultados de un tercero. Típicamente es un asunto de conexiones a base de datos. He visto los experimentos de Alvy con PHP, y si no recuerdo mal me dio la impresión de que eran lentos y pesados (no te ofendas, por favor), pero es una lectura a ojo del código fuente. Quizá debáis aumentar la memoria asignada a PHP (por defecto viene muy bajita). Si usáis MT, las reconstrucciones (rebuild) y las referencias cruzadas llevan su tiempo. Por ejemplo, los servicios nuevos que estáis poniendo son cañeros en coste de base de datos: entradas relacionadas, comentarios relacionados, etcétera. Cada vez que alguien mete un comentario, tenéis una reconstrucción bastante amplia: en el índice, el archivo, la página de la entrada y la página de últimos comentarios, etc, que implica una serie de densas consultas a la base de datos. Por no hablar de que blacklist come lo suyo, y con vuestra popularidad... Si sospecháis de mt-blacklist, deja registros en el propio log de MT que se pueden consultar y podéis localizar los intentos de spam. (el log se consulta en la entrada de la administración de MT).

Por último, sospechad de servicios de terceros: contadores, estadísticas, etc. No os muráis de éxito ni ambición. pello.info tiene un artículo dedicado a tunear MySQL. Puede veniros bien echar un vistazo.

#14 — victor

yo de esto se mas bien poco, pero en cierta ocacion, cuando curraba para dorna, hicimos una aplicación, q el dia q la inauguramos, tiro el servidor, con todas las páginas q estaban alojadas allí (y q nada tenian q ver con nosotros), desde entonces, dorna tuvo (supongo q aun tiene) servidores dedicados. ¿Tu compartes servidor? ¿no puede haber páginas de otras pesonas, q en sus horas punta esten jodiendo el servidor?, para averiguar eso tendrias q hablar con quien te provee el host.

#15 — Alvy

Mmmm gracias #13 revisaremos todo eso. Por ejemplo lo de la memoria del PHP ya lo detectamos al instalar el Wiki. Pero aparte de ahí que no tiene un uso excesivo (y antes no existía y este problema apareció alguna vez) no se usa apenas PHP en estos servidores. Los experimentos son minimos y llevan meses funcionando: salta, enviar a un amigo, etc. no creemos que realmente sea por eso así "de repente" digamos. Nos da la impresión, que puede ir mas en la linea de los comentarios o los plugins, spam, Blacklist, etc. y reconstrucciones, pero hace poco tampoco pasaba y los sistemas eran casi los mismos (y con un servidor menos potente).

Y en realidad el problema no es tan grave: todo funciona bien el 99% del tiempo, pero a lo mejor una o dos veces a la semana tiene un rato tonto y se pasa media hora o una hora "lento" y luego se arregla solo. El resto del tiempo va como un tiro, o no se servirían tantas peticiones como se sirven ni se transferirían tantos GB como se transfieren.

#16 — Alex Sancho

A veces estas cosas pasan por omitir las comprobaciones mas obvias, cambios de hardware, actualizaciones de software, lamento no tener una solucion concisa, pero sospecho que vuestro problema ocurre por alguno de estos motivos.

Salu2 desde BCN

#17 — abanico

Alvy, cuando en el comentario #1 dije "MT" me refería a MediaTemple, no a Movable Type. Como decía alguien por ahí arriba, no estaría de más hacerles la consulta técnica a esta gente por si acaso sea un problema de ellos.

Por cierto, que el modo "lento" en el que se pone el apache me recuerda mucho a un modo que tiene mi servidor de correo que se llama "tarpitting", que se pone en modo "lento" con ciertos usuarios a posta cuando detecta conexiones reiteradas desde esa IP para enviar correos con destinatario desconocido, o cuando esa IP está en una blacklist y está intentando conectar continuamente.

... aunque dudo que Apache tenga algo así, porque no tendría sentido en este contexto ¿no?

#18 — Alvy

#14  El servidor es compartido pero bien grande. Y no debería ser eso porque si cuando está atontado reseteamos nuestro apache, entonces funciona. Si estuviera todo medio muerto por alguna razón (otro cliente en el mism servidor) de poco serviría resetear nuestro Apache.

#16  Sí, estamos revisando todo eso también.

#19 — alex

Como dice #11 el mod server-status te vendrá muy bien si vuelve a ocurrir.

También te puede servir esto:

lsof | awk '{printf("%s\n",$1)}' | sort | uniq -c | sort -n

Mide el uso de file descriptors por aplicación. Es un poco rebuscado, pero a veces Apache en plena carga usa muchos file descriptors. Puede ser que llegue al límite y por eso vaya tan lento. Al reiniciarlo cierra todos los fd y tarda un rato en volver a llegar al límite.

Puedes ver el límite de fd de tu SO con:

sysctl fs.file-max

Y si te vuelve a pasar, mira también con netstat el número de conexiones activas en ese momento.

En cuanto a lo que dice #13, si dices que la carga está tan baja no creo que sea un problema de un script lento o una bd lenta.

#20 — Bellz

Holas,

si que es extraño, no se como teneis configurado vuestro apache, mirad el LogLevel a ver si se os está escapando algo (Apache Log Level) ponedlo en modo debug o warn y cambiar el formato si es necesario (Log

Format explained) y esperad a que se vuelva a reproducir la situación y volved a consultar el registro. Creo que más que un bot puede ser una máquina que tenga un Nimda o algún bicho de estos de MS que os deja fritos.

Espero que os sirva.

#21 — XiMac

Hace unos dias tuvimos nosotros el mismo problema, aunque con fallos aleatorios en mas servicios, lentitud, errores ... al final el problema era un modulo de RAM del servidor que no funcionaba bien. Lo cambiaron y otra vez como un tiro.

#22 — Nacho

El servidor en concreto es este (dv)Extreme por si a alguien le dice algo

#23 — Alvy

#19  El límite de fd es unos 130.000 y cuando hacemos el lsof y sale la lista hay unos 25 procesos con entre 1 y 400 fd en uso; los que mas tienen son httpd y mysqld con cerca de 400, pero sumados todos no llegan ni a 1.000.

Las cargas es que son bajísimas, por eso es tan raro, claro que ahora está bien pero aun cuando está "frito" no suele pasar de 0.20:

uptime: 03:43:35 up 14:53, 1 user, load average: 0.04, 0.14, 0.19

#24 — Kilburn

Teneis los DNS Lookups activados? De ser así, me juego algo a que es eso...

#25 — alex

Esos números son muy bajos como para causar ningún problema. Además tenéis el límite muy alto.

Habéis mirado también el messages.log? Puede que haya algo relacionado con ese problema.

Si no encontráis el problema yo creo que lo mejor será que pongáis log a todo lo posible.

PHP puede logear los errores y resulta muy útil.

MySQL tiene un log llamado "slow queries" que también resulta muy util.

Y como ha dicho más arriba, aumentar el nivel de detalle del log de Apache. Aunque ponerlo en debug creo que es demasiado.

Está costando... seguramente será el típico problema "tonto" y estamos matando moscas a cañonazos.

#26 — Alvy

#25  Mmmm en el messages.log no aparece nada extraño, errores normales, por lo que parece, de otras cosas que no deberían tener que ver (correos etc, los lamercillos típicos a ratos rebotando passwords mal de root y tal desde IPs de japón y cosas así, as usual). El log de MySQL tampoco indicada nada, pero no veo que tenga un log slow queries, solo el mysqld. Hemos tuneado un poco la memoria del PHP subiéndola a 20 MB que es lo que recomiendan para Wikimedia y el ThreadsPerChild del Apache lo hemos subido de 25 a 50 a ver qué tal, nos dijeron que mejor subirlo un poco.

#27 — alidhaey

A lo mejor, es una tonteria pero quizas el problema no este fisicamente en el servidor. Como comentais hasta ahora, los logs aparentan normalidad y el servidor no tiene una gran carga en ningun momento (aunque cuando entra en modo lento).

Quizas sea debido a una sobrecarga en algun punto anterior de la red en donde estan puestos los servidores de MT (un switch que se queda frito por ejemplo).

#28 — alidhaey

Umm, lo anterior tampoco tiene mucho sentido, porque cuando esta en modo lento podeis hacer otro tipo de trabajo (FTP por ejemplo) sin problemas.

¿Las conexiones web se gestionan con algun tipo de hardware intermedio que actua de proxy/Cache en MT?

PD: MT es MediaTemple

#29 — Pontfx

Bueno.. dentro de nada os toca el efecto-barrapunto ya que estais enlazados en la portada por la noticia del spammer asesinado.

#30 — Alvy

#27  Mmmm Pero si fuera eso, un switch o algo en el proveedor, entonces reiniciando nuestro Apache no tendría por qué arreglarse e ir bien durente esos momentos extraños (???) Cuando pasa eso reinciamos, funciona bien y a los 10 minutos empieza a ir lento de nuevo.

#31 — Nacho

no parece que tenga que ver con nada más allá del apache porque el resto de servicios no se ven afectados por el problema (correo, ftp, etc) y es de suponer que si fuera cosa de un switch afectaría a todo tipo de comunicación/conexión con el servidor.

#32 — Alvy

#29  Por suerte esos efectos ya no nos afectan casi nada, de hecho desde Barrapunto han llegado en varias horas solo unas 130 visitas, mientras que desde el enlace de Yonkis a lo del teclado aquel, que tiene ya dos semanas de antiguedad, sigue llegando el doble de gente a estas alturas. La Fuerza es más poderosa en los Yonkis estos días ;-)))

Ahora el servidor está OK y ni se entera apenas de eso, está de carga a 0.15-0.30 como máximo, vaya, y está haciendo mil cosas aparte de servir páginas ese Apache. Es decir que está normal tras el extraño indicente de ayer a medianoche ;-)

#33 — Nacho

#24, el DNS lookup está off

#34 — Felipe

wget -k -r http://www.microsiervos.com/

#35 — alidhaey

#30 Alvy ya me conteste a mí mismo en mis circustancias propias y personales intrasferibles individuales (vaya frasesita) en #28

Que por ciertito, #28 es posible? (me pregunto a mí mismo -bla, bla, bla-).

#36 — Alvy

#34  Sólo se ven unas pocas decenas de hits de wget en los logs, no parece que sea eso tampoco.

#37 — Driadan

Bueno, yo no se nada de esto y (seguramente) voy a decir una tonteria, pero por si acaso y por aportar un granito de arena.

Podria ser algun tipo de proceso automatizado en el server (cron o algo por el estilo) que este mal configurado y salte cada poco tiempo?

saludos,

Driadan

#38 — edu

Hola, aunque no soy experto en redes, nosotros tuvimos un problema similar en nuestra empresa y estaba relacionado con la programación de los back-ups de las bases de datos, el "cron" de PHP realizaba el back-up a una hora de bastante afluencia y eso provocaba que el apache se colapsara porque no podía atender las peticiones. Cambiamos la hora a una menos problemática y asunto solucionado.

#39 — Alvy

#37  El log de cron también es normal, hace las cosas normales que suele hacer y sin errores al parecer.

#40 — Anonymous

Descargad el código fuente original de Apache y compiladlo para descartar que se trate de algún "arreglo" de los empaquetadores de vuestra distribución.

#41 — David

échale una mirada al módulo mod_throttle de apache. Sirve para restringir peticiones concurrentes y limitar ancho de banda por sitio.

#42 — Nacho

#40 es un Red Hat Enterprise, casi que de momento vamos a confiar en que esté bien empaquetada ;-)

#41 La limitación de ancho de banda no parece ser el problema, el consumo total es poco más de una quinta parte del total sin más límite ¿también en el mod_throttle se configuran las peticiones concurrentes?

#43 — Alvy

test

(volvemos del averno)

#44 — DeWeert

¿SOLUCION?

De acuerdo con:

#2

la sensación es que va bien hasta que empiezan a entrar peticiones que se encolan porque por alguna razón tardan mucho en servirse. Pero esas peticiones son de ficheros estáticos .html .jpg .gif etc.

(ALVY)

#25

Está costando... seguramente será el típico problema "tonto" y estamos matando moscas a cañonazos.

(ALEX)

La soluzioni puede ser:

Alguien ha linkeado tus graficos en su sitio.

Haz un 301 redirect, y envialo a un gran archivo de otro servidor como Yahoo.

Es un pequeño uso de ancho de banda para ti, y

a ellos les demandará una eternidad la carga.

fuente:

http://www.sitepoint.com/forums/showthread.php?t=179947

#45 — Bellz

¿Qué os ha pasado? habeis estado toda la tarde caidos... ¿se ha roto algo? o_O

#46 — Agace Magatsh

En el trabajo nos ha pasado con un Apache en desarrollo y peticiones Java. El caso es que Apache se congestiona como si los procesos no terminaran, en línea con #2, #5, #9, y sobre todo #11 y #19 (y seguro que alguno más). No sé casi nada de apache, ¿no tiene una especie de "flush" para evitar esto? Espero que lo resolvais.Saludos, A.M.

#47 — Merc

Nosotros tuvimos un problema muy similar una vez. Después de pasar horas y horas monitoreando llegamos a la conclusión que si bien el Apache tardaba mucho en servir algunas páginas, no se debía a un problema de consumo de recursos.

A partir de ese momento fue cuestión de escribir e insistir mucho al proveedor para que hiciera una revisión del hardware. Tuvimos que insistir bastante.

Finalmente nos escribieron diciendo que habían detectado "un cable" en mal estado. Vete a saber que pasaba realmente, pero desde entonces no hemos tenido un problema.

Probad a hacer el típico drama de o me lo arreglan o esto se va a saber.

#48 — Gromka

#10 - "Hemos aumentado nuestra lista de robots.txt para eliminar más."

Si sospecháis que se trata de bots realmente agresivos, estos no harán caso del robots.txt y tendréis que bloquearlos vía servidor.

#49 — Alvy

#44  No parece robo de imágenes porque se notaría en el aumento de consumo de transferencia y no es el caso, además realmente tampoco tenemos gráficos enormes por ningún lado aunque había gente que por error nos chupaba el icono del xml y cosas así.

#45  Ver explicacion.

#46  Parece algo de eso y vamos a ver si la próxima vez lo podemos monitorizar cuando se esté colgando, es el típico problema que no puedes repetir cuando tú quieras.

#47  No parece, pero sería otra idea.

#48  Cierto, pero por intentarlo que no quede ;-)

#50 — Fernando Plaza

Yo no creo que sea un problema de configuración por vuestra parte.

A nosotros nos paso algo parecido cuando contratamos un servidor que instalaba varios Apache en la misma máquina. Todo muy bien porque podias manejar tu Apache pero cuando el vecino se pasaba con algo a nosotros se nos relentizaba (igual que a vosotros). Lo reiniciabamos y volvia a funcionar, pero al rato otra vez lo mismo.

Yo creo que es un problema de alojamiento.

#51 — Alvy

#50  Podría ser eso pero en realidad creemos que no, porque cuando reiniciamos nuestro Apache funciona estupendo durante un buen rato, así que ese tipo de problemas de "maquina compartida" lo hemos descartado de momento. el hosting este se llama "dedicado virtual" o algo así, que no es toda la máquina real para ti pero a nivel de recursos casi como si lo fuera, según tengo entendido.

#52 — JoshWink

En un ratito, por lo que he podido averiguar, os puedo aconsejar que la versión de apache y kernel que usais no hacen buena combinación para mi gusto. He tenido problemas de rendimiento similares bajo plataformas parecidas.

Os recomiendo que vigileis que tal andan de consumo de memoria todos los procesos "child" de httpd, en mi caso, en X versión del kernel no liberaba correctamente la memoria. Lo solucioné sin cambiar de kernel, solo compilando un Apache 1.3.33 a medida, y cargando solo los módulos que fueran estrictamente necesarios.

Sería interesante que pusierais un apache 1.3.x en otro puerto, y lo atacarais con ApacheBench o alguna otra utilidad para medir rendimiento.

Saludos a todos!

#53 — Alvy

Con tanto comentario y respuesta buscando el fallo olvidé dar las gracias a todo el mundo por los consejos, desde los más técnicos a los que han intentado pone su granito de arena haciendo un poco de brainstorming. ¡Gracias a todos!

#54 — Fernando Plaza

Alvy,

Sin animo de meter el dedo en la llaga porque a lo mejor ya lo sabéis y estáis con ello... el wiki no funciona, al menos entrando desde:

http://wiki.microsiervos.com/

Ayer salia un mensaje de error de php y hoy aparece:

"You'll have to set the wiki up first!"

#55 — Alvy

Sí, ya lo comentamos ayer por la tarde en el post sobre la caída: que se había roto y que hoy lo intentaríamos arreglar Estamos ahora con ello. Al arreglar una cosa se rompió la otra. ¡Suele pasar! ;-)

#56 — Cek

¿tenéis programado un backup diario? Puede ser que coincida la lentitud de apache con cuando se hace el backup del servidor...

#57 — Anonymous

mirad cómo y cuándo se generan las stats

#58 — tanke

Aunque no es la solucion... teneis instalado mod_security?? visita www.modsecurity.org y miratelo, es muy muy recomendable.. Configuralo para que ciertas peticiones a apache se queden por el camino... Yo la verdad tuve muchos problemas con peticiones raras que hacian a apache responder lento y con un poco de mod_throttle y mod_security lo tengo funcionando 100% sin problemas...

Es una sugerencia, un saludo

#59 — Sansara

Euh...

Creo que tengo la respuesta... al menos es algo que he descubierto yo hace bien poquito con las últimas versiones de apache, y en mis propias carnes...

La respuesta es "logrotate". Si os pasa en un momento en concreto de la semana, en un tiempo concreto de la semana, lo más seguro es que sea por este tema o, como he visto por ahí arriba, cuando el script que hace el parsing de los logs para las estadísticas ande rascando disco duro como un histérico. Si reiniciando apache se pasa, me da a mí que va a ser un tema de rotación de logs, o similares. Yo echaría un vistazo por ahí en google para configurarlo de forma que roten cada día... No sé, es una idea.

Suerte, de todos modos

Sansara.