J'ai lancé quelque chose qui prenait beaucoup de mémoire et maintenant tout est très lent. Je suppose que la mémoire de toutes les applications a été transférée dans la mémoire d'échange afin de libérer de l'espace pour le processus gourmand en mémoire, et maintenant tout retourne lentement à la RAM lors des accès.
Existe-t-il un moyen de déplacer explicitement tout ce qui est possible du swap vers la RAM ? Ou peut-être pas tout, mais seulement certaines données de processus particuliers ?
Je recommanderais de laisser le contrôle normal de la mémoire de Linux échanger les choses qui sont réellement utilisées, comme elles sont utilisées.
La seule chose à laquelle je pense est de désactiver le swap, puis de le réactiver.
sudo swapoff -a
sudo swapon -aCela suppose que vous ayez assez de mémoire physique libre pour contenir tout ce qui est en swap...
Cela fonctionne, mais très lentement :) Merci ! Mais je crois quand même qu'il y a une solution plus élégante :)
Attention avec cette solution, elle va tout sortir du swap de force... si ça ne rentre pas dans la mémoire physique, le noyau va lancer le tueur d'OOM mortel. Je ne connais pas de commande sympa "essayez de tout déplacer en RAM, mais échouez gracieusement si ce n'est pas possible".
Je l'ai essayé et j'ai découvert qu'il fonctionne très lentement. Donc il est possible de surveiller la RAM libre et de tuer swapoff si la mémoire devient faible : dans ce cas, l'espace d'échange restera fonctionnel :)
Vous pouvez le régler pour qu'il fasse écho à un nombre compris entre 0 et 100 en /proc/sys/vm/swappiness .
Ce contrôle est utilisé pour définir l'agressivité du noyau en matière d'échange de données. pages de mémoire. Des valeurs plus élevées augmenteront l'agressivité, valeurs inférieures diminuer le montant du swap . Une valeur de 0 indique que le noyau ne doit pas n'initie pas l'échange tant que la quantité de pages libres et de pages sauvegardées dans les fichiers n'est pas que le point culminant d'une zone.
La valeur par défaut est de 60.
N'utilisez pas directement /proc/sys, utilisez la fonction sysctl à la place. Dans ce cas, c'est sysctl vm.swappiness=x .
Je ne pense pas qu'un taux de permutation de zéro entraînera l'introduction explicite en mémoire principale de pages déjà permutées ?
@Douglas a raison. vm.swappiness va principalement contrôler la décision de déplacer les choses vers le swap ou de réduire la quantité de caches et de tampons lorsque la mémoire est demandée.
Linux fait un excellent travail de gestion de la mémoire et vous ne devriez pas vous mettre en travers de son chemin. Le paramètre vm.swappiness (mentionné précédemment) ne le gêne pas. Vous êtes plus susceptible de rencontrer des problèmes bizarres en procédant autrement.
Qu'avez-vous lancé qui était si gourmand en mémoire ? Peut-il être réglé ? S'il n'a pas ses propres directives de limitation de la mémoire, vous pouvez aussi regarder du côté de ulimit.
Dans mon cas, c'était convert -density 200 file.pdf jpegs/file.jpg . Pour une raison quelconque, il utilise beaucoup de mémoire, mais vous avez raison : il peut être réglé. De toute façon, la situation est possible avec n'importe quelle application :)
Je suis d'accord avec cette réponse - vous devriez probablement laisser les opérations normales sur la machine pour échanger ce qui est réellement nécessaire.
convert a le -limit pour contrôler son utilisation de la mémoire et du disque, et vous devriez vous documenter à ce sujet. Configuration de -limit memory 512MB ou similaire serait bien. Il serait probablement bon également de spécifier un MAGICK_TEMPORARY_PATH explicite et de le nettoyer après la fin de votre commande.
Pour copier une partie de ma réponse de cette question .
Pour que vous sachiez comment fonctionne l'accord de swappiness. Il indique au sous-système VM de rechercher des pages à échanger lorsque le % de la mémoire mappée aux tables de pages du processus + la valeur de swappiness est > 100. Ainsi, un réglage de 60 fera en sorte que le système commence à retirer les pages périmées de la table des pages de processus lorsqu'elle utilise plus de 40% de la mémoire de votre système. Si vous voulez permettre à vos programmes d'utiliser plus de mémoire au détriment du cache, vous devrez diminuer la valeur de swappiness.
Si vous avez la mémoire disponible pour toutes vos applications, il est possible de définir la permutation à 0 pour que les choses ne se permutent pas. Par exemple, qemu-kvm est une cible importante de la VMM pour être échangée, parce qu'elle "semble" être inactive la plupart du temps. J'ai vu jusqu'à 80% de la mémoire d'une mémoire qemu-kvm être écrite dans le swap. Les VMs fonctionnant dans qemu-kvm deviendront presque insensibles parce qu'elles sont à court de swap (bien que l'invité n'ait aucune idée de ce qui se passe). La VM invitée pensera que ses performances sont excellentes, alors qu'en réalité elle se traîne terriblement. Quand un groupe de VM se "réveille" et commence à faire des choses, la charge moyenne peut atteindre plus de 30, même sur du matériel de qualité professionnelle doté d'une mémoire et d'un disque rapides et abondants. Je suppose que c'est un défaut dans la conception de qemu-kvm prêt à l'emploi.
J'espère que cela aidera quelqu'un.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
