cgroups
sont la bonne façon de le faire, comme d'autres réponses l'ont souligné. Malheureusement, il n’ya pas de solution parfaite au problème, comme nous le verrons plus loin. Il existe différentes manières de définir les limites d'utilisation de la mémoire du groupe de contrôle. Comment faire pour que la session de connexion d'un utilisateur fasse automatiquement partie d'un groupe de contrôle varie d'un système à l'autre. Red Hat a quelques outils, tout comme systemd .
memory.memsw.limit_in_bytes
et memory.limit_in_bytes
fixer des limites incluant et non compris l'échange, respectivement. L'inconvénient memory.limit_in_bytes
est qu'il compte les fichiers mis en cache par le noyau pour le compte des processus du groupe de contrôle par rapport au quota du groupe. Moins de cache signifie plus d’accès au disque. Vous risquez donc de perdre des performances si le système disposait d’une mémoire suffisante.
D'autre part, memory.soft_limit_in_bytes
permet au groupe de contrôle de dépasser le quota, mais si le tueur de MOO du noyau est invoqué, les groupes de contrôle dépassant leurs quotas sont tués en premier, logiquement. L’inconvénient, c’est qu’il existe parfois des situations dans lesquelles de la mémoire est nécessaire immédiatement et que le tueur OOM n'a pas le temps de rechercher les processus à tuer, auquel cas quelque chose peut échouer avant les processus de l’utilisateur hors quota. tué.
ulimit
, cependant, est absolument le mauvais outil pour cela. ulimit impose des limites à l'utilisation de la mémoire virtuelle, ce qui n'est certainement pas ce que vous voulez. De nombreuses applications réelles utilisent beaucoup plus de mémoire virtuelle que de mémoire physique. La plupart des runtime collectés (Java, Go) fonctionnent de cette manière pour éviter la fragmentation. Un programme trivial "hello world" en C, s'il est compilé avec un assainisseur d'adresses, peut utiliser 20 To de mémoire virtuelle. Allocateurs qui ne s'appuient pas sur sbrk
, comme jemalloc (qui est l'allocateur par défaut pour Rust) ou tcmalloc, aura également une utilisation de la mémoire virtuelle largement supérieure à leur utilisation physique. Pour plus d'efficacité, de nombreux outils utilisent des fichiers mmap, ce qui augmente l'utilisation virtuelle mais pas nécessairement physique. Tous mes processus Chrome utilisent 2 To de mémoire virtuelle chacun. Je suis sur un ordinateur portable avec 8 Go de mémoire physique. Quiconque tenterait de définir des quotas de mémoire virtuelle risquait de casser Chrome, de le forcer à désactiver certaines fonctionnalités de sécurité reposant sur l'allocation (mais de ne pas utiliser) de grandes quantités de mémoire virtuelle, ou d'empêcher complètement un utilisateur d'abuser du système. .