Page 1 sur 1

Saturation HD du à la création intempestive de fichiers postgresql

Publié : 07 janv. 2020 - 20:57
par Sophie
Bonjour,
Tout d'abord meilleurs vœux pour cette nouvelle année.

Depuis lundi, suite à 15 jours de vacances, notre serveur wapt tombe en carafe en saturant le HD de fichiers postgresql dans /var/lib/postgresql/9.6/main/base/16385/
avec des fichiers atteignant la taille de 1048576 Kb jusqu'à saturation du HD.

Ci-après la configuration de notre serveur virtuel :
  • Version wapt 1.7.4.6165
  • OS Debian 4.9
  • 4 Go RAM
  • 40 Go HD
Nous avons environ 1800 machines dans notre inventaire.

Lors du démarrage de la console, le message d'erreur ci-après s'affiche :
Unable to get hosts list : Error on server:
OperationalError('could not connect to the server: No such file or directory\n\tls the server running locally and accepting \n\tconnections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432."?\n',)


Ci après le résultat de service waptserver status
waptserver.service - WAPT Server startup script
Loaded: loaded (/usr/lib/systemd/system/waptserver.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2020-01-07 12:17:02 CET; 8h ago
Main PID: 664 (python)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/waptserver.service
└─664 /opt/wapt/bin/python /opt/wapt/waptserver/server.py

janv. 07 20:40:36 srv-wapt15 python[664]: conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
janv. 07 20:40:36 srv-wapt15 python[664]: OperationalError: could not connect to server: No such file or directory
janv. 07 20:40:36 srv-wapt15 python[664]: Is the server running locally and accepting
janv. 07 20:40:36 srv-wapt15 python[664]: connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
janv. 07 20:40:36 srv-wapt15 python[664]: , instance:
janv. 07 20:40:36 srv-wapt15 python[664]: 2020-01-07 20:40:36,449 CRITICAL SocketIO pong error for uuid 4C4C4544-004B-3710-8059-B1C04F4D3632 and sid b270e
janv. 07 20:40:36 srv-wapt15 python[664]: File "/opt/wapt/waptserver/server_socketio.py", line 278, in on_wapt_pong
janv. 07 20:40:36 srv-wapt15 python[664]: with wapt_db.atomic() as trans:
janv. 07 20:40:36 srv-wapt15 python[664]: File "/opt/wapt/lib/python2.7/site-packages/peewee.py", line 3533, in __enter__
janv. 07 20:40:36 srv-wapt15 python[664]: return self._helper.__enter__()


La restauration de cette VM à un état antérieur ne résout pas le problème : au bout de quelques minutes le phénomène se reproduit.

Des idées svp ?
Merci de vos retours

Re: Saturation HD du à la création intempestive de fichiers postgresql

Publié : 08 janv. 2020 - 11:38
par dcardon
Bonjour Sophie,
Sophie a écrit : 07 janv. 2020 - 20:57 Tout d'abord meilleurs vœux pour cette nouvelle année.

Depuis lundi, suite à 15 jours de vacances, notre serveur wapt tombe en carafe en saturant le HD de fichiers postgresql dans /var/lib/postgresql/9.6/main/base/16385/
avec des fichiers atteignant la taille de 1048576 Kb jusqu'à saturation du HD.

Ci-après la configuration de notre serveur virtuel :
  • Version wapt 1.7.4.6165
  • OS Debian 4.9
  • 4 Go RAM
  • 40 Go HD
Nous avons environ 1800 machines dans notre inventaire.

Lors du démarrage de la console, le message d'erreur ci-après s'affiche :
Unable to get hosts list : Error on server:
OperationalError('could not connect to the server: No such file or directory\n\tls the server running locally and accepting \n\tconnections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432."?\n',)
Il semble que la taille des inventaires JSON (requêtes local WMI + dmidecode sur les postes en local) ont fortement augmenté, et la base PostgreSQL ne gère pas assez rapidement le VACUUM. Est ce que vous avez des messages comme ci-dessous dans vos logs?

Code : Tout sélectionner

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
Vous pouvez faire un peu d'espace sur la machine pour permettre de relancer Postgres (mais pas le service WAPT dans un premier temps) et puis faire un VACUUM FULL sur la base Wapt pour vérifier si ça libère bien l'espace.

Code : Tout sélectionner

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


Ca ne permet pas de résoudre le soucis, mais au moins de valider que c'est bien ça. On a un client qui a un soucis similaire on est entrain de débugger avec lui. Il y a probablement une mise à jour Windows qui a changé quelque chose récemment dans les requêtes WMI.

Cordialement,

Denis

Re: Saturation HD du à la création intempestive de fichiers postgresql

Publié : 08 janv. 2020 - 14:31
par dcardon
reBonjour,

Juste à titre d'information, est ce que vous auriez pas un paquet d'audit qui trigger un WAPT.register() régulièrement?

Cordialement,

Denis

Re: Saturation HD du à la création intempestive de fichiers postgresql

Publié : 08 janv. 2020 - 15:59
par stephaneB
Bonjour,
Merci pour cette réponse (je suis un collègue de Sophie qui a ouvert le sujet).

Nous avons effectivement des log pgsql de ce type:
" les points de vérification (checkpoints) arrivent trop fréquemment
(toutes les 25 secondes)
...Considérez l'augmentation du paramètre « max_wal_size »."

Le vacuum a bien permis de récupérer l'espace et redémarrer les services.

Est il judicieux de planifier un cron de psql vaccum en attendant ?

Concernant un éventuel paquet contenant un wapt.register(), je ne pense pas mais je vais chercher.

Re: Saturation HD du à la création intempestive de fichiers postgresql

Publié : 08 janv. 2020 - 16:40
par dcardon
Bonjour StephaneB,
stephaneB a écrit : 08 janv. 2020 - 15:59 Bonjour,
Merci pour cette réponse (je suis un collègue de Sophie qui a ouvert le sujet).

Nous avons effectivement des log pgsql de ce type:
" les points de vérification (checkpoints) arrivent trop fréquemment
(toutes les 25 secondes)
...Considérez l'augmentation du paramètre « max_wal_size »."

Le vacuum a bien permis de récupérer l'espace et redémarrer les services.

Est il judicieux de planifier un cron de psql vaccum en attendant ?

Concernant un éventuel paquet contenant un wapt.register(), je ne pense pas mais je vais chercher.
Le problème similaire que l'on a identifié est lié à un trop grand nombre de mise à jour complète d'inventaire (du genre 100 à 150 à la seconde) et la base de données n'a pas le temps de nettoyer ses fichiers de base (AUTOVACUUM) et la seule manière de récupérer l'espace est de faire un VACUUM FULL qui lock la table (et donc bloque les autres connexions histoire de lui laisser le temps de faire le ménage). Normalemnt le lock exclusif ne devrait pas durer plus que quelques secondes, mais pendant ce temps là aucune écriture pourront avoir lieu sur la table.

En attendant de trouver ce qui génère des inventaires complets inutiles vous pouvez mettre en place un cron avec le VACUUM FULL.

Cordialement,

Denis

Note : pour être plus précis, le soucis de VACUUM ne se pose pas pour la table Hosts en elle même mais pour la table TOAST correspondante qui stocke les blob bjson est TEXT.

Re: Saturation HD du à la création intempestive de fichiers postgresql

Publié : 08 janv. 2020 - 18:04
par dcardon
Bon, dans l'autre cas le trop grand nombre de remonté d'inventaire est du à un paquet avec un fichier de control qui a une valeur incorrecte pour le paramètre forced_install_on. Est ce que vous avez utilisé ce paramètre dans votre fichier de contrôle?

Re: Saturation HD du à la création intempestive de fichiers postgresql

Publié : 10 janv. 2020 - 15:54
par Sophie
dcardon a écrit : 08 janv. 2020 - 18:04 Bon, dans l'autre cas le trop grand nombre de remonté d'inventaire est du à un paquet avec un fichier de control qui a une valeur incorrecte pour le paramètre forced_install_on. Est ce que vous avez utilisé ce paramètre dans votre fichier de contrôle?
Bonjour,
Non nous n'utilisons jamais ce paramètre ne sachant pour l'instant à quoi il sert exactement.

Re: Saturation HD du à la création intempestive de fichiers postgresql

Publié : 13 janv. 2020 - 08:38
par stephaneB
Bonjour, à priori personne n'a jusqu'à présent utilisé ce paramètre "forced_install_on" dans les fichiers de contrôle de nos paquets. Ayant environ 200 paquets, il va être fastidieux de les vérifier un par un... Y'a t'il un moyen, une requête, qui nous permettrait de le retrouver rapidement ? ( un grep dans le dossier des paquets est sans effet on s'en doutait...).
j'ai édité les derniers paquets modifié depuis moins d'un mois et je n'ai pas trouvé de valeur pour ce paramètre. (certains paquet ne le mentionnent pas, sur la plupart il est mentionné sans valeur).

Re: Saturation HD du à la création intempestive de fichiers postgresql

Publié : 14 janv. 2020 - 10:16
par dcardon
Bonjour stephaneB,

le problème ne vient pas forcément du paramètre en question. C'est juste que pour une raison quelconque le moteur local de calcul de dépendance bug sur quelque chose et relance un inventaire pour vérifier ses paramètres de filtrage de paquet. Le lancement de update-status en boucle génère alors le problème rencontré.

Il vous faudrait trouver les machines qui pose problème (voir les machines qui ont une date de "dernière connexion" qui est toujours dans la dernière minutes), puis relancer le service en local en mode debug, ou sinon supprimer tous les paquets sur la machine en question et les rajouter les un après les autres pour trouver celui qui génère le soucis. Une fois le paquet trouver, vous pouvez renvoyer le fichier de control dans ce thread pour voir ce qui pose soucis.

Cordialement,

Denis

Re: Saturation HD du à la création intempestive de fichiers postgresql

Publié : 14 janv. 2020 - 10:46
par vcardon
stephaneB a écrit : 13 janv. 2020 - 08:38 Bonjour, à priori personne n'a jusqu'à présent utilisé ce paramètre "forced_install_on" dans les fichiers de contrôle de nos paquets. Ayant environ 200 paquets, il va être fastidieux de les vérifier un par un... Y'a t'il un moyen, une requête, qui nous permettrait de le retrouver rapidement ? ( un grep dans le dossier des paquets est sans effet on s'en doutait...).
j'ai édité les derniers paquets modifié depuis moins d'un mois et je n'ai pas trouvé de valeur pour ce paramètre. (certains paquet ne le mentionnent pas, sur la plupart il est mentionné sans valeur).
Bonjour stephaneB,

On peut vous apporter un appui plus interactif par téléphone avec un contrat de support. C'est très abordable et il semblerait que vous puissiez bénéficier de l'offre Groupement Logiciel du MESR et de la promotion valable jusqu'à fin 2020. Contactez nous via notre site https://www.tranquil.it/gerer-parc-info ... re-support si l'option vous intéresse.

Cordialement.

Vincent