Bonjour
Sur mon raspberry 3, pendant les mises à jour l’opération de backup semble génerer une chage CPU importante et le rend quasi inutilisable pendant cette opération.
Est ce qu’il serait possible de changer la priorité de l’operation d’archivage pour la baisser avec « nice » ?
Merci
Disons que le raspi devient limite pour les dernières version Jeedom / Debian
Donc je ne vois pas l’intérêt de pénaliser les machines récentes au prétexte que les machines plus anciennes souffrent.
Bonjour.
C’est pour cela que la sauvegarde s’effectue la nuit.
Question : combien de temps dure votre sauvegarde et quelle est la taille finale de cette sauvegarde.
J’ai des pi3b de test et je ne constate pas une tel gène.
La charge CPU est une notion qui n’existe pas…
C’est soit la charge, et une charge importante sur une opération de sauvegarde est souvent plutôt liée à des PB d’accès en lecture écriture sur le disque (et pour le coup, une saturation des accès disque peut vraiment empêcher une connexion, même ssh à la machine)
Soit le pourcentage d’utilisation du CPU, mais je ne vois pas pourquoi (à part sur une opération de compression) le CPU pourrait saturer …) De plus, une opération qui prend du temps CPU est déjà dépriorisée (nice) par rapport au reste des processus (colonne ni de la commande top)
Du coup, la question est effectivement
1 - comment analysez vous cette « charge CPU »
2 - quelle est la taille de votre save ?
3 - quel support de stockage est utilisé ?
Et un screenshot de la page santé serait carrément bien
Norbert
Bonjour
Merci pour vos réponses.
Mon raspeberry est déjà pas mal chargé par des process autres qui tournent dessus.
Ma suavegarde fait 275Mo mais peut prendre 30-40min pour se faire.
J’ai remarqué que pendant la création de l’archive, la charge CPU peut être dans les 75% avec un nice=0.
Il me semble que le fait de faire un nice à +10/+15 permet de ne pas bloquer la l’usage, en particulier pendant les mises à jour qu’on déclenche manuellement et donc pas la nuit…
Pour la page santé :
Il est à genoux tu veux dire
Bonjour.
Au lieu de tourner 40 minutes pour la sauvegarde, celle-ci va durer un temps d’autant plus long quelle sera ralentie.
Sur quoi tourne cette machine ? (comme support de stockage)
Un upgrade était en cours justement…
C’est un raspberry pi 3.
Le support est une carte sd qui est utilisée par le système. Je sais que ce n’est pas recommandé car les sd finissent par lâcher au bout d’un certain nombre de lectures/ecritures.
Pour éviter ce pb j’avais fait une manip qui consiste à utiliser une partie de la ram pour écrire le fichiers temporaires. Ça va dans le sens d’avoir un système un peu plus lent mais plus robuste. Avec une carte sd de qualité ça marche depuis 4/5 ans. Bien sur il y a une sauvegarde externe sur un NAS en cas de pépins…
Je sais bien qu’un Nice plus élevé augmente le temps de la sauvegarde mais je ne trouve pas que ce soit un problème. Je trouve plus gênant d’avoir le système indisponible car non réactif. Et en réalité ça ne va pas changer bcp car les opérations vont se faire par rapport à la capacité dispo de la machine. À moins de lancer une autre opération lourde en même temps on n’a va consommer qu’un peu de ressources pour la
réactivité.
J’ai des scripts pythons qui tournent en arrière plan pour la collecte des infos de ma domotique avec une priorité très basse. Aussi c’est surtout la fréquence à laquelle les données sont récupérés qui va baisser quand la machine est trop occupée par l’interface Jeedom par exemple.
Moi tout ce que je vois c’est une machine à genoux.
Pour une évolution d’OS et de Core cela va de plus en plus être limite
Alors, c’est très intéressant ce que vous dites.
Je vous conseil simplement de supprimer votre astuce 
Sur un Pi3B+, voici le temps de ma sauvegarde (1m30) :
0298|***************Jeedom backup end***************
0299|[END BACKUP SUCCESS]
0300|[START BACKUP]
0301|***************Start of Jeedom backup at 2024-01-24 01:20:02***************
0302|Send begin backup event...OK
0303|Checking files rights... OK
0304|Checking database...OK
0305|Backing up database...OK
0306|Cache persistence:
0307|OK
0308|Creating archive...
0309|OK
0310|Cleaning old backup...OK
0311|Limiting backup size to 1000 Mb...
0312|OK
0313|Backup name: /var/www/html/core/php/../../backup/backup-Jeedev-4.4.2-2024-01-24-01h20.tar.gz
0314|Checking files rights...OK
0315|Send end backup event...OK
0316|Backup operation duration: 94s
0317|***************Jeedom backup end***************
0318|[END BACKUP SUCCESS]
Voici le temps d’une mise à jour d’un plugin (6 secondes) :
0000|[2024-01-23 06:39:31] ALERT : [START UPDATE]
0001|[2024-01-23 06:39:31] ALERT : Début de la mise à jour de : MQTTDiscovery
0002|[2024-01-23 06:39:31] ALERT : Téléchargement du plugin (source : market)...
0003|[2024-01-23 06:39:31] ALERT : Téléchargement de MQTTDiscovery...
0004|[2024-01-23 06:39:31] ALERT : URL https://market.jeedom.com/core/php/downloadFile.php?id=4429&version=beta&jeedomversion=4.4.2&hwkey=2a0d63b42c4281d736b140535aaccb342c550ba00b05256b19a7c41bbeb071c&username=Fabrice.Goess&password=c4ab90e0de5a99b41dcf121245cfc3cf6ad3476b&password_type=sha1
0005|--2024-01-23 06:39:31-- https://market.jeedom.com/core/php/downloadFile.php?id=4429&version=beta&jeedomversion=4.4.2&hwkey=2a0d63b42c4281d736b140535aaccb342c550ba00b05256b19a7c41bbeb071c&username=Fabrice.Goess&password=c4ab90e0de5a99b41dcf121245cfc3cf6ad3476b&password_type=sha1
0006|Resolving market.jeedom.com (market.jeedom.com)... 57.128.120.126
0007|Connecting to market.jeedom.com (market.jeedom.com)|57.128.120.126|:443... connected.
0008|HTTP request sent, awaiting response... 200 OK
0009|Length: unspecified [application/octet-stream]
0010|Saving to: '/tmp/jeedom/market/MQTTDiscovery.zip'
0011|0K .......... .......... .......... .......... .......... 3.23M
0012|50K .......... .......... .......... .......... .......... 7.02M
0013|100K .......... .......... .......... .......... .......... 5.51M
0014|150K .......... .......... .......... .......... .......... 4.09M
0015|200K .......... .......... .......... .......... .......... 9.52M
0016|250K .......... .......... .......... .......... .......... 10.4M
0017|300K .......... .......... .......... .......... .......... 7.09M
0018|350K .......... .......... .......... .......... .......... 10.4M
0019|400K .......... .......... .......... .......... .......... 9.52M
0020|450K .......... .......... .......... .......... .......... 10.3M
0021|500K .......... .......... .......... .......... .......... 4.58M
0022|550K .......... .......... .......... .......... .......... 10.2M
0023|600K .......... .......... .......... .......... .......... 9.58M
0024|650K .......... .......... .......... .......... .......... 10.3M
0025|700K .......... .......... .......... .......... .......... 9.57M
0026|750K .......... .......... .......... .......... .......... 10.2M
0027|800K .......... .......... .......... .......... .......... 9.64M
0028|850K .......... .......... .......... .......... .......... 10.2M
0029|900K .......... .......... .......... .......... .......... 9.59M
0030|950K .......... .......... .......... .......... .......... 10.4M
0031|1000K .......... .......... .......... .......... .......... 9.67M
0032|1050K .......... .......... ....... 10.9M=0.1s
0033|2024-01-23 06:39:31 (7.71 MB/s) - '/tmp/jeedom/market/MQTTDiscovery.zip' saved [1103556]
0034|[2024-01-23 06:39:31] ALERT : OK
0035|[2024-01-23 06:39:31] ALERT : Décompression du zip...
0036|[2024-01-23 06:39:31] ALERT : OK
0037|[2024-01-23 06:39:34] ALERT : Action de pré-update...
0038|[2024-01-23 06:39:35] ALERT : OK
0039|[2024-01-23 06:39:35] ALERT : Post-installation de MQTTDiscovery...
0040|[2024-01-23 06:39:35] ALERT : Vérification des droits sur les fichiers...
0041|[2024-01-23 06:39:37] ALERT : OK
0042|[2024-01-23 06:39:37] ALERT : Suppression des fichiers inutiles...
0043|[2024-01-23 06:39:49] ALERT : OK
0044|[2024-01-23 06:39:49] ALERT : END UPDATE SUCCESS
0045|[2024-01-23 06:39:49] ALERT : Launch cron dependancy plugins
0046|[2024-01-23 06:39:49] ALERT : [END UPDATE SUCCESS]
Sur une carte MicroSD de qualité. Même si, préventivement vous voulez la remplacer tous les ans par pure sécurité, vous y gagnez à laisser les paramétrages d’origine.
Vous avez FORCEMENT créé la situation de lenteur que vous constatez.
Et peut-être passer sur une emmc qui améliore et sécurise.
Je viens d’installer l’update de Jeedom 4.4.2 (alpha), même configuration que vous : RPI3B+, carte MicroSD de qualité (cela compte beaucoup).
=> Temps de mise à jour de Jeedom : 98s
Vos problèmes de lenteur sont soit dû aux « bidouiles » coté OS que vous avez fait, soit au choix de votre carte MicroSD.
Il est facile de réinstaller Jeedom sur les Pi, faites le et laissez tout ce qui est OS par défaut et testez pas vous même.
Merci pour vos réponses et vos commentaires. Je pense que toutes les installations sont différentes et qu’en fonction du nombre de plugin installés, de services activés, etc les résultats sont différents. Il me semble aussi évident qu’un Rpi3 est une config modeste!
Voici ma page santé à jour
J’ai un facteur de charge un peu élevé, mais j’ai regardé sur un rpi3 il y a 4 coeurs donc une valeur autour de 4 me semble acceptable. J’ai plusieurs scripts python qui tournent pour la collection des données de mon installation (Domotique) et les renvoient vers jeedom en mqtt avec un nice très bas.
Ma modif du pour les fichiers temporaire est un ramdisk (Raspberry Pi : comment ajouter un RAMDisk) mais il ne fait que 10Mo.
Dans /etc/fstab
tmpfs /ramdisk tmpfs nodev,nosuid,size=10M 0
Je pense que mon Rpi est chargé par la façon dont j’ai construit mon installation mais son usage reste fluide.
Pour les sauvegardes la création de l’archive est consommatrice en CPU et génère un lag dans la réponse de mon jeedom. J’ai testé de faire un renice moi même et ça fonctionne bien. Ma question initiale était donc de savoir pourquoi ne pas mettre une priorité basse par défaut sur ce process ?
=> Quel enjeu est ce qu’il y aurait d’avoir une priorité basse pour la compression de l’archive de la sauvegarde ?
J’ai résolu mon problème en automatisant la mise à jour la nuit. J’ai un script de sauvegarde et de mise à jour de mon Rpi qui tourne la nuit et donc qui fait aussi la sauvegarde et mise à jour de jeedom maintenant. J’ai trouvé les liens pour jeedom ici pour ceux que ça intéresse :
/var/www/html/install/backup.php
/var/www/html/install/update.php mode=force
Vu la charge indiquée dans la page santé, le truc est à genoux.
On ne se rejoint pas sur la façon dont on cherche à utiliser un Rpi c’est pas grave
J’ai refait des tests sur ma carte SD récemment pour évaluer sa vitesse et son fonctionnement. Pour ceux que ça intéresse :
Jeedom intègre un benchmark directement dans la page santé.
On va pas modifier un truc dans Jeedom pour 1 utilisateur.
Et pénaliser les milliers d’autres qui n’ont pas le problème.
Je vous ai donné des références sur la même machine que vous, vous voyez bien que je suis au antipodes de vos problèmes.
Testez votre sauvegarde de Jeedom sur une installation fraîche avec Debian 11.
Donc en gros tu ne veux pas reconnaitre que ton raspi est à genoux vu la charge car vu ton install c’est normal.
Chose que les autres n’ont pas.
Mais il faudrait modifier le core pour toi ?
M’sieur Rrnault tu peux modifier ma voiture car moi je roule avec le frein à main, c’est comme ça mais ta brouette a pas les perfs attendues.
Je ne pensais pas que baisser la priorité d’un processus de backup puisse être penalisant pour les autres désolé. Donc désolé je n’ai pas du comprendre.
Loin de moi l’idée d’être directif pour les autres. Je pensais être dans la proposition c’est tout pas du tout dans la critique.
Bonne journée