Ejecutamos la operación que reprocesa actividades para todo el grupo de estudiantes que tiene la universidad y la pantalla del Guaraní se detuvo en el 0% durante tres horas. Pasado todo ese tiempo, y sin ver cambios en la pantalla, ingresamos desde otro usuario a ver los procesos anteriores y pudimos constatar que en el único proceso corrido el día de hoy sólo se relevó un 2% y no avanzó más. Estamos en la versión 3.22.2.
Y no sólo falló con la tira completa de estudiantes, sino que también falló con una sola carrera. Se detuvo en el 32%.
Seguimos con este problema. Hicimos nuevas pruebas subiendole los recursos a una máquina de desarrollo y el proceso se vuelve a truncar, aún con carreras de aproximadamente 1000 estudiantes regulares (que están lejos de las carreras mas grandes que tenemos). Viendolo conjuntamente con el area de informática en ningún momento los recursos se estresan, trabajando en desarrollo con 8 núcleos y 12 gb de ram, el proceso nunca ocupa mas de un núcleo y 1 gb de ram, nunca llega a swappear. El técnico nos pasó un registro de inscripción en el que proceso se detiene y haciendo el reprocesamiento para todos los estudiantes de esa comisión con esa inscripción incluida, el proceso se pudo realizar con éxito. Es evidente que tiene que ver con el tamaño del set de datos manejado pero en ningún momento hay evidencias de que la máquina esté trabajando al límite o cercano al límite. Estamos bastante desorientados con este tema. Precisamos asistencia.
Lo único raro que notamos es que en el archivo pro_reprocesar_inscripciones_actividades_68fb9c7c73684.txt hacia el final se aprecia un error y el abortar proceso.
Es posible que al trabarse ustedes hayan pulsado el botón de “Abortar”?
Dentro de instalación/i__desarrollo/p__guarani/logs/procesos_bk hay algún archivo log_ejecucion.txt? Si es así envíennoslo porfa
Sino dentro de instalacion/logs_comandos/comandos.log deberían poder rastrear más archivos de logs de errores. Por favor vean si al trabarse el proceso se genera algún archivo allí y envíenlo, así vemos si podemos rastrear más detalles de lo que esté generando el error.
Hola Martín, sigo yo, Pablo, con este hilo. No abortamos el proceso. Nunca finaliza. De todos modos vamos a pasar tu consulta a ver qué respuesta nos da el área técnica.
Incrementar la variable $timeout_procesos_bk de php/nucleo/_lib/comunes_nucleo.php, se puede incrementar personalizando la función get_timeout_procesos_bk en personalizacion/php/nucleo/_lib/comunes.php:
<?php
class comunes extends comunes_nucleo {
static function get_timeout_procesos_bk()
{
return 3000; // 3 segundos
}
}
?>
También les pedimos si pueden detallarnos qué requisitos tienen configurados para la operación de reprocesar inscripciones.
Dentro de comandos.log puede haber varios archvos que se llamen comandos.log seguido de un número y dentro de alguno de ellos puede llegar a estar el comando que necesitamos revisar.
Por favor vean si pueden mandarnos los archivos que tienen allí así los revisamos.