Pues ya est\u00e1. Ya he conseguido resolver el problema con el servidor secundario. Por fin. <\/p>\n\n\n\n\n\n\n\n
Este servidor ha sido siempre para pruebas y replicaci\u00f3n de servicios, pero estaba siendo usado tambi\u00e9n para tareas secundarias y lo cierto es que el rendimiento iba en picado d\u00eda tras d\u00eda. Como he contado en d\u00edas anteriores el problema principal era que los recursos del sistema estaban siendo utilizados principalmente por el servidor PostgreSQL a instancias del programa odoo de manera brutal y sin sentido alguno. Las r\u00e1fagas continuas de lecturas de disco dejaban siempre a la instalaci\u00f3n de rodillas y la soluci\u00f3n de reiniciar servicios s\u00f3lo funcionaba temporalmente. <\/p>\n\n\n\n
Bueno, he dicho el problema pero no es exactamente as\u00ed. El problema real era qu\u00e9 estaba haciendo el servidor, no lo que provocaba por ello. As\u00ed que mi idea de obtener informaci\u00f3n sobre \u00e9l estaba acertada. Estudiando las estad\u00edsticas he visto que la mayor parte del tiempo lo gastaba en esperar acceso a tablas y tuplas en procesos extra\u00f1os que tardaban horas diarias en completarse. Y encima para algo como los inventarios de productos, que no se utilizan en ese caso para nada. Cosas del muchacho externo 1, que ten\u00eda otras prioridades que configurar adecuadamente los sistemas y documentarlo. El caso es que con esa informaci\u00f3n en la mano, viendo qu\u00e9 consultas se realizaban he buscado en el c\u00f3digo odoo y he visto que, efectivamente, se trataba de algo que se lanzaba autom\u00e1ticamente y con much\u00edsima frecuencia. <\/p>\n\n\n\n
Explorando la configuraci\u00f3n de la aplicaci\u00f3n he encontrado el causante en las acciones planificadas:<\/p>\n\n\n\n
![\"\"](\"https:\/\/esferas.org\/mldt\/wp-content\/uploads\/sites\/23\/2022\/01\/image.png\")
<\/a><\/figure><\/div>\n\n\n\n