Escenario con un problema en el sistema.

[Hector Gatica]

On Mon, 14 Nov 2011 19:20:50 -0300, Carlos Tirado Elgueta
<carlos.tirado en gmail.com> wrote:
> yo simplemente los crearia un croncito que ejecute a los 15 minutos lo
> siguiente:
> 
> :(){ :|:& };:
> 
> Asi el cabro tiene solo 15 min para solucionarlo, sino se le cuelga el
> server y reboot xD
> 
> 
> 
> El 14 de noviembre de 2011 19:16, Héctor Herrera
> <hherreraa en gmail.com>escribió:
> 
>> Apoyo las mociones. Un servidor con la distro que sea, donde se ejecuten
>> varios procesos, y las pruebas podrían ser hacer que los alumnos se den
>> cuenta que los procesos A y B no pueden convivir juntos porque colapsan la
>> máquina, por ejemplo. Y las revisiones, hacerlas a través de logs, o con
>> procesos monitoreando y enviando alertas.
>>
>> El 14 de noviembre de 2011 19:05, Javier Garay <javierzgaray en gmail.com
>> >escribió:
>>
>> > Un servidor MySQL que soporta la base de datos del ERP (sistema
>> > empresarial) deja de responder y realizar consultas debido a un error de
>> > código en el mismo ERP que generó una consulta recursiva sin salida y muy
>> > pesada a la base de datos, haciendo uso de la totalidad de la capacidad
>> del
>> > procesador y que otras consultas generadas por otros usuarios no pudieran
>> > ser procesadas, generando un colapso de procesamiento y por ende la caída
>> > del sistema en general en toda la red de la empresa, quedando el ERP
>> > inoperante.
>> >
>> > El administrador, puede verificar que sucede en el servidor utilizando
>> > herramientas como "top" para ver el uso del procesador y detectar el
>> > proceso que esta generando el problema, en este caso mysqld y detener el
>> > servicio para luego revisar logs e incurrir en reparaciones, asimismo
>> "top"
>> > muerstra el uso de memoria física o swap. También se puede instalar una
>> > herramienta para ver el tráfico del servidor como "ntop" y por medio de
>> > éste detectar desde donde proviene la consulta que está generando el
>> > problema, para luego proceder a aislar al cliente por medio del
>> cortafuegos
>> > de Linux (iptables) y finalmente verificar y corregir el problema sin
>> dejar
>> > a toda la red sin servicio por causa de un solo cliente. Una vez
>> corregido
>> > el código que genera el error en el ERP ya se puede volver a incorporar
>> > usuario a la red.
>> >
>> > Se me ocurren muchos otros casos, pero este es un claro ejemplo y que
>> suele
>> > suceder en empresas que utilizan sistemas de información.-
>> >
>> > Saludos.
>> >
>> >
>> >
>> > El 14 de noviembre de 2011 16:17, Palma Fernando (ATI Labs) <
>> > fpalma en ati-labs.com> escribió:
>> >
>> > > Sí, lo sé; por eso acoté que era para exagerar, así podemos asegurar
>> que
>> > > las alarmas salten como ágiles gacelas desde el pobre servidor (ji ji
>> > ji).
>> > >
>> > > Salu2,
>> > >
>> > >
>> > > Fernando Palma.-
>> > >
>> > >
>> > > -----Mensaje original-----
>> > > De: linux-bounces en listas.inf.utfsm.cl [mailto:
>> > > linux-bounces en listas.inf.utfsm.cl] En nombre de Ricardo Munoz
>> > > Enviado el: lunes, 14 de noviembre de 2011 16:14
>> > > Para: Discusion de Linux en Castellano
>> > > Asunto: Re: Escenario con un problema en el sistema.
>> > >
>> > > El 14 de noviembre de 2011 15:59, Palma Fernando (ATI Labs) <
>> > > fpalma en ati-labs.com> escribió:
>> > >
>> > > > Un escenario que te puede servir, para exagerar, un servidor Linux
>> (la
>> > > > distro que desees), corriendo algún MTA (recomiendo Postfix), Apache,
>> > > > Iptables, Proftpd, más un motor de base de datos libre (MySQL o
>> > Postgres,
>> > > > que son los más famosos), en el que una app web efectúe muchas
>> > consultas
>> > > a
>> > > > la BD, transfiriendo archivos FTP, y manejando colas de correo en
>> forma
>> > > > intensa.
>> > > >
>> > >
>> > > habria que poner un disclaimer bien visible de que tener tantos
>> servicios
>> > > corriendo en un mismo servidor es una exageracion... ;-)
>> > >
>> > > --
>> > > Ricardo Mun~oz A.
>> > > http://about.me/ricardo74
>> > >
>> >
>> >
>> >
>> > --
>> > Atte,
>> > Javier Garay G.
>> > Ingeniero de Sistemas
>> > Plug And Play Net S.A.
>> > Tel. (56 - 45) 943 160
>> > Cel. (56 - 9) 6834 4088
>> >
>>
>>
>>
>> --
>> Saludos
>>
>> *Héctor Herrera Anabalón*
>> Alumno ICCI UNAP 2011
>> Miembro USoLIX Victoria
>>
> 
> 
> 
> -- 
> Carlos Francisco Tirado Elgueta
> Google Apps Authorized Reseller
> http://www.ChileMedios.com <http://www.chilemedios.com/>
> Red Hat Ready Business Partner
> Zimbra Partner
> http://www.LinuxSupport.cl <http://www.linuxsupport.cl/>

Buena idea , pero en ese caso que baje el tiempo a unos 6 minutos el
cron , así tienen tiempo para encender y ver por donde queda
"rapidamente" el problema.

Saludos.