Posté par duf .
En réponse au message swap.
É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.
[^] # Re: swap
Posté par duf . En réponse au message swap. É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 :)
@+