La vraie question est, pourquoi courez-vous sans swap ? Surtout si vous rencontrez des problèmes de performances (graves) liés à un manque de RAM ? Vous savez que ne pas avoir de swap peut en fait rendre votre système plus lent, n'est-ce pas ?
La solution évidente est d'ajouter de l'espace d'échange et de ne pas faire chier votre système. Compte tenu du faible coût de l'espace disque, je ne vois aucune situation courante dans laquelle vous devriez jamais construire un système sans swap.
Pour répondre à votre question, je ne me souviens pas de tous les détails de bas niveau expliquant pourquoi l'échange est important même sur les systèmes où vous n'allez pas épuiser la mémoire, mais il y a eu des arguments sur la liste de diffusion du noyau Linux pour savoir si il est raisonnable d'exécuter des systèmes sans échange (et il n'y a pas eu beaucoup de réponses concluantes). Le consensus général est généralement de toujours avoir un swap , et ajustez la permutation si nécessaire.
De plus, je pense que vous comprenez mal certaines mises en garde importantes concernant le Linux OOM killer. Tout d'abord, compter sur lui pour gérer vos problèmes de mémoire insuffisante est une très mauvaise idée (tm). Il peut être très aveugle sur ce qu'il tue, et il est tout à fait possible que vous vous retrouviez avec un système instable ou même inutilisable. Oui, il tente de tuer les processus récents qui consomment beaucoup de mémoire (une sauvegarde mineure pour essayer d'attraper un processus en fuite), mais il n'y a aucune garantie. Je l'ai vu tuer ssh, tuer les processus Xen (sur un serveur hôte virtuel Xen, provoquant le plantage des machines virtuelles) et, dans un cas, il a tué NFS.
Quant à l'IO. . . Je ne sais pas avec certitude ce qui en serait la cause. Peut-être qu'un processus lié au système de fichiers ou au disque a été tué ? Peut-être qu'un processus a une sorte de fonctionnalité "cache sur disque" intégrée lorsqu'il ne peut pas allouer suffisamment de mémoire ?
Autre remarque, s'il s'agit d'un bureau, un échange est requis pour Suspend to Disk. S'il s'agit d'un serveur, s'appuyer sur OOM n'est jamais une bonne idée, car cela compromet la stabilité pour, eh bien, aucune bonne raison.
[1] Les systèmes embarqués sont à peu près la seule exception évidente, et ils ne sont pas particulièrement courants (et si vous avez affaire à des systèmes embarqués, vous connaissez déjà les exigences).
Je pense qu'AndreasM l'a frappé sur la tête (la raison pour laquelle le disque devient tout thrash.) Les exécutables sont paginés à la demande - donc en fonctionnement normal, vous aurez presque tous vos exécutables et bibliothèques assis dans une bonne vieille RAM physique. Mais lorsque la RAM est faible, mais pas suffisamment pour que le tueur de mémoire insuffisante soit exécuté, ces pages sont expulsées de la RAM. Vous vous retrouvez donc dans une situation où les pages sont expulsées - au début, pas de problème, car elles sont expulsées les moins récemment utilisées en premier et cela expulse les pages que vous n'utilisez pas de toute façon. Mais ensuite, ça expulse ceux que vous êtes en utilisant, juste pour avoir à les paginer juste quelques instants plus tard. Ville thrash.
Fondamentalement, si quelque chose utilisait juste un peu plus de RAM, vous auriez probablement le coup de pied du tueur OOM, mais vous n'étiez pas encore là. Comme quelques-uns l'ont dit, OOM killer est aveugle, c'est vraiment plus un dernier recours pour éviter une panique du noyau que quelque chose que vous devriez envisager d'utiliser en fonctionnement normal. Si vous avez une configuration personnalisée, j'envisagerais d'écrire un démon pour surveiller la mémoire libre et de tuer en utilisant la politique de votre choix lorsqu'elle approche de la saturation.