Je viens de mettre 1h (3600). Je surveille et je te tiens au courant.
Bonsoir nebz,
Ca ne se calme pas malheureusement, toujours 10% de consommation CPU en continue.
On voit bien sur le htop ci-dessous que le contrôleur est à fond !
J’ai rebooté pour voir mais ça ne s’arrange pas…
10% ça ne me dérange pas en fait… un Control est sensé être dédié donc ça ne pose pas problème.
Ce qui m’intrigue c’est que le contrôleur continue d’être chargé alors que le plugin ne lui envoi plus rien… je suppose qu’il met en file d’attente les messages pendant ce temps
Il faudrait peut être regarder dans les logs de ton contrôleur ce qui se passe…
10% ça me dérange un peu quand même surtout qu’il semble qu’il y ait des io en pagailles et avec un pi avec une carte sd c’est un peu chaud…
Avec un top on voit des consommations de cpu en pointe autour de 70, 80% ponctuellement qui montre qu’il y a définitivement une forte activité. Je pense qu’il y a un truc à faire…
En attendant, je désactive…à mon grand regret.
Bien cordialement,
Christophe
Ok, je vais regarder si de mon côté il n’y a vraiment plus aucune communication avec le contrôleur, si c’est le cas et qu’il continue à garder un cpu élevé malgré cela, je ne pourrai probablement pas faire grand chose.
Bonjour,
j’ai un load average de 0.05 0.09 0.16 une fois que j’ai passé le plugin à 3600.
le pourcentage passe parfois à 10% moins d’une seconde puis redescend à quasi zero. (htop prenant 2.6%)
j’en conclu que vous devez avoir d’autres traitements (scenarios etc) qui continuent à charger votre controleur malgré avoir descendu le rafraichissement du plugin.
et je réitère 10% de charge sur 1 core d’un système multicore est tout à fait acceptable.
en repassant à 3 secondes, j’ai un load average de 0.12.
concernant les IO, aucun problème non plus puisqu’il s’agit principalement de lectures et pas d’écritures. donc pas plus de charge sur la SD.
Bonjour,
Pour info le raspberry qui fait tourner le controleur lui est complètement dédié. J’ai essayé le plugin dans ma maison de campagne ou le controleur est un « unifi cloud key » qui est encore plus dédié si je puis dire et les résultats sont malheureusement les mêmes. Voici la courbe de l’activité CPU (15 mn load average) sur la cloud key et cette belle « molaire » le temps que le plugin a été activé. J’ai une douzaine de clients unifi mais pour j’en ai « activé » qu’un seul dans le plugin.
Y a quand même un truc…
et tu as mis quel taux de rafraichissement ?
J’ai mis 3600
Donc d’après mes tests, c’est impossible de charger le controleur avec 3600… tu dois avoir autre chose qui le questionne … tu peux confirmer les communications avec le contrôleur dans le log unifi_daemon en débug, si tu ne vois rien, je n’envoi rien !
A partir de ce moment, je ne peux plus rien faire…
J’ai mis le niveau de log à Debug et j’ai redémarré le démon. Je te donne les résultats dès que ça bouge un peu. Pour le moment très calme.
Si demain matin je vois que je consomme j’agirai sur les niveaux de log du contrôleur que je laisse à normal pour le moment :
C’est reparti pour un tour. Les logs coté plugin même en debug sont presque muet. Je vais logger en debug unifi et mongodb coté cloudkey. Tu retrouve dans le graphique la molaire précédent et au taquet à droite l’expérience de cette nuit.
Le process qui tourne à plein (père et fils) :
unifi 1151 1079 14 Mar17 ? 16:43:06 /usr/lib/jvm/java-8-openjdk-armhf/jre/bin/java -Dfile.encoding=UTF-8 -Djava.awt.headless=true -Dapple.awt.UIElement=true -Xmx768M -XX:+ExitOnOutOfMemoryErro
r -XX:ErrorFile=/usr/lib/unifi/logs/hs_err_pid%p.log -jar /usr/lib/unifi/lib/ace.jar startunifi 1232 1151 0 Mar17 ? 00:51:22 bin/mongod --dbpath /usr/lib/unifi/data/db --port 27117 --unixSocketPrefix /usr/lib/unifi/run --noprealloc --nohttpinterface --smallfiles --bind_ip 127.0.0.
1 --journal
Ce process 1151 passe de 100% à 1% à l’arrêt du plugin coté jeedom.