Le test a été effectué sur un Raspberry Pi 400 avec 4Go de RAM, donc oui dans ce cas là ça fait un vrai boost car un système 32 bits gère environ 3.5 GB de RAM max, et le passage au 64 bits permet à un seul process de prendre toute la RAM au besoin
Sur n’importe quel autre Pi, le gain ne sera pas aussi fort, et il peut même être négatif sur certain modèle.
Mais je suis d’accord sur le fait qu’avoir une image 64 bits sera utile, à partir du Pi 4 d’après les benchmark il y a un vrai intérêt
( Et j’ai cru voir des leaks d’un Raspberry Pi 4 + qui aurait jusqu’à 16Go de RAM… Là ce sera clairement nécessaire )
Là où ça m’intéresse, c’est que théoriquement un système 64 bits peut avoir des performances améliorées sur les opérations genre chiffrement/compression.
Dans Gladys, ça peut avoir un vrai impact sur toute la partie Gladys Plus :
Le chiffrement de bout en bout théoriquement plus rapide?
La sauvegarde quotidienne (compression gzip + openssl pour le chiffrement)
Si besoin de test, j’ai un RPi 4 4Go et SSD Gladys est dessus mais c’est aussi mon Media Center (Kodi) d’où mon intérêt pour des performances améliorées
Installation sans souci, tout fonctionne comme avant
Intégration MQTT fonctionnelle, le container est lancé, tourne bien
Intégration Zigbee2mqtt fonctionnelle
Retours sur l’image Raspberry Pi OS 64 bits Bullseye sur SSD/Pi 4 - 8 Go :
Lancement ok,
Backend de mise à jour au démarrage,
Intégration MQTT fonctionnelle,
Intégration Zigbee2mqtt fonctionnelle, une erreur est survenu pendant le démarrage, mais il s’en est dépatouillé tout seul ^^
Intégration Bluetooth testée rapidement avec mon tel, il a bien détecté et j’ai pu l’ajouter … pas d’autres appareils bluetooth ^^ mais ça à l’air fonctionnel,
Intégration caméra fonctionnelle,
Intégration tasmota fonctionnelle,
Backup Gladys Plus semble fonctionnel, les fichiers ont bien été créés dans le dossier /var/lib/gladysassistant/backups/ mais pour le moment pas de refresh de l’envoi sur le backend
J’en profite pour proposer d’avoir un retour sur l’exécution en cours et les étapes réalisées lors d’une sauvegarde manuelle (on voit dans le dossier backup qu’il y a une première étape de copie de la base, puis une seconde de compression et enfin je suppose l’envoi vers Gladys Plus. Si une étape bloque, le message pourrait peut-être spécifier à quelle étape pour mieux debug),
Tout me parait bon pour le moment également, plus qu’à voir dans le temps si ok pour les backup !!
Pour infos, l’interface m’a l’air beaucoup plus rapide, notamment les pages avec de nombreux graphiques … Est-ce lié au 64 bits ??
Merci du retour @Terdious ça fait plaisir de lire ça !!
@lmilcent m’avait fait le même retour en décembre, j’ai créé une issue github:
Oui c’est lié au 64 bits, et à mon avis c’est plus lié à l’image Docker buildée en ARMv8 64 bits que le passage de l’OS en lui même !
En gros, jusque-là, pour avoir une image unique qui marche sur tous les Raspberry Pi, on buildait l’image Docker en ARMv6 (car les Pi 1, 2 et Zero sont ARMv6)
Ce qui était dommage, c’est que ton Pi 4 a un CPU ARMv8, qui lui a beaucoup plus d’instructions. Par retro-compatibilité, les images ARMv6 fonctionnaient quand même, mais sans prendre parti de toutes les possibilités du CPU.
En passant en 64 bits, tu télécharge maintenant l’image Docker linux/arm64/v8, qui elle est compilée pour cette architecture.
Tout ce qui est code compilé, ou qui fait appel à des fonctions systèmes compilés devrait voir ses performances grandement améliorée :
Accès à la DB (Car le binaire de SQlite3 est compilée ARMv8 64 bits désormais)
Chiffrement de bout en bout pour Gladys Plus, compression et chiffrement des backups
Tout ce qui est lié à de la compression, du chiffrement, des calculs
Ce serait chouette de quantifier ces améliorations pour faire un petit blog post (avec un petit titre putaclic)
Suite à ton retour, comme le retour est vraiment positif et correspond à ce que je voyais aussi, j’ai publié l’image sur le site et sur Rpi-Imager !
Je ne vais pas faire de communication pour l’instant en revanche, on va laisser l’image être progressivement téléchargé et voir ce que ça donne Je ferais de la com semaine prochaine je pense.
En revanche, pour vous qui connaissez Gladys, je ne recommande pas de passer par l’image affichée dans Rpi-Imager (mais par un téléchargement manuel + Rpi Imager), car j’ai remarqué que le menu “avancés” qui permet de rentrer les informations de connexion au Wi-Fi n’apparaissaient pas sur les images non-custom, mais il apparait bien quand on télécharge l’image en local :
Bon après presque 2 jours de retour, une remarque toutefois, j’ai à nouveau des « blocages » moins récurrents (j’ai l’impression que cela se produit seulement sur des requetes de création / suppression de devices) et pas de plantage de Gladys, la page reste toujours affichée mais reste en recherche 2 min environ, je n’ai aucune idée d’où cela peut venir, contrairement à avant, aucun log docker. Tout est freeze. Sur l’inspecteur idem, aucune requête ne passe, la seule chose que je peux voir c’est ça :
Je sais ce qu’il se passe, tu as du effectivement supprimer un appareil.
Sauf qu’actuellement dans Gladys, quand tu supprime un appareil, ça va supprimer en cascade toutes les device_features ainsi que les états de ces features
Tu l’as compris, si derrière cet appareil a des milliers d’états, ça peut prendre 2 minutes et pendant ce temps là, la DB est bloquée car c’est une énorme transaction qui prend toute la bande passante du disque.
On a pensé à une solution si ce problème devient trop récurrent, ce serait de supprimer de manière plus soft les états, en étalant dans leur temps leur suppression (200 par 200 par exemple), pour laisser l’instance Gladys respirer entre ces suppressions.
Après c’est un développement à part entière Tu peux créer une issue github pour qu’on garde une trace de ça ? Je te garantie pas que je vais travailler dessus dans les jours qui viennent, mais tu as raison c’est un point important
Aucun soucis, je te crée ça. Bien sûr qu’il n’y a aucune urgence là dessus, on ne supprime pas de device tout les jours. Et tant qu’on sait que c’est normal, on peut être patient ^^