Too many connexion ... Jeedouino ? BLEA ? ou autre?

benj29 · Octobre 3, 2020, 7:56

Bonsoir,

J’ai remarqué depuis peu que j’ai des avertissements de too many connexion. J’ai eu une « perte » de Jeedom de quelques secondes avec des avertissements message pour tous mes scénarios de ce type :

La dernière exécution du scénario ne s’est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario « XXXXXX ».

Le fichier log en question n’a que ça :

PHP Warning:  Module 'mosquitto' already loaded in Unknown on line 0
PHP Warning:  Module 'mosquitto' already loaded in Unknown on line 0
PHP Warning:  Module 'mosquitto' already loaded in Unknown on line 0
PHP Warning:  Module 'mosquitto' already loaded in Unknown on line 0
PHP Warning:  Module 'mosquitto' already loaded in Unknown on line 0
PHP Warning:  Module 'mosquitto' already loaded in Unknown on line 0
PHP Warning:  Module 'mosquitto' already loaded in Unknown on line 0
PHP Warning:  Module 'mosquitto' already loaded in Unknown on line 0
PHP Warning:  Module 'mosquitto' already loaded in Unknown on line 0

Le log scenario me donne à l’heure où tout a déraillé (je montre que quelques lignes…)

2020-10-03 19:45:12][ERROR] : Trop d'appel simultané du scénario, il ne peut-être exécuté une nouvelle fois. Il est conseillé de réduire les appels au scénario "Portail".
[2020-10-03 19:45:12][ERROR] : Trop d'appel simultané du scénario, il ne peut-être exécuté une nouvelle fois. Il est conseillé de réduire les appels au scénario "Notifications Monitoring".
[2020-10-03 19:45:13][ERROR] : Trop d'appel simultané du scénario, il ne peut-être exécuté une nouvelle fois. Il est conseillé de réduire les appels au scénario "Portail".
[2020-10-03 19:45:13][ERROR] : Trop d'appel simultané du scénario, il ne peut-être exécuté une nouvelle fois. Il est conseillé de réduire les appels au scénario "Portail".
[2020-10-03 19:45:13][ERROR] : Trop d'appel simultané du scénario, il ne peut-être exécuté une nouvelle fois. Il est conseillé de réduire les appels au scénario "Portail".
[2020-10-03 19:45:14][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "Motion Detection".
[2020-10-03 19:46:02][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "Surveillance relance démons BLEA".
[2020-10-03 19:46:02][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "(Chauffage) Mise à jour des Thermostats Globaux".
[2020-10-03 19:46:02][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "(Climatisation) Mise à jour des Thermostats".
[2020-10-03 19:46:02][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "ScreenOFF Tablette Entrée (répétition)".
[2020-10-03 19:46:02][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "Comptage Compteurs @minute".
[2020-10-03 19:46:02][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "Comptage Elec Conso  Production @h".
[2020-10-03 19:46:02][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "ScreenOFF Téléphone Garage (répétition)".
[2020-10-03 19:46:02][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "Surveillance Démons Jeedouino".
[2020-10-03 19:46:02][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "Consommation @5min".
[2020-10-03 19:46:02][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "Statistiques PV sur pulse (@5min)".
[2020-10-03 19:46:02][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "Statistiques Température et Humidité".
[2020-10-03 19:46:02][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "Refresh Wazeintime".
[2020-10-03 19:46:02][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "Surveillance Compteurs Jeedouino".
[2020-10-03 19:46:02][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "Batterie Tracker".
[2020-10-03 19:50:03][ERROR] : La dernière exécution du scénario ne s'est pas lancée. Vérifiez le log scenario_execution, ainsi que le log du scénario "Notifications Monitoring".

Ce soir vers 19h00/45, une montée en charge côté processeur de la VM Jeedom (je tourne sur la dernière stable en V3 sous Debian 9). je vais faire l’update OS à l’instant (ma dernière update date d’il y a quelques semaines).

En fouillant dans les logs, il semblerait que le http.error renvoie en permanence un souci depuis une rapsberry en 192.168.2.54 faisant tourner Jeedouino uniquement et antenne BLEA.

[Sat Oct 03 19:44:52.544447 2020] [:error] [pid 28370] [client 192.168.2.54:41338] PHP Fatal error:  Uncaught PDOException: SQLSTATE[HY000] [1040] Too many connections in /var/www/html/core/class/DB.class.php:41
Stack trace:
#0 /var/www/html/core/class/DB.class.php(41): PDO->__construct('mysql:host=loca...', 'jeedom', 'XXXX', Array)
#1 /var/www/html/core/class/DB.class.php(54): DB->__construct()
#2 /var/www/html/core/class/DB.class.php(86): DB::getConnection()
#3 /var/www/html/core/class/config.class.php(173): DB::Prepare('SELECT `key`,`v...', Array, 1)
#4 /var/www/html/core/class/translate.class.php(34): config::byKeys(Array)
#5 /var/www/html/core/class/translate.class.php(150): translate::getConfig('language', 'fr_FR')
#6 /var/www/html/core/class/translate.class.php(75): translate::getLanguage()
#7 /var/www/html/core/class/translate.class.php(54): translate::exec('{{Lumi\xC3\xA8re Togg...', '/var/www/html/c...', false)
#8 /var/www/html/core/class/translate.class.php(164): translate::sentence('Lumi\xC3\xA8re Toggle', '/var/www/html/c...', false)
#9 /var/www/html/core/config/jeedom.config.php(78): in /var/www/html/core/class/DB.class.php on line 41
[Sat Oct 03 19:44:52.556003 2020] [:error] [pid 28370] [client 192.168.2.54:41348] PHP Fatal error:  Uncaught PDOException: SQLSTATE[HY000] [1040] Too many connections in /var/www/html/core/class/DB.class.php:41
Stack trace:
#0 /var/www/html/core/class/DB.class.php(41): PDO->__construct('mysql:host=loca...', 'jeedom', 'XXXXXXXXXXX', Array)
#1 /var/www/html/core/class/DB.class.php(54): DB->__construct()
#2 /var/www/html/core/class/DB.class.php(86): DB::getConnection()
#3 /var/www/html/core/class/config.class.php(173): DB::Prepare('SELECT `key`,`v...', Array, 1)
#4 /var/www/html/core/class/translate.class.php(34): config::byKeys(Array)
#5 /var/www/html/core/class/translate.class.php(150): translate::getConfig('language', 'fr_FR')
#6 /var/www/html/core/class/translate.class.php(75): translate::getLanguage()
#7 /var/www/html/core/class/translate.class.php(54): translate::exec('{{Lumi\xC3\xA8re Togg...', '/var/www/html/c...', false)
#8 /var/www/html/core/class/translate.class.php(164): translate::sentence('Lumi\xC3\xA8re Toggle', '/var/www/html/c...', false)
#9 /var/www/html/core/config/jeedom.config.php(78): in /var/www/html/core/class/DB.class.php on line 41
[Sat Oct 03 19:44:52.565973 2020] [:error] [pid 28370] [client 192.168.2.54:41350] PHP Fatal error:  Uncaught PDOException: SQLSTATE[HY000] [1040] Too many connections in /var/www/html/core/class/DB.class.php:41
Stack trace:
#0 /var/www/html/core/class/DB.class.php(41): PDO->__construct('mysql:host=loca...', 'jeedom', 'XXXXXXXXXXX', Array)
#1 /var/www/html/core/class/DB.class.php(54): DB->__construct()
#2 /var/www/html/core/class/DB.class.php(86): DB::getConnection()
#3 /var/www/html/core/class/config.class.php(173): DB::Prepare('SELECT `key`,`v...', Array, 1)
#4 /var/www/html/core/class/translate.class.php(34): config::byKeys(Array)
#5 /var/www/html/core/class/translate.class.php(150): translate::getConfig('language', 'fr_FR')
#6 /var/www/html/core/class/translate.class.php(75): translate::getLanguage()
#7 /var/www/html/core/class/translate.class.php(54): translate::exec('{{Lumi\xC3\xA8re Togg...', '/var/www/html/c...', false)
#8 /var/www/html/core/class/translate.class.php(164): translate::sentence('Lumi\xC3\xA8re Toggle', '/var/www/html/c...', false)
#9 /var/www/html/core/config/jeedom.config.php(78): in /var/www/html/core/class/DB.class.php on line 41
[Sat Oct 03 19:44:52.567067 2020] [:error] [pid 28370] [client 192.168.2.54:41352] PHP Fatal error:  Uncaught PDOException: SQLSTATE[HY000] [1040] Too many connections in /var/www/html/core/class/DB.class.php:41
Stack trace:
#0 /var/www/html/core/class/DB.class.php(41): PDO->__construct('mysql:host=loca...', 'jeedom', 'XXXXXXXXXXX', Array)
#1 /var/www/html/core/class/DB.class.php(54): DB->__construct()
#2 /var/www/html/core/class/DB.class.php(86): DB::getConnection()
#3 /var/www/html/core/class/config.class.php(173): DB::Prepare('SELECT `key`,`v...', Array, 1)
#4 /var/www/html/core/class/translate.class.php(34): config::byKeys(Array)
#5 /var/www/html/core/class/translate.class.php(150): translate::getConfig('language', 'fr_FR')
#6 /var/www/html/core/class/translate.class.php(75): translate::getLanguage()
#7 /var/www/html/core/class/translate.class.php(54): translate::exec('{{Lumi\xC3\xA8re Togg...', '/var/www/html/c...', false)
#8 /var/www/html/core/class/translate.class.php(164): translate::sentence('Lumi\xC3\xA8re Toggle', '/var/www/html/c...', false)
#9 /var/www/html/core/config/jeedom.config.php(78): in /var/www/html/core/class/DB.class.php on line 41
[Sat Oct 03 19:44:52.884141 2020] [:error] [pid 28370] [client 192.168.2.54:41356] PHP Fatal error:  Uncaught PDOException: SQLSTATE[HY000] [1040] Too many connections in /var/www/html/core/class/DB.class.php:41
Stack trace:
#0 /var/www/html/core/class/DB.class.php(41): PDO->__construct('mysql:host=loca...', 'jeedom', 'XXXXXXXXXXX', Array)
#1 /var/www/html/core/class/DB.class.php(54): DB->__construct()
#2 /var/www/html/core/class/DB.class.php(86): DB::getConnection()
#3 /var/www/html/core/class/config.class.php(173): DB::Prepare('SELECT `key`,`v...', Array, 1)
#4 /var/www/html/core/class/translate.class.php(34): config::byKeys(Array)
#5 /var/www/html/core/class/translate.class.php(150): translate::getConfig('language', 'fr_FR')
#6 /var/www/html/core/class/translate.class.php(75): translate::getLanguage()
#7 /var/www/html/core/class/translate.class.php(54): translate::exec('{{Lumi\xC3\xA8re Togg...', '/var/www/html/c...', false)
#8 /var/www/html/core/class/translate.class.php(164): translate::sentence('Lumi\xC3\xA8re Toggle', '/var/www/html/c...', false)
#9 /var/www/html/core/config/jeedom.config.php(78): in /var/www/html/core/class/DB.class.php on line 41

Une idée ?

Pour notes : la VM se balade tant en RAM/CPU.

Moy :

Max :

Sauf vers 19h/20h ce jour (en max à 70% et encore…) :

olive · Octobre 4, 2020, 5:38

Il serait bien d’ajouter le traffic réseau voir si il n’y aurait pas de problème de ce coté …
Une copie écran de la page santé.
Comment est partitionner le disque et surtout taille du swap ?

benj29 · Octobre 4, 2020, 7:11

Hello,

tellement logique pour moi, mais rien de particulier. Le swap est 100% dispo.

côté jeedom :
L’erreur HTTPS est « normale » car j’ai un routeur derrière une livebox ; mais l’https est bien fonctionnel (443) et cela n’implique rien sur mon problème.

Par contre, je remarque que le besoin en RAM a bondi par rapport à mes souvenirs. Il me semblait tourner à 3/4 GO sur une VM dimensionnée à 8 Go max. Et là, c’est du 7…

J’ai perdu mon historique Proxmox lors du changement de serveur en Juin, mais ça tourne à 6/7 de moyenne visiblement depuis Juin.

Traffic réseau et disque en moy sur la dernière semaine :

En max :

Après vérification, mon backup est à 4h du matin.

olive · Octobre 4, 2020, 10:31

Essai juste pour voir de mettre 2go de mémoire en plus si il t’en reste.

benj29 · Octobre 4, 2020, 1:35

Euh… 10go sur un jeedom

naboleo · Octobre 4, 2020, 1:48

Salut,

As-tu simplement vérifié :

que tu n’as pas une boucle dans les appels de tes scénarios genre A => B => A?
des scénarios avec des étapes bloquantes (wait trop long etc) ?
une répétition d’un déclencheur qui arrive plus vite que la fin d’execution du scénario ?

olive · Octobre 4, 2020, 2:58

jai dit juste pour voir … si tu continue a bourré la mémoire ou si ce n’est pas le taquet du swapp.
cela pourrait être indicateur/révélateur suit egalement les recommandations de @naboleo

benj29 · Octobre 4, 2020, 4:29

@olive,

Pas de problème, j’avais compris. C’est juste que je suis épaté car je pensais être déjà confortable.

Je suis passé de 8 à 16 Go en balloon pour être à l’aise.
Et là, santé me donne 94% de mémoire dispo… alors qu’avant 83% avec un baloon de 4 à 8 Go.

Mémoire disponible 94 % (Total 16051 Mo)

@naboleo,
ce qui me dérange c’est que je n’ai rien changé dans mes scénarios depuis des mois (en terme de scénario lourd).

La seule chose que j’ai faite, c’est :

ajouter des timeout sur des scénarios qui tournent souvent (détection de mouvement),
rajouter des déclencheurs sur des scénarios de mouvement. Du coup, ce qui pourrait se passer c’est que le fait que ces déclencheurs dans une zone apparaissent de manière successive, cela charge trop ? Mais du coup je n’ai pas autorisé le multi-lancement …

Mais dans le principe, j’ai du mal à y croire car ces scénarios tournent depuis déjà 2/3 ans !

En regardant, je vois que les scénarios (certains) restent en « en cours » et il faut que je fasse « arrêter ».
Me faut-il mettre des timeout partout ?
J’ai tenté aussi de modifier certains déclencheurs en mettant répétition à JAMAIS au lieu d’automatique (pour voir) sur un scénario qui était dans les messages par exemple.

benj29 · Octobre 4, 2020, 4:34

La CPU/ram ont bien chuté au reboot :

olive · Octobre 4, 2020, 4:37

Ha c’était donc pas une mauvaise idée …
je pense a de la mémoire qui butte dans le swap mais pas d’autres idées !

si ce n’est de surveiller l’évolution de l’utilisation mémoire …

naboleo · Octobre 4, 2020, 4:41

C’est dépendant de la config (quantité de devices, de scénarios…) mais pour infos 2Go sur mon NUC ça passe à l’aise !

De ce coté là, il faut aussi jouer avec les répétitions des valeurs (surtout les déclencheurs), le multi-lancement c’est pas assez et justement ça ‹ empêche › de lancer des scénarios…

Assez logique, les processus éventuellement liés aux sénarios qui se télescopent ns sont pas encore là, il faut voir l’évolution

benj29 · Octobre 4, 2020, 6:25

En tout cas, merci pour vos pistes.

Exemple sur ce scénario.

Jeedouino, capteur sec de porte.
J’ai laissé en automatique (pas à jamais répéter sinon il loupe des fois le 0).

Lui même par sur un virtuel à jamais répéter. Je viens de le passer en automatique pour voir si changement.

Le scénario qui gère l’éclairage est sur le déclencheur du virtuel précédent, sans == 1 ou 0.
Par contre, le scénario est protégé en non-répétition. Le problème c’est que si je mets un == 1 pour le déclencheur il restera toujours en non-répétition car ne verra que le 1 et jamais le 0 qui réautorisera l’ouverture suivante.

Effectivement dans les logs de ce scénario, je vois qu’il est appelé trop de fois. Voyons si le passage en automatique, change quelque chose.

Une idée ?

EDIT : rebelotte, même avec auto au lieu de jamais répéter, j’ai ce message…

Effectivement, dans les logs, j’ai bien les appels.

Par contre, désolé, mais je n’ai rien changé avec avant… je ne comprends pq j’ai ces problèmes maintenant…
Et surtout je vois que ça continue de se tanker avec la mémoire qui se balade.

benj29 · Octobre 4, 2020, 7:06

Au final, la RAM/CPU se baladent toujours et j’ai toujours ses erreurs de scénario :

Après, je remarque que ces soucis de répétition / scénario et messages associés sont plutôt sur mes ouvrants basés Jeedouino et scénarios associés. Mais après les messages d’erreur quand ça se tanke (il me faut aller dans scénario, cliquer sur arrêter et là tout repart ensuite) touche plusieurs scénarios.

Je veux bien me dire que je fais mal quelquechose d’un point de vue déclencheur, répétition et scénario. Mais ce que je ne comprends pas c’est pourquoi tous ces soucis alors qu’avant je n’avais rien de tout ça.

Je vais tenter de désactiver les scénarios liés aux ouvrants qui m’affichent ses erreurs et voir comment ça se comporte.

Je ne sais pas si mon install est lourde ou non :

A priori j’ai isolé les scénarios en question, ce sont bien ceux issus de la Jeedouino de mon portail et les éclairages associés qui se lancent.

Si vous avez des idées pour mieux les gérer au niveau déclencheur…
Tous les timeout en question sont à 0.
je vous dis demain si le fait de les avoir désactivé a changé qlqchose…

éclairage ouverture garage :
Se lance sur (xiaomi en automatique) :
#[Capteurs et Actionneurs][Porte Garage][Etat]#

éclairage ouverture portail :
Se lance sur un virtuel en auto pris d’un capteur sec jeedouino (binaire) :
#[Extérieur][Etat Portail (tab)][Portail]#

notification si garage ouvert :
sur déclencheur #[Capteurs et Actionneurs][Porte Garage][Etat]# == 1

si porte ouverte, 10min plus tard, je vérifie si toujours ouverte depuis 480s et qu’il y a qlq1 à la maison, alors je notifie (en résumé) :

naboleo · Octobre 4, 2020, 7:54

Tu es certain de ça ? Le jamais c’est justement pas ce cas là qu’il bloque : si ton info est égale à la valeur reçue… ça fait rien. Si c’est différent alors ça met à jour.
Si tu rates une valeur c’est à mon avis soit un souci de réception soit une collision dans ton traitement (genre scénario déjà en cours avec autre chose)
Le mode auto gére un cache, la mécanique n’est pas très claire mais c’est pas neutre avec la remarque qui suit

Quant à passer tous les capteurs sur des virtuels intermédiaires (pour éviter j’imagine de se refarcir les id si changement) c’est ultra consommateur. Surtout qu’il existe des fonctions de substitution/remplacement au besoin

Sauf que là tu te coinces tout seul …
La valeur 0 dans ton scénario ne sert absolument à rien (il y a pas de SINON)… mais ça a quand même déclenché le scénario … Dans le cas ou tu reçoit un 0 suivi tout de suite d’un 1 comme il n’est pas autorisé à s’exécuter en muli-lancement… ben l’info du 1 est perdue… Tout ça en plus de bouffer des ressources utilement. En plus on voit plusieurs appels dans la même seconde dans les logs

Une simple mise à jour de version suffit pour peu qu’un comportement à la con cache le problème dans la version précédente. Aussi bien sur un plugin que sur jeedom

Si tu as doublé les id avec tes virtuels … c’est inutilement lourd

En plus il y a plein de wait partout… (120 - 240 - 360) Rien que le scénario du portail, il reste en action entre 480 (120+360 => moto ou 308) et 600 (120+360+120 => swift) secondes…

A mon avis il va y avoir un peu/beaucoup de temps à passer mais tu gagnerai à revoir tes algos pour les rendre plus simples (petits) et moins interdépendants… Essaye de faire des DANS déjà, le scénario est libéré et la tache est planifiée… Mais bon si tu géres pas mieux les répétitions c’est sur que ça va coincer

benj29 · Octobre 5, 2020, 3:50

Le fait d’avoir juste désactivé les 5 scénarios en question n’a pas regénéré tout cela.
Après les waits sont nécessaires car ce sont des temps courts par exemple dans certains cas.
Je vais reprendre les 5 scénarios en question car après analyse, ce sont ceux qui n’arrêtent pas de se relancer.
Je reprends à tête reposée et fais un statut.

Merci !

benj29 · Octobre 5, 2020, 4:06

Bon, même en ayant désactivé les scénarios en question attachés à la PI portail/garage et autres, ce soir, jeedom s’est remis en carafe…

Pardon, mais je veux bien entendre que ma manière de faire les scénarios n’est pas bonne mais j’aimerai surtout comprendre pourquoi du jour au lendemain alors que mon installation tourne depuis bientôt plus de 2 ans et demi en VM à 4 CPU avec de la RAM confortable (4 à 8 Go) tout se met en carafe comme cela.

Donc, j’ai désactivé les scénarios qui étaient gourmands en wait (si tant est qu’ils le sont vraiment), il en reste forcément notamment ceux d’arrivée ou de présence. Mais il y a forcément quelque chose qui a été touché au niveau de la DB pour que d’un coup, ça saute comme ça au point de mettre Jeedom en état 0 et quelques secondes après repasser à 1. Comme si le matériel/mémoire n’était plus suffisant.

Je commence à me demander de remonter une VM « neuve » par exemple …

Jeedom3 et Debian10 sont-ils compatibles ? (dans une volonté de migrer en Jeedom4 à terme).

benj29 · Octobre 5, 2020, 6:38

Bon j’ai passé toutes les commandes sensibles (portail et autre) générant beaucoup d’événements à notre arrivée/départ à Jamais et non automatique.

Ce qui est vraiment bizarre, c’est que je vois dans les logs que certains scénarios remontés bloqués ne sont pas appelés plein de fois mais indique qu’ils n’ont pas pu se lancer.

J’ai regardé mes notes, j’ai fait une update du debian 9 vendredi et depuis je n’ai que des soucis…
J’ai aussi affecté 16 Go de ram sans ballonning… pour voir.

Je commence à me poser la question de remonter une VM vierge…

naboleo · Octobre 5, 2020, 6:49

Tu donnes toi même un élément de réponse : pas que debian9 soit forcement fautif mais ton jeedom évolue comme n’importe quel autre en 2 ans et demi

les scénarios qui deviennent plus nombreux et/ou complexes
les historiques qui grossissent
les mises à jour diverses et variées (OS, Jeedom, plugins)

Si le souci est coté Jeedom (mon avis perso), ça ne changera pas grand chose. Mais c’est pas long à tester avec une VM (l’image JeedomV4 Debian10 est dispo)

benj29 · Octobre 5, 2020, 6:52

Il y a un truc qui me chagrine… je suis pris d’un doute.

4 CPU pour 1 thread par CPU.
ou 1 CPU pour 4 threads ?

On est d’accord que 4 CPU c’est mieux en VM… logiquement !

Enfin, quand je regarde la mémoire, le fait de l’augmenter ou la baisser ne pose pas de souci particulier. C’est bien un nombre d’accès et une ressource de calcul insuffisante.

J’ai mis pas mal de « non répéter » à voir.

Par contre virer mes waits, non il y en a quand même plusieurs qui ne sont pas compressible (sur des temps courts).

Pour les autres je vais les reprendre progressivement.

naboleo · Octobre 5, 2020, 7:01

Oui même si dans une VM c’est pas aussi simple . Tu as les CPU et le vCPU
Sachant qu’en plus (v)CPU est multicores, tu fais globalement de toute façon du multi-thread : 1 tache par core

Temp court c’est une question de point de vue : 4 min c’est long

J’ai aucun repeter ou auto … sur les 1000 commandes. Rien que des jamais