On Mon, 14 Nov 2011 19:20:50 -0300, Carlos Tirado Elgueta <[email protected]> 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 > <[email protected]>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 <[email protected] >> >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) < >> > [email protected]> 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: [email protected] [mailto: >> > > [email protected]] 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) < >> > > [email protected]> 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.
