Bonjour Philippe, Philippe Monroux, on 2025-01-10: > Je suis sous debian depuis 1995 mais pour des raisons personnelles je > ne mets plus les mains dans le cambouis. Donc vu mon grand âge j'ai > bien oublié...(d'ailleurs je n'utilise plus mutt mais l'interface web > de gmail :-( ) Vous faites comme vous pouvez. Je pense que personne n'a à vous juger pour ça. ;) Votre problème m'a rappelé quelque chose de très similaire que j'ai essayé de contourner avec quelque chose d'assez technique. Si vous voulez remettre les mains dans le cambouïs, alors il va y avoir un peu de matériau. Je me concentre sur le problème suivant : > Mais souvent le disque crépite assez longtemps ce qui grève la > rapidité de mon desktop. Quelque part aux alentours de Linux 3[1], avec l'apparition des stockages SSD, le système de gestion des blocs de stockages pour les entrées et sorties brutes sur disques a été entièrement refondu pour permettre la gestion de multiple flux de données (multiqueue I/O block layer, j'ai du mal à exprimer ça en Français sans lourdeurs) au lieu d'un seul (single queue). [1] : https://lwn.net/Articles/552904/ Le problème est que l'algorithme historique CFQ (Completely Fair Queueing) d'ordonnancement n'a pas suivi du mode single-queue vers multi-queue ; l'une des raisons pour lesquelles le CFQ n'a pas suivi est qu'il n'était optimal que pour piloter un disque dur, mais pas pour n'importe quelle autre topologie de stockage, si je me souviens bien. Du coup, depuis que le single-queue n'est plus implémenté dans Linux, le CFQ n'est plus disponible. Sur un SSD, ce n'est pas gênant d'une part parce que le firmware du stockage va refaire l'ordonnancement à sa sauce pour limiter l'usure, et d'autre part leurs capacité à absorber des entrées et sorties sur un laps de temps donné a sensiblement augmenté par rapport aux disques durs. Cela ne veut pas dire qu'il n'est plus possible d'implémenter un ordonnanceur d'entrées et sorties (E/S) sur un système contemporain. La multiqueue block layer comprend quelques ordonnanceurs introduits dans Linux 4.12[2], notamment le BFQ, ou « Budget Fair Queuing », qui fonctionne assez différemment du CFQ mais avec des effets similaires. BFQ a été spécifiquement conçu pour améliorer l'intéractivité des machines lors des situations de forte charge d'E/S, typiquement quand une tâche de fond émettrice d'E/S est en cours (par exemple une copie de données volumineuses ou une sauvegarde), le BFQ va prioriser les E/S des processus n'ayant pas eu d'activité disque récente en premier. Cela va donc prioriser les tâches intéractives qui vont avoir de rares pics d'E/S, ou les lancements de programmes depuis un environnement de bureau. [2] : https://lwn.net/Articles/720675/ Voilà, c'était la théorie. Maintenant, on peut passer à la pratique : > Que me conseillez-vous concernant l'augmentation de la RAM et/ou > l'adaptation du swap ? Avant d'investir dans du matériel, je suggérerais de jeter un œil à l'implémentation du BFQ pour voir s'il y a du mieux quand vous utilisez votre machine pendant un épisode de charge avec beaucoup d'activité disque. Avec un peu de chance ça améliorera un peu les choses. J'implémente BFQ notamment sur une machine qui a douze ans et toujours son disque dur d'origine, 1 Gio de mémoire vive et 4 Gio de swap. J'ai un peu de mal à quantifier le gain en intéractivité, mais à l'ouïe, le disque « crépite » moins en période de charge élévée, à la place il fait un bruit beacoup plus continu. Pour implémenter bfq sur une machine, j'ai ce script /usr/local/sbin/bfq : #! /bin/sh set -e # bfq kernel module must be loaded before use. if ! lsmod | grep -q ^bfq then modprobe bfq fi # For all drives, identify the rotational hard drives to # change their I/O scheduler for bfq. for disk in /sys/block/sd*/queue do if [ "$(cat "$disk/rotational")" = 1 ] then echo bfq > "$disk/scheduler" fi done Je le démarre automatiquement en même temps que la machine en utilisant un service /etc/systemd/system/bfq-scheduler.service : [Unit] Description=BFQ scheduler actuator [Service] Type=oneshot ExecStart=/usr/local/sbin/bfq RemainAfterExit=yes [Install] WantedBy=multi-user.target Une fois les fichiers en place, il n'y a plus qu'à les activer : $ sudo chmod +x /usr/local/sbin/bfq $ sudo systemctl daemon-reload $ sudo systemctl start bfq-scheduler $ sudo systemctl enable bfq-scheduler et vérifier que l'ordonnanceur est implémenté sur tous les disques rotatifs : $ grep . /sys/block/sd*/queue/scheduler /sys/block/sd*/queue/rotational /sys/block/sda/queue/scheduler:none mq-deadline [bfq] /sys/block/sdb/queue/scheduler:none mq-deadline [bfq] /sys/block/sda/queue/rotational:1 /sys/block/sdb/queue/rotational:1 Si [none] ou [mq-deadline] sont toujours sélectionnés dans le fichier queue/scheduler, c'est qu'une étape ne s'est pas bien passée. Attention, je ne garantis pas que la machine répondra désormais instantanément en temps réel, mais il devrait y avoir un gain sensible si le réglage initial était sur [none]. Du moins, les pertes en réactivité en cas de forte charge d'E/S devraient être un peu moins sensibles. Après, je peux toujours être à côté de la plaque et être passé à côté du problème. Si ça n'aide pas, alors peut-être qu'il y aura du mieux en migrant du disque dur vers un SSD. Avoir un peu plus de swap ou de ram ne fera pas de mal dans les situations où vous auriez besoin de grandes quantités de mémoire pour vos applications, afin de repousser le plantage au moment où vous arrivez au bout. Bonne journée, :) -- .''`. Étienne Mollier <emollier@debian.org> : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-
Attachment:
signature.asc
Description: PGP signature