Votre avis ? Necessité De Fermer Une Session Net.fhttp ?

[Dgille]

Bonjour à  tous, j'avais posé la question dans le forum "pour les nuls", mais sans réponse, je me permets de reposer la question dans le bistrot... pour les pros du lua....

 

Dans tous les exemples du forum, lors de l'utilisation de l'api net.Fhttp permettant de contacter nos objets connectés préférés (eco device, sonos, netatmo,etc), je ne vois jamais de code de fermeture de la connexion http.

Dans tous les autres langage de programme, c'est le cas, pour éviter de consommer un descripteur de connexion et de provoquer in fine le blocage de linux.

 

Comme nos HC2 ne sont pas des modèles de stabilité, et les problèmes de mémoire semblant être éliminés(ou réduits)  dans les dernières versions, je me demande si le fait de ne pas fermer ces connexions ne consommerait pas les handles disponibles...

 

merci pour vos réponses !

[Lazer]

PS : tu ne peux pas poster de nouveau sujet dans la section pour les Nuls, surement pour ça que tu n'as pas eu de réponse.... d'ailleurs je viens d'y trouver ton sujet, que je vais supprimer car tu as créé un nouveau topic.

 

 

Idéalement, il faut fermer la connexion Net.FHTTP, mais c'est vrai qu'on ne le fait pas systématiquement.... car le Garbage Collector du LUA fait le ménage à  intervalle régulier.

Si tu veux forcer la libération de mémoire, tu peux affecter nil à  la variable :

local HC2 = Net.FHttp("127.0.0.1", 11111)

-- blah blah blah

HC2 = nil

[Lazer]

Concernant la stabilité, j'ai des VD qui tournent en boucle infinie, et qui ne plantent pas, que je libère la connexion HTTP ou pas (j'ai testé dans les 2 cas).

Donc je ne pense pas que cela ait un impact sur la stabilité de la box.

 

Comme je l'avais déjà  précisé ailleurs, notre code LUA est exécuté par l'interpréteur LUA, qui est une librairie standard, non développée par Fibaro. Et jusqu'à  preuve du contraire, le LUA est un langage robuste, avec un garbage collecteur efficace, qui rattrape nos erreurs de programmation.

Les instabilités de la HC2 ne sont pas dues à  nos quelques centaines de lignes en LUA, mais à  ce qu'à  développé FIbaro. Certainement des fuites mémoires non maitrisées.... auxquelles nous ne pouvons rien faire.

[Dgille]

Merci pour ta réponse, les connexions TCP sous jacentes finissent pas tomber, c'est entendu.  De mémoire, c'est 2 heures sur un pile TCP/IP classique. Je ne sais pas à  quelle interval le GC du lua entre en action.

Théoriquement, si un grand nombre de connexions sont établies dans un délai court, sans fermeture, on peut saturer l'OS.

Je vais tester la fermeture de la socket pour voir si cela améliore la stabilité de la box.

 

Sur le fond, je suis d'accord, Fibaro ne fait pas son boulot correctement, mais mes derniers plantages sont survenus avec mon de 20% de mémoire (user, hors buffer) utilisée. J'explore donc toutes les pistes....

 

 

Encore merci.

[Lazer]

j'ai eu des plantages avec plus de 50 % de RAM libre.

Et les plantages peuvent arriver sur tout  : VD, Scène, voire process principal (HC Serveur), et pourtant tout cela est dans des process différents au niveau OS LInux.

Les crash que j'ai observé sont des core dump, très aléatoire (entre 3h après le reboot de la box, et plusieurs mois après le reboot) donc ce n'est pas une conséquence d'une grande utilisation de la RAM, sinon le process ne planterait pas et la RAM utilisée augmenterait, de même que le swap (paging space).

 

A noter de plus que l'utilisation RAM d'un process de type VD, Scène, ou Plugin, augmente rapidemment pour atteindre son régime de croisière, puis se stabilise autour d'une valeur nominale (modérée), qui varie légèrement en fonction du déclenchement du garbage collector.

Le Garbage Collector est très bien décrit dans les docs LUA, je ne me souviens plus bien de l’intervalle, mais tu peux retrouver l'info facilement, et même le déclencher manuellement si tu veux.

-- Appeler manuellement le garbage collector
collectgarbage("collect")

Tu peux aussi surveiller la consommation mémoire :

-- getCurrentMemoryUsed() return total current memory in use by lua interpreter in kilobytes
-- collectgarbage("count") permet de vérifier la "gestion de la mémoire".
-- Attention Le Mainloop et les boutons sont des Sandbox (bacs à  sable), le collectgarbage("count") retourne uniquement la mémoire utilisée par le script dans le sandbox.
getCurrentMemoryUsed = (function()
	return collectgarbage("count");
end)

Si tu veux aller plus loin, root ta box, surveille les process et la RAM globale du système, et tu verras que tu ne peux rien faire.

C'est codé avec les pieds, on est obligé de faire avec.

 

J'ai contourné le problème avec un watchdog (dans ma signature) qui relance les VD/Scènes quand ils plantent à  tord (core dump) ou à  raison (erreur de syntaxe LUA).

[Dgille]

Merci pour ces infos, effectivement, en parcourant le forum, on a l'impression que les fuites mémoires sont responsables de tout nos problèmes, ce qui n'est pas le cas, en tout cas, de ma petite expérience sur HC2.

Je suis d'accord sur le fait qu'on ne règlera pas les problèmes àla place de Fibaro, l'idée est plutôt de trouver des solutions de contournement (je vais regarder ton watchdog) et/ou des bonnes pratiques (fermer les sockets), qui permettent d'obtenir un peut plus de stabilité.

Je pense que l'on en reparlera dans quelques temps

[Lazer]

je t'avoue que j'ai jamais pensé àsurveiller les sockets.

J'ai étudié l'utilisation mémoire des process, ainsi que le nombre de thread (plusieurs centaines, en augmentation continue pour un seul process, làaussi il y a un problème)

Ca serait intéressant que j'étudie également les sockets.... Mais la pile TCP/IP est censée les fermer comme tu le fais remarquer.

[Dgille]

Oui, mais le GC du lua fera le ménage après un timeout tcp, donc imaginons de multiples connexions http (sur tcp) jamais fermées, le GC interviendra après le timeout,en ajoutant son propre délai d'activation.

Il n'est pas non plus impossible que Fibaro ait modifié les paramétres du noyau linux pour limiter la conso mémoire, je ne suis pas root sur ma box, mais c'est un point àvérifier.

Tu sais aussi que le nb total de descripteurs est partagé avec les fichiers, du point de vu de linux, pas de différence entre un handle de fichier et un handle de socket.

Tout çàme laisse penser que les plantages de process et coredump associés sont peut être la conséquence de cette surconsommation.

Ce n'est qu'une hypothèse, mais ma petite expérience linux me fait penser àcela.

[Lazer]

Limites systèmes :

root@fghc2:~# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Je viens de comparer avec une installation par défaut de Debian 6, c'est exactement pareil, donc FIbaro n'a rien modifié.

 

Effectivement, je pense que tu as mis le doit sur un point intéressant...; open files = 1024

et regarde ça :

root@fghc2:~# netstat -a | grep TIME_WAIT | wc -l
1101

Faut que j’identifie les sockets pour voir par quels process ils sont ouverts....

[Dgille]

Oui, pas normal, sur une centos 7, gros serveur d'application chez moi, le netstat me donne moins de 50 sockets ouvertes. Pas de raison qu'une HC2 en ait besoin d'autant....

[Dgille]

Peux tu essayer un ulimit -Ha pour avoir les valeurs max ?

merci

[Lazer]

root@fghc2:~# ulimit -Ha
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Apparemment, les TIME_WAIT ne sont pas un souci, on reste sur des valeurs assez faibles : http://vincent.bernat.im/fr/blog/2014-tcp-time-wait-state-linux.html

Il semble que les TIME_WAIT sont supprimés au bout de 1 à4 minutes, donc vu que j'ai plusieurs VD qui font plusieurs Net.FHTTP(), ce n'est pas aberrant.

[Dgille]

J'étais sur le même article.

Mais 1100 connexions "en fin de vie" sur 4 minutes max , cela indique quand même une forte activé sur les sockets et les limites hautes sont toujours à  1024, je suis à  4096 sur une centos.

 

il faudrait vérifier les  ESTABLISHED, pas impossible que l'on frole les 1024 régulièrement.

[Lazer]

Non les ESTABLISHED sont bien fermées systématiquement.

J'ai plus de ESTABLISHED dues àmes connexions SSH qu'aux connexions Web, c'est dire ! Au moins les sockets sont bien fermées àchaque fois qu'on sort de la boucle LUA.

[Lazer]

J'ajoute que Fibaro utilise lui-même massivement l'API http pour ses propres besoins.... donc entre ça et mes propres scripts LUA, en fin de compte il n'est pas étonnant d'avoir autant de TIME-WAIT, qui signifie que les sockets sont bien fermées.

[Dgille]

oui, d'où le grand nombre de sockets en fin vie. Donc provisoirement, ce n'est pas la source principale de nos problèmes. C'est à  la fois rassurant (pour la bonne gestion des sockets) et inquiétant (sur la source des plantages).

 

Merci pour ton aide

[Lazer]

Si j'ai le temps ce soir, j'essaierai de monter une maquette avec ma HC2 de test et mon serveur Xeon en face.... test de requêtes http massives dans un sens, puis dans l'autre, afin de voir si on arrive àcrasher la HC2.

[Lazer]

Test violent depuis un Linux : une requête http toutes les 30ms vers /api/devices :

while [ 1 ]
do
  curl --silent -u admin:password http://192.168.x.y/api/devices > /dev/null
done

A la louche, ça fait donc environ 30 requêtes à  seconde.

J'ai laissé tourné environ 10 minutes..... soit plus de 18000 requêtes HTTP !

Sur la HC2, le nombre de connexions en TIME_WAIT monte assez vite, puis se stabilise :

root@fghc2:~# netstat -a | grep TIME_WAIT | wc -l
4188
root@fghc2:~# netstat -a | grep TIME_WAIT | wc -l
4232
root@fghc2:~# netstat -a | grep TIME_WAIT | wc -l
4075
root@fghc2:~# netstat -a | grep TIME_WAIT | wc -l
4622
root@fghc2:~# netstat -a | grep TIME_WAIT | wc -l
4338

Coté client (ma VM Debian), on a sensiblement le même nombre de TIME_WAIT.

 

Aucun process n'a crashé, et en particulier le HCServer qui est responsable des 503 Unavailable Error :

root@fghc2:~# screen -ls
There are screens on:
        1386.LILIServer (01/14/2016 06:26:47 PM)        (Detached)
        1383.Zwave      (01/14/2016 06:26:47 PM)        (Detached)
        1335.Router     (01/14/2016 06:26:43 PM)        (Detached)
        1327.RemoteAccess       (01/14/2016 06:26:43 PM)        (Detached)
        1348.HCServer   (01/14/2016 06:26:43 PM)        (Detached)
        1330.DbUpdater  (01/14/2016 06:26:43 PM)        (Detached)
        1256.GPIOServer (01/14/2016 06:26:36 PM)        (Detached)
7 Sockets in /var/run/screen/S-root.

L'utilisation en RAM est totalement stable durant ce test (version 4.063 Beta) :

root@fghc2:~# free -m
             total       used       free     shared    buffers     cached
Mem:           993        470        522          0         61        233
-/+ buffers/cache:        175        817
Swap:          243          0        243

Après :

root@fghc2:~# free -m
             total       used       free     shared    buffers     cached
Mem:           993        469        523          0         61        231
-/+ buffers/cache:        176        816
Swap:          243          0        243

Bref, on peut y aller niveau charge sur l'API, la HC2 encaisse sans souci.

 

Donc on en revient toujours au même : les crashs ne sont pas dus à  une charge excessive, puisque notre HC2 ne fait rien en temps normal (charge CPU moyenne très largement inférieure à  10%, plutôt proche du pourcent.....)

 

Demain je ferai le test inverse, en utilisant la HC2 comme client http. Il faut que je monte un Apache sur ma VM pour donner un peu de données à  ingurgiter à  la HC2.

 

Si tu as une idée d'un autre test que je peux faire, c'est le moment

[Dgille]

´

Bon ok, la hc2 en mode serveur se comporte plutot bien, meme s il reste des zones d ombre, je pense aux pbs liés a hombebridge.

Mais ton test est interessant, cependant, curl ferme bien ses sockets, donc plus facile pour la box.

Effectivement, le test suivant et qui correspond aux interrogations d objects connectés est de generer en lua un grand nombre de sessions https jamais fermées explicitement vers un serveur externe.

Une question, le process hcserver, c est bien un apache avec php? Si oui, quels sont les limites fixées a apache ds le httpd.conf?

[Lazer]

Non Apache c'est bien les process httpd classiques, indépendants des développements Fibaro. Idem pour PHP.

Je regarderai la conf demain, mais c'est du relativement standard de mémoire.

 

HCServer c'est le processus principal de la box (en C compilé, donc on ne sais pas ce qu'il y a dedans). C'est un espèce d'ordonnanceur, qui va communiquer vers les process Z-Wave, le DB Updater, les VD, Scène, Plugins, etc...

Ce HCServer est notamment responsable de l'API, pour rappel tout passe par l'API (nos scripts, nos commande LUA de type fibaro;call(...) setvalue(...) etc et aussi l'interface Web, les applis mobiles, etc).

L'API est disponible via l'URL /api sur le port 11111 en localhost uniquement (proxy Apache local), et c'est le process HCServer qui écoute sur ce port, donc c'est lui qui traite toutes les requêtes.

Lors de mon test de charge aujourd'hui, c'était bien le process HCServer qui était logiquement responsable de la majorité du %User CPU (et un peu de %Syst, car il fait des appels systèmes aussi)

 

En effet pour Homebridge c'est assez mystérieux.... je ne l'utilise pas, mais il faudrait monitorer la box (en root bien sà»r) durant toute la phase de fonctionnement, jusqu'au crash.

J'envisage 2 cas possible :

- une augmentation d'un paramètre, qui finit par mener au crash (à  priori on a exclu les sockets TCP et la RAM avec le test d'aujourd'hui, mais on est peut être passé à  coté d'un autre paramètre critique)

- le chaos, c'est à  dire un développement anarchique purement Fibaro, qui fait que le bug se produit de façon aléatoire. Les requêtes répétées de Homebridge ne font qu'augmenter la probabilité d'occasionner ce bug. Mon test d'aujourd'hui également, peut être qu'en le laissant tourner une journée complète ça finirait par arriver.

[Dgille]

Ok, merci. donc , si tu as l'occasion de faire de test en lua en tant que client, interrogeant un objet connecté en http, sans fermer la socket, voire les deux tests simultanément.

Pour mettre en évidence l'éventuelle mauvaise gestion de ces connexions par le HCserver, le test pourrais consister à  occuper les 1024 handles (c'est la valeur max d'après le ulimit -Ha), et si l'API en a tant besoin, on provoquera peut être le plantage.

[Lazer]

Comme je le disais, la config Apache est ultra standard (/etc/apache2/sites-available/default) :

<VirtualHost *:80>
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/>
                Options FollowSymLinks MultiViews IncludesNOEXEC
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

    Alias /doc/ "/usr/share/doc/"
    <Directory "/usr/share/doc/">
        Options MultiViews FollowSymLinks
        AllowOverride None
        Order deny,allow
        Deny from all
        Allow from 127.0.0.0/255.0.0.0 ::1/128
    </Directory>

#   ProxyRequests On
    ProxyPass /api    http://127.0.0.1:11111/api retry=0

    Options +Includes
    AddType text/html .html
    AddOutputFilter INCLUDES .html

</VirtualHost>

La seule ligne intéressante, c'est le ProxyPass.

Le process HCServer écoute bien sur le port 11111 :

root@fghc2:~# netstat -aep | grep LISTEN | grep 11111
tcp        0      0 *:11111                 *:*                     LISTEN      root       4485        1350/HCServer

.
Je fais le test en LUA dès que possible.

 

Par contre je suis en train de penser que mon test d'hier soir n'est pas représentatif du bug rencontré sur Homebirdge. Car je me suis contenté de surveiller le crash des process, mais le problème est différent avec Homebirdge ; apparemment, plus aucun ordre Z-Wave ne passe, donc ce n'est pas tout à  fait pareil....

[Lazer]

Sur la VM Debian, création d'une page Web eco.html servie par Apache contenant un JSON basique (issu d'un Eco-Devices) :

{"product":"Eco-devices","T1_PTEC":"HC..","T1_PAPP":1560,"T1_HCHP":11861401,"T1_HCHC":9250490,"T2_PTEC":"----","T2_PAPP":0,"T2_BASE":0,"INDEX_C1":3371475,"INDEX_C2":2829685}

.

Sur la HC2, création d'un VD avec un bouton contenant le code suivant :

-- Test de charge

fibaro:debug("Starting loop...")

local selfID = fibaro:getSelfId()
local ip = fibaro:get(selfID, 'IPAddress')
local port = fibaro:get(selfID, 'TCPPort')
local i = 0

while i < 1000 do
	local WEB = Net.FHttp(ip, tonumber(port))
	local response, status, errorCode = WEB:GET("/eco.html?i="..tostring(i))
	if tonumber(errorCode) == 0 and tonumber(status) == 200 and response ~= nil and response ~= "" then
		fibaro:debug("i="..i.." memory="..collectgarbage("count"))
	else
		fibaro:debug("Erreur : i="..i)
	end
	i = i + 1
	--WEB = nil
	--collectgarbage("collect")
end

fibaro:debug("Loop finished")

.

Après enregistrement du VD, sous Linux, on récupère le PID du process associé au VD :

root@fghc2:~# ps -ef | grep "PluginManager 15"
root      1754     1  0 16:21 ?        00:00:00 /opt/fibaro/PluginManager 15 startMainLoop 0 0 ...

De base, ce VD a déjà  26 descripteurs de fichiers ouverts :

root@fghc2:~# ls /proc/1754/fd | wc -l
26

.

On lance le test en appuyant sur le bouton du VD. Dans la fenêtre de debug :

[DEBUG] 16:34:41: Starting loop...
[DEBUG] 16:34:41: i=0 memory=32.888671875
[DEBUG] 16:34:41: i=1 memory=33.0341796875
[DEBUG] 16:34:41: i=2 memory=33.181640625
[DEBUG] 16:34:41: i=3 memory=33.3271484375
[DEBUG] 16:34:41: i=4 memory=33.474609375
...
[DEBUG] 16:34:43: i=992 memory=50.4111328125
[DEBUG] 16:34:43: i=993 memory=50.564453125
[DEBUG] 16:34:43: i=994 memory=50.7158203125
[DEBUG] 16:34:43: i=995 memory=50.869140625
[DEBUG] 16:34:43: i=996 memory=51.0205078125

Cela s'arrête brusquement à  la 997ème itération, sans jamais arriver au message "Loop Finished".

L’exécution est très rapide, cela ne prend que 2 secondes (donc environ 500 requêtes http par seconde, le LUA est décidément un langage très rapide, bien plus que le Shell).

L'occupation mémoire du moteur LUA reste très contenue, ne montant qu'à  51 ko.

Sous Linux, on observe l'apparition d'un core dump :

root@fghc2:~# ls -l /core
-rw------- 1 root root 9261056 Jan 19 16:21 /core

Cela s'exécute tellement vite que je n'ai pas le temps de monitorer le nombre de fichiers ouverts, mais de toute évidence on atteint la fameuse limite de 1024 fixée par le ulimit du système (26 + 997 = 1023).

 

 

 

 

Dans le code LUA, j'ai mis en commentaire les 2 lignes suivantes à  la fin de la boucle while :

	WEB = nil
	collectgarbage("collect")

Si on les décommente et qu'on relance le test, on constate que la RAM utilisée par le moteur LUA n'augmente pas et se limite à  30 ko. En revanche les performances sont bien inférieures, car on force le garbage collector à  tourner à  chaque passage dans la boucle. Mais surtout, le nombre de descripteurs de fichiers atteint quand même 1024, occasionnant quand même le crash du VD avant de terminer la boucle :

[DEBUG] 16:21:25: Starting loop...
[DEBUG] 16:21:25: i=0 memory=32.9609375
[DEBUG] 16:21:25: i=1 memory=30.333984375
[DEBUG] 16:21:25: i=2 memory=30.365234375
[DEBUG] 16:21:25: i=3 memory=30.365234375
...
[DEBUG] 16:21:27: i=993 memory=30.369140625
[DEBUG] 16:21:27: i=994 memory=30.369140625
[DEBUG] 16:21:27: i=995 memory=30.369140625
[DEBUG] 16:21:27: i=996 memory=30.369140625

.

 

Enfin, si on sort la ligne local WEB = Net.FHttp(...) de la boucle while, pour le positionner avant d'entrer dans la boucle, il n'y a qu'un seul socket TCP utilisé durant tout le script, donc la boucle s'exécute parfaitement. Je suis allé à  10'000 itérations sans faire broncher la box, et c'est encore plus rapide (car il n'y a pas besoin de rouvrir un socket à  chaque passage dans la boucle, opération de loin la plus longue sur la totalité des instructions présentes)

 

 

Conclusion de ce test :

 

Cela se confirme, on a donc bien une limitation à  1024 fichiers ouverts par chaque process (chaque VD, Scène, Plugin étant dans des process séparés).

Avec ce petit benchmark; volontairement violent, on atteint en 2 seconde la limite, et donc le crash (core dump) du process lié au module virtuel.

 

Le test suivant sera de faire un bench un peu plus représentatif de nos modules virtuels que nous utilisons couramment. C'est à  dire d'exploiter la Main Loop et son sleep() de 3 seconde à  chaque passage dans la boucle.

Cela laissera le temps de monitorer les descripteurs de fichiers ouverts au niveau Linux, et de voir si la main loop ouvre les sockets plus vite que la pile TCP/IP les libère.

[Dgille]

Super, en sachant aussi qu'au total, linux ne peut pas gérer plus de 65535 handles, avec ton test, 60 vd (mal écrits, c'est vrai), plus les besoins propres à  la box, on peut arriver au bout je pense.

 

Ma conclusion provisoire est donc qu'il faut quand même apporter un soin particulier à  l'écriture des scènes et VD en lua (mais c'est valable pour tous les langages), et ne pas faire n'importe quoi; On peut aussi essayer de modifier cette limite de 1024 handles/process, mais si c'est mal écrit, cela ne fait que repousser le problème.

 

Pour les VD, je me dits aussi que cela milite en faveur d'une main loop appelée régulièrement plutôt qu'une boucle infinie..... et on a quand même intérêt à  fermer les sockets en cas d'usage intensif de net.fhttp.

 

Par contre, cela conforte ton opinion sur les développeurs fibaro, le net.fhttp devrait renvoyer une erreur en absence de handle au lieu d'un coredump :angry: C'est peut être un point à  leur remonter.

 

voilà , on a au moins quelques bonnes pratiques

 

merci pour te temps passé sur le sujet, je suis convaincu que c'est la source d'une bonne partie des soucis remontés, même s'il y a surement d'autres problèmes, on peut leur faire confiance.

[Dgille]

Bonjour à  tous, un petit retour d'expérience suite aux échanges ci dessus. Pour repréciser le contexte, je suis toujours en 4,063b. Avec plantage (erreur 503) de la box tous les 4/5 jours au début de la discussion.

 

Suite aux échanges avec Lazer( encore merci pour le tps passé), j'ai rebalayé mes VD pour fermer proprement mes sockets. Aujourd'hui, j'ai un uptime de plus de 350 heures (14/15 jours) sans reboot (yes!!).

 

Le seul VD qui plante régulièrement et qui est relancé par  le watchdog de Lazer, c'est la remontée emoncms sur internet. je vais encapsuler la fonction dans un pcall pour voir si cela améliore les choses.

 

De ma fenêtre, cette fermeture des socket a quand même bien stabilisé la box. Cela dit,o n parlera de vrai changement quand elle tiendra 3 à  4 mois sans reboot....

 

A suivre donc.