[Jderobot-admin] [Jderobot-dev] ¿Servidor web jderobot.org caído?

[JoseMaria]

¡Qué buena pinta tienen las herramientas que mencionas! Habrá que
probarlas.

He creado la lista de correo jderobot-admin en gsyc.es para estas
conversaciones. Usemosla a partir de ahora.

Saludos,

JoseMaria
On Mon, 2012-10-29 at 20:32 +0100, Oscar Garcia wrote:
> El lun, 29-10-2012 a las 17:50 +0100, JoseMaria escribió:
> > La paginación no tendría que tirar la máquina, si acaso, ralentizarla,
> > no?. Sólo respondía a pings. Servidor web tostado y conexión por ssh
> > imposible. En local ponía periódicamente un mensajito un poco críptico
> > sobre disco duro, imposible acceder en local también. Entendería que
> > ocurriera paginación si tiene muchísimos procesos ejecutando y se queda
> > corta de memoria. El servidor en principio no ejecuta demasiados
> > procesos. Igual se ha ido la mano a algún demonio... Pero vamos, no
> > tengo idea de qué pasó, no descarto nada. Habrá que seguir buscando la
> > causa.
> 
> 
> La paginación tiene muchos efectos en la máquina. Cuando es una
> paginación leve se produce ralentización del sistema, pero cuando es una
> paginación excesiva se producen diferentes efectos que son detectables
> para predecir el estado "zombi" en el que se quedará la máquina.
> 
> Uno de ellos es que se produce un cuello de botella en el disco duro que
> hace aumentar el número de procesos en estado iowait y, por ende, la
> carga del sistema aumenta debido a que se acumulan los procesos que
> están en ejecución esperando que termine una operación de
> entrada/salida.
> 
> Por otro lado se producen timeouts de lectura o escrita en disco (los
> errores que suelen salir por consola) junto con mensajes de procesos
> matados para intentar liberar memoria entre otros mensajes (incluso
> algunos kernel panic). Una vez llegado a este estado no se puede hacer
> nada más que un reset hardware (pulsando el botón) o reset software
> (provocado por el watchdog software que te comenté, por ejemplo)
> 
> Se produce la paginación en muchos casos. Uno de ellos es cuando se
> levantan procesos ssh para dar servicio a aplicaciones (como rsync o svn
> sobre ssh, etc) que se pueden ir quedando colgados hasta colapsar la
> memoria.
> 
> También puede provocarse por tareas de cron que tardan mucho en
> finalizar o que tienen algo que las hace detener y se van acumulando o
> incluso scripts de PHP en un servidor apache que se queden esperando una
> operación de entrada/salida (como acceder a un archivo en un sistema de
> archivos NFS que no responde, por ejemplo).
> 
> Son muchas las formas de provocar que una máquina se quede en ese
> estado. La monitorización puede ayudar a determinar la fuente del
> problema.
> 
> 
> > No tenemos zabbix instalado, igual conviene ponerlo para monitorizar la
> > red...
> 
> 
> Más que monitorizar la red se debe monitorizar uso de CPU, memoria,
> sistema de archivos, etc. 
> 
> En mi empresa tenemos desplegamos un millar de agentes zabbix (sin
> exagerar) entre máquinas de producción, calidad y desarrollo.
> 
> 
> > > Hace tiempo te comenté los problemas de DNS del dominio y cómo 
> > > solucionarlos, sigue en pie mi oferta de colaboración en lo que haga falta.
> > 
> > Claro que sí, tu ayuda es más que bienvenida, vendrá muy bien. Los
> > problemas de DNS al final los solucionamos usando el servidor de nombres
> > de la propia empresa que nos alquila el dominio. Antes me empeñaba en
> > usar el servidor de nombres de GSYC, pero ha dado muchos problemas...
> > asi que al carajo. Desde entonces creo que no tenemos problemas de
> > nombres.
> 
> 
> Mañana puedo volver a hacer las pruebas. Una de las cosas que no
> funcionaba era que no coincidían los registros del registrador con las
> entradas DNS y que los servidores DNS adicionales (los que supuestamente
> son de backup) respondían con que ellos no sabían nada de dicho dominio,
> etc...
> 
> 
> 
> > > Por otro lado, ¿has probado a usar watchdog en esa máquina para que se 
> > > reinicie automáticamente cuando entre en paginación o se vuelva inestable?
> > Interesante... ¿Cómo detecta que se vuelve inestable o 'entra en
> > paginación'?
> 
> 
> Tiene muchos métodos.
> 
> Uno de ellos es cuando la máquina tenga una carga superior a un límite
> dado.
> 
> Normalmente cuando la máquina empieza a paginar los procesos se van
> acumulando aumentando la carga del sistema.
> 
> Por otro lado se puede lanzar la ejecución de un proceso o comprobar la
> fecha de última modificación de un archivo, etc. Cuando la máquina se
> queda sin memoria no se pueden levantar ni procesos de shell para
> atender dichas comprobaciones, por lo que al minuto de hacer el intento
> y que ésta no responda la máquina se resetearía (bueno, con la opción
> "-b" se le haría un "reboot", pero si la máquina está tan mal como para
> no levantar un proceso entonces tampoco podrá levantar los scripts de
> parada por lo que saltaría el reset). Por eso se suele poner un umbral
> de carga para que se resetee antes de que sea tarde.
> 
> En /usr/share/doc/watchdog/examples/ hay scripts de ejemplo. Uno de
> ellos es un script vacío sólo para comprobar que se puede levantar una
> shell.
> 
> Un parámetro de /wtc/watch.conf que merece la pena descomentar es:
> max-load-5             = 18
> 
> No lo hagáis con el max-load-1 ya que el ordenador puede tener picos de
> proceso elevado que al poco tiempo terminen, pero si se mantienen
> durante 5 minutos entonces es diferente y algo va mal.
> 
> Por último, desde zabbix, se pueden crear triggers cuando aumenten el
> numero de procesos ssh por encima de un umbral para que haga un killall
> ssh (por ejemplo).
> 
> Un saludo.
> 

-- 
http://gsyc.es/jmplaza 
Universidad Rey Juan Carlos