Interdire l'usage de la SWAP à certains programmes

Coa · Février 21, 2016, 6:18pm

Bonjour,

Je me permets de venir voir les Grands Anciens de Debian because j’ai pas trouvé la réponse ailleurs…

En gros: je suis sous linux Mint 13 (un dérivé de Ubuntu 12.04).
J’ai 4Go de Ram sur mon ordi et une partition SWAP de 8Go.

Sauf que les temps ont évolués, et comme dit dans un autre sujet (https://www.debian-fr.org/en-2013-interet-d-une-swap-avec-8-go-de-ram-t44687-50.html), la SWAP c’est minimum 5fois plus lent que la Ram.
Comme dit aussi dans le sujet pré-cité, tant que mon ordi ne se sert de la SWAP que pour écrire un truc puis le relire 10min plus tard, tout va bien. Mais dès qu’il commence à vouloir faire des lectures écritures à intervalles rapprochés, là, c’est la cata!

J’ai remarqué d’ailleurs que ce genre de cata ne se produit jamais du fait du système lui-même. Ca se produit plutôt lorsqu’un programme (flash a été coutumier du fait) lancé par l’utilisateur (moi) se met tout d’un coup à vouloir écrire des tonnes de données dans swap+ram. Dans 99% des cas, c’est que le programme en question a pété un câble. C’est d’ailleurs pour ça que je surveille toujours d’un œil inquiet l’occupation de la Ram par les programmes, prêt à flinguer le processus qui se prendrait une crise de boulimie ramiesque. Parce que si je rate le coche, tout le système se mue alors au rythme de la swap, y compris le truc qui me permettrait de flinguer le processus déjanté, et j’en suis réduit à devoir faire joujou avec les touches magiques pour flinguer le système sans trop de dégâts.

Bref, j’aimerai savoir s’il y a un moyen d’interdire aux processus lancés par les simples utilisateurs d’accéder à la swap.

Ceci dit, s’il y a d’autres solutions plus adaptées possibles, comme de flinguer automatiquement tout processus utilisateur qui s’offrirait une boulimie de ram sans raison, je suis preneur.

ggoodluck47 · Février 21, 2016, 6:18pm

Salut,

Avec 4Go de ram et une Debian tu ne devrais pas avoir besoin de swap pour un usage courant. Mais je dis bien avec une Debian

josephtux · Février 21, 2016, 6:18pm

Il me semble que sous Debian, la swap n’est utilisée que quand un programme ne peut plus accéder à la mémoire vive dont il a besoin. Donc vouloir s’en passer si elle est utilisée, ce serait faire planter le programme. je me trompe ?

agentsteel · Février 21, 2016, 6:18pm

On peut jouer sur certains paramètres pour limiter l’utilisation du swap

en.wikipedia.org/wiki/Swappiness

ggoodluck47 · Février 21, 2016, 6:18pm

Re,

Afin de faire des essais il serait intéressant que tu nous donnes des exemples de programmes coutumier du fait

kna · Février 21, 2016, 6:18pm

Le noyau le fait automatiquement quand toute la mémoire (RAM+swap) est occupée : en.wikipedia.org/wiki/Out_of_memory
Du coup, ton problème est que tu as trop de swap !

Note que ce n’est pas forcément la meilleure solution non plus : si un processus s’accapare toute la mémoire c’est tout de même lui qui devrait être killé, mais ce n’est pas le seul critère de sélection, et un OOM pourrait killer un processus que tu ne voudrait pas tuer…

Une autre solution est de limiter l’usage de mémoire à ton user (ou à un processus si tu en as un que tu soupçonne d’accaparer la RAM). Sous bash, tu peux le faire avec la commande ulimit :

[code]$ help ulimit
ulimit: ulimit [-SHacdefilmnpqrstuvx] [limite]
Modifie les limites de ressources du shell.

Fournit un contrôle sur les ressources disponibles au shell et aux processus
qu'il crée, sur les systèmes qui permettent un tel contrôle. 

Options :
    -S	utiliser la limite de ressources « soft »
    -H	utiliser la limite de ressources « hard »
    -a	toutes les limites actuelles sont présentées
    -b	la taille du tampon de socket
    -c	taille maximale des fichiers « core » créés
    -d	taille maximale du segment de données d'un processus
    -e	la priorité maximale d'ordonnancement (« nice »)
    -f	la taille maximale des fichiers écrits par le shell et ses fils
    -i	le nombre maximal de signaux en attente
    -l	la taille maximale qu'un processus peut verrouiller en mémoire
    -m	la taille maximale de « set » résident
    -n	le nombre maximal de descripteurs de fichiers ouverts
    -p	la taille du tampon pour les tubes
    -q	le nombre maximal d'octets dans les queues de messages POSIX
    -r	la priorité maximale pour l'ordonnancement temps-réel
    -s	la taille maximale de la pile
    -t	la quantité maximale de temps processeur en secondes
    -u	le nombre maximal de processus utilisateurs
    -v	la taille de la mémoire virtuelle
    -x	le nombre maximal de verrous de fichiers
    
Si LIMIT est fournie, elle est utilisée comme nouvelle valeur de ressource
Les valeurs spéciales de LIMIT « soft », « hard » et « unlimited » correspondent
respectivement aux valeurs actuelles de la limite souple, de la limite dure,
ou à une absence de limite. Sinon la valeur actuelle de la limite est affichée
Si aucune option n'est donnée, « -f » est supposée.

Les valeurs sont des multiples de 1024 octets, sauf pour « -t » qui prend des secondes,
« -p » qui prend un multiple de 512 octets et « -u » qui prend un nombre
de processus sans unité.

Code de sortie :
Renvoie le code de succès à moins qu'une option non valable ne soit fournie ou qu'une erreur ne survienne.

[/code]

Cluxter · Février 21, 2016, 6:18pm

Il suffit de laisser le noyau faire son boulot.

Lorsque la mémoire vive vient à manquer, le noyau va se mettre à utiliser le swap.
Lorsque le swap est plein, le noyau va chercher le processus qui selon lui est à dégager, et il va lui mettre une balle dans la tête pour libérer de la mémoire.

Pour savoir quel(s) processus tuer, le noyau utilise l’algorithme “OOM Killer” (“OOM” pour “out of memory” = mémoire insuffisante).
Cet algorithme va passer tous les processus en revue et va calculer un score pour chacun d’entre eux. Le(s) processus avec le(s) score(e) le(s) plus élevé(s) seront tués.

Voici les règles sur lesquelles repose l’algorithme :

il faut perdre un minimum de travail réalisé ;
il faut récupérer un maximum de mémoire ;
il ne faut pas tuer quelque chose qui n’est pas la source d’un manque de mémoire (dit autrement : il faut une cible utile) ;
il faut tuer le moins de processus possible (idéalement un seul) ;
il faut essayer de tuer le processus que l’utilisateur s’attend à voir disparaître (dans ton cas, Flash par exemple).

Source, explications, algorithme et détails du code commenté ici : linux-mm.org/OOM_Killer

Dans ton cas si Flash vient à utiliser 98% de ta mémoire, il y a fort à parier que ce sera bien lui qui sera tué par le noyau.

EDIT : grillé par kna.

josephtux · Février 21, 2016, 6:22pm

Question naïve: et nice dans tout ça ?

Cluxter · Février 21, 2016, 6:22pm

“nice” permet de définir un coefficient de priorité afin d’allouer plus ou moins de temps processeur à un processus. Exemple : si ton CPU tourne à 1 GHz (restons simple : avec un seul coeur), parmi ces 1 milliard d’opérations par seconde, combien souhaites-tu en allouer chaque seconde pour un processus donné ?

Dans ce post il est question d’allocation de ressources de la mémoire virtuelle, alors que “nice” s’occupe de l’allocation de ressources du processeur.

Coa · Février 21, 2016, 6:26pm

[quote=“ggoodluck47”]Re,

Afin de faire des essais il serait intéressant que tu nous donnes des exemples de programmes coutumier du fait [/quote]
Ca se produit de manière assez aléatoire donc déterminer quel est le crétin en cause est difficile…
Il me semble que le plugin flash de firefox fait parfois ce genre de boulette.
Je crois que j’ai vu d’autres programmes faire des bêtises similaire mais c’est plutôt rare.
En fait, je soupçonne que les programmes en cause sont soit buggés, soit mal utilisés. Il entrent alors dans une sorte de frénésie de consommation de mémoire vive. Ca me fait un peu penser à ces boucles infinies en informatique, des machins du genre “Tant que valeur > 0 ajoute 5 à valeur”. L’idéal ce serait un programme qui détecte ce genre d’emballement et me prévienne.

Au sujet de OOM Killer :
L’idée me semble bonne, mais si j’ai bien compris OOM killer n’agit Que lorsque dès que la SWAP et la RAM sont pleines.
Dès lors, je me retrouve avec deux options.
-soit je supprime la SWAP et OOM killer agira dès que la ram est pleine. Problème: ça désactive la fonction de veille (pas trop grave) mais surtout ça empeche un programme qui utiliserait normalement la swap de faire son boulot.
-soit je ne supprime pas la SWAP. OOM Killer n’agira alors que lorsque la SWAP et la RAM seront pleine. A la vitesse à laquelle tourne la SWAP, j’en ai pour 30min à chaque plantage…

Au passage, une autre piste.
Je suis tombé sur ça:
fr.wikipedia.org/wiki/Linux-rt
Si j’ai bien compris, cette fonctionnalité permettrait de faire fonctionner le noyau en temps réel. Ce qui, si j’ai bien compris, voudrait dire que si un processus utilisateur fait l’imbécile (par exemple en bouffant la swap), je pourrais toujours appeler le noyau pour le flinguer (alors que dans le cas présent, c’est impossible).
Qu’en pensez vous?

Coa · Février 21, 2016, 6:26pm

[quote=“kna”]Une autre solution est de limiter l’usage de mémoire à ton user (ou à un processus si tu en as un que tu soupçonne d’accaparer la RAM). Sous bash, tu peux le faire avec la commande ulimit :
[/quote]
Ca a pas l’air mal ulimit.
En fait, en y réfléchissant, le problème est qu’en cas de “baffrage de swap”, le système est fortement ralentis. Plus que limiter l’usage de la ram par les processus utilisateurs, une solution serait de réserver en permanence une partie de la ram pour des programmes me permettant éventuellement de stopper les processus fous.

ggoodluck47 · Février 21, 2016, 6:26pm

Salut,

Ton problème ne semble pas concerner la Debian, nous ne pouvons présager de l’usage fait par d’autres distributions

haleth · Février 21, 2016, 6:26pm

Pour ton problème, j’ai une trallé de solutions:

Mettre beaucoup moins de swap (2G me parait suffisant pour 4G de ram)
Identifier les programmes qui sont craignos, et les virer (pour une humanité durable, vire JAVA et FLASH)
Mettre les programmes sadiques -que tu souhaites cependant concerver- dans un cgroup, avec une quantité de mémoire maximale (le kernel va le démonter s’il dépasse )

NB: j’ai vu nice plus haut, c’est franchement un programme à éviter, parcqu’il n’a jamais vraiment été utile, encore moins depuis 5ans;

Cluxter · Février 21, 2016, 6:26pm

Solution sale. Avoir un swap au moins égal à la quantité de RAM est obligatoire pour pouvoir faire de l’hibernation.

+1 mais ça n’est malheureusement pas toujours possible. A défaut de les virer il peut toujours tenter de les patcher…

Je n’ai toujours pas bien compris comment fonctionnaient les cgroups ou même à quoi ils servaient exactement, mais ça me semble être la solution à adopter.
Si tu as quelques explications claires et simples ou que tu peux même m’expliquer en 2 phrases à quoi ça sert, je suis preneur

Pourquoi ?

fran.b · Février 21, 2016, 6:26pm

[quote=“haleth”]
NB: j’ai vu nice plus haut, c’est franchement un programme à éviter, parcqu’il n’a jamais vraiment été utile, encore moins depuis 5ans;[/quote]
nice est particulièrement utile dans la gestion d’un serveur, permettant d’éviter qu’une machine ne répondent pas parce que motion est installé dessus et qu’unimbécile dase la jave devant la webcam, alors même que 10000 spams arrivent et que tu compiles ton noyau.
Que ça ne te sert à rien à toi est une chose, conseiller de l’éviter est absurde.

jb1 · Février 21, 2016, 6:26pm

bonjour,
ci-dessous un copier/coller



    Votre système sera moins stable.
    Votre système ne sera pas capable d'hiberner.
    vitesse d'accès au disque dans votre système sera plus lent par rapport à un système qui a une partition de swap. En outre, la vitesse d'accès au disque va baisser au cours du temps.

je sais par exemple que le noyau Oracle n’est pas swappable

dans:
root@alpha30:/usr/include/sys#
swap.h répond-il au besoin?

des autres point comme évoqués:
ulimit,
shmmax
A+
JB1

haleth · Février 21, 2016, 6:26pm

Ben, de mon expérience, mettre un gros programme avec une priorité basse via nice ne va pas empêcher le serveur de craquer. Du fait, je considère cela plus comme un placebo qu’autre chose

Alors en fait, tu vas définir des groupes de processus (par default, y’a un groupe et tout le monde est dedans).
Chaque processus est enfermé dans son groupe: s’il fork, alors le petit est aussi dans le groupe (avantage: tu met ton shell dans le cgroup et tout ce que tu fait dedans ne sort pas)

À chaque cgroup, tu définis des contraintes fortes, auquel les processus ne peuvent pas échapper.
Par exemple, tu peux lui dire : "Ok, les process de ce groupe ne peuvent utiliser que le proc n° 2 et 5"
Tu peux lui dire: “Ok, les process de ce groupe ont la priorité sur le proc par rapport aux autres groupes”

Tu peux gérer de cette manière plein de trucs: memoire, IO (disk & net), proc, avoir des stats sur l’utilisation d’une certaine ressources par le group, limité l’accès à certains périphérique etc

C’est une création très utile.

Une bonne doc est trouvable chez RedHat: http://docs.huihoo.com/redhat/rhel6/en-US/html-single/Resource_Management_Guide/index.html?etpn7=oppressive+LAX+encrypt