Admin

Holas,
esta mañana estaba tieso otra vez.
Habian tres interpretes de ruby consumiendo toda la CPU y uno que no consumia CPU pero se estaba llevando unas 3Gb de RAM haciendo que todo fuese a swap.
El restart y reload del apache ha hecho que empezase a responder a las peticiones el servidor, pero esos cuatro procesos ruby seguian consumiendo memoria y CPU al mismo ritmo.
Les hemos enviado la señal SIGTERM (-15) y han muerto, pareciendo que el redmine resolvia paginas mas rapidamente.

No se si se tenia contempleado lo del proceso que consumia toda la memoria, lo anoto aqui por si sirve de algo.

Un saludo
Joaquin

Algo de información encontrada:

http://www.redmine.org/boards/2/topics/31731

intentando ejecutar el comando que indica para fijar la fecha:

date -s "`date`"

pero devuelve un error de fecha inválida.
Se han hecho pruebas para ver si se puede adaptar el formato para que pueda actuar como parámetro de entrada:

sudo date -s now +"%c"

faltaría ponerlo en un script para que se haga este proceso al iniciar "crontab -e"

@reboot /home/me/myscript.sh

If you want to run something like a service for your linux system, when booting your system, you should use an init-script. With traditional systems, you place the init-script in /etc/init.d, and activate it in the correct rc level.

Faltaría comprobar si esto soluciona el problema, tal y como se comenta en el enlace.

He comentado la siguiente linea del /etc/cron.d/redmine por si fuese la causa:

[...]
#00 */1 * * * root /var/local/scripts/redmine/update_svn_redmine.sh 2>&1 /var/log/redmine/update-svn.log
[...]

No se ha detectado aún que el problema continue. De todas formas, y viendo http://www.modrails.com/documentation/Users%20guide%20Apache.html se ha configurado el fichero conf.d/passenger.conf con los siguientes parámetros:

PassengerMaxPoolSize 2
PassengerPoolIdleTime 1000

El problema persiste. Parece ser que se queda un proceso de ruby colgado. Al hacer un service apache2 reload sigue funcionando el servicio pero limpia estos procesos que consumen memoria. La solución de momento parece ser que pasa por hacer un reload de Apache todos los días.
Se ha editado el fichero /etc/cron.d/redmine y se ha añadido la siguiente línea (ejecuta un reload todos los días a las 11:05AM)

05 11 * * * root /usr/sbin/service apache2 reload

Este fin de semana se ha vuelto a quedar colgado el servidor.

Ha costado casi 10 min hacer el login por SSH, pero ya se ha restablecido el funcionamiento

Incidencias miércoles 9 de enero de 2013:
- Detectados problemas de rendimiento desde primera hora de la mañana.
- Se realiza un "reload" sobre las 9h. No se resuelve el problema.
- Se realiza un "restar" sobre las 11h. No se resuelve el problema.
- Se mata un proceso "ruby1.8" que estaba utilizando permanentemente un 80.5% de memoria (no de CPU).
- Aparentemente se reestablece el buen funcionamiento.

La máquina fue reiniciada el lunes a las 8:00h.

Queríamos ver si nos confirmáis que no se hizo nada más hasta lo de hoy, para ver si se puede acotar las acciones que se realizan durante ese intervalo que llevan a esa carga de cpu.

Gracias

Manuel Madrid wrote:

Incidencias miércoles 9 de enero de 2013:
- Detectados problemas de rendimiento desde primera hora de la mañana.
- Se realiza un "reload" sobre las 9h. No se resuelve el problema.
- Se realiza un "restar" sobre las 11h. No se resuelve el problema.
- Se mata un proceso "ruby1.8" que estaba utilizando permanentemente un 80.5% de memoria (no de CPU).
- Aparentemente se reestablece el buen funcionamiento.