Buenos días:
Les cuento un poco como está organizado el esquema de servidores para el problema puntual que tenemos.
Un servidor de aplicaciones con debian squeeze apache, php y postgresql desde repositorios, es decir apache 2.2.x php 5.3.x y postgresql 8.4.x
Varias aplicaciones toba versión 2.1.0 instaladas en este servidor, en particular una aplicación denominada becas (algo parecida a Tehuelches que tiene varios usuarios 2880 hasta el día de hoy) que se conectan localmente a su base toba y a un servidor de bases (para la base de negocio)
Estábamos actualizando nuestras aplicaciones en forma normal hasta que ocurrió este problema al tratar de actualizar esa aplicación de becas y no se pueden actualizar más ni esta ni las otras.
Pareciera ser problema de postgresql porque cuando está actualizando la memoria del servidor donde está la base toba queda al limite y haciendo swapping, luego aparece el cartel, he probado de modificar shared buffers, work_mem, maintenance_work_mem, también vm.overcommit_memory pero sigue ocurriendo el problema.
¿Tendrán alguna idea de lo que puede estar pasando? Adjunto envío captura de pantalla del error y log de postgresql.
me paso alguna vez de necesitar incrementar el parametro max_lock_per_transaction, debido a que habia metido garfio en la configuracion de postgres y se nota que no de la mejor manera.
Igualmente eso siempre se me dio al tirar comandos por la consola, supongo que quizas pueda ser una causa… pero el mensaje de error que informa postgres es completamente distinto en este caso.
Del log pareciera que se esta ejecutando un autovacuum mientras vos estas actualizando la bd, igualmente no estoy muy en tema asi que no puedo ser de mucha ayuda, lo que voy a hacer es moverte el msg a la parte de postgres para ver si alguien con mas conocimiento te puede dar una mano.
Richard: Muchas gracias por responder. Seguimos la pista que nos diste sobre el tema del autovacuum de postgresql. Aparentemente es un problema con la memoria de la máquina donde se corre el instalador. Probé de hacer un backup y correr el instalador en otro equipo con más memoria disponible y lo actualizó.
Luego en una virtual box imitando las características de memoria y procesador del equipo de producción traté de seguir una guía de actualización (que está en el foro) sin usar el instalador directamente sino haciendo toba instancia regenerar y toba proyecto regenerar y ahí largó en el log de comandos que se corta al exceder el límite de memoria haciendo una serie de inserts anidados en la tabla apex_solicitud.
Miré el tamaño de esta tabla en la base y es de unos 280.000 registros similar cantidad en apex_solicitud_browser.
Luego probé en la misma virtual box eliminar los registros de esa tabla, hacer vacuum de la base y volver a correr el instalador y ahí si actualizó la aplicación.
Esa tabla se carga por tener tildad la propiedad del proyecto registrar accesos? La verdad no le había dado bolilla a esa propiedad hasta ahora que no pudimos actualizar la aplicación :)
Se debería destildar en producción esta propiedad?
desde ya muchas gracias por la atención.
claro el tema era de memoria, lo que no sabia es si tenia que ver con la configuracion particular de postgres, con la cofiguracion del SO o puntualmente con la cantidad de memoria fisica disponible. Por eso lo tire para esta seccion, por ahi habia un parametro en postgres que no conozco y jodia, ademas era mas factible que alguien sacara una conclusion mas acertada sobre el log que adjuntaste.
Luego en una virtual box imitando las características de memoria y procesador del equipo de producción traté de seguir una guía de actualización (que está en el foro) sin usar el instalador directamente sino haciendo toba instancia regenerar y toba proyecto regenerar y ahí largó en el log de comandos que se corta al exceder el límite de memoria haciendo una serie de inserts anidados en la tabla apex_solicitud.
Miré el tamaño de esta tabla en la base y es de unos 280.000 registros similar cantidad en apex_solicitud_browser.
Luego probé en la misma virtual box eliminar los registros de esa tabla, hacer vacuum de la base y volver a correr el instalador y ahí si actualizó la aplicación.
Esa tabla se carga por tener tildad la propiedad del proyecto registrar accesos? La verdad no le había dado bolilla a esa propiedad hasta ahora que no pudimos actualizar la aplicación :)
Se debería destildar en producción esta propiedad?.</blockquote>
Esas tablas forman parte del log de accesos de toba, lo que te permite en conjunto con el log de errores determinar en algunos casos puntuales cual es la fuente (la mas comun, perdida de sesion), por otro lado, te provee de info extra. Por defecto toba loguea esta informacion siempre, de hecho es recomendable que asi lo haga, para al menos tener idea de quien accedio al sistema.
En versiones posteriores lo que hicimos fue pasar todas estas tablas a un schema propio, de forma que nunca sean tocadas cuando se regenera la instancia (que es lo que hace el instalador), eso hace que no sea necesario exportar los logs a SQL y por tanto se ahorra bastante, en tiempo y en carga. El detalle es que vino despues de la version 2.1 ese cambio, con lo cual tendrias que migrar el proyecto primero.
En la version que trabajas vos, existe sin embargo un comando toba instalacion eliminar_logs que borra todos esos datos, podrias llegar a usarlo antes de actualizar si es que esos datos que se van guardando no tienen utilidad para ustedes. No se cual sea la importancia que esos datos tienen para el proyecto, asi que podria ser una opcion hasta que lo migren de version, al menos para poder usar el instalador web.
Hola Richard:
De nuevo muchas gracias por responder. Migraremos entonces de versión,por este y el motivo del ordenamiento de los combos y otros…:). Aparte de esto cambiaremos en cuanto se pueda el equipo en cuestión.
Aprovecho este tema para consultarte sobre ¿cuales son las versiones recomendadas de postgresql, apache y php para cada versión de toba desde la 2.1 a la 2.5?