Casi 8 horas de 100% de tiempo de CPU
La pasada noche del Viernes 11 de enero sobre las 23:30h hasta casi las 20h del siguiente dÃa Sábado 12 de Enero, estuve con un uso de 100% de CPU en el servidor, me di cuenta mirando los gráficos del MRTG.
Al darme cuenta, rápidamente me conecte por ssh y ejecuté el comando top:
root@Arpanet:~$ topEsta es la captura:
Normalmente el proceso “hlds_amd” es el que mas me consume, para los curiosos, es el servidor de Counter-Strike, que suele gastarme entre un 10% y 30%, pero por encima de este, estaba el proceso “mysqld_safe” y dije… -¡¡WTF!! ¿Que conio hace el mysqld_safe chupando la cpu esa manera? Lo segundo que dije fue: -Muhahah le hago un /etc/init.d/mysql restart y listo:
root@Arpanet:~$ /etc/init.d/mysql restart
El restart se realizó correctamente, pero al volver hacer el top: ¡Sorpresa! seguÃa consumiendo como una mala cosa. Total que pensé un poco mas (solo un poco…) y decidà asesinar el proceso de una manera muy cruel, antes por eso, hay que decirlo también, pensé como un windowuser: Reinicio el server y listos…pero no…conio que esto no es un Windows, no necesito reiniciar xD
Bueno en definitiva que realice la matanza del proceso con kill:
root@Arpanet:~$ kill 24094
Y problema resuelto. Ya no existÃa proceso tragón ni consumo de cpu del 100% en el servidor. Pero como no me gusta matar a sà a los procesos y menos aun cuando no se que realiza el proceso, no me quedé tranquilo y volvà a reiniciar el servicio mysql, por si las moscas:
root@Arpanet:~$ /etc/init.d/mysql restart
Una vez más el restart se realizó con normalidad y las BBDD funcionaban correctamente, pero no estaba del todo tranquilo, aun tenia remordimientos por haber cometido tal acto (conio que dramático xD) asà que me fui a los ubuntuforums y busqué una posible respuesta a la situación:
En los ubuntuforums descubrà que no era el único que habÃa sufrido los problemas del proceso chupón…pero tampoco encontré una explicación, tan solo un par de soluciones, entre ellas las del asesinato mediante kill.
Te seguiré vigilando mysqld_safe…
Adjunto los gráficos del MRTG:
Antes:
Un poco después:
