Re: oomkiller

トップ ページ

このメッセージに返信
著者: Olivier Allard-Jacquin
日付:  
To: guilde
題目: Re: oomkiller
    Bonjour,

Le 01/10/2017 à 12:00, Frédéric a écrit :
> Le dimanche 01 octobre 2017, Olivier a écrit :
>
>>     Attendez, c'est quoi cette histoire ?

>>
>>     Ce n'est parce qu'un programme est écrit comme une .... et qu'il
>> décide de prendre toute la ram (afin d'améliorer ses performances, au
>> détriment du reste de la machine), qu'il doit forcément vous imposer des
>> règles de configuration de vos machines ?

>>
>>     C'est au soft de s'adapter à l'OS, pas à l'OS de se plier aux
>> caprices d'un soft (ou d'une équipe de dev).

>
> Je suis entièrement d'accod avec toi sur ce point...
>
> Sauf que..
>
> J'en ai déjà parlé plusieurs fois, et personne n'a pu m'aider, mais sur ma
> machine du boulot, dès qu'il y a un accès disque musclé, comme lorsque ça
> swape, je ne peux plus rien faire ! On a bricolé la gestion des
> interruptions, sans succès.
>
> Cette machine est assez récente, et tourne sous sid.
>
> Or, ma machine perso, bien plus ancienne, qui a aussi toujours été sous
> sid, je n'avais aucun souci de ce genre jusqu'à récemment. Maintenant,
> c'est comme au boulot : dès que j'ai un gros transfert, ou utilisation du
> swape, la machine ne répond plus... Le souci est apparu à peu près en même
> temps que sur l'autre.
>
> Si c'était un bug provisoire, il y a longtemps qu'il aurait été résolu. Il
> y a donc des évolutions dans le noyau qui foutent le bordel sur certaines
> configs.


    Je veux bien te croire, moi c'est l'USB qui est super lente depuis
quelques années, suite à une mise à jour mineur (je suis en testing). Je
n'ai pas pu le résoudre, mais j'ai toujours une suspiction sur le hardware.


> Donc je m'adapte à l'OS, et je cherche à faire en sorte qu'il fonctionne.
> Comme je suis bien incapable d'aller débugger le noyau, c'est bricolerie &
> co.


    Il y a 2 trucs sur lesquels tu peux travailler afin de tenter d'isoler
/ comprendre le problème :


- iotop
    C'est un programme en python, à lancer en root, qui t'indique quel sont
les process qui utilisent les disques, en lecture & écriture


- top
    La bonne vielle commande top donne des infos intéressantes:


top - 14:00:03 up 4:55, 11 users, load average: 0,34, 0,27, 0,20
Tasks: 264 total, 1 running, 263 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1,6 us, 0,7 sy, 0,0 ni, 97,8 id, 0,0 wa, 0,0 hi, 0,0 si,
0,0 st


- load average: 0,34, 0,27, 0,20
=> Cela te donne le nombre moyen de process en attente dans la "queue
process" kernel. Tant que c'est en-dessous de 1, c'est que ta machine
est peu utilisé
=> Lorsque cela monte, chez moi c'est au-dela de 6-8, la machine a une
grosse impression de lourdeur. La souris ne se déplace pas linéairement,
le clavier le bloque plus ou moins
=> Un fois j'ai observé une load de 60, dus à un crash du module vidéo

Le 1er chiffre est la "load" en temps réel. Le 2nd, c'est la charge
moyennée sur xx secondes, et le 3ème sur 1 minute.

%Cpu(s) => wa (= wait)
C'est le temps que la machine passe à attendre le hardware (réseau,
disque dur, ...). Si cela monte trop, c'est typiquement des gros accès
disques

%Cpu(s) => hi (= temps passé à l'entretien d'interruptions matérielles)
Il vaut mieux que cela reste bas

%Cpu(s) => sy (= temps d'exécution des processus du noyau)
Dès que tu tapes sur le disque dur ou les gros accès réseau, cela va monter.

    Bref, entre top et iotop, tu peux arriver à identifier qui fait des
gros accès.


    Après, il y a d'autres trucs intéressant:


strace -t -f -e open [PROGRAMME]
ou
strace -t -f -e open -p [PID_PROCESS]

La commande "strace -e open" va te dire en temps quels les fichiers
ouverts par un programme . Utile pour voir si un programme fait beaucoup
d'ouvertures de fichiers, et surtout, quels fichiers il ouvre.

Tu peux remplacer "open" par "read" ou "write", cela t'affiche ce qui
est lu/écrit (soit à l'écran, entre les threads, sur les disques, le
réseau, etc ...). C'est TRES verbeux ...

    Enfin, un truc ( à moi ?) :
while [ 1 ]; do clear; cat /proc/interrupts ; sleep 1s; done


Cela te donne quels sont les répartitions des IRQ par CPU . Cela peut
aider à comprendre qui génère des interruptions hardware. Pour mon
problème d'USB, je me suis rendu compte qu'avoir les modules USB sur la
même IRQ que les pata & sata n'était pas forcément top.

    Et pour finir : irq_balance
C'est un programme qui est supposé faire du load balancing des IRQ sur
les différents CPU, afin que ce ,e soit pas toujours les mêmes coeurs
qui gèrent les interruptions. Cela peut aider



    Cordialement,


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