Lazer

Du coup, je propose de réinitialiser le compteur de message de Pascaldu54 à0. Vous êtes tout d'accord bien sûr ?

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

mprinfo est parti mais voici Pascaldu54, pro-jeedom

C'est moi ou le forum est ànouveau très lent en ce moment ?

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.

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.

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.

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.

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....

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.

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).

Sujet déplacé, merci de ne pas poster dans la section pour les nuls, réservé aux tutos. Essaye le format PNG, je ne pense pas que le JPEG soit accepté.

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.

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

méchant les pompiers te diront qu'ils préfèrent pourtant le bois au métal.... car la réaction du bois en cas d'incendie est plus prévisible que les structures métalliques, qui s'effondrent sans prévenir.

Ouaip c'est collé ! Mais ça devrait passer en refroidissement passif, pour l'instant avec le switch de 10W, ça reste froid. Sinon l'évacuation se fera par le trou vers le placard d'àcôté, ou àgauche le long des câbles réseaux.

OK bon j'en parle àmon boss, sur un malentendu ça peut passer

quoi, pas de mirabelle ? Bon inutile que je vienne alors Comme il va faire froid dans l'Est, peut être que je ferais mieux de rester chez moi et rendre visite àmon ami Fredo Il parait que le serveur DHCP fonctionne maintenant

Mon coffret réseau 10" était trop étroit.... aucun switch de qualité (marque réputée, manageable, et avec plus de 16 ports) ne rentrait dedans. Et mon Netgear 8 ports ne me convenait plus. Problème, je suis limité en espace, et le seul emplacement à ma disposition est le bas d'un placard, qui nous sert de porte-manteaux. Aucun coffret 19 pouces ne me convenait, à cause des profondeurs, c'est soit 30cm, soit 45cm.... mais jamais entre les deux. J'ai donc acheté 4 profilés rack en acier 2 mm de 6U sur eBay pour une poignée d'euros. Une cornière acier pré-percée chez Leroy Merlin, ainsi que quelques vis et écrous papillons pour une autre poignée d'euros. Et du bois de récupération (des chutes de liteaux de mon abris de jardin) Fabrication de la structure sur mesure, en me servant du switch Cisco et du panneau de brassage Legrand comme référence pour la largeur entre les montants : Ça rentre parfaitement dans le placard : Les écrous papillons servent à ajuster la profondeur des rails, en fonction de la profondeur du switch, afin de maximiser le peu d'espace disponible. J'ai fait sauter le fond du placard afin de mettre le sol à nu, ce qui laisse la place pour l'arrivée des câbles réseau. Pour fermer cela proprement, je pensais le faire en panneau MDF peint. Une fois dans mon Leroy Merlin local, je tombe sur un stock de planches en chêne de 20mm en promo. C'est parfait, ça sera plus propre, et puis un coffret réseau en chêne massif, c'est juste la classe Voici l'ensemble monté, avec des vitres en plexiglas, et de la quincaillerie de la marque Hettich (j'adore leurs produits) : Commentaire de Madame à ce moment là : il est bizarre ton nouveau meuble à chaussure (euh, comment dire... tu en as déjà un qui est aussi large et qui fait 2m de haut... ) Bon clairement, les portes sont ce qui m'a pris le plus de temps à faire dans tout le projet, je me suis galéré avec des tourillons pour l'assemblage, une belle rainure pour la fixation de la vitre, le positionnement des charnières, et le système de fermeture. En haut à gauche, on voir quelques câbles réseaux qui remontent, ils seront masqués ultérieurement avec un double fond en HDF. Il y a largement la place pour monter une 15zaine de câbles réseau directement vers l'étage. Vue de l'intérieur : Reste à faire : - une réglette de prise électrique (certaines seront sur un onduleur à venir) - terminer le câblage réseau avec des câbles de qualité et aux bonnes longueurs. - continuer à passer des câbles dans toute la maison, j'ai maintenant de la marge pour le brassage. - installer le routeur et le point d'accès Wi-Fi Ubiquiti Comme le coffret est en bois, je pourrais y installer des équipements hertziens, tels que Wi-Fi, Z-Wave, etc.... mais je vais m'abstenir car : situé au ras du sol ce n'est pas l'idéal pour diffuser dans la maison, et ça risque de chauffer assez vite (HC2 + Freebox, ça consomme beaucoup, si je peux éviter d'installer des ventilateurs d'extraction, c'est mieux). Et puis comme j'ai la place pour tout cela, voici justement la vue du placard de droite, qui contient le serveur HP (d'ailleurs faut que je mette le G8 à la place du G7), la Freebox, la HC2, et les tableaux électriques :

c'est pas bon, ça sent les fichiers corrompus. A mon avis t'es bon pour faire un recovery.

- oui c'est ce que j'utilise chez moi, le nom du site fonctionne parfaitement à la place de l'IP - je pense que tu vas devoir modifier les scripts pour changer l'URL.... galère à faire Est-ce que tu ne peux pas créer une URL du style domotique.monsite.com (le www étant inutile) Cool Je ne connais pas du tout les NAS WD..... mais vu l'erreur, j'ai l'impression qu'il n'y a pas MySQL sur le NAS. Faudrait que tu cherches comment activer cette fonction sur ton NAS.

ah cool, bravo

Je pense que tu n'as pas la dernière version du VD..... Ta vieille version doit avoir les commentaires dans la main loop, ce qui fait trop de caractères et l'empêche de démarrer.... Comme expliqué dans les dernières pages. J'ai partagé une version directement utilisable.

Essaye de supprimer toutes les variables globales de ce VD, puis réenregistre le, ça va le forcer àrefaire une authentification. Par contre si tu n'as rien dans la fenêtre de debug de la main loop, y'a un autre problème.... ?!?

Normalement ça ressemble àquelque chose comme ça : mysql -u root --password -D nom_de_la_base < nom_du_fichier.sql 38 Mo ça devrait passer sans problème normalement. Moi j'avais buté sur des fichiers de plusieurs centaines de Mo.