Forum Domoticz en français

Bonjour,
De très nombreux posts et excellents articles sont disponibles sur wiki et les forums sur comment optimiser la configuration Domoticz pour préserver la vie de la carte SD.

Je n'ai en revanche trouver nul part d'indicateurs et de références disponibles permettant d'auto évaluer une configuration domoticz, bref comment apréhender si l'on écrit raisonnablement peu, beaucoup, trop ou dangereusement trop ?

Bien sur la solution pourrait être d'attendre le crash de la carte SD et donc d'en déterminer une durée de vie

Plus scientifiquement, mieux vaut prévenir que guérir, aussi je propose de partager les configurations et d’évaluer les taux d’écriture afin que chacun puisse se faire son opinion et apporter les améliorations jugées nécessaires.

Je propose de me lancer, aussi veuillez trouver un résumé de paramètres de configuration qui me paraissent intéressant à partager.

- Domoticz version stable V3.18153 avec database updatée toutes les 5 minutes, Automatic Backup de domoticz selectionné.
- Log minimaliste et RAM drive configuré sur la base de l'article suivant a l'exception du Var/log https://easydomoticz.com/preserver-la-s ... e-cle-usb/,
- domoticz.db-shm et domoticz.db-wal en RAM drive: https://www.domoticz.com/wiki/Moving_Lo ... _RAM_Drive
- Bus 1Wire - 15 sondes
- RF Link - 1 sonde RF - 6 prises RF en manuel sans scenario de commande
- 5 Teleinfo relayées par des Scripts bash et Lua écrivant dans base SQL domoticz via JSON API chaque minute environ 20 valeurs.

Bref une config plus de type monitoring que domotique au sens contrôle de processus à proprement parler.

Configurations, identification des fichiers écrits et évaluation des taux d'écritures au moyen des 3 commandes suivantes:
Ci dessous, le snapshot a l'instant t, l'important étant d'évaluer la variation de KB écrit (kB_wrtn) sur une période donnée, idéalement de 24h.
Sur 24h, le Taux d'écriture sur Carte SD est de 506 441 KB/jour

Pour information juste avant la mise en RAM de domoticz.db-shm et domoticz.db-wal, le taux d'écriture était de 2 753 837 KB/jour soit plus de 5 fois supérieure.

Alors est' ce grave Docteur ?
Encore longtemps à vivre ?

Vos expériences, références et commentaires sont les bienvenues

Intéressant.

Je ne sais pas si on peut en déduire la fin de vie d'une carte sd.
Ça dépend plutôt dans quelle "case" mémoire on écrit et ré-écrit, et ceci n'a pas grand chose à voir avec un fichier dans son système de fichier.

Par contre, je me demande si mettre les fichiers de journalisation de la base sur un ramdisk est une bonne idée ;
Comme je l'ai indiqué récemment, le fichier -wal sert à défaire une transaction qui n'a pas abouti correctement.

Il est possible que domoticz s'en serve après un crash du programme ou une coupure de courant par exemple, et conserve ainsi une base cohérente.
Si c'est sur ramdisk, il n'y a plus rien après le reboot, et donc pas de retour arrière possible.

Chrominator a écrit : Je ne sais pas si on peut en déduire la fin de vie d'une carte sd.

Nous sommes 100% d'accord, impossible de prévoir la durée de vie d'une carte SD, entre les différentes technologies de celles ci , MLC ... le firmware associé et technique de wear-leveling, adressage virtuel, l'organisation du file system, la rotation des fichier etc ..... beaucoup trop de paramètres et aucun intérêt.

En revanche au sein d'une config domoticz qui ne sollicite qu'un certain nombres de fichiers relativement limités, et déjà identifiés pour la plupart, nul doute que des taux d'écritures dans des rapports de 5 ou 10 font la différence sur l'espérance de vie de la carte.

Savoir que quelqu’un qui claque une carte SD tous les 3 mois avec une config sollicitant sa carte avec un taux d’écriture mesurable, est à mon sens une information intéressante à partager.

Chrominator a écrit : Il est possible que domoticz s'en serve après un crash du programme ou une coupure de courant par exemple, et conserve ainsi une base cohérente.
Si c'est sur ramdisk, il n'y a plus rien après le reboot, et donc pas de retour arrière possible.

Je n'ai pas d'avis sur la question et j’entends parfaitement tes propos sans être à même de juger si cela est effectivement problématique ou pas.

j'accepte le risk du plantage nécessitant la récupération manuelle de domoticz.db depuis un backup au profit d'un taux d'écriture en carte SD optimisé et ainsi éviter de remplacer une carte SD tous les x mois.
C'est peut être une erreur j'en conviens surtout ne connaissant pas le fameux x, pas toujours facile de faire son choix

C'est bien l’objectif du post que de confronter les avis et les expériences de chacun, les avantages, inconvénients de chaque config et de tenter de définir un référentiel de taux d'écritures.

@Chrominator, pour commencer, depuis combien de temps tournes tu sur ta carte SD ? A quel taux d’écriture la sollicites tu sur 24h et comment résumerais tu ta config ?

salut à tous

j'ai beaucoup étudier la question aussi, et lus tous plein de chose varié sur le net.

pour commencer ma carte SD a plus d'un an et demi malgré un usage hyper intensif.
description résumé :
- jusqu’à récemment tous les log sur la SD (autant l'OS que Domoticz)
- jusqu’à récemment 2 dongles sur 2 compteurs erdf pour la téléinfo, sollicité toutes les 5 sec avec pas mal de paramètre. (gros log) (maintenant 30sec)
- jusqu'à récemment 1wire sur 5 sec (maintenant sur 60sec, uniquement des DS18B20 donc inutile de mettre plus)
- motherboard sensor du Pi historisé sur domoticz (gros log aussi)
- météo internet
- 28 périphérique z-wave représentant 184 dispositifs
- backup auto d'origine activé
- backup fait maison via ftp pour les logs + image complète de la SD sur un NAS synology

donc au niveau quantité de donné écrite je dois être dans un haut du panier facile je pense, pourtant m'a carte micro SD ne bronche pas depuis presque 18 mois.

J'en ai déduis 2 choses, d'abord l'utilité de mettre une carte micro SD surdimensionner (ok ça a un prix...) tout en ne partitionnant pas la totalité du support. ex une carte de 16giga utilisé sur 8 ou 10giga, primo on gagne du temps lorsqu'on fait une image (backup sur NAS), deuzio, le système de répartition fera durée la carte bien plus longtemps, car il affectera les octet aux blocs les moins usée. Donc une carte de 16g utilisé à 8 sera bien plus "fiable" qu'une de 8, car les blocs utilisable sont dans mon exemple 2 fois plus nombreux que ceux potentiellement utilisable.
Une carte de 8g utilisé sur les 8g, pourra non seulement pas facilement répartir l'usure car beaucoup de bloc seront "fixe/occupé", et en aura 2 fois moins de disponible.
Je sais pas si je m'explique bien, mais le principe est la.

2eme chose : un onduleur est vital ! j'ai investie dans un onduleur en même temps que j'ai changé la microSD la dernière fois (18 mois) suite à un plantage, absolument aucun soucis depuis.
Moi j'ai investi dans du lourd : APC Back-UPS Pro 1200, il me sert a secourir les 2 box internet, les switch, le PC fixe, le NAS synology et tous ce qui est lié a la domotique. Si Pc fixe en utilisation avec 2 écrans, autonomie de 15min, sinon 45min/1h pour la domotique/box internet etc..
Après un bien plus petit peut suffire pour les petits budget, la majorité des coupures n'excédant pas quelques minutes (du moins chez moi)

Et quand on creuse sur le net, on remarque que la majorité des problèmes remonté le son vis a vis de la micro sd bien sur, mais surtout après coupure de courant. (et donc plus la carte vieilli plus elle aura "subi" de coupure)

Pour l'alimentation, j'ai acheté ça.
Avantage, ne coupe pas l'alimentation USB en cas de coupure de courant, se charge et alimente en même temps, le top.

fabienp a écrit : donc au niveau quantité de donné écrite je dois être dans un haut du panier facile je pense, pourtant m'a carte micro SD ne bronche pas depuis presque 18 mois.

Bonsoir,
Retour d’expérience très intéressant, pourrais tu tenter de quantifier en taux d’écritures sur 24h ce que tu qualifies de "Haut du panier"
Cdlt

je viens d'installe iostat pour faire comme tu demande.
j'ai fais une capture ce jours, 22 926 858kB ecris depuis le dernier redémarrage je suppose, qui d’après domoticz a eu lieu il y a 7,5 jours (183heures pour être exact.)
donc 22 926 858 / 183h = 125283kB / heure
125283 * 24 = 3006801 kB pour 24h, soit 3Go par jour, eh ben, elle écrit la bestiole !
je pensais pas autant...
autant dire que niveau usure, j’envoie du patté, pourtant la carte tiens la route depuis tous ces mois.
donc en theorie, si ma carte fait 16Go, je l'utilise a moitié (partition de 8Go).
en gros on va arrondir, je la remplis tous les 3 jours.
Les cartes de marque sont donné pour 100 000 cycles (je pars du principe qu'ils sont bien répartie au vue du fait que j'ai surdimensionné ma micro sd, donc répartition de l'usure des blocs presque parfaite).
3 * 100 000 = 300 000 jours... je me suis loupé quelques part dans mon calcul non?
sinon ça signifierai que je peux la garder a vie en admettant qu'elle ne subisse pas de surtension, sur intensité, coupure de courant etc... plausible si je conserve en bon fonctionnement mon onduleur ( qui est de très bonne facture, cf la ref plus haut)



EDIT : rectification, 100 000 cycle c'est pour de la SLC, ils semble que la majorité des cartes soit plutot en MLC ou TLC, en moyenne 3000 cycles pour les bonnes cartes et ça tombe à 1000 pour les pires, ça monte à 10 000 pour les meilleures.
donc en refaisant le calcul :
moyenne à 9000jours , mini à 3000jours, et maxi à 30000 jours.
donc au moins 8,21ans, et je peux espérer 24.65 ans pour la moyenne? je me suis encore loupé quelque part?

Ma première carte SD de 32GB m'a fait un peu plus d'un an. J'avais optimisé un peu sur le tard les logs domoticz en tmpfs en ram (les logs système, je préfère les conserver sur la SD pour avoir une chance de comprendre en cas de pb) et surtout le FTP qui reçoit les captures des caméras. Je devais le faire de suite, un peu tard et repoussé au lendemain... puis oubli jusqu'à ce qu'un jour, suite à un plantage consécutif à des IO error...

Suite à cela, la SD était presque rincée. Ses perfs avaient aussi bcp diminuées. J'ai restauré un backup et la dernière BD, ca a "tenu" 1 mois. Le temps d'acheter une kingston gamme industrielle (qui au moins tiens mieux en Tre car mon PI3 dans un meuble ventilé peut tutoyer les 50°C l'été niveau SoC, un peu moins sur la SD mais tout de même).

Sur les stockages flash, surtout amovibles, j'ai lu ici le conseil de surdimensionner en sous-partitionnant. Cela a toutes chances de fonctionner sur un vrai SSD (ancien ou utilisant un système de fichier n'utilisant pas la commande TRIM, car avec cette dernière cela n'a plus guère d'intérêt car le FS sait alors dire au controleur de stockage quels blocs il n'utilise plus suite à un effacement), pas sur un stockage normalement amovible tel SD/USB.

La raison est que les compteurs de cycles d'effacement des secteurs de flash sous-jacente sont maintenus dans une ram du controleur de stockage intégré à la SD (qui va émuler un disque Sata standard, cad une machine à lire/écrire des blocs/LBA). Ce sont ces compteurs qui servent aux stratégies d'égalisation de l'usure.

Dès lors, on comprends qu'une égalisation de l'usure qui se fait de manière globale (ou statique, cad qu'on peut bouger toute donnée même invariante) en bonne partie en tâche de fond quand le stockage sert peu n'a aucun sens avec un périphérique fait pour avoir de courtes périodes d'utilisation, disjointes, et entre lesquelles ces données sont perdues.

Les controleurs de stockages amovibles font donc une égalisation de l'usure simplifiée, dite dynamique. Cad qu'elle n'a lieu que sur les données qui sont écrites. Les données invariantes ne sont pas concernées. Donc inutile de créer du point de vue du stockage de vastes zones de données invariantes en sous-partitionnant un stockage sur-dimensionné. Cela ne pourra pas être utilisé.

A ma connaissance, seuls des stockages industriels (type eUSB, voir SD industrielles) fonctionnent de ce point de vue comme un SSD interne.

fabienp a écrit :je me suis encore loupé quelque part?

Non, mais cela suppose que l'usure est vraiment uniformément distribuée sans création de "point chaud". Hors, cf mon autre message, ce qui fonctionne sur un stockage interne a toutes chances de ne pas être vrai sur un stockage amovible car pour l'utilisation majoritaire qui en est faite un contrôleur évolué faisant un wear-levelling statique n'a pas de sens.

En réalité, on voit les perfs baisser graduellement jusqu'a tomber en IO error.

IO error qui peut être du au fait que les effacements de secteurs de flash sont devenus si lents avec l'usure qu'ils tombent en timeout (cela va donc re-fonctionner sur restauration d'une image... jusqu'a ce que ce secteur resserve), que le stockage se sentant défaillir se passe en read-only pour tenter de protéger les données existantes et donner une chance de récup à l'utilisateur (là, point de remise en fonctionnement possible)... ou bien les données deviennent vraiment volatiles et les checksum du système de fichier qui les lit sont KO: Une flash neuve les garde en moyenne 10 ans, mais quand on en arrive au max du nb de cycles d'effacement cela tombe sous l'année.

En pratique, il faut plutôt considérer la fraction de données qui bouge (logs etc) et va créer des points chauds pour calculer la durée de vie. Pas la capacité totale.

Je pense que nous sommes dans le cœur du sujet.

Je partage le sentiment avec @lost sur le fait que le sous partitionnement ne contribue par à étendre la dilution des cycles d'effacements écritures sur des cartes SD et que comme dans tout system ce sera le maillon faible, donc les Hot spots qui seront la cause de plantage dès lors que les Bit altérés seront critiques au fonctionnement de domoticz.

N'oublions pas non plus qu'un log altéré jamais relu ou incorrectement relu ne fera pas planté le système, pas plus qu'un backup corrompu non exploité.

Même si les config varient, je retiens de @fabienp qu'une config avec backup domoticz c'est très proches de 3GB/j et comparable au taux que j'ai mesuré de 2.7GB/j et qu'une carte de 8GB peut tenir jusque 18 mois. C'est vrai qu'il y a carte et carte et tout ne se vaut pas.

Qu'en es-t’il de ton coté @lost, as tu une idée de ton taux d’écriture qui a mené ta carte de 32G a se dégrader en perf aussi rapidement et claquer après 1 an seulement ? (iostat -kt après install du package ou alors vmstat 1 1 -a -p /dev/mmcblk0p2 sans oublier de diviser les "requested write' par 2 s'agissant de secteur )