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
`-
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmeGqv0ACgkQeTz2fo8N Edp3KQ//f0/zCsa5inSq/a6mQl6F04gJ4d95KSgXVgf+VUMJcgwTxv1vxVFEinSB cEWBjwPJRk1vwkc17Q80SDmUI7apg96pz2F8DJFIL5sWmikRniVDYIeoTay/nBkM jKlydD5HJmJrWMEOzAmVK6Fy1OiRimLLV3ywCoNA4V8maogm3ILCxB84nBFHUtw4 FmTePx7Qw8t9UwxuuWmkO779uMpQDDr9MzGxR0qIsudQYnyhc6wjoRrs8HwuGQva b2NaNhH+9C5pa40Sd35alKi65z4iIxtf8i0FCwMYAOlAcNFJM3h4ojn/6mQ4uY/r A4Zg76LO2xy15wK8GNLtEacou+kdumh55qWy6GxaVkFgwDl/ZX4hKrXAFr+47kw2 8t/2OEbpnv7+BX6P9PNPQa7mcceWgfoPy5ftaeuVu/H2qyR+Cub/tS9uQQ03zPQU U/6uSERIrp7bh4avpQt343TICVilGMFSGsPVx2xxO4Y2KlghX4NPEIzCQNXTZB0I h6C25vG53K2AQGpF4Dfkovj/dyx0TTkxeYME53uqHLPHomIZDz8EXEP20not5Msn J5jHC/W+a+uVKxQYM2ilbb0KLnCVEQd2JqLGHjsR2brjUGjPNChSu/5h+qp0+1Fz 5Zr0Rv+4aQm514qVpl3L+oz+pgoux3YvNujc5eqlEWPWatrvjLg=
=aG2Q
-----END PGP SIG