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

Question about WAPT Server / Requêtes et aides autour du serveur Wapt
Règles du forum
Règles du forum
* English support on www.reddit.com/r/wapt
* Le support en français se fait sur ce forum
* Merci de préfixer le titre du thread par [RESOLU] s'il est résolu.
* Préciser version de WAPT installée ( 1.3.13 / 1.5 / 1.7.4)
* Préciser OS du serveur (Linux / Windows) et version (Debian Stretch/Buster - CentOS 7 - Windows Server 2012/2016/2019)
* Préciser OS de la machine d'administration/création des paquets (Windows 7 / 10)
Répondre
Sophie
Messages : 2
Inscription : 26 avr. 2018 - 12:22

07 janv. 2020 - 20:57

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
Avatar de l’utilisateur
dcardon
Expert WAPT
Messages : 393
Inscription : 18 juin 2014 - 09:58
Localisation : Nantes
Contact :

08 janv. 2020 - 11:38

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
Denis Cardon - Tranquil IT Systems
Communiquez autour de vous sur WAPT! Envoyez nous vos url de blog et d'articles dans la catégorie votre avis du forum, nous les mettrons en avant sur le site WAPT
Avatar de l’utilisateur
dcardon
Expert WAPT
Messages : 393
Inscription : 18 juin 2014 - 09:58
Localisation : Nantes
Contact :

08 janv. 2020 - 14:31

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
Denis Cardon - Tranquil IT Systems
Communiquez autour de vous sur WAPT! Envoyez nous vos url de blog et d'articles dans la catégorie votre avis du forum, nous les mettrons en avant sur le site WAPT
stephaneB
Messages : 2
Inscription : 08 janv. 2020 - 15:48

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.
Avatar de l’utilisateur
dcardon
Expert WAPT
Messages : 393
Inscription : 18 juin 2014 - 09:58
Localisation : Nantes
Contact :

08 janv. 2020 - 16:40

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.
Denis Cardon - Tranquil IT Systems
Communiquez autour de vous sur WAPT! Envoyez nous vos url de blog et d'articles dans la catégorie votre avis du forum, nous les mettrons en avant sur le site WAPT
Avatar de l’utilisateur
dcardon
Expert WAPT
Messages : 393
Inscription : 18 juin 2014 - 09:58
Localisation : Nantes
Contact :

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?
Denis Cardon - Tranquil IT Systems
Communiquez autour de vous sur WAPT! Envoyez nous vos url de blog et d'articles dans la catégorie votre avis du forum, nous les mettrons en avant sur le site WAPT
Sophie
Messages : 2
Inscription : 26 avr. 2018 - 12:22

10 janv. 2020 - 15:54

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.
stephaneB
Messages : 2
Inscription : 08 janv. 2020 - 15:48

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).
Avatar de l’utilisateur
dcardon
Expert WAPT
Messages : 393
Inscription : 18 juin 2014 - 09:58
Localisation : Nantes
Contact :

14 janv. 2020 - 10:16

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
Denis Cardon - Tranquil IT Systems
Communiquez autour de vous sur WAPT! Envoyez nous vos url de blog et d'articles dans la catégorie votre avis du forum, nous les mettrons en avant sur le site WAPT
Avatar de l’utilisateur
vcardon
Expert WAPT
Messages : 119
Inscription : 06 oct. 2017 - 22:55
Localisation : Nantes, FR

14 janv. 2020 - 10:46

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
Vincent CARDON
Tranquil IT
Répondre