Au démarrage du système, il n'y a que 300 Mo d'occupé en mémoire RAM.
Au fur et à mesure que l'on ouvre des programmes et qu'on les ferme une fois
fini, la quantité de mémoire occupé augmente.
Est-ce qu'il y a un moment ou ça redescend pour revenir à 300 Mo environ
quand on utilise plus de programme?
Je pensais qu'une fois tous les programmes fermés, la quantité de mémoire
occupée reviendrait "de suite" comme au démarrage du système.
Visiblement ce n'est pas le cas ou alors faut attendre un peu.
Je croyais que sous Linux il y avait une feature OOM_KILLER (un truc dans le genre) qui tue les processus au petit bonheur la chance quand y'a plus de mémoire ?
C'est une question qui m'intéresse. Cette option de configuration existait dans les noyaux de la série 2.4, mais je ne la retrouve plus dans les noyaux de la série 2.6. Qu'est-elle devenue ? Renommée, retirée pour cause de fiabilité insuffisante ou au contraire devenue non désactivable ?
Je croyais que sous Linux il y avait une feature OOM_KILLER (un truc dans le
genre) qui tue les processus au petit bonheur la chance quand y'a plus de
mémoire ?
C'est une question qui m'intéresse. Cette option de configuration
existait dans les noyaux de la série 2.4, mais je ne la retrouve plus
dans les noyaux de la série 2.6. Qu'est-elle devenue ? Renommée, retirée
pour cause de fiabilité insuffisante ou au contraire devenue non
désactivable ?
Je croyais que sous Linux il y avait une feature OOM_KILLER (un truc dans le genre) qui tue les processus au petit bonheur la chance quand y'a plus de mémoire ?
C'est une question qui m'intéresse. Cette option de configuration existait dans les noyaux de la série 2.4, mais je ne la retrouve plus dans les noyaux de la série 2.6. Qu'est-elle devenue ? Renommée, retirée pour cause de fiabilité insuffisante ou au contraire devenue non désactivable ?
Nicolas George
Pascal Hambourg wrote in message <fcjcup$ig3$:
C'est une question qui m'intéresse. Cette option de configuration existait dans les noyaux de la série 2.4, mais je ne la retrouve plus dans les noyaux de la série 2.6. Qu'est-elle devenue ? Renommée, retirée pour cause de fiabilité insuffisante ou au contraire devenue non désactivable ?
L'OOM Killer n'est pas désactivable (cf. mm/Makefile). Mais normalement, il doit être possible de désactiver l'overcommit assez pour qu'il ne survienne jamais.
Pascal Hambourg wrote in message <fcjcup$ig3$1@biggoron.nerim.net>:
C'est une question qui m'intéresse. Cette option de configuration
existait dans les noyaux de la série 2.4, mais je ne la retrouve plus
dans les noyaux de la série 2.6. Qu'est-elle devenue ? Renommée, retirée
pour cause de fiabilité insuffisante ou au contraire devenue non
désactivable ?
L'OOM Killer n'est pas désactivable (cf. mm/Makefile). Mais normalement, il
doit être possible de désactiver l'overcommit assez pour qu'il ne survienne
jamais.
C'est une question qui m'intéresse. Cette option de configuration existait dans les noyaux de la série 2.4, mais je ne la retrouve plus dans les noyaux de la série 2.6. Qu'est-elle devenue ? Renommée, retirée pour cause de fiabilité insuffisante ou au contraire devenue non désactivable ?
L'OOM Killer n'est pas désactivable (cf. mm/Makefile). Mais normalement, il doit être possible de désactiver l'overcommit assez pour qu'il ne survienne jamais.
-- We are all worms. But I do believe I am a glowworm. -- Winston Churchill
Matthieu Moy
Patrick Lamaizière writes:
Arol wrote:
C'est juste que je ne voulais pas me retrouver sur une erreur du type "memory full" avec arrêt du système.
ha ha ha
On a tous eu cette même peur mais elle n'est plus fondée.
Je croyais que sous Linux il y avait une feature OOM_KILLER (un truc dans le genre) qui tue les processus au petit bonheur la chance quand y'a plus de mémoire ?
C'est effectivement possible de remplir toute la mémoire de la machine, et que ce soit l'OOM_KILLER ou un malloc qui renvoit NULL, a priori, ça se passe mal (que ceux qui ont déjà testé _toutes_ les possibilités d'échec de malloc dans leurs programmes me jettent la première pière ;-) ).
Mais c'est vrai que vu la quantité de RAM des machines actuelles, en général, on n'atteint pas cette limite : on utilise toute la RAM, mais principalement pour du cache (donc, si on a besoin de plus de RAM, on oublie le cache, et pas besoin de tuer qui que ce soit), et pour peu qu'on ai quelques giga de swap, la machine se mettra à ramer bien avant d'attendre la limite « dure ».
-- Matthieu
Patrick Lamaizière <patnews1@davenulle.org> writes:
Arol wrote:
C'est juste que je ne voulais pas me retrouver sur une erreur du
type "memory full" avec arrêt du système.
ha ha ha
On a tous eu cette même peur mais elle n'est plus fondée.
Je croyais que sous Linux il y avait une feature OOM_KILLER (un truc dans le
genre) qui tue les processus au petit bonheur la chance quand y'a plus de
mémoire ?
C'est effectivement possible de remplir toute la mémoire de la
machine, et que ce soit l'OOM_KILLER ou un malloc qui renvoit NULL, a
priori, ça se passe mal (que ceux qui ont déjà testé _toutes_ les
possibilités d'échec de malloc dans leurs programmes me jettent la
première pière ;-) ).
Mais c'est vrai que vu la quantité de RAM des machines actuelles, en
général, on n'atteint pas cette limite : on utilise toute la RAM, mais
principalement pour du cache (donc, si on a besoin de plus de RAM, on
oublie le cache, et pas besoin de tuer qui que ce soit), et pour peu
qu'on ai quelques giga de swap, la machine se mettra à ramer bien
avant d'attendre la limite « dure ».
C'est juste que je ne voulais pas me retrouver sur une erreur du type "memory full" avec arrêt du système.
ha ha ha
On a tous eu cette même peur mais elle n'est plus fondée.
Je croyais que sous Linux il y avait une feature OOM_KILLER (un truc dans le genre) qui tue les processus au petit bonheur la chance quand y'a plus de mémoire ?
C'est effectivement possible de remplir toute la mémoire de la machine, et que ce soit l'OOM_KILLER ou un malloc qui renvoit NULL, a priori, ça se passe mal (que ceux qui ont déjà testé _toutes_ les possibilités d'échec de malloc dans leurs programmes me jettent la première pière ;-) ).
Mais c'est vrai que vu la quantité de RAM des machines actuelles, en général, on n'atteint pas cette limite : on utilise toute la RAM, mais principalement pour du cache (donc, si on a besoin de plus de RAM, on oublie le cache, et pas besoin de tuer qui que ce soit), et pour peu qu'on ai quelques giga de swap, la machine se mettra à ramer bien avant d'attendre la limite « dure ».
-- Matthieu
Nicolas George
Nicolas wrote in message :
J'en ai déduit que c'était le process qui demandait un surplus de mémoire, sans possibilité d'en avoir, qui était arrêté...
Non, ça ce serait ce qui se passe sans OOM Killer dédié, puisque quasiment aucun programme ne prévoit le cas d'un échec d'allocation de mémoire autrement qu'en quittant. L'OOM Killer essaie d'être plus fin, en trouvant le vrai responsable. Mais ce n'est pas une notion qu'il est possible de définir en toute rigueur.
Nicolas wrote in message <87bqc2itdi.fsf@nicoastro.homelinux.org>:
J'en ai déduit que c'était le
process qui demandait un surplus de mémoire, sans possibilité d'en
avoir, qui était arrêté...
Non, ça ce serait ce qui se passe sans OOM Killer dédié, puisque quasiment
aucun programme ne prévoit le cas d'un échec d'allocation de mémoire
autrement qu'en quittant. L'OOM Killer essaie d'être plus fin, en trouvant
le vrai responsable. Mais ce n'est pas une notion qu'il est possible de
définir en toute rigueur.
J'en ai déduit que c'était le process qui demandait un surplus de mémoire, sans possibilité d'en avoir, qui était arrêté...
Non, ça ce serait ce qui se passe sans OOM Killer dédié, puisque quasiment aucun programme ne prévoit le cas d'un échec d'allocation de mémoire autrement qu'en quittant. L'OOM Killer essaie d'être plus fin, en trouvant le vrai responsable. Mais ce n'est pas une notion qu'il est possible de définir en toute rigueur.
noone
On Sun, 16 Sep 2007 09:29:17 +0000, Arol wrote:
ha ha ha On a tous eu cette même peur mais elle n'est plus fondée.
parce que maintenant linux tue tous les processus pour libérer de la mémoire, DONC pas de soucis hein ?
On Sun, 16 Sep 2007 09:29:17 +0000, Arol wrote:
ha ha ha
On a tous eu cette même peur mais elle n'est plus fondée.
parce que maintenant linux tue tous les processus pour libérer de la
mémoire, DONC pas de soucis hein ?
ha ha ha On a tous eu cette même peur mais elle n'est plus fondée.
parce que maintenant linux tue tous les processus pour libérer de la mémoire, DONC pas de soucis hein ?
Pascal Hambourg
Pascal Hambourg wrote in message <fcjcup$ig3$:
C'est une question qui m'intéresse. Cette option de configuration existait dans les noyaux de la série 2.4, mais je ne la retrouve plus dans les noyaux de la série 2.6. Qu'est-elle devenue ? Renommée, retirée pour cause de fiabilité insuffisante ou au contraire devenue non désactivable ?
L'OOM Killer n'est pas désactivable (cf. mm/Makefile).
L'examen de mm/Makefile ne suffit pas conclure, car celui du noyau 2.4 est similaire, il ne tient pas compte de CONFIG_OOM_KILLER. La différence est dans la disparition du #ifdef CONFIG_OOM_KILLER conditionnant l'appel de la fonction out_of_memory() de l'OOM killer.
Mais normalement, il doit être possible de désactiver l'overcommit assez pour qu'il ne survienne jamais.
Tu veux dire que l'OOM killer ne peut se produire que lorsque l'overcommit est autorisé ?
Pascal Hambourg wrote in message <fcjcup$ig3$1@biggoron.nerim.net>:
C'est une question qui m'intéresse. Cette option de configuration
existait dans les noyaux de la série 2.4, mais je ne la retrouve plus
dans les noyaux de la série 2.6. Qu'est-elle devenue ? Renommée, retirée
pour cause de fiabilité insuffisante ou au contraire devenue non
désactivable ?
L'OOM Killer n'est pas désactivable (cf. mm/Makefile).
L'examen de mm/Makefile ne suffit pas conclure, car celui du noyau 2.4
est similaire, il ne tient pas compte de CONFIG_OOM_KILLER. La
différence est dans la disparition du #ifdef CONFIG_OOM_KILLER
conditionnant l'appel de la fonction out_of_memory() de l'OOM killer.
Mais normalement, il
doit être possible de désactiver l'overcommit assez pour qu'il ne survienne
jamais.
Tu veux dire que l'OOM killer ne peut se produire que lorsque
l'overcommit est autorisé ?
C'est une question qui m'intéresse. Cette option de configuration existait dans les noyaux de la série 2.4, mais je ne la retrouve plus dans les noyaux de la série 2.6. Qu'est-elle devenue ? Renommée, retirée pour cause de fiabilité insuffisante ou au contraire devenue non désactivable ?
L'OOM Killer n'est pas désactivable (cf. mm/Makefile).
L'examen de mm/Makefile ne suffit pas conclure, car celui du noyau 2.4 est similaire, il ne tient pas compte de CONFIG_OOM_KILLER. La différence est dans la disparition du #ifdef CONFIG_OOM_KILLER conditionnant l'appel de la fonction out_of_memory() de l'OOM killer.
Mais normalement, il doit être possible de désactiver l'overcommit assez pour qu'il ne survienne jamais.
Tu veux dire que l'OOM killer ne peut se produire que lorsque l'overcommit est autorisé ?
Matthieu Moy
Pascal Hambourg writes:
Mais normalement, il doit être possible de désactiver l'overcommit assez pour qu'il ne survienne jamais.
Tu veux dire que l'OOM killer ne peut se produire que lorsque l'overcommit est autorisé ?
Sans overcommit, quand il y a assez de mémoire, un malloc fait effectivement l'allocation. Quand il n'y a pas assez de mémoire, malloc ne fait rien et renvoit NULL. C'est au programme de décider ce qu'il doit faire avec ce NULL (souvent, il fait quelque chose du genre « printf("Aille aille aillen"); exit(1) »), mais je ne vois pas de cas où l'OOM Killer devrait intervenir.
Par contre, avec overcommit, on ne se rends vraiment compte qu'on manque de mémoire que quand on accède vraiment à la mémoire. Et là, le programme ne peut pas faire grand chose, vu qu'il n'a pas de moyen de tester si un accès mémoire va marcher ou pas. Donc, le kernel a le choix entre tuer ce processus là, ou un choisir un autre qui à l'air louche.
Mais normalement, il
doit être possible de désactiver l'overcommit assez pour qu'il ne survienne
jamais.
Tu veux dire que l'OOM killer ne peut se produire que lorsque
l'overcommit est autorisé ?
Sans overcommit, quand il y a assez de mémoire, un malloc fait
effectivement l'allocation. Quand il n'y a pas assez de mémoire,
malloc ne fait rien et renvoit NULL. C'est au programme de décider ce
qu'il doit faire avec ce NULL (souvent, il fait quelque chose du genre
« printf("Aille aille aillen"); exit(1) »), mais je ne vois pas de
cas où l'OOM Killer devrait intervenir.
Par contre, avec overcommit, on ne se rends vraiment compte qu'on
manque de mémoire que quand on accède vraiment à la mémoire. Et là, le
programme ne peut pas faire grand chose, vu qu'il n'a pas de moyen de
tester si un accès mémoire va marcher ou pas. Donc, le kernel a le
choix entre tuer ce processus là, ou un choisir un autre qui à l'air
louche.
Mais normalement, il doit être possible de désactiver l'overcommit assez pour qu'il ne survienne jamais.
Tu veux dire que l'OOM killer ne peut se produire que lorsque l'overcommit est autorisé ?
Sans overcommit, quand il y a assez de mémoire, un malloc fait effectivement l'allocation. Quand il n'y a pas assez de mémoire, malloc ne fait rien et renvoit NULL. C'est au programme de décider ce qu'il doit faire avec ce NULL (souvent, il fait quelque chose du genre « printf("Aille aille aillen"); exit(1) »), mais je ne vois pas de cas où l'OOM Killer devrait intervenir.
Par contre, avec overcommit, on ne se rends vraiment compte qu'on manque de mémoire que quand on accède vraiment à la mémoire. Et là, le programme ne peut pas faire grand chose, vu qu'il n'a pas de moyen de tester si un accès mémoire va marcher ou pas. Donc, le kernel a le choix entre tuer ce processus là, ou un choisir un autre qui à l'air louche.
-- Matthieu
Thomas S
G-raison :
Au démarrage du système, il n'y a que 300 Mo d'occupé en mémoire RAM. Au fur et à mesure que l'on ouvre des programmes et qu'on les ferme une fois fini, la quantité de mémoire occupé augmente.
Avec quoi mesures-tu la mémoire utilisée?
La mémoire ne sert pas qu'à faire tourner les programmes, mais aussi au cache disque. Au fur et à mesure que tu lances des programmes, le cache disque se remplit, et n'a pas de raison de se vider tant que l'on a pas rempli toute la mémoire avec le cache et les données. Au-delà, le système doit faire des choix, comme abandonner une partie du cache ou envoyer des programmes dans le swap. windows Vista a repris ce principe, et microsoft essaie encore une fois
de faire passer pour une de ses innovation ce que linux fait depuis toujours.
G-raison :
Au démarrage du système, il n'y a que 300 Mo d'occupé en mémoire RAM.
Au fur et à mesure que l'on ouvre des programmes et qu'on les ferme une fois
fini, la quantité de mémoire occupé augmente.
Avec quoi mesures-tu la mémoire utilisée?
La mémoire ne sert pas qu'à faire tourner les programmes, mais aussi au
cache disque. Au fur et à mesure que tu lances des programmes, le cache
disque se remplit, et n'a pas de raison de se vider tant que l'on a pas
rempli toute la mémoire avec le cache et les données. Au-delà, le système
doit faire des choix, comme abandonner une partie du cache ou envoyer des
programmes dans le swap.
windows Vista a repris ce principe, et microsoft essaie encore une fois
de faire passer pour une de ses innovation ce que linux fait depuis
toujours.
Au démarrage du système, il n'y a que 300 Mo d'occupé en mémoire RAM. Au fur et à mesure que l'on ouvre des programmes et qu'on les ferme une fois fini, la quantité de mémoire occupé augmente.
Avec quoi mesures-tu la mémoire utilisée?
La mémoire ne sert pas qu'à faire tourner les programmes, mais aussi au cache disque. Au fur et à mesure que tu lances des programmes, le cache disque se remplit, et n'a pas de raison de se vider tant que l'on a pas rempli toute la mémoire avec le cache et les données. Au-delà, le système doit faire des choix, comme abandonner une partie du cache ou envoyer des programmes dans le swap. windows Vista a repris ce principe, et microsoft essaie encore une fois
de faire passer pour une de ses innovation ce que linux fait depuis toujours.
Matthieu Moy
Thomas S writes:
windows Vista a repris ce principe, et microsoft essaie encore une fois de faire passer pour une de ses innovation ce que linux fait depuis toujours.
Euh, ça fait un moment aussi que Windows sait ce que c'est que le cache et le swap ...
-- Matthieu
Thomas S <thomas.saveol@wouannadou.fr> writes:
windows Vista a repris ce principe, et microsoft essaie encore une
fois de faire passer pour une de ses innovation ce que linux fait
depuis toujours.
Euh, ça fait un moment aussi que Windows sait ce que c'est que le
cache et le swap ...
