Timeout aléatoire

[RNF-SI]

Bonjour,

Un utilisateur à tenté à plusieurs reprises d'importer un fichier de 12000 observations.
Il a obtenu un timeout à chaque fois, mais pas toujours à la même étape.
J'ai tenté de mon côté et ait réussi sans problème à importer ses données.
Puis j'ai retenté par acquis de conscience, et ait également eu des timeout à plusieurs reprises.
Pourtant 12000 observations ne me semble pas un trop gros fichier...

Côté logs, j'ai ça dans geonature.log :

[2023-10-20 12:22:28 +0200] [400707] [CRITICAL] WORKER TIMEOUT (pid:1183957)
[2023-10-20 12:22:28 +0200] [1183957] [INFO] Worker exiting (pid: 1183957)
[2023-10-20 12:22:29 +0200] [400707] [ERROR] Worker (pid:1183957) was sent SIGKILL! Perhaps out of memory?
[2023-10-20 12:22:29 +0200] [1193742] [INFO] Booting worker with pid: 1193742
[2023-10-20 12:22:59 +0200] [400707] [CRITICAL] WORKER TIMEOUT (pid:1183725)
[2023-10-20 12:22:59 +0200] [1183725] [INFO] Worker exiting (pid: 1183725)
[2023-10-20 12:23:00 +0200] [400707] [ERROR] Worker (pid:1183725) was sent SIGKILL! Perhaps out of memory?
[2023-10-20 12:23:00 +0200] [1193979] [INFO] Booting worker with pid: 1193979

J'ai pourtant suivi l'état du serveur, et j'ai jamais dépassé 1.8 GB/8GB de RAM, et environ 30% de CPU.
Je n'ai pas de log sur cet tâche sur geonature-worker.log.

[camillemonchicourt]

Même question que d'habitude. 😀
Quelle version de GN et du module ?

[RNF-SI]

Désolé... GN 2.13.2 et IMPORT 2.2.3

[camillemonchicourt]

Je ne vois pas car avec les versions 2.2, il y a eu d'importantes améliorations des performances et de la consommation de la RAM et nous avons testé d'importer des fichiers avec plus de 300.000 observations, avec succès.

[bouttier]

Pour voir si c’est à cause de la RAM que le processus a été tué, regarder le résultat de la commande dmesg

[Vottana]

Geonature 2.12.3
Import 2.1.0
Debian GNU/Linux 11 Bullseye

Bonjour à tous,
je me permets de faire suite à ce post car j'ai le même problème, mais avec des versions plus ancienne de GN et du module Import.
Impossible d'importer un fichier de 12000 données. Il fait 11 Mo. Je l'ai découpé en plus petit fichier mais même un fichier de 4.7 Mo aboutit à un timeout.
Dans le log de geonature :
[2024-09-03 15:29:42 +0200] [2859525] [CRITICAL] WORKER TIMEOUT (pid:2065728) [2024-09-03 15:29:43 +0200] [2859525] [WARNING] Worker with pid 2065728 was terminated due to signal 9 [2024-09-03 15:29:43 +0200] [2185539] [INFO] Booting worker with pid: 2185539 [2024-09-03 15:33:28 +0200] [2859525] [CRITICAL] WORKER TIMEOUT (pid:2065730) [2024-09-03 15:33:29 +0200] [2859525] [WARNING] Worker with pid 2065730 was terminated due to signal 9 [2024-09-03 15:33:29 +0200] [2185608] [INFO] Booting worker with pid: 2185608 [2024-09-03 15:45:28 +0200] [2859525] [CRITICAL] WORKER TIMEOUT (pid:2016376) [2024-09-03 15:45:29 +0200] [2859525] [WARNING] Worker with pid 2016376 was terminated due to signal 9 [2024-09-03 15:45:29 +0200] [2186075] [INFO] Booting worker with pid: 2186075 [2024-09-03 15:49:19 +0200] [2859525] [CRITICAL] WORKER TIMEOUT (pid:2185539) [2024-09-03 15:49:20 +0200] [2859525] [WARNING] Worker with pid 2185539 was terminated due to signal 9 [2024-09-03 15:49:20 +0200] [2186148] [INFO] Booting worker with pid: 2186148 [2024-09-03 15:53:44 +0200] [2859525] [CRITICAL] WORKER TIMEOUT (pid:2186075) [2024-09-03 15:53:45 +0200] [2859525] [WARNING] Worker with pid 2186075 was terminated due to signal 9 [2024-09-03 15:53:45 +0200] [2186219] [INFO] Booting worker with pid: 2186219 [2024-09-03 16:00:23 +0200] [2859525] [CRITICAL] WORKER TIMEOUT (pid:2186219) [2024-09-03 16:00:24 +0200] [2859525] [WARNING] Worker with pid 2186219 was terminated due to signal 9 [2024-09-03 16:00:24 +0200] [2186325] [INFO] Booting worker with pid: 2186325 [2024-09-03 16:04:30 +0200] [2859525] [INFO] Handling signal: term [2024-09-03 16:04:30 +0200] [2065732] [INFO] Worker exiting (pid: 2065732) [2024-09-03 16:04:30 +0200] [2185608] [INFO] Worker exiting (pid: 2185608) [2024-09-03 16:04:30 +0200] [2186148] [INFO] Worker exiting (pid: 2186148) [2024-09-03 16:04:30 +0200] [2186325] [INFO] Worker exiting (pid: 2186325) [2024-09-03 16:04:34 +0200] [2859525] [INFO] Shutting down: Master [2024-09-03 16:04:34 +0200] [2186407] [INFO] Starting gunicorn 20.1.0 [2024-09-03 16:04:34 +0200] [2186407] [INFO] Listening at: http://127.0.0.1:8000 (2186407) [2024-09-03 16:04:34 +0200] [2186407] [INFO] Using worker: sync [2024-09-03 16:04:34 +0200] [2186408] [INFO] Booting worker with pid: 2186408 [2024-09-03 16:04:35 +0200] [2186409] [INFO] Booting worker with pid: 2186409 [2024-09-03 16:04:35 +0200] [2186410] [INFO] Booting worker with pid: 2186410 [2024-09-03 16:04:35 +0200] [2186411] [INFO] Booting worker with pid: 2186411 [2024-09-03 16:05:59 +0200] [2186407] [CRITICAL] WORKER TIMEOUT (pid:2186410) [2024-09-03 16:06:00 +0200] [2186407] [WARNING] Worker with pid 2186410 was terminated due to signal 9 [2024-09-03 16:06:00 +0200] [2186569] [INFO] Booting worker with pid: 2186569

J'ai fait un restart de Geonature et du worker mais le problème persiste.
Dans le log du workers, je n'ai rien de noté.

@RNF-SI Est-ce de votre côté vous avez pu résoudre le problème ?
@bouttier

Pour voir si c’est à cause de la RAM que le processus a été tué, regarder le résultat de la commande dmesg

J'ai tapé la commande dmesg mais le résultat est incompréhensible pour moi...

Est-ce que vous auriez d'autres pistes ?

Merci d'avance pour vos retours !

[gildeluermoz]

Tu as possiblement un pb de ram qui sature et oom killer tue postgres qui consomme trop de ram.
Si tu es sur un VPS, il est possible qu'il n'y ait pas d'espace de swap. Fais un free -h et regarde dans la partie Echange s'il y a de l'espace pour le swap. Si tu n'as que des zéro, c'est qu'il n'y a pas de swap : classique sur des VPS OVH.

Dans ce cas, je te recommande de créer un fichier dédié au swap, à la manière de windows. Suis ce tuto :https://www.it-connect.fr/comment-ajouter-de-lespace-de-swap-sur-gnu-linux-debian-10/
J'ai fait ça sur tous mes VPS et je n'ai plus de plantage de ce genre.

Regarde tes logs postgres : /var/log/postgresql pour savoir si c'est lui qui plante
Tu as redémarré les services geonature mais je te conseille aussi de redémarrer le service postgres car il est peut-être instable ou planté. Puis les services geonature, TH et UH

[Vottana]

Bonjour, merci pour ton message.
La commande free -h me renvoie ça :
total utilisé libre partagé tamp/cache disponible
Mem: 31Gi 3,2Gi 2,2Gi 8,2Gi 25Gi 19Gi
Partition d'échange: 974Mi 864Mi 110Mi

Donc apparemment j'ai bien cet espace d'échange mais est-ce qu'il est trop petit ?

Dans le log de postgres j'ai ça :
2024-09-03 16:06:00.518 CEST [2186553] geonatadmin@geonature2db LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant 2024-09-03 16:06:00.518 CEST [2186553] geonatadmin@geonature2db LOG: fin de fichier (EOF) inattendue de la connexion du client avec une transaction ouverte 2024-09-03 16:09:41.068 CEST [2186641] [inconnu]@[inconnu] FATAL: protocole frontal 0.0 non supporté : le serveur supporte de 2.0 à 3.0 2024-09-03 16:09:41.342 CEST [2186642] [inconnu]@[inconnu] FATAL: protocole frontal 255.255 non supporté : le serveur supporte de 2.0 à 3.0 2024-09-03 16:09:41.621 CEST [2186643] [inconnu]@[inconnu] FATAL: aucun nom d'utilisateur PostgreSQL n'a été spécifié dans le paquet de démarrage 2024-09-03 16:22:38.108 CEST [2186559] geonatadmin@geonature2db LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant 2024-09-03 16:22:38.108 CEST [2186559] geonatadmin@geonature2db LOG: fin de fichier (EOF) inattendue de la connexion du client avec une transaction ouverte 2024-09-03 16:23:38.271 CEST [2186822] geonatadmin@geonature2db LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant 2024-09-03 16:23:38.271 CEST [2186822] geonatadmin@geonature2db LOG: fin de fichier (EOF) inattendue de la connexion du client avec une transaction ouverte
Mais je ne sais pas vraiment ce que ça veut dire, Postgres n'a pas l'air d'avoir planté.

Je vais redémarrer Postgres, mais quand tu dis

Puis les services geonature, TH et UH

Ça veut dire quoi TH et UH ? (je n'ai pas trouvé sur internet...)

[Vottana]

@gildeluermoz
J'ai suivi le tuto pour le swap, et oh miracle, je n'ai pas eu de time out cette fois !
Merciiiiii !
Mais je suis toujours preneuse de l'explication pour le TH et UH :)

[gildeluermoz]

TH = TaxHub et UH = UsersHub

Oui tu avais bien un espace de swap et donc la manip du tuto n'était pas indispensable. Je suis étonné que ce soit ça qui ait résolu ton soucis, d'autant que ton serveur a beaucoup de RAM : 32 Go.
Si tu as redémarré postgresql, je pense que ce serait plutôt ça qui a résolu ton souci.

En fait quand tu redémarres postgresql, ça affecte le fonctionnement des services GeoNature, UsersHub et Taxhub. Mais je crois que depuis qq versions, un restart de postgres doit provoquer le redémarrage de GeoNature de TaxHub et de UsersHub. Pour être sûr, chaque fois que je redémarre Postgresql, je redémarrage les services GeoNature, UH et TH.

Par ailleurs, je te recommande de faire les mises à jour de ton GN et de ses modules. Le module d'import a reçu des améliorations de performances dans les dernières versions, notamment la 2.2.3

Il faudrait que les dev du module te répondent pour savoir s'il est normal d'avoir un TIMEOUT avec ta version 2.1.0 et un gros fichier car depuis la version 2 du module, c'est Celery qui bosse en tache de fond et il ne devrait plus y avoir de TIMEOUT. Mais je ne suis sur de rien sur ce point.

[Vottana]

Ah, TH et UH, je croyais que c'était des termes d'administration serveur....
J'avais fait le restart de postgres, puis de Geonat, puis du worker. Mais j'avais toujours le timeout.
C'est après la manip du swap que j'ai pu importer le fichier.

La mise à jour de GN et des modules est prévue en 2025. Mais j'ai un peu des sueurs froides rien que d'y penser.

[camillemonchicourt]

C'est plus de mettre à jour GN de sa version 12 à 14, que de configurer le swap d'un serveur... :-)