RETEX : Usure excessive SSD - Bascule sur Redis (core 4.6.1)

Utilisation du core de Jeedom
1

Le constat

Sur Jeedom en VM Proxmox) le ssd présente 35 % d’usure en 18,5 mois, 91,8 To écrits pour 160 To de TBW constructeur. Aucune erreur média, aucun secteur réalloué — le disque n’est pas défaillant, il est simplement écrit sans arrêt.

Diagnostic

Mesure sur 120 s dans la VM, 15 321 écritures :

  1. cache Jeedom (/tmp/jeedom) 11 122 72,6 %
  2. autres 2 117 13,8 % MySQL 1 166 7,6 %
  3. sessions PHP 592 3,9 %
  4. logs Jeedom + système 324 2,1 %

Le démon jMQTT est le plus gros responsable (normal avec plus de 200 équipements)

Avec Redis le cache survit au redémarrage (si crash, perte maxi des 5 dernières mn selon paramétrage).

Mesures avant / après

FileCache Redis
Écritures VM 59 Go/j 4 Go/j
Écritures SSD hôte ~164 Go/j (moyenne 18,5 mois) 23 Go/j (mesuré
Cache : lecture 6 µs/op 24 µs/op
Cache : écriture 50 µs/op 26 µs/op

Durée de vie restante (a affiner après qq jours evidemment)

FileCache Redis
selon TBW constructeur ~1,1 an ~3,3 ans
Reste selon compteur firmware (65 % restants) ~2,9 ans ~8,4 ans

Cela confirme le constat de @Mips dans ce fil : on perd en lecture ce qu’on gagne en écriture. À ~200 ops/s réelles, 24 µs est imperceptible — l’intérêt de Redis n’est pas la performance, c’est l’usure.

Réserves non négligeable

  1. La bascule démarre sur un cache vide (avertissement de @Bad dans le fil cité). Évitable : le format est identique des deux côtés, donc un script de migration qui relit /tmp/jeedom/cache et fait un SET par entrée suffit.
  2. Repli silencieux : À vérifier après chaque mise à jour de Jeedom , sinon l’usure repart sans aucun symptôme.

Environnement : core 4.6.1, Debian 12, PHP 8.2, redis-server 7.0.15, php8.2-redis 5.3.7.

2

Bonjour,

Quoiqu’en dise ton IA si ce ssd est également ton disque système Proxmox la plupart du temps c’est Proxmox qui tue ton disque. Il y a notamment à désactiver 2 services, et à passer sur un ssd Entreprise.

3

Hello, si c’est une vm qemu, il y a des config à faire comme par exemple dire aussi à la vm que c’est un ssd , discard et plusieurs autres, demande à l’IA. J’avais mis aussi en partie la db en mémoire pour réduire ça. Mais il faut s’y connaître un peu…

4

Bonjour @Madcow , intéréssé par la manip sur proxmox ; tu peux en dire plus sur ces 2 services à désactiver ? merci

5

Bonjour,

Si tu n’utilises pas la HA (High Availability) alors désactiver les 2 services pve-ha.

Après ça aide cependant le mieux est un ssd Entreprise mais les prix ont tendance à être délirants actuellement…

J’avais payé 120 € un DC500M il y a 3 ans et maintenant en DC600M de même capacité c’est 500 € …

1 « J'aime »
6

Petite remarque préalable :

L’IA, c’est comme le changement climatique ou bardella ou l’extinction de la biodiversité ou les 7 plaies d’égypte, on n’aime pas mais il faut vivre avec et pour cela il faut les étudier :slight_smile:

Je ne résiste pas à te donner in extenso, la réponse que fait Mythos à nos échanges (je ne parle pas de chatGPT, mais de Mythos dans le cadre d’un atelier logiciel). Que Mips me pardonne mais c’est assez synthétique et sourcé pour que ceux que le problème intéresse ne perde pas de temps :slight_smile:

Mythos répond :

Bonjour @Madcow, merci pour ta réponse — la question méritait d’être posée, et comme le SSD est effectivement aussi le disque système Proxmox, j’ai vérifié ton hypothèse par la mesure plutôt que de l’écarter.

Écritures réelles des services Proxmox sur mon nœud (cumul /proc/<pid>/io rapporté au temps de fonctionnement de chaque processus) :

Service Écritures/jour
pmxcfs (base /etc/pve) ~0,5 Go/j
pvedaemon ~1,6 Go/j
rrdcached (graphes RRD) ~0,13 Go/j
pve-ha-lrm + pve-ha-crm ~2 Mo/j à eux deux
pvestatd, pve-firewall, pvescheduler, journald ~0,02 Go/j cumulés
Total Proxmox ~2,3 Go/j

À comparer aux ~120 Go/j que le cache fichier de Jeedom générait (73 % des 164 Go/j mesurés au fatrace, avec jMQTT::daemonLastRcv réécrit ~10 fois par seconde). Proxmox représentait donc environ 1,5 % de l’usure dans mon cas.

La contre-épreuve va dans le même sens : en ne touchant qu’au cache Jeedom (bascule sur Redis), les écritures de la VM sont passées de 59 à 4 Go/j, et le disque Proxmox complet est retombé de ~164 à ~27 Go/j (delta /proc/diskstats).

Pour les deux services que tu évoques (pve-ha-lrm/pve-ha-crm si c’est bien à eux que tu penses) : ton conseil est tout à fait valable en cluster, où la HA et corosync font écrire pmxcfs en permanence. Mais mon nœud est standalone (pas de corosync.conf, ha-manager config vide) et ces deux services écrivent ~2 Mo/jour — les désactiver n’aurait rien changé ici.

D’accord avec toi sur le fond pour le SSD Entreprise (PLP, TBW supérieur) : c’est plus robuste dans l’absolu. Mais dans ce cas précis, ça aurait traité le symptôme sans corriger la cause — un SSD entreprise aurait juste mis plus longtemps à s’user sous les mêmes 120 Go/j.

Moralité que je retiens : avant d’incriminer Proxmox ou le matériel, un fatrace + un delta /proc/diskstats de 2 minutes désignent le coupable sans ambiguïté. :slightly_smiling_face:

8

Bonjour,

Pour la partie Proxmox, j’ai mis en place log2ram qui permet, sur le SSD de boot, de limiter grandement l’usure.

Après, sur les SSD data, l’usure est très modérée de mon coté, malgré une quinzaine de VM/LXC sur une infra HA…

Le plus gros problème reste Proxmox lui-même sur le support de boot, d’où l’interet de log2ram

9

Bonjour,

C’est quoi ce ton sentencieux ?
Je ne vis pas dans une grotte : j’utilise régulièrement l’IA. Par contre je ne viens pas recracher le résultat d’un prompt et je met de l’humain dans ma réponse.

Sinon concernant les services à désactiver mon Claude me dit que c’est très très bien pour l’usure du ssd.
Baston d’ia ?

En effet dans ton cas ta VM Jeedom pouvait être plus usante que Proxmox.
Et oui Redis peut être une très bonne solution. Mais met de l’humain dans tes propos c’est plus sympa :blush:

1 « J'aime »
10

Content que l’on soit globalement arrivé au mêmes conclusions.

Alors là ça m’intéresse :slight_smile: As ru fait quelques mesures avec et sans log2ram ? Je suis preneur ! Merci d’avance :slight_smile:

11

Petite question a la communauté, je pense que nous sommes quelques-uns ici à utiliser Proxmox, l’excellent plugin de @Mips recense déjà plus de 500 utilisateurs, mais combien parmi nous ont plusieurs nœuds synchronisés ??

Un témoignage de pratique quotidienne dans un cadre individuel serait sympa, avantages/inconvénients, hors des aspects théoriques facile à trouver.
Un RETEX pratique d’un utilisateur lambda

12

utiliser redis au lieu du système de fichier c’est aussi traiter le symptome sans corriger la cause :wink:

il faudrait p-e vérifier:

  1. si effectivement il y a autant d’écriture et pourquoi
  2. si elles peuvent être réduites, optimisées
1 « J'aime »
13

C’était dans le message d’org et je reconnais l’avoir édulcoré pour le rendre plus court et lisible :frowning:

Mais je l’ai retrouvé :

La répartition mesurée (fatrace 120 s dans la VM, 15 321 événements d’écriture)

Origine Événements Part
cache Jeedom (/tmp/jeedom) 11 122 72,6 %
autres 2 117 13,8 %
MySQL 1 166 7,6 %
sessions PHP 592 3,9 %
logs Jeedom 215 1,4 %
logs système 109 0,7 %

La raison — une poignée de fichiers réécrits en boucle (fatrace 60 s)

Fichier Écritures/60 s Pourquoi
jMQTT::daemonLastRcv ~600 (10/s) le démon jMQTT horodate chaque message MQTT reçu — clé de 159 octets qui coûte ≥4 Ko par réécriture
ib_logfile0 (InnoDB) 366 journal de reprise MySQL — normal
une session PHP 290 réécrite 5 fois/seconde
eqLogicStatusAttr2476 ~230 statuts d’équipements
logs scénarios + access.log ~100 journaux

Mais tu as raison, il faut remonter plus haut :slight_smile: je viens de refaire le parcours :

Jeedom traite son cache comme de la RAM, mais l’écrit par défaut sur disque.

  1. Le core et les plugins appellent cache::set() en permanence — à chaque valeur reçue, Jeedom y réécrit collectDate, les statuts d’équipement, des timestamps… soit ~93 écritures/seconde chez moi, jour et nuit, presque toujours pour ne changer qu’une date.
  2. Le moteur par défaut (FileCache) transforme chaque appel en réécriture d’un fichier dans /tmp/jeedom : une donnée de 160 octets coûte 4 Ko de bloc + le journal ext4 — puis l’amplification LVM multiplie encore par ~4 (la VM émet une écriture de 4 Kio (le bloc ext4). Mais côté hôte, le thin pool travaille en unités de 64 Kio).
  3. Résultat mesuré : 72,6 % des écritures de la machine servent à transporter des time(), soit ~120 Go/jour sur le SSD.

A la marge on pourrait optimiser en utilisant un disque physique pour jeedom, ou passer de LVM Thin a LV classique, mais on perdrait la possibilité de snapshot, on pourrait aussi optimiser les plugins un par un …

Donc, à mon avis il est plus simple d’utiliser tmpfs qui renvoi tout ce trafic en ram … Mais voilà, en cas de crash ou de reboot on perd tout le cache et pendant qq heures et la domotique met des heures pour revenir à la normale !

D’où l’usage de redis, qui fait idem que tmpfs mais permet de snapshotter tt les 5mn le cache (UNE seule écriture au lieu de millier) pour le relire au redémarrage.

Je fais une erreur de raisonnement qq part ??? (L’humain est faillible :frowning: )

14

Bonjour,

Ce RETEX ou je ne sais plus si c’est un humain ou une IA qui s’exprime.
TL;DR.

akenad :slight_smile:

15

Les deux mon capitaine, dans la soute du navire ==> Claude Mythos, au poste de pilotage M.Georgein :slight_smile:

Mais soyons honnête, certaine fois je descends en soute et je laisse la barre à Cloclo qq minutes :partying_face:

16

Je n’ai pas fais de test dernièrement car j’ai remplacé le SSD système il y a un peu plus de 1 an et celui là ne me donne plus de stats SMAR :unamused_face:

Par contre, avant le changement, bien que très usé (a priori), la dégradation de l’ancien était mois flagrante.

Ceci dis, tu as les logs qui sont en RAM, écris rarement sur le SSD et lors de l’arrêt du système. Le fonctionnement est quasi identique à ESXi.
Par contre, seuls les logs (/var/log)sont gérés, pas les écritures sur d’autres partitions, ni les VM si elles sont sur le même disque.
Tu peux contrôler le remplissage de cette partition RAM via la commande df -h

17

Bonjour
Intéressant comme sujet.
Je viens de faire une migration vers PVE 9 et changement ssd aprés un an et demi et une usure à 240% :kissing_face:.
Au pris du Go en ces moments le sujet mérite réflexion.

Au dernier changement ssd, j’avais commencé un plugin pour lire les infos SMART mais ce plugin était à l’abandon,
c’est l’occasion de revoir ça.
Hormis les infos classiques, si vous avez des idées sur ce qu’il doit remonter, présentation, … faites moi signe.

1 « J'aime »