Bonjour j'ai une question lié à un serveur que j'ai
j'ai remarqué que ma machine swap alors qu'il lui reste de la mémoire vive
free -m
total used free shared buffers cached
Mem: 8112 5166 2946 0 497 136
-/+ buffers/cache: 4532 3580
Swap: 1999 424 1575
Si quelqu'un peut m'expliquer pourquoi je suis preneur
Merci
# le swapin est normal sous linux...
Posté par ze_lionix (site web personnel) . Évalué à 3.
C'est le système qui met en swap les processus qui fichent pas grand choses, pour avoir de la mémoire "rapide" disponible en cas de besoin
C'est linux qui gère bien la mémoire, mieux que zin tout ca( buffercache, swap in/out )
Tu as pour 424 Mo de processus qui "pioncent"...
Rien d'affolant pour moi....
Pour te rassurer regarde les page in/out
NB : si c'est des proc java il est recommandé de forcer le maintient en mémoire haute.
La JVM ( en tout cas celle de sun, ha non oracle, car pour la jerokit je sais pas trop je l'ai pas trop pratiqué ) supporte assez mal les allé retour en swap..
Fuse : j'en Use et Abuse !
[^] # Re: le swapin est normal sous linux...
Posté par drexya . Évalué à 1.
Et pour un peu plus d'infos concernant la gestion du swap > http://lwn.net/Articles/83588
[^] # Re: le swapin est normal sous linux...
Posté par BB . Évalué à 4.
J’ajouterai, pour régler tout ça :
echo 0/100 > /proc/sys/vm/swappiness
et direction /etc/sysctl.(conf|d)
# swap
Posté par tese . Évalué à 1.
ok merci pour vos réponse
j'ai fait
cat /proc/meminfo pour avoir plus d'info mais c’était trop tard je suis redescendu à 65 mo .j 'ai remarqué que c'est accès récurrent cette utilisation de 400~ mo. Mais si vous me dite que c'est pas anormale.
# swap
Posté par tese . Évalué à 1.
Effectivement sur ce serveur il n'y a que des jvm
[^] # Re: swap
Posté par duf . Évalué à 5.
Bonjour,
Tout d'abord les aspects purement performance, qui peut être ne t'intéresse pas mais qui me permette d'introduire rapidement des mécanismes de fonctionnement. Donc quelles que soient les JVMs (sun, hp, jrockit, etc.) elles sont toujours sensibles quand elles sont en swap disque (je précise swap disque pour pas confondre avec la pseudo-swap d'hp-ux), c'est d'autant plus vrai lorsqu'elles sont soumises à de la charge.
Pour faire simple, si les utilisateurs remontent des problèmes de performance, alors le seul indicateur a regarder pour savoir si le swap disque est la cause, c'est de surveiller le swapin/swapout. Le taux d'occupation du swap ne sert à rien si on ne sait pas à quel moment il s'est rempli.
En effet, pour une raison ou une autre, le système d'exploitation a pu décider à un moment de mettre des process en swap car il avait besoin de la mémoire. Mais si ensuite il n'y a plus aucun si/so alors que les process sont toujours en swap, c'est qu'ils n'ont aucune activité. Et ils vont rester en swap tant qu'ils ne seront pas sollicités.
Si par contre, tu constates du si/so, alors c'est mauvais pour les performances (c'est d'ailleurs vrai pour d'autres process, pas seulement JVMs).
Pour le surveiller, le plus simple c'est un vmstat -n 5, tu as le si et le so.
Pour revenir sur ton cas précis, les ~400Mo de swap sont peut être là depuis très longtemps et si le système constate qu'ils ne sont pas utilisés alors il estime qu'il n'a pas intérêt à le repasser en mémoire. En effet ça évite de lire le disque et d'écrire en mémoire et de prendre de la place mémoire pour des process qui a priori ne font rien. Donc autant laisser la mémoire libre disponible pour les prochaines exécutions.
C'est un peu rapide mais le sujet est long :)
@+
# Explication possible
Posté par DLFP est mort . Évalué à 3.
J'ai remarqué ça sur un serveur à moi aussi, et je pense que ça vient de tâches ponctuelles qui prennent beaucoup de mémoire et relèguent donc les autres en swap. Comme ces dernières restent inactives elles restent en swap.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Explication possible
Posté par benja . Évalué à 2.
Qui restent inactives ou qui n'accèdent tout simplement plus à toutes les pages de mémoire qui leurs ont été allouées... Évidemment c'est moins chouette avec les garbage collectors qui parcourent inconditionnellement l'ensemble du tas :^)
[ Btw, il me semble avoir entendu parler (d'un projet/recherche) d'une implémentation de gc qui s'appuyerait sur des indications du kernel justement : le problème étant qu'un processus n'a pas les informations d'accès et de pagination que le kernel a, rendant certaines optimisations impossibles pour les gc, aussi il ne sait pas tirer partie de la mmu matérielle. ]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.