Saturación de HD debido a la creación inoportuna de archivos postgresql

[Sofía]

Buen día,
Lo primero que quiero es desearles lo mejor para el nuevo año.

Desde el lunes, después de 15 días de vacaciones, nuestro servidor Wapt se ha colapsado, saturando el disco duro con archivos PostgreSQL en /var/lib/postgresql/9.6/main/base/16385/
con archivos que alcanzan un tamaño de 1048576 Kb hasta que el HD se satura.

A continuación se muestra la configuración de nuestro servidor virtual:

• Versión de Wapt 1.7.4.6165

• Sistema operativo Debian 4.9

• 4 GB de RAM

• Disco duro de 40 GB

Tenemos aproximadamente 1800 máquinas en nuestro inventario.

Cuando se inicia la consola, se muestra el siguiente mensaje de error:
No se pudo obtener la lista de hosts: Error en el servidor:
OperationalError('No se pudo conectar al servidor: No existe tal archivo o directorio\n\tls el servidor se está ejecutando localmente y acepta \n\tconexiones en el socket de dominio Unix "/var/run/postgresql/.s.PGSQL.5432."?\n',)

A continuación se muestra el resultado de Estado del servicio waptserver
waptserver.service - Script de inicio del servidor WAPT
Cargado: cargado (/usr/lib/systemd/system/waptserver.service; habilitado; configuración predeterminada del proveedor: habilitada)
Activo: activo (en ejecución) desde el martes 7 de enero de 2020 12:17:02 CET; Hace 8 h
PID principal: 664 (python)
Tareas: 1 (límite: 4915)
CGroup: /system.slice/waptserver.service
└─664 /opt/wapt/bin/python /opt/wapt/waptserver/server.py

7 de enero 20:40:36 srv-wapt15 python[664]: conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
7 de enero 20:40:36 srv-wapt15 python[664]: OperationalError: no se pudo conectar al servidor: No existe tal archivo o directorio
7 de enero 20:40:36 srv-wapt15 python[664]: ¿El servidor se está ejecutando localmente y acepta
7 de enero 20:40:36 srv-wapt15 python[664]: ¿conexiones en el socket de dominio Unix "/var/run/postgresql/.s.PGSQL.5432"?
7 de enero 20:40:36 srv-wapt15 python[664]: , instancia:
7 de enero 20:40:36 srv-wapt15 python[664]: 2020-01-07 20:40:36,449 CRITICAL Error de SocketIO pong para uuid 4C4C4544-004B-3710-8059-B1C04F4D3632 y sid b270e
7 de enero 20:40:36 srv-wapt15 python[664]: Archivo "/opt/wapt/waptserver/server_socketio.py", línea 278, en on_wapt_pong
7 de enero 20:40:36 srv-wapt15 python[664]: con wapt_db.atomic() como trans:
07 de enero 20:40:36 srv-wapt15 python[664]: Archivo "/opt/wapt/lib/python2.7/site-packages/peewee.py", línea 3533, en __enter__
07 de enero 20:40:36 srv-wapt15 python[664]: return self._helper.__enter__()

Restaurar esta máquina virtual a un estado anterior no resuelve el problema: después de unos minutos, el fenómeno vuelve a ocurrir.

¿Alguna idea, por favor?
Gracias por tus comentarios

[dcardón]

Hola Sophie,

Lo primero que quiero es desearles lo mejor para el nuevo año.

Desde el lunes, después de 15 días de vacaciones, nuestro servidor Wapt se ha colapsado, saturando el disco duro con archivos PostgreSQL en /var/lib/postgresql/9.6/main/base/16385/
con archivos que alcanzan un tamaño de 1048576 Kb hasta que el HD se satura.

A continuación se muestra la configuración de nuestro servidor virtual:

• Versión de Wapt 1.7.4.6165

• Sistema operativo Debian 4.9

• 4 GB de RAM

• Disco duro de 40 GB

Tenemos aproximadamente 1800 máquinas en nuestro inventario.

Cuando se inicia la consola, se muestra el siguiente mensaje de error:
No se pudo obtener la lista de hosts: Error en el servidor:
OperationalError('No se pudo conectar al servidor: No existe tal archivo o directorio\n\tls el servidor se está ejecutando localmente y acepta \n\tconexiones en el socket de dominio Unix "/var/run/postgresql/.s.PGSQL.5432."?\n',)

Parece que el tamaño de los inventarios JSON (consultas WMI locales + dmidecode en equipos locales) ha aumentado significativamente y la base de datos PostgreSQL no gestiona los VACUUM con la suficiente rapidez. ¿Ve mensajes como los siguientes en sus registros?

Código: Seleccionar todo

ERROR: canceling autovacuum task CONTEXT: automatic vacuum of table "segmentation.pg_toast.pg_toast_237738400" LOG: checkpoints are occurring too frequently (8 seconds apart) HINT: Consider increasing the configuration parameter "max_wal_size

Puede liberar algo de espacio en la máquina para permitir que Postgres se reinicie (pero no el servicio WAPT inicialmente) y luego realizar un VACUUM FULL en la base de datos Wapt para verificar que libera espacio.

Código: Seleccionar todo

df -h 
systemctl stop waptserver
rm quelques_fichiers_inutiles_pour_recupere_un_peu_despace
systemctl restart postgresql
sudo -u postgres psql wapt -c "VACUUM FULL"
df -h

Esto no soluciona el problema, pero al menos confirma que efectivamente existe. Tenemos un cliente con un problema similar y lo estamos depurando con ellos. Probablemente haya una actualización reciente de Windows que haya cambiado algo en las solicitudes WMI.

Atentamente,

Denis

[dcardón]

Hola de nuevo,

solo por curiosidad, ¿tienen algún paquete de auditoría que active regularmente WAPT.register()?

Saludos,

Denis

[Stephane B]

Hola,
gracias por tu respuesta (soy colega de Sophie, quien inició este hilo).

Efectivamente, tenemos registros de pgsql como este:
"Los puntos de control se producen con demasiada frecuencia
(cada 25 segundos)
... Considera aumentar el parámetro 'max_wal_size'".

La función vacuum liberó el espacio y reinició los servicios.

¿Sería buena idea programar una tarea cron de pgsql vacuum mientras tanto?

Respecto a un posible paquete que contenga la función wapt.register(), no creo que exista, pero lo investigaré.

[dcardón]

Hola StephaneB,

Hola,
gracias por esta respuesta (soy colega de Sophie, quien inició este hilo).

De hecho, tenemos registros de pgsql como este:
"Los puntos de control ocurren con demasiada frecuencia
(cada 25 segundos)
... Considere aumentar el parámetro 'max_wal_size'".

La función vacuum nos permitió recuperar el espacio y reiniciar los servicios. ¿

Sería buena idea programar una tarea cron de pgsql vacuum mientras tanto?

Con respecto a un posible paquete que contenga una función wapt.register(), no lo creo, pero lo investigaré.

El problema similar que identificamos se relaciona con un número excesivo de actualizaciones completas del inventario (entre 100 y 150 por segundo). La base de datos no tiene tiempo suficiente para limpiar sus archivos principales (AUTOVACUUM), y la única manera de recuperar espacio es realizar un FULL VACUUM, que bloquea la tabla (y, por lo tanto, bloquea otras conexiones para darle tiempo a limpiar). Normalmente, el bloqueo exclusivo no debería durar más de unos segundos, pero durante este tiempo no se puede escribir en la tabla.

Mientras espera encontrar lo que está generando inventarios completos innecesarios, puede configurar un trabajo cron con VACUUM FULL.

Atentamente,

Denis

Nota: para ser más precisos, el problema VACUUM no surge para la tabla Hosts en sí, sino para la tabla TOAST correspondiente que almacena los blobs bjson y TEXT.

[dcardón]

En el otro caso, el número excesivo de actualizaciones de inventario se debe a un paquete cuyo archivo de control tiene un valor incorrecto para el parámetro `forced_install_on`. ¿Usaste este parámetro en tu archivo de control?

[Sofía]

De acuerdo, en el otro caso, la cantidad excesiva de actualizaciones de inventario se debe a un paquete con un archivo de control que tiene un valor incorrecto para el parámetro forced_install_on. ¿Utilizaste este parámetro en tu archivo de control?

Buen día,
No, nunca usamos este parámetro porque aún no sabemos exactamente para qué sirve.

[Stephane B]

Hola, parece que nadie ha usado aún el parámetro "forced_install_on" en nuestros archivos de control de paquetes. Con unos 200 paquetes, revisarlos uno por uno sería tedioso... ¿Existe alguna forma, alguna consulta, que nos permita encontrarlo rápidamente? (Una búsqueda con grep en el directorio de paquetes no tuvo ningún efecto, como era de esperar...).
Edité los paquetes modificados más recientemente (en el último mes) y no encontré ningún valor para este parámetro. (Algunos paquetes no lo mencionan; en la mayoría, aparece como sin valor).

[dcardón]

Hola stephaneB,

el problema no necesariamente se debe al parámetro en cuestión. Simplemente, por alguna razón, el motor de cálculo de dependencias local está fallando y reiniciando un inventario para verificar sus parámetros de filtrado de paquetes. El bucle de `update-status` genera el problema que estás experimentando.

Necesitarías encontrar las máquinas que están causando el problema (busca máquinas cuya fecha de "última conexión" sea siempre dentro de los últimos minutos), luego reiniciar el servicio localmente en modo de depuración, o bien, eliminar todos los paquetes de la máquina en cuestión y agregarlos uno por uno para encontrar el que causa el problema. Una vez que encuentres el paquete, puedes publicar el archivo de control en este hilo para ver cuál es el problema.

Saludos,

Denis

[vcardón]

Hola, parece que nadie ha usado todavía el parámetro "forced_install_on" en nuestros archivos de control de paquetes. Con unos 200 paquetes, va a ser tedioso revisarlos uno por uno... ¿Hay alguna forma, una consulta, que nos permita encontrarlo rápidamente? (Un grep en el directorio del paquete no tiene efecto, como era de esperar...).
Edité los paquetes más recientes modificados en el último mes y no encontré un valor para este parámetro. (Algunos paquetes no lo mencionan, y en la mayoría aparece como sin valor).

Hola stephaneB,

Podemos brindarle soporte telefónico más interactivo con un contrato de soporte. Es muy económico y, al parecer, podría beneficiarse de la oferta de Agrupación de Software MESR y de la promoción, válida hasta finales de 2020. Contáctenos a través de nuestro sitio web https://www.tranquil.it/gerer-parc-info ... re-apoyo Si esa opción te interesa.

Atentamente.

Vicente