Comment apprivoiser la réactivité, la mémoire et la pagination de Linux

Première question sur le débordement =) ... +100 primes. Je ne pouvais pas penser à quelque chose dont je me souciais vraiment jusqu'à présent:

J'en ai vraiment marre de l'état de la réactivité du bureau Linux, par exemple http://brainstorm.ubuntu.com/item/85/ - dans les situations avec une faible RAM libre ou des situations avec un débit de disque élevé, le système ralentit pour une exploration ; c'est absolument terrible pour les applications qui nécessitent des performances décentes. En outre, l'interface utilisateur ne répond pas du tout. Comparez cela par exemple avec OS X, où si une application monopolise des ressources, on peut toujours cliquer sur Option pour forcer la fermeture, tandis que sous Linux, je ne peux même pas alt-tab ou changer de bureau, ou même ctrl-alt-f1 pour obtenir un terminal - eh bien je peux, cela prend environ 1-2 minutes par opération.

J'utilise gkrellm pour voir la situation au fur et à mesure. En règle générale, l'utilisation de la mémoire devient assez élevée ou le débit du disque augmente considérablement.

Ce n'est pas du mauvais matériel, avec un quadricœur à 2,6 GHz et 4 Go de RAM DDR2 à 800 MHz (aurait eu 6 Go, mais en raison d'une incompatibilité matérielle, il ne pouvait pas mélanger et assortir avec l'ancien ensemble). Ce problème peut disparaître lorsque j'obtiens inévitablement plus de RAM, mais je ne pense pas que ce soit le cœur du problème. J'ai même deux partitions d'échange sur des disques différents.

Je pense que le problème est triple:

• programmes incontrôlables qui accaparent des quantités massives de mémoire - la loi doit être établie pour ces programmes, avec des limites sur leur
  • (par exemple, des onglets sur Chrome, dont chacun est de 20 à 50 Mo, dont certains peuvent utiliser des centaines de Mo)
  • (par exemple, d'autres programmes comme update-db et les indexeurs que j'ai dû désactiver et supprimer de cron car ils ralentissaient le système à chaque fois qu'ils s'exécutaient, etc.)
• quelque chose de terrible qui se produit dans le conflit du noyau ou du bus, de telle sorte que les situations à haut débit de disque ralentissent le système entier à une analyse (peut-être en paginant des programmes importants)
• le noyau ne priorise pas l'interface utilisateur ou les programmes importants en termes de ressources, telles que la mémoire, la pagination, voire l'utilisation du processeur

Les votes positifs vont à:

Je recherche donc une solution où tous ces programmes disparaissent. En particulier, je recherche une solution telle que les processus ralentissent proportionnellement, tandis que le système et les autres programmes restent entièrement inchangés et réactifs suffisamment longtemps pour tuer manuellement quelque chose. Le processus du gestionnaire de fenêtres (et tout ce qui pourrait affecter la réactivité de l'interface utilisateur) doit également être réactif en toutes circonstances.

En particulier, je suis intrigué par /etc/security/limits.conf( man limits.conf), mais je crains que cela ne donne qu'un contrôle par utilisateur, et les exemples commentés dans le fichier semblent plutôt opaques en termes de description ou par où commencer. J'espère que cela limits.conffonctionne, mais je ne serais pas surpris si cela ne fonctionnait même pas, ou si ce n'était pas une solution appropriée à mon problème, ou aussi granulaire que j'essaie de réaliser. Un nom par processus limits.confserait idéal, en supposant à nouveau que limits.conf fonctionne. Je serais heureux d'essayer un fichier limits.conf que les gens fournissent, pour tester si cela fonctionne, bien que je sois ouvert à toutes les solutions à ce stade.

Il pourrait également être utile d'avoir des informations sur la façon dont OS X parvient à maintenir une telle réactivité de l'interface utilisateur.

J'ai déjà modifié mes /tmpdossiers de cache et pour qu'ils soient activés tmpfset, en général, l'utilisation du disque est presque nulle.

Sujets vaguement liés:

• surcharge de mémoire

Les réponses que je ne pense pas fonctionneront:

• swapoff (Cela permet toujours aux programmes de mémoire de porc de s'en tirer avec un meurtre, et le système se bloque en permanence si la mémoire est vraiment mauvaise - vote à tous ceux qui peuvent suggérer un ajustement qui a invoqué le tueur OOM plus tôt avant de permuter et cible des programmes spécifiques)
• echo ?? > /sys/.../swappiness (aucun effet discernable)
• nice (n'a jamais fonctionné)
• ionice (jamais remarqué de différence)
• selinux (l'incompatibilité de programme semble être un cauchemar)
• Linux en temps réel, c.-à-d. peut interrompre le noyau (ne veut pas s'occuper de la compilation et de la mise à jour du noyau personnalisé; pourrait être correct s'il a migré dans des référentiels)
*

On dirait que votre système est lourdement échangé. L'utilisation vmstat 1peut révéler certains détails - il suffit de le laisser s'exécuter dans une fenêtre de terminal et d'y basculer lorsque le ralentissement entre en action.

Plutôt que de mettre / tmp et "cache" dans tmpfs, j'utiliserais un système de fichiers sur disque normal monté avec l' noatimeoption. Souvent, les données utilisées restent dans les caches et les anciennes données peuvent être écrites sur le disque pour libérer de la RAM pour les applications. Si / tmp et / ou le cache grossit, cela pourrait être très utile.

Je ne suis pas développeur de noyau mais j'ai passé des années à philosopher sur ce problème parce que je suis tombé sur ce soooo plusieurs fois. En fait, j'ai trouvé une métaphore pour toute la situation, alors laissez-moi vous dire cela. Je suppose dans mon histoire que des choses comme «swap» n'existent pas. Le swap n'a pas beaucoup de sens de nos jours avec 32 Go de RAM.

Imaginez un de vos quartiers où l'eau est raccordée à chaque bâtiment par des canalisations et où les villes doivent gérer la capacité. Supposons que vous n'ayez qu'une production de 100 unités d'eau par seconde (et que toute la capacité inutilisée soit gaspillée parce que vous n'avez pas de réservoirs). Chaque maison (maison = une petite application, un terminal, le widget horloge, etc.) nécessite 1 unité d'eau par seconde. Tout cela est agréable et bon parce que votre population est d'environ 90 personnes, donc tout le monde a assez d'eau.

Maintenant, le maire (= vous) décide que vous souhaitez ouvrir un grand restaurant (= navigateur). Ce restaurant abritera plusieurs cuisiniers (= onglets du navigateur). Chaque cuisinier a besoin d'une unité d'eau par seconde. Vous commencez avec 10 cuisiniers, donc la consommation totale d'eau pour tout le quartier est de 100 unités d'eau, ce qui est toujours bien.

Maintenant, les choses amusantes commencent: vous embauchez un autre cuisinier dans votre restaurant, ce qui rend les besoins en eau totaux 101 que vous n'avez évidemment pas. Tu dois faire quelque chose.

La gestion de l'eau (= noyau) a 3 options.

1. La première option consiste simplement à déconnecter le service pour les maisons qui n'ont pas utilisé l'eau récemment. C'est bien, mais si la maison déconnectée veut utiliser l'eau à nouveau, elle devra recommencer le long processus d'enregistrement. La gestion peut déconnecter plusieurs maisons pour libérer plus de ressources en eau. En fait, ils déconnecteront toutes les maisons qui n'ont pas utilisé d'eau récemment, gardant ainsi une certaine quantité d'eau gratuite toujours disponible.

Bien que votre ville continue de fonctionner, l'inconvénient est que le progrès s'arrête. La plupart de votre temps est consacré à l'attente de la gestion de l'eau pour rétablir votre service.

C'est ce que fait le noyau avec les pages sauvegardées sur fichier. Si vous exécutez un grand exécutable (comme Chrome), son fichier est copié dans la mémoire. Lorsqu'il manque de mémoire ou s'il y a des parties qui n'ont pas été consultées récemment, le noyau peut supprimer ces parties car il peut les recharger de toute façon. Si cela est fait de manière excessive, cela arrête votre bureau car tout attendra simplement les E / S du disque. Notez que le noyau supprimera également beaucoup de pages les moins récemment utilisées lorsque vous commencez à faire beaucoup d'E / S. C'est pourquoi il faut du temps pour passer à une application d'arrière-plan après avoir copié plusieurs fichiers volumineux comme des images DVD.

C'est le comportement le plus ennuyeux pour moi car je déteste les hickups et vous n'avez aucun contrôle sur cela. Ce serait bien de pouvoir l'éteindre. Je pense à quelque chose dans le sens de

sed -i 's/may_unmap = 1/may_unmap = (vm_swappiness >= 0)/' mm/vmscan.c

puis vous pouvez définir vm_swappiness sur -1 pour désactiver cela. Cela a très bien fonctionné dans mes petits tests mais hélas je ne suis pas développeur de noyau donc je ne l'ai envoyé à personne (et évidemment la petite modification ci-dessus n'est pas complète).

2.La direction pourrait refuser la demande d'eau du nouveau cuisinier. Cela semble initialement être une bonne idée. Cependant, il y a deux inconvénients. D'abord, il y a des entreprises qui demandent beaucoup d'abonnements à l'eau même si elles ne les utilisent pas. Une raison possible de le faire est d'éviter tous les frais généraux de parler à la gestion de l'eau chaque fois qu'ils ont besoin d'un peu d'eau supplémentaire. Leur consommation d'eau augmente et diminue en fonction de l'heure de la journée. Par exemple, dans le cas du restaurant, l'entreprise a besoin de beaucoup plus d'eau à midi qu'à minuit. Ils demandent donc toute l'eau possible qu'ils pourraient utiliser, mais cela gaspille les allocations d'eau à minuit. Le problème est que toutes les entreprises ne peuvent pas prévoir correctement leur utilisation de pointe, elles demandent donc beaucoup plus dans l'espoir qu'elles n'auront jamais à se soucier d'en demander plus.

C'est ce que fait la machine virtuelle de Java: elle alloue un tas de mémoire au démarrage puis fonctionne à partir de cela. Par défaut, le noyau n'allouera la mémoire que lorsque votre application Java commencera à l'utiliser. Cependant, si vous désactivez la surcharge, le noyau prendra la réservation au sérieux. Elle ne permettra à l'allocation de réussir que si elle a réellement les ressources nécessaires.

Cependant, il y a un autre problème plus grave avec cette approche. Disons qu'une entreprise commence à demander une seule unité d'eau chaque jour (plutôt que par étapes de 10). Finalement, vous atteindrez un état où vous aurez 0 unités libres. Désormais, cette entreprise ne pourra plus allouer. C'est bien, qui se soucie de toute façon des grandes entreprises. Mais le problème est que les petites maisons ne pourront pas non plus demander plus d'eau! Vous ne pourrez pas construire de petites salles de bains publiques pour faire face à l'afflux soudain de touristes. Vous ne pourrez pas fournir d'eau d'urgence pour le feu dans la forêt voisine.

En termes informatiques: dans des situations de mémoire très faible sans surengagement, vous ne pourrez pas ouvrir un nouveau xterm, vous ne pourrez pas accéder à votre machine, vous ne pourrez pas ouvrir un nouvel onglet pour rechercher d'éventuelles corrections. En d'autres termes, la désactivation de la surcommission rend également votre bureau inutile lorsqu'il manque de mémoire.

3. Voici maintenant une façon intéressante de gérer le problème lorsqu'une entreprise commence à utiliser trop d'eau. La gestion de l'eau explose! Littéralement: il se rend sur le site du restaurant, y jette des dynamites et attend qu'il explose. Cela réduira instantanément de beaucoup les besoins en eau de la ville afin que de nouvelles personnes puissent emménager, vous pouvez créer des toilettes publiques, etc. Vous, en tant que maire, pouvez reconstruire le restaurant dans l'espoir que cette fois, il aura besoin de moins d'eau. Par exemple, vous direz aux gens de ne pas aller dans les restaurants s'il y a déjà trop de monde à l'intérieur (par exemple, vous ouvrirez moins d'onglets de navigateur).

C'est en fait ce que fait le noyau lorsqu'il manque de toutes les options et qu'il a besoin de mémoire: il appelle le tueur OOM. Il sélectionne une grande application (basée sur de nombreuses heuristiques) et la tue, libérant un tas de mémoire tout en conservant un bureau réactif. En fait, le noyau Android le fait de manière encore plus agressive: il tue l'application la moins récemment utilisée lorsque la mémoire est faible (par rapport au noyau de base qui ne le fait qu'en dernier recours). Cela s'appelle le Viking Killer dans Android.

Je pense que c'est l'une des solutions les plus simples au problème: ce n'est pas comme si vous aviez plus d'options que cela, alors pourquoi ne pas y remédier plus tôt que tard, non? Le problème est que le noyau fait parfois beaucoup de travail pour éviter d'invoquer le tueur OOM. C'est pourquoi vous voyez que votre bureau est très lent et que le noyau n'y fait rien. Mais heureusement, il existe une option pour invoquer le tueur OOM vous-même! Tout d'abord, assurez-vous que la clé magique sysrq est activée (par exemple echo 1 | sudo tee /proc/sys/kernel/sysrq) puis chaque fois que vous sentez que le noyau manque de mémoire, appuyez simplement sur Alt + SysRQ, Alt + f.

OK donc tout ça est sympa mais tu veux l'essayer? La situation de mémoire faible est très simple à reproduire. J'ai une application très simple pour ça. Vous devrez l'exécuter deux fois. La première exécution déterminera combien de RAM libre vous avez, la deuxième exécution créera la situation de mémoire faible. Notez que cette méthode suppose que vous avez désactivé l'échange (par exemple, faites un sudo swapoff -a). Le code et l'utilisation suivent:

// gcc -std=c99 -Wall -Wextra -Werror -g -o eatmem eatmem.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main(int argc, char** argv)
{
    int limit = 123456789;
    if (argc >= 2) {
        limit = atoi(argv[1]);
    }
    setbuf(stdout, NULL);
    for (int i = 1; i <= limit; i++) {
        memset(malloc(1 << 20), 1, 1 << 20);
        printf("\rAllocated %5d MiB.", i);
    }
    sleep(10000);
    return 0;
}

Et voici comment vous l'utilisez:

$ gcc -std=c99 -Wall -Wextra -Werror -g -o eatmem eatmem.c
$ ./eatmem
Allocated 31118 MiB.Killed
$ ./eatmem 31110
Allocated 31110 MiB.Killed

La première invocation a détecté que nous disposions de 31 118 Mo de RAM libre. J'ai donc demandé à l'application d'allouer 31 110 Mo de RAM pour que le noyau ne le tue pas mais consomme presque toute ma mémoire. Mon système s'est figé: même le pointeur de la souris n'a pas bougé. J'ai appuyé sur Alt + SysRQ, Alt + f et cela a tué mon processus eatmem et le système a été restauré.

Même si nous avons couvert nos options ce que font dans une situation de faible mémoire, la meilleure approche (comme toute autre situation dangereuse) est de l'éviter en premier lieu. Il y a plusieurs façons de procéder. Une façon courante que j'ai vue est de mettre les applications qui se comportent mal (comme les navigateurs) dans des conteneurs différents de ceux du reste du système. Dans ce cas, le navigateur ne pourra pas affecter votre bureau. Mais la prévention elle-même est en dehors de la portée de la question, donc je n'écrirai pas à ce sujet.

TL; DR: Bien qu'il n'existe actuellement aucun moyen d'éviter complètement la pagination, vous pouvez atténuer l'arrêt complet du système en désactivant la surcharge. Mais votre système sera toujours inutilisable lors d'une situation de faible mémoire, mais d'une manière différente. Indépendamment de ce qui précède, dans une situation de faible mémoire, appuyez sur Alt + SysRQ, Alt + f pour tuer un grand processus du choix du noyau. Votre système devrait restaurer sa réactivité après quelques secondes. Cela suppose que la clé magique sysrq est activée (ce n'est pas le cas par défaut).

Le fait de placer tous vos fichiers temporaires et de cache sur un tmpfsréduit la quantité de RAM libre dont vous disposez, de sorte que vous pourriez faire en sorte que le système permute plus tôt que nécessaire sans cela.

Il semble que vous ayez certaines applications qui reposent sur une sorte d'installation ou de pilote du noyau qui est surchargé. Vous n'entrez pas trop dans les détails sur les types d'applications autres que vous utilisez les navigateurs et les indexeurs et que vous avez désactivé les indexeurs.

Vous pouvez essayer de basculer vers un environnement de bureau ou un gestionnaire de fenêtres qui consomme moins de ressources, comme LXDE ou IceWM. Au travail, j'utilise un système Linux avec LXDE installé et ROX-Filer pour un environnement de bureau très minimal. Le but de ce système Linux est d'exécuter VMWare Player afin que je puisse exécuter Windows XP et Windows 7 simultanément. Les spécifications matérielles sont similaires à ce que vous dites et je n'ai pas trop de problèmes de réactivité sous cette lourde charge que je soumets au matériel. Je n'ai aucun problème de réactivité avec Linux lui-même (ce sont généralement les machines virtuelles qui me font parfois attendre une seconde, et le partage de 1 disque entre 2 machines virtuelles + 1 système d'exploitation est prévu) et j'ai toujours pu suspendre ou arrêter les machines virtuelles à chaque fois Je veux.

Donc, pour moi, cela indique un problème avec des applications spécifiques que vous exécutez.

Le DMA est-il activé pour vos lecteurs de disque? (utilisation hdparm) Si vous utilisez le chiffrement complet du disque, cela nécessite que tout le trafic disque passe par le processeur, ce qui annule une grande partie des avantages du DMA. L'effet serait que le trafic de disque élevé provoque un pic de CPU qui ralentirait alors l'ensemble du système. (EDIT: pour clarifier, avoir DMA désactivé OU utiliser dm-cryptentraînera un CPU élevé pendant un trafic disque élevé)

Il s'agit d'un problème courant avec le planificateur de Linux. Le système ralentit jusqu'à une analyse chaque fois que des activités lourdes d'E / S se produisent. Il n'y a pas vraiment beaucoup de choses que vous pourriez faire pour améliorer la situation, sauf si vous êtes dans le piratage du noyau :)

Peut-être que ceux-ci peuvent aider:

http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1

http://www.osnews.com/story/24223/Alternative_to_the_200_Lines_Kernel_Patch_that_Does_Wonders_

Même si la question remonte à plus de deux ans et que la réponse de @ ypsu est excellente, la situation avec les systèmes basés sur Linux qui va mal en raison du manque de RAM est toujours là.

Voici mon observation sur le problème: même si je n'ai pas du tout d'échange, une fois que le système est à court de mémoire, mon indicateur de disque dur s'allume car il s'agit d'une charge de disque à 100%. Compte tenu de ce fait, il semble que la cause principale soit que le noyau essaie de libérer de la mémoire en déchargeant quelque chose qui peut être restauré à partir du disque, et qui est, très certainement, des bibliothèques partagées. Étant donné que les applications GUI ont généralement des tonnes de bibliothèques partagées, il semble que le système pense qu'il suffit de décharger certaines d'entre elles, mais cela ne fonctionne que jusqu'à la prochaine opération de l'espace utilisateur qui nécessite le retour de ces bibliothèques déchargées. Cela semble être le scénario le plus probable provoquant la boucle sans fin de déchargement des bibliothèques partagées et de les recharger.

Il existe un projet qui agit comme un démon de l'espace utilisateur tuant les processus les plus gourmands en mémoire avant qu'il ne soit trop tard: https://github.com/rfjakob/earlyoom

De plus, j'avais l'habitude d'utiliser des conteneurs Docker avec des limites de mémoire raisonnables pour les applications gourmandes en mémoire (par exemple Chrome).