Forum Communauté Jeedom

Une machine dédié avec pas grand chose dessus:
Intel atom N270 avec 1Go de memoire et un SSD dessus Cela fait pas un peu beaucoup?

L'important c'est ton ressenti utilisateur. Pas le chiffre.


Pour ma part entre 15 et 1,6 je ne vois aucun impact. A 15 c'est déjà de l'immédiat pour l'utilisateur.

avec tapatruc depuis mon Amiga500

Contenu supprimé à la demande de son auteur

Si je change c'est parce que justement mon jeedom était très lent. Il y a quand même eu beaucoup d'améliorations en modifiant la conf de php5-fpm mais ça n'était pas suffisant à mon goût.

mon bench :

jeedom sous ESXI

Nom Temps
cache_write_5000 0.37057209014893
cache_read_5000 0.1156919002533
database_write_delete_1000 0.90458488464355
database_update_1000 0.46959805488586
database_replace_1000 0.49875807762146
database_read_50000 0.062896966934204
subprocess_200 0.39302897453308
total 2.8151309490204

En rajoutant 20€ a la SD, ca fait un mSSD 30g + boitier, et tu descends a 8 (pi3) et bien plus fiable

Theduck38 a écrit :

edivad a écrit : Comment tu fais pour déporter MySql sur un Syno, ça m'intéresse ?
Du coup ça à l'air de porter ses fruits au niveau perf ?

Blablabla... voir posts précédents

Tu as essayé ? Ça fonctionne ?

k0n24d a écrit :

sbafs a écrit :Je suis preneur de tes optimisations.

Bien joué

Avec un peu de retard (oups il y en a qui commençaient déjà à raler...)

Le principal problème avec une carte SD c'est tout ce qui est I/O. Donc la chose la plus logique c'est de s'en passer.

Pour cela j'utilise folder2ram avec une synchro toutes les 8h (au pire ça m'est égal de perdre les 8 dernières heures de stats - je force une synchro si j'ai fait un gros reparamétrage).

Voici les répertoire que je monte en mémoire:

Code : Tout sélectionner

tmpfs    /var/log                                              -
tmpfs    /var/lib/mysql                                        -
tmpfs    /var/lib/mosquitto                                    -
tmpfs    /var/lib/nginx                                        -
tmpfs    /usr/share/nginx/www/jeedom/log                       -
tmpfs    /usr/share/nginx/www/jeedom/plugins/openzwave/data    -
tmpfs    /var/lib/php5/sessions                                -

C'est pour une installation avec nginx et fpm. Donc à adapter pour apache. Aussi il faut vérifier que tout rentre en mémoire avant de sauter le pas.

EDIT: j'ai fait d'autres petites optimisations mineures mais pas forcément adaptées à tous les cas et leur apport relatif est assez minime.

EDIT2: je vous conseille de regarder si d'autre plugin font beaucoup d'io dans votre cas spécifique (iotop, iostat, nmon sont vos amis)

Bonjour j'aurais bien voulu tenter mais je ne comprend pas ce qu'il faut faire ??

Coucou,

Juste pour vous faire part de ma récente installation.
Niveau Hardware, je n'ai rien changé comparé à avant. C'est à dire COre i3 4020Y, 8 Go de RAM et SSD Sandisk de 240 Go.

Mon installation d'avant :
WIndows 10 Pro installé sur le SSD dans son entièreté avec Kodi + SqueezeLite
Virtualisation de Jeedom avec 2 CPUCore et 2 Go de RAM, 20 Go de DD
Virtualisation d'un Windows 10.
Virtualisation via VMWare WKS 12 PRO

Mon score : de 9 à 10 !

Ma nouvelle installation :
ESXi 6 installé sur le SSD dans son entièreté (ISO de notre Rosty national :p)
VM Jeedom sous Debian 8.6 en suivant la doc d'installation avec les mêmes caractéristiques Proc, Mem, DD qu'avant
VM Windows 10
KODI est passé sous une Android Box à part.

Mon score : de 1.5 à 2 !

Je ne pense pas que Kodi joue un rôle important dans le score, surtout quand il ne fonctionne pas

Donc le hardware OK, mais le soft a aussi a rôle très important notamment dans la virtu.
Si ça peut aider certains à sauter le pas

Faudra voir aussi sous Hyper-V/ProxMox pour comparer lol

Good score

Je viens de trouver ce bench en me baladant sur le forum. Aussitôt lu, aussitôt testé.
Voici les résultats:
Nom Temps
cache_write_5000 0.18526482582092
cache_read_5000 0.065003156661987
database_write_delete_1000 0.12747097015381
database_update_1000 0.075957059860229
database_replace_1000 0.076498985290527
database_read_50000 0.028223037719727
subprocess_200 0.28319478034973
total 0.84161281585693

Cela confirme que ma config ( cf ci dessous ou là: viewtopic.php?f=66&t=21246#p378906) est totalement surdimensionnée; espérons que cela se traduira par un MTBF également surdimensionné!!

Bonjour à tous,

je compare aussi aux data postées par les autres membres, et je vois que mon système est particulièrement lent au niveau MySQL.
Mon système : Synology DS916+ @ 8ghz RAM & Docker : jeedom (jeedom/jeedom;lastest) + mysql (mysql:5.7.9)
Je prends toute astuce pour améliorer les perf.

Merci.

https://raw.githubusercontent.com/jeedo ... s.asciidoc

Et
Mettre /tmp en ram

Jeedom utilise /tmp comme systeme de cache le mettre en ram permet donc d’alleger les écritures sur disque et d’accelerer Jeedom :

sudo echo "tmpfs /tmp tmpfs defaults,size=128M 0 0" >> /etc/fstab
Il faut ensuite redemarrer le machine :

sudo reboot


Sent from my iPad using Tapatalk

nechry a écrit :https://raw.githubusercontent.com/jeedo ... s.asciidoc

Et
Mettre /tmp en ram

Jeedom utilise /tmp comme systeme de cache le mettre en ram permet donc d’alleger les écritures sur disque et d’accelerer Jeedom :

sudo echo "tmpfs /tmp tmpfs defaults,size=128M 0 0" >> /etc/fstab
Il faut ensuite redemarrer le machine :

sudo reboot


Sent from my iPad using Tapatalk

Bonjour @nechry

C'est peut être une question bête, mais y a-t-il un lien entre cette optimisation et la future optimisation sql de la version 2.4 ?
Ne risque t on pas d'avoir des soucis quand on passera en 2.4 si on a fait l'optimisation du wiki au préalable ?

A +

Complémentaire, dirais-je !

Envoyer avec mon pouce ...

c'est la même, elle sera juste déjà faite et pas a faire.

mais dans le doute faite un full backup de vos SD avant de toucher

Avec mon nouveau NUC i5-5250u, 250 Go SSD (un vieux crucial M4), 4 Go ram (bientôt 16 Go) :

cache_write_5000 0.18365383148193
cache_read_5000 0.067295074462891
database_write_delete_1000 0.16131091117859
database_update_1000 0.093036890029907
database_replace_1000 0.089575052261353
database_read_50000 0.029660940170288
subprocess_200 0.21640181541443
total 0.84093451499939

Ca va me changer des 28s avec mon Rpi 3 !

@prophete3d, pour les performances sur syno j'avais du activer le cache en écriture. Il y a un post la dessus plus haut dans cette discussion

Hello,

Petit retour avec cette config dédiée Jeedom (récupère juste une fois par semaine les photos stockées sur d'autres PC pour les dupliquer sur le SSD) :

Jeedom 2.3.18, PHP 5.6.14, Database 5.5.46, Debian Jessie 64
Gigabyte Brix GB-BXBT-J1900GB-XM33, 8 Go Ram, SSD Kingston 240Go V300
11 scénarios activés au moment des tests

Sur 10 benchmarks, temps total moyen : 5.6 +/- 0.6 sec

Globalement très content de cette config vu le bon ressenti

NUC6i5SYH avec esxi installé selon le tuto dans la doc.

cache_write_5000 0.2223699092865
cache_read_5000 0.078550100326538
database_write_delete_1000 0.15915822982788
database_update_1000 0.087925910949707
database_replace_1000 0.089269161224365
database_read_50000 0.027094841003418
subprocess_200 0.25626707077026
total 0.92063522338867

J'etais à plus de 250 avec mon pi2 pas tmpfs