Pouvez-vous définir une taille minimale de tampon de disque Linux?

J'ai une machine Linux assez ancienne avec 2 Go de RAM, pas de swap, et cela fonctionne très bien, avec le système utilisant chaque morceau de mémoire inutilisé pour la mise en cache avec beaucoup d'effet.

Cependant, lorsque je suis sur le point de surcharger la mémoire (par exemple,> 1950 Mo alloués), cela ralentit en une exploration; Je soupçonne que c'est parce qu'il n'y a plus de tampons de disque. Je sais que le tueur OOM entrerait bientôt en vigueur, mais il n'y arrive généralement pas - il devient si lent que les charges tournent à 30-40, aucun processus ne progresse (donc n'alloue pas plus de mémoire), et Je dois le redémarrer.

Lorsque j'essaie de tuer un seul processus pour que la machine réponde, par exemple en allant sur la console (via Alt-F1, en me connectant et en effectuant simplement un "mauvais processus killall"), cela fonctionne généralement, sauf que je dois attendre ~ 10 minutes entre l'utilisateur / mot de passe et l'obtention d'une invite - tout en présence d'activité sur le disque.

Encore une fois, il n'y a pas d'échange, donc ce n'est pas l'échange - c'est juste une raclée car il n'y a plus de tampons.

J'aurais beaucoup plus de 100 Mo dédiés exclusivement aux tampons de disque, ce qui déclencherait le tueur OOM plus tôt (moins de mémoire pour les programmes, après tout) mais, d'autre part, laisserait la machine réactive à tout moment.

Y-a-t-il un moyen de faire ça? Je n'ai pas pu trouver une entrée / proc / kernel ou / sys / vm qui fait ce genre de chose.

linux cache

— HopelessN00b
source

J'ai également le même problème, et malheureusement aucune des réponses à cette date n'aide dans cette affaire.

— Krišjānis Nesenbergs

Réponses:

Jetez un œil à / proc / sys / vm / min_free_kbytes . C'est la limite des kilo-octets libres qui déclenche le tueur à gages. De plus, il serait bon de vérifier dans les journaux le mot-clé oom-killer afin de savoir ce qui est tué {de préférence, vous ne voulez pas tuer ssh , il vaut mieux le renier }

— Nikolaidis Fotis
source

Merci. Je l'ai agrandi, mais cela ne semble pas résoudre le problème - une fois que la mémoire physique était proche de l'épuisement, il ne restait plus de mémoire tampon et la machine a ralenti.

Aucune aide ici non plus, le système ne répond toujours pas du tout.

— Tronic

En fait, cela m'a aidé, j'ai également 2 Go de RAM et je l'ai réglé à près de 500 Mo

— Krišjānis Nesenbergs

Je teste actuellement ce paramètre sur mon poste de travail. J'ai 8 Go de RAM et la plupart du temps, je n'en utilise pas plus de 5 ... sauf quand, pour une raison quelconque, je dois allumer une machine virtuelle Windows qui nécessite environ 4 Go de RAM. J'ai installé ZRAM sur mon OS hôte car mon disque dur est mécanique, mais il devient encore assez lent avec la RAM presque pleine en raison précisément du faible espace RAM pour les tampons et les caches du système de fichiers. Je viens d'utiliser vm.min_free_kbytes pour m'assurer que j'ai toujours au moins 2 Go de libre et que le reste est paginé sur la RAM zippée (ce qui est beaucoup plus rapide que l'espace de swap normal). Publiera plus tard avec les résultats.

— RAKK

Attendre que le tueur à gages libère de la mémoire, c'est un peu comme attendre que le moteur s'arrête sur votre voiture pour vous dire quand il est temps de remplir votre réservoir d'essence. Le tueur à gages est un outil lourd de dernier recours et de désespoir pour une machine affamée de ressources. Il tue le prochain programme qu'il touche sans tenir compte de la façon dont cela affectera votre application, l'accessibilité, la fiabilité, etc. Lorsque le tueur à gages est invoqué, votre serveur est à bout de souffle et dans un état critique.

Au lieu de cela, il vaut mieux adopter une approche active pour gérer votre utilisation de la mémoire dans votre environnement d'application. Vous pouvez surveiller / proc / meminfo en cas de problème et prendre les mesures appropriées et réduire votre charge de travail avant qu'une situation grave ne se gêne.

— tylerl
source

La situation que j'ai découverte est exactement le moment où mon serveur est à bout de souffle et dans un état critique. Cela prend moins de 20 secondes d'une machine entièrement réactive à prendre 1 minute pour répondre à Ctrl-Alt-F1 (passer de X à la console). Et la connexion est impossible car elle expire après 1 minute sans même demander un mot de passe. Il s'agit d'une machine qui exécute de nombreux processus; chacun n'est indépendamment PAS le problème. En outre, il s'agit strictement d'un problème de mémoire - le processeur est bien et le disque est bien tant qu'il reste environ 50 Mo de tampons de disque.

que se passe-t-il si vous utilisez ulimit et si une application utilise plus d'un certain seuil pour effectuer une action?

— Nikolaidis Fotis

Le problème est la somme de toutes les applications; Environ 20 sont en cours d'exécution, chacun avec 20 à 100 Mo alloués. Cela fonctionne bien pendant des semaines, voire des mois, mais quand ils veulent tous avoir ~ 100 Mo alloués en même temps, tout se bloque et brûle; Je préfère que oom_killer tue l'un d'entre eux plutôt que moi d'avoir à redémarrer la machine. Quoi qu'il en soit, j'ai activé le swap pour l'instant - la plupart des applications n'utilisent pas toute leur mémoire tout le temps, donc la machine reste stable même lorsqu'elle est stressée jusqu'à la fin de la mémoire physique; cependant, je préférerais n'avoir aucun échange pour cette machine, si je le peux.

Ne résout pas le problème réel qui est une combinaison de ne pas définir de limites d'utilisation de la mémoire appropriées (les ulimits ne sont pas très utiles), les applications font facilement des ravages avec les allocations de mémoire, le tueur OOM ne se déclenche pas assez tôt et la destruction massive du disque et la non réponse causée par tout ça. Je viens de perdre 30 minutes du temps de mon employeur parce que la machine de développement mettrait le disque à la poubelle pendant une demi-heure lors de la compilation de mon code, au lieu de simplement tuer les processus Chrome dont il avait besoin pour tuer (ou la compilation elle-même) en moins d'une seconde, puis en finir.

— Tronic

Si vous configurez oom_adjcorrectement, vous pouvez faire fonctionner votre système de bureau un peu comme Android, où le système fonctionne pratiquement toujours contre OOM killer (techniquement, il existe un "low memory killer" et il est réglé via /sys/module/lowmemorykiller). La logique est de marquer en permanence les processus d'arrière-plan non critiques comme des victimes potentielles pour le tueur OOM et de rechercher les processus tués et de redémarrer lentement les programmes tués requis pour éviter de surcharger le système. Assurez-vous simplement que le processus qui continue de relancer d'autres processus est hors des limites pour OOM killer.

— Mikko Rantalainen