framboise314.fr

Salut à tous.

J'utilise indifféremment mes Raspberry Pi avec mes deux disques que voici :
--> disque dur Maxtor de 512GB où tous mes développements s'y trouvent avec bullseye.
--> disque SSD Western Digital Green de 120GB pour des tests avec buster.

Je rencontre un problème de performance uniquement avec mes RPi 3A+, sous bullseye et pas sous Buster et j'ignore pourquoi.
Je n'ai aucun problème de performances avec mes cartes micro SD dans l'usage de mes RPi 3A+. Elles ne sont pas sous bullseye, mais sous stretch et buster.

A quoi me sert RPi 3A+ ? J'ai installé le module unicorn de 256 leds de chez Pimoroni. Pour mes tests, je l'ai oté.

J'ai commenté tout ce qui se trouve dans le fichier "/boot/config.txt" mais je n'ai pas touché au fichier "/boot/cmdline.txt".

En faisant un "top", je constate que le processus qui est très sollicité se nomme "kswapd0". Je n'ai pas de partition swap dans bullseye ni ailleurs. Avant de basculer vers bullseye, c'était déjà le cas !

Pas de problème d'alimentation car j'utilise depuis fort longtemps les même adaptateurs. Elles sont en 5,1Vcc et 3A. Je m'en serais rendu compte avant que je bascule vers bullseye.
Pas de problème non plus avec mes câbles USB A mâle vers Micro USB B pour le disque Maxtor et mon adaptateur Inateck UA1002 pour le disque SSD WD Green.

J'ai utilisé mon HUB USB pensant à un problème de puissance électrique, mais ce n'est pas le cas.

La seule différence que je vois est le fait d'utiliser bullseye !
Je supose que je dois trouver le bon paramétrage dans le fichier "/boot/config.txt" pour résoudre ce problème.

Si vous avez des suggestions à me fournir, je suis preneur car je ne sais plus où chercher.

Cordialement.
Artemus24.
@+

Bonjour
Tu sais que kswpa0 est un processus qui switch entre mémoire vive et mémoire de swap.
En cherchant sur google, je vois que cela a touché beaucoup d'utilisateurs d'Ubuntu (basée aussi sur Debian)
Est-ce que cela se produit tout de suite après un démarrage (je veux dire, après un reboot, as-tu un moment de calme ?)
Aurais-tu activé l'utilisateur "invité" ? et choper une saloperie ?
Ce sont des Pi3 avec 512 Mb de RAM ou 1Gb ?
Combien as-tu de mémoire swap ?
Les temps d'accès au SSD sont "normaux" ou plutôt lents ?

Bonjour Artemus,

Quelle version de Bulleseye ? La dernière ?
Firmware des dd à jour ? (on ne sait jamais, voir Piper )

Comme ça je dirais que ça vient du kernel. Je prendrais le kernel qui fonctionne de buster pour le mettre sous bullseye. Prends directement le dossier boot.
Tu peux aussi tester différents noyaux : https://downloads.raspberrypi.org/raspi ... _notes.txt

Ce que je ferai :
- remettre le config.txt par defaut
- mettre du swap (pour tester) : https://www.startpage.com/do/search?q=kswapd0

Si ce n'est pas ça, tu peux analyser ton démarrage avec :
dmesg -e
systemd-analyze
systemd-analyze blame
systemd-analyze critical-chain

Voici quelques pistes de réflexions. Bonnes recherches !

Salut à tous.

J'ai un autre processus qui est très sollicité aussi. Il s'agit de kworker. En faisant une recherche, je découvre que la cause est soit l'absence de la carte micro SD ou soit le réseau (Eth0 & Wlan0). Pour remédier à l'absence de la carte micro SD que l'OS interroge toutes les secondes, il est dit de mettre dans "/boot/config.txt" ceci : Il me semble avoir moins de sollicitation avec mes autres raspberry, mais par contre, cela plante mes RPi 3A+. Du coup, je ne mets pas ces deux paramètres dans mon fichier "/boot/config.txt".

J'ai testé la désactivation du wifi, sans succès. La RPi 3A+ ne dispose que d'une seule prise USB. J'utilise un câble usb/RJ45 pour accéder par éthernet à la RPi 3A+. Je branche mon disque dur et mon câble usb/rj45 sur mon hub usb. Les performances sont aussi pourries !

Piper a écrit :Est-ce que cela se produit tout de suite après un démarrage (je veux dire, après un reboot, as-tu un moment de calme ?)

Est-ce que j'ai une accalmie ? Au début oui, mais après, je perds la connexion et impossible de se reconnecter. Je suis obligé de débrancher ma RPi 3A+.

Piper a écrit :Aurais-tu activé l'utilisateur "invité" ? et choper une saloperie ?

Aucun rapport avec un quelconque virus. Je suppose que c'est un problème de paramétrage très spécifique à la RPi 3A+ quand j'utilise bullseye.

Piper a écrit :Ce sont des Pi3 avec 512 Mb de RAM ou 1Gb ?

La RPi 3A+ dispose que de 512Mb, wifi, pas d'éthernet et un seul port usb.
La RPi 3B+ dispose de 1Gb, du wifi, de l'éthernet et de quatre port usb.

Piper a écrit :Combien as-tu de mémoire swap ?

Aucune mémoire car je l'ai désactivé sous bullseye. Je peux en recréer un et faire le test. Comme tu peux le constater sous ma RPi 4B / 8GB, je n'ai pas de fichier swap.

Sous Buster, je n'ai pas de fichier swap et aucun problème d'accès à la RPi 3A+. Dois-je comprendre que bullseye l'exige ?

Piper a écrit :Les temps d'accès au SSD sont "normaux" ou plutôt lents ?

Ni l'un ni l'autre. Dans le meilleur de cas, ils sont extrêment lents.
Au bout de quelque manipulation, je me retrouve bloqué (ou gelé) sans pouvoir faire quoi que ce soit.

Dyox a écrit :Quelle version de Bulleseye ? La dernière ?

Je te donne la version bullseye, telle que je l'obtiens avec ma RPi 3A+ :

Dyox a écrit :Firmware des dd à jour ? (on ne sait jamais, voir Piper )

Et je fais cela comment ? C'est une disque tout simplement, ce n'est pas un boitier comme dans le cas de Piper.

Dyox a écrit :Comme ça je dirais que ça vient du kernel. Je prendrais le kernel qui fonctionne de buster pour le mettre sous bullseye.

Tu me traduis cela car je ne comprends pas ce que tu veux que je fasse. Je ne désire pas écraser bullseye par du buster, mais de faire en sorte que mes RPi 3A+ fonctionnent sous bullseye, avec des performances normales.

Je vais faire le teste de la recréation du fichier swap.

a) je fais : "sudo apt-get install dphys-swapfile" pour réinstaller l'application.

b) je modifie le fichier "/etc/dphys-swapfile". Je mets : "CONF_MAXSWAP=512", soit 512Mb.

c) je le désactive : "dphys-swapfile swapoff".

d) je lance : "sudo dpkg-reconfigure dphys-swapfile".

d) je vérifie : Bizarre, il me mets 100 Mb et pas ce que je lui demande.

e) j'arrête la RPi 4B.

f) je fais le test d'accès avec la RPi 3A+. C'est bien mieux qu'avant, mais moins bien qu'avec ma RPi ZERO.

Question : pourquoi ai-je besoin du fichier SWAP avec bullseye ???
J'ai du mal à comprendre, même avec le fichier SWAP, pourquoi ma RPi 3A+ n'est pas performante.
Je vais devoir l'utiliser uniquement avec buster.

Cordialement.
Artemus24
@+

Que ce soit sur windows ou linux, il n'a jamais été conseillé de désactiver le swap. Cela peut engendrer des inconvenances. Tu y as échappé jusqu'à maintenant. C'est pour que je j'aime bien zram-config. Tu as le swap en ram.

Pour ton d), je préfère la commande LANG=C free -h. Je me suis encore fait avoir à ta lecture

Tu as rien vu de suspect avec mes commandes ?
dmesg -e
systemd-analyze
systemd-analyze blame
systemd-analyze critical-chain

Tous tes daemons sont bien lancés sans erreurs ? systemctl --failed

Tu me traduis cela car je ne comprends pas ce que tu veux que je fasse. Je ne désire pas écraser bullseye par du buster, mais de faire en sorte que mes RPi 3A+ fonctionnent sous bullseye, avec des performances normales.

Je vais étayer ma pensée.
Qu'est-ce qui change en bulleye / buster ?
- les applications : des versions supérieures et quelques nouvelles. Si elles sont fautives, tu peux facilement le vérifier avec les logs et les commandes ci-dessus.
- le dossier /boot : nouveau noyau donc nouveau firmware et donc potentiellement des bugs nouveaux.

Je te proposais de copier le /boot d'un buster qui fonctionne sur ton bulleye pour s'affranchir d'un bug kernel concernant la 3A+. Tu peux renommer le temps de ton test ton /boot (bulleye) en /boot.bak par exemple.

Voilà, j'espère avoir été plus clair.

Salut à tous.

Merci pour vos interventions et vos explications.

Dyox a écrit :Que ce soit sur windows ou linux, il n'a jamais été conseillé de désactiver le swap. Cela peut engendrer des inconvenances. Tu y as échappé jusqu'à maintenant.

J'ai désactivé le swapfile à cause de la durée de vie des cartes micro SD. Et j'ai reporté cela sur mes disques.

J'utilise beaucoup mes RPi 4B/8GB, et un peu moins mes RPi ZERO, presque plus mes RPi 3B+ et RPi 3A+ et plus du tout mes RPi 2B.

Dyox a écrit :Tu as rien vu de suspect avec mes commandes ?
dmesg -e
systemd-analyze
systemd-analyze blame
systemd-analyze critical-chain

je suis parti dans la recréation du SWAPFILE et j'ai oublié de traiter tes commandes. Désolé. Oups

Dyox a écrit :Tous tes daemons sont bien lancés sans erreurs ? systemctl --failed

Oui, aucun problème de ce coté là.

Dyox a écrit :Voilà, j'espère avoir été plus clair.

Oui, en effet. Merci.

L'absence de SWAPFILE n'explique le problème que j'ai rencontré avec mes RPi 3A+ et pas sur les autres Raspberry Pi.

Cordialement.
Artemus24.
@+

Personnellement, je désactive aussi, autant que possible le swap pour augmenter la durée de vie des cartes SD, je désactive même les logs
Cependant, sur des Pi ayant peu de mémoire (512Mb tels les Pi Zéro , Pi1, P2, P3A et même quelque fois les Pi3B) je constate que trop sollicité par des processus gourmands, cela provoque à minima des performances catastrophiques, voir gros lagues.
Ex : Installez juste emby serveur sur un Pi sans bureau (tout nu), avec une médiathèque de plusieurs milliers de fichiers sur un disque dur externe.
La première construction de la base de données d'emby fera figer ou planter les Raspberry qui ont moins de 2Gb de RAM et pas de swap.
Autre exemple : une "simple" recompilation de numpy à partir des sources sur un Pi qui n'a pas de swap et 512Mb de RAM : idem (la dernière fois : 5h de compilation sur un Pi Zéro !)
Donc désactiver le swap est une très bonne idée, à partir du moment ou on sait que la quantité de RAM suffira pour ce qu'on a à faire.

Salut à tous.

Merci Piper pour ton retour d'expérience.
Aujourd'hui, je vais créer une partition SWAP dans mon disque Maxtor, celui qui est sous Bullseye, afin de ne plus rencontrer ce problème, enfin j'espère.

Cordialement.
Artemus24.
@+

Salut à tous.

Je viens de le faire avec ma RPi 4B. Voici comment j'ai procédé :

1) j'ai réduit la dernière partition qui est destiné aux backup.
Comme mon disque dur maxtor fait 500 GO, j'ai suffisamment d'espace.
Du coup, j'ai de l'espace libre à la fin de mon disque Maxtor.
J'ai procédé par "cfdisk /dev/sda".

2) J'ai supprimé la dernière partition. Je l'ai réduite. Je l'ai recréé en linux (83). Puis formaté en "ext4".

3) Sur l'espace libre à la fin de mon disque, j'ai créé ma partiton swap (82) et formaté en "swap".

4) modification du fichier "/etc/sphys-swapfile". J'ai mis 8Go car c'est la taille de la ram de ma RPi 4B.

5) modification du fichier "/etc/fstab". 6) puis les commandes suivantes :
--> dphys-swapfile setup
--> dphys-swapfile swapon
--> free -h 7) je redémarre ma raspberry. Il me semble que tout est correcte.

8) je teste ma RPi 3A+.
Première tentative. Je me connecte et là, plantage de la RPi 3A+.
Deuxième tentative, ca fonctionne.
Je constate que j'ai un fichier de 1Go qui a été créé sous "/root" portant le nom "PARTUUID="9cba179a-07" de ma partition swap.
Je le détruis et je redémarre ma RPi 3A+. Tout va bien. Je vérifie : Il y a bien une écriture dans la partition swap.

Quand j'entre dans ma RPi 3A+, c'est plutôt lent.
Après, c'est mieux qu'avant mais j'ai parfois des blocages de quelques secondes.

9) voici mon "blkid" : 10) je fais le même test mais en branchant ma RPi 3A+ sur mon hub usb, afin d'avoir accès par mon câble USB/RJ45 à l'éthernet.
Pour démarrer la RPi 3A+, j'ai besoin d'insérer la carte micro SD qui ne contient que la partition boot. Bizarre.
Avec ma RPi 4B, je n'ai pas ce problème.

J'ai pu démarrer la RPi 3A+ et je me suis connecté par mon câble éthernet.
J'ai les mêmes problèmes de fluidités qu'avec ma connexion Wifi.

Je teste à nouveau : La partition swap est encore sollicité.

11) Au démarrage de la RPi 3A+, j'ai des lenteurs, puis après cinq minutes, c'est beaucoup plus fluide sous Ethernet ainsi qu'en Wifi.
Il semble y avoir une application qui doit être consommatrice de CPU, peut-être le bureau.

Je peux supposer que j'ai résolu mon problème.

Cordialement.
Artemus24.
@+

Si tu penses que cela vient du bureau, donc après le login regarde ce qui peut prendre du temps dans ~/.xsession-errors