Re: Swap sans swap ?

Page principale

Répondre à ce message
Auteur: Olivier Allard-Jacquin
Date:  
À: guilde
Sujet: Re: Swap sans swap ?
    Bonsoir Frederic,

Le 28/11/2019 à 08:50, Frédéric a écrit :
> Merci pour vos réponse. Mais...
>
> - je n'ai pas de SSD sur ma bécane du boulot, et y'a aussi le problème ;


    Je n'ai pas dit que le SSD était une solution.

    J'ai simplement dit que le fait d'avoir un SSD ne t'empêche pas de
mettre un swap. Dans ce cas, le but du swap est d'éviter que la machine
se trouve à cours de mémoire, et donc que les programmes plantent
"sauvagement".

> - que le noyau utilise un max le swap et la mémoire pour optimiser les
> choses en fonctions des applis, ok, c'est très bien, mais ça n'explique
> pas pourquoi les accès disques foutent littéralement la machine à genoux,
> au point que même la souris ne bouge plus !!! C'est pas sensé être
> multi-tâches, linux ?


    Il est possible que ton disque soit très lent, parce que fragmenté
ou trop vieux.

    Au boulot, j'ai un paquet de machine dotés de disque, en RAID0 /
RAID1 / RAID5 ou non, et je peux te dire qu'à après 5 ans de
fonctionnement en 24/24 et 7/7, la mécanique fait que les accès sont
ralentis. La cause est dus aux têtes de lecture qui mettent plus de
temps à se caler à la bonne position, du fait, entre autre, du
vieillissement de la lubrification du pivot des têtes.

    Maintenant, pour ton problème tu as certainement plusieurs applis
qui bourinent le disque en parallèle. et ça, cela affect bien le
ressenti de fluidité de la machine.

    Dans la commande "top", tu as une ligne de "% wa" (ou "% de wait").
C'est le pourcentage de temps que le kernel attend lors des opérations
d'I/O. Concrètement:

- ton linux veut lire/écrire des données sur le disque dur (mais aussi
le réseaux, ou les cartes entrée/sortie de ta machine)

- le hardware ne réponds pas tout de suite, car il est lent à faire le
boulot. Et le kernel ne peut pas faire grand chose mise à part attendre

- ce temps d'attente se calcul en "% wait"

- pour une machine en IDLE, le % est à 0. Si le disque dur est vieux, tu
peux t'attendre à des valeurs fortes. A partir de 20% je dirais que tu
le ressens au niveau de la réactivité de la machine.

- le fait que le kernel attende lors d'IO est, il me semble, spécifique
aux PC x86. L'utilisation des IO est bloquant pour le CPU. J'imagine que
d'autres architectures gèrent cela différemment.

- il y a aussi la priorité des IRQ. Diantre, cela fait bien 10 ans que
je n'ai pas abordé le sujet.

Dans
https://fr.wikipedia.org/wiki/Interruption_mat%C3%A9rielle#Les_IRQ_sur_les_architectures_compatibles_PC
tu vois que les IRQ 8 à 15, sont prioritaires aux autres, parce que
câblées sur l'IRQ 2 (l'IRQ la plus faible est la plus prioritaire).

Pour des machines "récentes" à bus PCI, c'est un peu différent, mais le
principe est le même.

Conclusion : Les IRQ des disques durs sont prioritaires sur à peu près tout.

> - et, surtout, ça n'explique pas pourquoi, quand je vire le swap dans
> le but d'éviter ces emmerdes d'optmisation, le noyau swape quand
> même !!! Ce point là, il me fascine vraiment !


    Là je ne vois pas.

    Reste à savoir si c'est vraiment du swap, ou autre chose.

    Patrice à parlé de la commande "htop". tu devrais l'utiliser, car
cela indique quel quantité d'accès disque fait tel et tel programme.
Attention, le programme est en python, et consomme du CPU.

    Il existe un mécanisme qui rend moins prioritaire les I/O des
programmes. C'est le pendant de "nice" pour le CPU: "man ionice".

    Personnellement, j'ai un alias sur tar, afin de le rentre
sous-prioritaire en terme de CPU et d'I/O, avec un bon mélange de "nice"
et "ionice" :

alias tar='ionice -n 7 -c 3 tar'

    Enfin, il me semble que tu as dit que tu utilisais un grand nombre
d'onglets firefox ouverts en permanence. C'est un gouffre à consommation
de mémoire et d'accès disque. Aussi, je ne serais pas surpris que ce
soit la cause de tes ennuis.

    Il y a plusieurs choses à faire:

- éliminer les extensions

- purger de temps en temps le cache de FF, qui peut mettre beaucoup de
temps à être indexé. Le mécanisme interne de FF n'est pas efficace,
aussi perso je fais de temps en temps un "rm -rf ~/.cache/mozilla/firefox/"

- il peut y avoir une belle quantité de m... dans les fichiers
téléchargés dans ~/.mozilla/firefox/xxxxxx/ . Perso, je purge
régulièrement les sous-répertoires du ~/.mozilla/firefox/xxxxxx/ (il
faut avoir un peu d'expérience pour cela)

- et puis, il y a la purge des bases de données nosql, afin de virer les
entrée supprimées (nécessite le programme "sqlite3"):

 + fermer FF

 + cd ~/.mozilla/firefox/xxxxxx/

 + for I in *.sqlite; do ls -la $I; sqlite3 $I vacuum && sqlite3 $I
reindex; ls -la $I; done

    Cordialement,

                                                    Olivier

-- 
~~~~~~~  _____/\_____  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix /   _ \/ _   \    Olivier Allard-Jacquin
       /   / \  / \   \   Web:  http://olivieraj.free.fr/
      /___/  /  \  \___\  Mail: olivieraj@???
~~~~ /////  ///\\\  \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!