J'ai commencé à m'interesser à l'etude de la mémoire utilisée (ou pas)
sous linux (noyau 2.4 , red hat et suse )
J essaye de mettre en place une supervision qui me permettrait de savoir
si la machine commence à etre limite coté memoire Vive. Sachant que de
tres nombreux process plus ou moins gourmands tournent sur le serveur
(oracle , java etc...)
D'apres les informations recoltées , je sais que la commande "free" est
une blague et qu'il est nécessaire de taper sur /proc/meminfo pour
connaitre la mémoire "immédiatement reallouable" autrement dit la
mémoire effectivement disponible à l instant T sur le serveur.
A priori il semblerait qu'il faille regarder "Inact_target" afin de
connaitre la mémoire reellement dispo.
En parallele j'ai lu ailleurs que Memoire libre = Buffers + Cached
(toujours dans /proc/meminfo)
Sur 2 Go , il ne resterait que 20 kilo de memoire libre sur ce Serveur
à en croire Inact_target ? O_o
Dois je ajouter Cached + Buffers pour me faire une idée de ma memoire
restante et prete à etre utilisée ?
J aurai tendance a dire que Cached et buffers sont des memoires qui sont
"utilisées" donc non disponibles.
Dois je faire une simple soustraction : MemTotale - Active pour me
faire une idée de ce qu'il me reste reellement à disposition ?
Bref, quelqu'un pourrait il m eclairer sur ma mémoire disponible et sur
un manque potentiel à ce niveau sur mon serveur ?
Merci à ceux qui pourront m apporter des lumieres.
Ce qui est caractéristique d'un manque de RAM, c'est du trafic swapin & swapout simultané pendant longtemps (ie au moins plusieurs secondes) ou très fréquement: ça veut dire que le noyau est obligé de swapper un process pour en relancer un autre. Il faut quand même faire attention: au lancement d'un process, il y a un swapin important: chaque page de code du process qui n'a jamais été accédée déclenche un swapin qui la charge depuis le fichier executable. Mais, dans ce cas de figure, il ne devrait pas y avoir de swapout (ou très peu) en même temps.
Apparement, les champs si/so sont donnés en Ko/s, c'est donc exactement l'info voulue.
[...]
bon ok , alors que pensez vous d'une surveillance comme celle ci : Génération d'un log vmstat toute les 5 secondes (vmstat 5 >> /tmp/log)
avec une surveillance continue des champs swap "SI" et "SO" Si ces 2 champs sont différents de 0 simultanément sur 3 lignes (15 secondes) ==> Alors MANQUE DE RAM sur le serveur ou tout du moins etude approfondie à effectuer sur la memoire.
J'avoue etre tout de meme surpris de n avoir vu aucun post à ce sujet. Linux commence à etre serieusement utilisé en entreprise et je trouve que c est la moindre des choses de savoir si le serveur est deja limite ou va saturer à ce niveau si l'on monte en charge etc...
Merci de votre aide.
Ce qui est caractéristique d'un manque de RAM, c'est du
trafic swapin & swapout simultané pendant longtemps (ie au moins
plusieurs secondes) ou très fréquement: ça veut dire que le noyau est
obligé de swapper un process pour en relancer un autre.
Il faut quand même faire attention: au lancement d'un process, il y a un
swapin important: chaque page de code du process qui n'a jamais été
accédée déclenche un swapin qui la charge depuis le fichier executable.
Mais, dans ce cas de figure, il ne devrait pas y avoir de swapout (ou
très peu) en même temps.
Apparement, les champs si/so sont donnés en Ko/s, c'est donc exactement
l'info voulue.
[...]
bon ok , alors que pensez vous d'une surveillance comme celle ci :
Génération d'un log vmstat toute les 5 secondes (vmstat 5 >> /tmp/log)
avec une surveillance continue des champs swap "SI" et "SO"
Si ces 2 champs sont différents de 0 simultanément sur 3 lignes (15
secondes) ==> Alors MANQUE DE RAM sur le serveur ou tout du moins
etude approfondie à effectuer sur la memoire.
J'avoue etre tout de meme surpris de n avoir vu aucun post à ce sujet.
Linux commence à etre serieusement utilisé en entreprise et je trouve
que c est la moindre des choses de savoir si le serveur est deja limite
ou va saturer à ce niveau si l'on monte en charge etc...
Ce qui est caractéristique d'un manque de RAM, c'est du trafic swapin & swapout simultané pendant longtemps (ie au moins plusieurs secondes) ou très fréquement: ça veut dire que le noyau est obligé de swapper un process pour en relancer un autre. Il faut quand même faire attention: au lancement d'un process, il y a un swapin important: chaque page de code du process qui n'a jamais été accédée déclenche un swapin qui la charge depuis le fichier executable. Mais, dans ce cas de figure, il ne devrait pas y avoir de swapout (ou très peu) en même temps.
Apparement, les champs si/so sont donnés en Ko/s, c'est donc exactement l'info voulue.
[...]
bon ok , alors que pensez vous d'une surveillance comme celle ci : Génération d'un log vmstat toute les 5 secondes (vmstat 5 >> /tmp/log)
avec une surveillance continue des champs swap "SI" et "SO" Si ces 2 champs sont différents de 0 simultanément sur 3 lignes (15 secondes) ==> Alors MANQUE DE RAM sur le serveur ou tout du moins etude approfondie à effectuer sur la memoire.
J'avoue etre tout de meme surpris de n avoir vu aucun post à ce sujet. Linux commence à etre serieusement utilisé en entreprise et je trouve que c est la moindre des choses de savoir si le serveur est deja limite ou va saturer à ce niveau si l'on monte en charge etc...
Merci de votre aide.
yves
Il faut quand même faire attention: au lancement d'un process, il y a un swapin important: chaque page de code du process qui n'a jamais été accédée déclenche un swapin qui la charge depuis le fichier executable. Mais, dans ce cas de figure, il ne devrait pas y avoir de swapout (ou très peu) en même temps.
Tiens ça me fait penser... Ca c'est valable seulement dans le cas où l'algorithme de la vm précharge les pages en swap au chargement du process dans la ram. Les dernières versions de Linux font ça ? C'est pas ce qu'on appelle "aggressive swapping" ça ? Sur une machine moyennement chargée, ça me semble un peu bourrin comme méthode...
Yves
-- http://wiki.rougy.net -- Wiki Unix/Linux
Il faut quand même faire attention: au lancement d'un process, il y a un
swapin important: chaque page de code du process qui n'a jamais été
accédée déclenche un swapin qui la charge depuis le fichier executable.
Mais, dans ce cas de figure, il ne devrait pas y avoir de swapout (ou
très peu) en même temps.
Tiens ça me fait penser... Ca c'est valable seulement dans le cas où
l'algorithme de la vm précharge les pages en swap au chargement du
process dans la ram. Les dernières versions de Linux font ça ?
C'est pas ce qu'on appelle "aggressive swapping" ça ?
Sur une machine moyennement chargée, ça me semble un peu bourrin comme
méthode...
Il faut quand même faire attention: au lancement d'un process, il y a un swapin important: chaque page de code du process qui n'a jamais été accédée déclenche un swapin qui la charge depuis le fichier executable. Mais, dans ce cas de figure, il ne devrait pas y avoir de swapout (ou très peu) en même temps.
Tiens ça me fait penser... Ca c'est valable seulement dans le cas où l'algorithme de la vm précharge les pages en swap au chargement du process dans la ram. Les dernières versions de Linux font ça ? C'est pas ce qu'on appelle "aggressive swapping" ça ? Sur une machine moyennement chargée, ça me semble un peu bourrin comme méthode...
Yves
-- http://wiki.rougy.net -- Wiki Unix/Linux
yves
bon ok , alors que pensez vous d'une surveillance comme celle ci : Génération d'un log vmstat toute les 5 secondes (vmstat 5 >> /tmp/log)
avec une surveillance continue des champs swap "SI" et "SO" Si ces 2 champs sont différents de 0 simultanément sur 3 lignes (15 secondes) ==> Alors MANQUE DE RAM sur le serveur ou tout du moins etude approfondie à effectuer sur la memoire.
15 secondes, ça me parait léger. Je mettrai plutot une alarme à partir de 45 à 60 secondes pour voir ce qu'il se passe. Mais on ne peut pas encore parler de manque de mémoire, c'est un peu prématuré...
J'avoue etre tout de meme surpris de n avoir vu aucun post à ce sujet. Linux commence à etre serieusement utilisé en entreprise et je trouve que c est la moindre des choses de savoir si le serveur est deja limite ou va saturer à ce niveau si l'on monte en charge etc...
Ben c'est le boulot de l'admin, et c'est pas différent de n'importe quel Unix de base... Et c'est repris dans la plupart des cours d'admin Unix. C'est pas vraiment une info confidentielle ;-)
Merci de votre aide.
De rien, bon courage
Yves
-- http://wiki.rougy.net -- Wiki Unix/Linux
bon ok , alors que pensez vous d'une surveillance comme celle ci :
Génération d'un log vmstat toute les 5 secondes (vmstat 5 >> /tmp/log)
avec une surveillance continue des champs swap "SI" et "SO"
Si ces 2 champs sont différents de 0 simultanément sur 3 lignes (15
secondes) ==> Alors MANQUE DE RAM sur le serveur ou tout du moins
etude approfondie à effectuer sur la memoire.
15 secondes, ça me parait léger. Je mettrai plutot une alarme à partir
de 45 à 60 secondes pour voir ce qu'il se passe. Mais on ne peut pas
encore parler de manque de mémoire, c'est un peu prématuré...
J'avoue etre tout de meme surpris de n avoir vu aucun post à ce sujet.
Linux commence à etre serieusement utilisé en entreprise et je trouve
que c est la moindre des choses de savoir si le serveur est deja limite
ou va saturer à ce niveau si l'on monte en charge etc...
Ben c'est le boulot de l'admin, et c'est pas différent de n'importe quel
Unix de base... Et c'est repris dans la plupart des cours d'admin Unix.
C'est pas vraiment une info confidentielle ;-)
bon ok , alors que pensez vous d'une surveillance comme celle ci : Génération d'un log vmstat toute les 5 secondes (vmstat 5 >> /tmp/log)
avec une surveillance continue des champs swap "SI" et "SO" Si ces 2 champs sont différents de 0 simultanément sur 3 lignes (15 secondes) ==> Alors MANQUE DE RAM sur le serveur ou tout du moins etude approfondie à effectuer sur la memoire.
15 secondes, ça me parait léger. Je mettrai plutot une alarme à partir de 45 à 60 secondes pour voir ce qu'il se passe. Mais on ne peut pas encore parler de manque de mémoire, c'est un peu prématuré...
J'avoue etre tout de meme surpris de n avoir vu aucun post à ce sujet. Linux commence à etre serieusement utilisé en entreprise et je trouve que c est la moindre des choses de savoir si le serveur est deja limite ou va saturer à ce niveau si l'on monte en charge etc...
Ben c'est le boulot de l'admin, et c'est pas différent de n'importe quel Unix de base... Et c'est repris dans la plupart des cours d'admin Unix. C'est pas vraiment une info confidentielle ;-)
Merci de votre aide.
De rien, bon courage
Yves
-- http://wiki.rougy.net -- Wiki Unix/Linux
l'indien
On Fri, 08 Apr 2005 19:19:19 +0200, yves wrote:
Il faut quand même faire attention: au lancement d'un process, il y a un swapin important: chaque page de code du process qui n'a jamais été accédée déclenche un swapin qui la charge depuis le fichier executable. Mais, dans ce cas de figure, il ne devrait pas y avoir de swapout (ou très peu) en même temps.
Tiens ça me fait penser... Ca c'est valable seulement dans le cas où l'algorithme de la vm précharge les pages en swap au chargement du process dans la ram. Les dernières versions de Linux font ça ? C'est pas ce qu'on appelle "aggressive swapping" ça ?
Je n'ai jamais dit que le kernel préchargeait quoi que ce soit en swap. D'ailleurs, le code ne va jamais dans le swap, ce serait totalement innefficace, tant au niveau de la place perdue que du temps perdu à swapper pour rien: tout le code d'une appli (à part les applis auto-modifiantes, mais il y en a peu) est déjà stocké sur le disque, dans le fichier executable. Idem pour les données read-only. Plutôt que de perdre du temps à recopier du code ou des data inchangées dans le swap, Linux (comme tous les OS, je pense, actuellement) marque juste la page virtuelle comme étant swappée et libère la page physique. Lorsqu'il démare un executable, il marque _toutes_ les pages de code et de donnée (sauf la BSS, bien sur) comme étant swappées et ne charge rien en RAM. Ce qui fait que dès que le programme, dès qu'il accède à une page de code ou de donnée pour la première fois déclenche une faute de page. Le noyau voit que la page est marquée swappée et qu'elle n'est pas référencée dans le swap, donc il la recharge directement depuis le fichier executable. Ainsi, aucune page n'est jamais chargée pour rien et on n'utilise le swap que pour les pages qui ont été modifiées. Ca explique également qu'au démarage d'un process, il y a beaucoup de swap-in, puisque, toutes les pages étant marquées swappées, chaque accès à une nouvelle page déclenche une requête de swap. Tu peux l'observer facilement: juste après le démarage d'un process, tu regardes ses statistiques de swap, tu verras qu'il aura fait bcp d'accès au swap. Par contre, en tant normal, ce nombre n'augmente plus ou quasiment plus ensuite, sauf dans le cas de programmes très modulaire: un accès à un nouveau "module" (même s'il est dans le même fichier executable) demandera de charger celui ci, donc déclenchera de nouvelles requêtes de swap-in.
Sur une machine moyennement chargée, ça me semble un peu bourrin comme méthode...
C'est bien pour ça qu'aucun OS ne fait jamais celà...
On Fri, 08 Apr 2005 19:19:19 +0200, yves wrote:
Il faut quand même faire attention: au lancement d'un process, il y a un
swapin important: chaque page de code du process qui n'a jamais été
accédée déclenche un swapin qui la charge depuis le fichier executable.
Mais, dans ce cas de figure, il ne devrait pas y avoir de swapout (ou
très peu) en même temps.
Tiens ça me fait penser... Ca c'est valable seulement dans le cas où
l'algorithme de la vm précharge les pages en swap au chargement du
process dans la ram. Les dernières versions de Linux font ça ?
C'est pas ce qu'on appelle "aggressive swapping" ça ?
Je n'ai jamais dit que le kernel préchargeait quoi que ce soit en swap.
D'ailleurs, le code ne va jamais dans le swap, ce serait totalement
innefficace, tant au niveau de la place perdue que du temps perdu à
swapper pour rien: tout le code d'une appli (à part les applis
auto-modifiantes, mais il y en a peu) est déjà stocké sur le disque,
dans le fichier executable. Idem pour les données read-only. Plutôt que
de perdre du temps à recopier du code ou des data inchangées dans le
swap, Linux (comme tous les OS, je pense, actuellement) marque juste la
page virtuelle comme étant swappée et libère la page physique.
Lorsqu'il démare un executable, il marque _toutes_ les pages de code et
de donnée (sauf la BSS, bien sur) comme étant swappées et ne charge
rien en RAM. Ce qui fait que dès que le programme, dès qu'il accède à
une page de code ou de donnée pour la première fois déclenche une faute
de page. Le noyau voit que la page est marquée swappée et qu'elle n'est
pas référencée dans le swap, donc il la recharge directement depuis le
fichier executable. Ainsi, aucune page n'est jamais chargée pour rien et
on n'utilise le swap que pour les pages qui ont été modifiées.
Ca explique également qu'au démarage d'un process, il y a beaucoup de
swap-in, puisque, toutes les pages étant marquées swappées, chaque
accès à une nouvelle page déclenche une requête de swap.
Tu peux l'observer facilement: juste après le démarage d'un process, tu
regardes ses statistiques de swap, tu verras qu'il aura fait bcp d'accès
au swap. Par contre, en tant normal, ce nombre n'augmente plus ou
quasiment plus ensuite, sauf dans le cas de programmes très modulaire:
un accès à un nouveau "module" (même s'il est dans le même fichier
executable) demandera de charger celui ci, donc déclenchera de nouvelles
requêtes de swap-in.
Sur une machine moyennement chargée, ça me semble un peu bourrin comme
méthode...
C'est bien pour ça qu'aucun OS ne fait jamais celà...
Il faut quand même faire attention: au lancement d'un process, il y a un swapin important: chaque page de code du process qui n'a jamais été accédée déclenche un swapin qui la charge depuis le fichier executable. Mais, dans ce cas de figure, il ne devrait pas y avoir de swapout (ou très peu) en même temps.
Tiens ça me fait penser... Ca c'est valable seulement dans le cas où l'algorithme de la vm précharge les pages en swap au chargement du process dans la ram. Les dernières versions de Linux font ça ? C'est pas ce qu'on appelle "aggressive swapping" ça ?
Je n'ai jamais dit que le kernel préchargeait quoi que ce soit en swap. D'ailleurs, le code ne va jamais dans le swap, ce serait totalement innefficace, tant au niveau de la place perdue que du temps perdu à swapper pour rien: tout le code d'une appli (à part les applis auto-modifiantes, mais il y en a peu) est déjà stocké sur le disque, dans le fichier executable. Idem pour les données read-only. Plutôt que de perdre du temps à recopier du code ou des data inchangées dans le swap, Linux (comme tous les OS, je pense, actuellement) marque juste la page virtuelle comme étant swappée et libère la page physique. Lorsqu'il démare un executable, il marque _toutes_ les pages de code et de donnée (sauf la BSS, bien sur) comme étant swappées et ne charge rien en RAM. Ce qui fait que dès que le programme, dès qu'il accède à une page de code ou de donnée pour la première fois déclenche une faute de page. Le noyau voit que la page est marquée swappée et qu'elle n'est pas référencée dans le swap, donc il la recharge directement depuis le fichier executable. Ainsi, aucune page n'est jamais chargée pour rien et on n'utilise le swap que pour les pages qui ont été modifiées. Ca explique également qu'au démarage d'un process, il y a beaucoup de swap-in, puisque, toutes les pages étant marquées swappées, chaque accès à une nouvelle page déclenche une requête de swap. Tu peux l'observer facilement: juste après le démarage d'un process, tu regardes ses statistiques de swap, tu verras qu'il aura fait bcp d'accès au swap. Par contre, en tant normal, ce nombre n'augmente plus ou quasiment plus ensuite, sauf dans le cas de programmes très modulaire: un accès à un nouveau "module" (même s'il est dans le même fichier executable) demandera de charger celui ci, donc déclenchera de nouvelles requêtes de swap-in.
Sur une machine moyennement chargée, ça me semble un peu bourrin comme méthode...
C'est bien pour ça qu'aucun OS ne fait jamais celà...
