Benchmark plateforme hardware

[stef]

bon, faut dire que j'ai changé par une VM sous Esxi, la machine à 4go de RAM là aussi, avec un samsung evo
j'en avais marre que mes lumières mette 5 secondes à s'allumer ( surtt ma femme hein ), du coup là, limite ça s'allume pas avant

[sela]

@Stef OK !!! Je comprends mieux tu es passé d'un RPi3 à une VM ! Le miracle est là...

@Sarakha63 J'ai tout à gagner à reconnecter mon SSD (rapidité + fiabilité)... J'y cours !

[Theduck38]

Hello,

Il semble (c'est ce que je constate en tous cas) que déporter la BDD dans un NAS puisse amener un gain de performances. J'ai été surpris par les 14s de mon RPi2 alors que je lisais ce fil depuis un certain temps. La seule différence dans mon cas est la BDD dans un NAS, et je ne dépasse pas les 3.5s en Write/Delete.

Pourtant, en théorie, je devrais écrire au moins à la même vitesse sur une classe 10 que via mon réseau en 100Mb (en considérant qu'il faut que le NAS prenne la demande, stocke les données et réponde à la requête)...

Je n'ai pas d'explication à ça pour le moment...

[totovaauski]

Pas vraiment un "gain", plutôt une " tranquillité " d esprit face aux écriture fréquente sur une carte sd. En plus tu cumul un peu les latences, ton réseau 100mb encaisse facile mais ton nas doit se "réveiller", secouer MySQL pour qu il traite l' info, MySQL doit écrire sur le disque ... Bref dans la ligne, tu " cumul" un peu... Donc rien d anormal...

Envoyer avec mon pouce ...

[Theduck38]

Oui, mais comment expliquer les 3,5s sur ce critère où une config identique est à 17s ?
Je comprends bien ton point, mais je trouve justement que mes perfs sont "anormalement" bonnes... et la seule différence est la délocalisation de la BDD qui ne devrait pas apporter d'amélioration.


Envoyé de mon iPhone en utilisant Tapatalk

[jolyp]

Bonjour
Est ce qu'il y a un tuto pour déplacer la bdd vers un nas (j'ai un synology avec tout ce qu'il faut)?
J'ai des iowait supérieurs à 20 % la moitié de la journée (dixit zabbix) sur un raspi 3 et cela m'inquiète un peu...
Merci

Envoyé de mon T03 en utilisant Tapatalk

[totovaauski]

@Theduck38, je pense que la fréquence d écriture doit jouer énormément, + de "buffering" sur une sd que sur un disque dur (via le réseau). Un test intéressant a faire : mettre la bdd sur un disque dur en USB (pas un ssd, un mécanique) je pense que tu aurais un résultat proche de 3,5s!

Envoyer avec mon pouce ...

[Theduck38]

Bonjour
Est ce qu'il y a un tuto pour déplacer la bdd vers un nas (j'ai un synology avec tout ce qu'il faut)?
J'ai des iowait supérieurs à 20 % la moitié de la journée (dixit zabbix) sur un raspi 3 et cela m'inquiète un peu...
Merci

Envoyé de mon T03 en utilisant Tapatalk

Tuto, je ne sais plus... mais tu dois modifier le fichier suivant :
/var/www/html/core/config/common.config.php (install Apache)
ou
/usr/share/nginx/www/jeedom/core/config/common.config.php (install Nginx)

Edit : en fait, c'est probablement un peu juste comme info... il te faudra exporter ta BDD depuis l'interface MySql du RPi et l'importer dans le syno (avec probablement des soucis de taille max)

[sbafs]

Pour moi je trouve vraiment bizarre les valeur sur la database, vous en pensez quoi ?
Pour info je suis sur un SSD avec un processeur 2 double coeur 1Ghz et 2G de RAM

[bartounet]

Je m'en sort pas trop mal avec mon RPI2 non ?
Simple RPI2 avec SD Sandisk classe 10 et /tmp en RAM



Et après migration sur un rpi3

Jeedom benchmark
Close
Nom Temps
cache_write_5000 1.2508409023285
cache_read_5000 0.53051114082336
database_write_delete_1000 8.6948189735413
database_update_1000 3.8680629730225
database_replace_1000 3.8629670143127
database_read_50000 0.29577684402466
subprocess_200 1.234277009964
total 19.737254858017

[k0n24d]

Bonjour,

avec un peu d'optimisation voici ce que j'obtiens sur une Jeedom Mini+ sur carte micro-SD

Code : Tout sélectionner

Nom                           Temps
cache_write_5000              2.3857519626617
cache_read_5000               0.94765996932983
database_write_delete_1000    1.7501339912415
database_update_1000          0.95206499099731
database_replace_1000         0.93275308609009
database_read_50000           0.27580308914185
subprocess_200                1.4492590427399
total                         8.6934261322021

[sbafs]

Je suis preneur de tes optimisations.

Bien joué

[Theduck38]

+1

[team18fr]

Moi aussi je suis intéressé, merci d'avance.

[Theduck38]

Est-ce que je suis le seul pour qui le benchmark ne marche pas ? Quand je clique sur l'icône, j'ai la roue crantée qui tourne, puis une fenêtre vide.

Je ne vois rien dans les logs. Je suis sur Docker sous OMV sur un N54L

J'ai le même problème sur un PC tout neuf "dédié Jeedom" que je viens de monter. L'install est toute fraîche et à jour. La roue tourne à l'infini et aucune erreur dans le log même en niveau Debug.
C'est frustrant de ne pas savoir, du coup...

[romainh41]

Bjr à tous

je viens de découvrir cette fonction Benchmark, et je crois que j'ai un gros souci....

RI 2 avec carte micro SD 16Go, 4 modules, une dizaine de scénarios, clé Gen Z-wave, clé 3G, et voici mes résultats :

benchmark.png (15.27 Kio) Consulté 1475 fois

Comment analyser ces résultats et que faire pour les améliorer ??

merci à vous

[kouaw]

il faut voir la class de ta SD après si le /tmp est en tmpfs

en suite il y a des petites astuces pour MySQL qui est ton point noir mais bon si tu as des camera et ou des scenario lourd sa joue aussi

[Swatmorpheus]

j'avoue que j'aimerai bien pouvoir décrire les différentes lignes du benchmark , si tu aurais un lien ou une explication kouaw ça serait cool et ça interesserait du monde merci d'avance

[romainh41]

il faut voir la class de ta SD après si le /tmp est en tmpfs

en suite il y a des petites astuces pour MySQL qui est ton point noir mais bon si tu as des camera et ou des scenario lourd sa joue aussi

/tmp n'est effectivement pas en tmpfs...

Carte SD classe 10. Si je prend une pro genre samsung, ce sera tjs mieux ? Je reste sur 16 ou je passe à 32 ?

Pour les astuces je vais regardes tous tes articles....

merci chef !

[kouaw]

pas tres complexe a comprendre les lignes

en gros les deux premier sont des operations sur le cache jeedom 5000 ecriture et 5000 lecture, le cache jeedom se trouve dans la partition /tmp donc si pas en tmpfs il est sur la SD donc dangereux pour la sd et ecriture/lecture lente

les 4 lignes après sont des operations sur la base de donnée
ecriture/suppression
mise a jour
remplacement
lecture

la c'est de l'optimisation MySQL + vitesse SD

et la dernier lignes le lancement simultanée.