Lorsque ce programme termine son execution la RAM n'est pas vider.
J'ai un deuxiemme programme qui se lance et ne dispose pas d'assez de
RAM. Du coup, le systeme (kernel 2.4) tue certain service (snmpd, sshd)
au hasard pour liberer de la RAM.
Idealement, je souhaiterais vider la RAM apres l'execution du premier
programme.
- Qu'est-il censé ce passer si la partie physique de/des barette(s) sur lesquelles se trouvaient ce cache sont defectueuses?
Si la RAM permet la détection d'erreur, il me semble que la seule réaction raisonnable est un kernel panic.
Ceci dit, j'avais vu un jour un truc bizarre.
- Est-ce que le noyau "defragmente" ce qui se trouve en RAM (genre: y a une grosse usine qui se pointe, je pousse un peu ce que j'ai déjà pour lui laisser un gros bloc)?
Aucun intérêt, la fragmentation ne joue que quand il y a un malus à manipuler des données non-contiguës, ce qui est le cas quand il y a des pièces mécaniques en jeu. La RAM ne pose pas ce genre de considérations. Une clef USB non plus, d'ailleurs.
R12y wrote in message <13572871.BnvC19LZ4m@asso-polyvalente.fr>:
- Qu'est-il censé ce passer si la partie physique de/des barette(s) sur
lesquelles se trouvaient ce cache sont defectueuses?
Si la RAM permet la détection d'erreur, il me semble que la seule réaction
raisonnable est un kernel panic.
Ceci dit, j'avais vu un jour un truc bizarre.
- Est-ce que le noyau "defragmente" ce qui se trouve en RAM (genre: y a une
grosse usine qui se pointe, je pousse un peu ce que j'ai déjà pour lui
laisser un gros bloc)?
Aucun intérêt, la fragmentation ne joue que quand il y a un malus à
manipuler des données non-contiguës, ce qui est le cas quand il y a des
pièces mécaniques en jeu. La RAM ne pose pas ce genre de considérations. Une
clef USB non plus, d'ailleurs.
- Qu'est-il censé ce passer si la partie physique de/des barette(s) sur lesquelles se trouvaient ce cache sont defectueuses?
Si la RAM permet la détection d'erreur, il me semble que la seule réaction raisonnable est un kernel panic.
Ceci dit, j'avais vu un jour un truc bizarre.
- Est-ce que le noyau "defragmente" ce qui se trouve en RAM (genre: y a une grosse usine qui se pointe, je pousse un peu ce que j'ai déjà pour lui laisser un gros bloc)?
Aucun intérêt, la fragmentation ne joue que quand il y a un malus à manipuler des données non-contiguës, ce qui est le cas quand il y a des pièces mécaniques en jeu. La RAM ne pose pas ce genre de considérations. Une clef USB non plus, d'ailleurs.
Nicolas George
Thierry Boudet wrote in message :
<pinaille>
Je ne prétendais pas être exhaustif.
Eventuellement des bouts de stack ip (SO_REUSE, toussa)
Ça, ce sera libéré à terme, c'est juste un délai, donc ça ne compte pas vraiment.
Thierry Boudet wrote in message <ih7ui4-381.ln1@prout.stex>:
<pinaille>
Je ne prétendais pas être exhaustif.
Eventuellement des bouts de stack ip (SO_REUSE, toussa)
Ça, ce sera libéré à terme, c'est juste un délai, donc ça ne compte pas
vraiment.
Eventuellement des bouts de stack ip (SO_REUSE, toussa)
Ça, ce sera libéré à terme, c'est juste un délai, donc ça ne compte pas vraiment.
Thierry Boudet
On 2007-05-29, Nicolas George <nicolas$ wrote:
<pinaille>
Je ne prétendais pas être exhaustif.
Eventuellement des bouts de stack ip (SO_REUSE, toussa)
Ça, ce sera libéré à terme, c'est juste un délai, donc ça ne compte pas vraiment.
Sauf que l'OP a semble-t-il un problème de ce genre, puisqu'il semble que ce soit en _enchainant_ deux logiciels communiquants par des chauissettes que le crash se produit...
-- - Le monde appartient à ceux dont les ouvriers se lèvent tôt. (Coluche)
On 2007-05-29, Nicolas George <nicolas$george@salle-s.org> wrote:
<pinaille>
Je ne prétendais pas être exhaustif.
Eventuellement des bouts de stack ip (SO_REUSE, toussa)
Ça, ce sera libéré à terme, c'est juste un délai, donc ça ne compte pas
vraiment.
Sauf que l'OP a semble-t-il un problème de ce genre, puisqu'il
semble que ce soit en _enchainant_ deux logiciels communiquants
par des chauissettes que le crash se produit...
--
- Le monde appartient à ceux dont les ouvriers se lèvent tôt. (Coluche)
Eventuellement des bouts de stack ip (SO_REUSE, toussa)
Ça, ce sera libéré à terme, c'est juste un délai, donc ça ne compte pas vraiment.
Sauf que l'OP a semble-t-il un problème de ce genre, puisqu'il semble que ce soit en _enchainant_ deux logiciels communiquants par des chauissettes que le crash se produit...
-- - Le monde appartient à ceux dont les ouvriers se lèvent tôt. (Coluche)
Denis Beauregard
Le Tue, 29 May 2007 20:26:41 +0200, Pascal Hambourg écrivait dans fr.comp.os.linux.configuration:
Pourtant, il me semble que la mémoire est gérée par 2 systèmes différents. D'un côté, les appels au bios et de l'autre, ceux au noyau Linux.
Euh, des appels BIOS sous Linux ?
Je sais que c'est presqu'une hérésie, mais ici, on parle d'une SGBD sans la nommer. Il peut s'agir d'une application Windows roulant dans Wine ou d'une application Linux faite à partir d'une autre écrite d'abord pour Windows et où on aurait laisser du code par oubli. Je pense que cela doit bien exister dans le compilateur gcc par exemple. D'ailleurs, j'ai essayé une application DOS dans DOSEMU, une application que j'ai écrite en ASM (il y a 20 ans) et elle utilise des appels au BIOS.
Denis
Le Tue, 29 May 2007 20:26:41 +0200, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org> écrivait dans
fr.comp.os.linux.configuration:
Pourtant, il me semble que la mémoire est gérée par 2 systèmes
différents. D'un côté, les appels au bios et de l'autre, ceux au
noyau Linux.
Euh, des appels BIOS sous Linux ?
Je sais que c'est presqu'une hérésie, mais ici, on parle d'une
SGBD sans la nommer. Il peut s'agir d'une application Windows
roulant dans Wine ou d'une application Linux faite à partir d'une
autre écrite d'abord pour Windows et où on aurait laisser du code
par oubli. Je pense que cela doit bien exister dans le compilateur
gcc par exemple. D'ailleurs, j'ai essayé une application DOS dans
DOSEMU, une application que j'ai écrite en ASM (il y a 20 ans)
et elle utilise des appels au BIOS.
Le Tue, 29 May 2007 20:26:41 +0200, Pascal Hambourg écrivait dans fr.comp.os.linux.configuration:
Pourtant, il me semble que la mémoire est gérée par 2 systèmes différents. D'un côté, les appels au bios et de l'autre, ceux au noyau Linux.
Euh, des appels BIOS sous Linux ?
Je sais que c'est presqu'une hérésie, mais ici, on parle d'une SGBD sans la nommer. Il peut s'agir d'une application Windows roulant dans Wine ou d'une application Linux faite à partir d'une autre écrite d'abord pour Windows et où on aurait laisser du code par oubli. Je pense que cela doit bien exister dans le compilateur gcc par exemple. D'ailleurs, j'ai essayé une application DOS dans DOSEMU, une application que j'ai écrite en ASM (il y a 20 ans) et elle utilise des appels au BIOS.
Denis
Pascal Hambourg
C'est reproductible (ou presque) en faisant un "swapoff -a" quand la swap est utilisée ;-)
Ce n'est pas comparable. D'un côté, on essaie d'allouer de la mémoire qu'on n'a pas. De l'autre, on retire de la mémoire qui était occupée.
Attends. Le P.O. dit que le fait de lancer l'usine à gaz tue "certains" process parcequ'ils leur "piquent" leur RAM. Je ne pense pas que ce soit vraiment ce qui se passe,
Qui sait ? Le noyau 2.4 a une option de configuration CONFIG_OOM_KILLER qui lorsqu'elle est activée lui permet en cas de manque de mémoire+swap de tuer des tâches "au mieux" au lieu de tuer systématiquement celle qui a demandé de la mémoire.
mais si c'était le cas, le "gros" a "retiré de la mémoire qui était occupée" par "certains".
Je ne vois pas les choses comme ça.
C'est reproductible (ou presque) en faisant un "swapoff -a" quand la swap
est utilisée ;-)
Ce n'est pas comparable. D'un côté, on essaie d'allouer de la mémoire
qu'on n'a pas. De l'autre, on retire de la mémoire qui était occupée.
Attends.
Le P.O. dit que le fait de lancer l'usine à gaz tue "certains" process
parcequ'ils leur "piquent" leur RAM. Je ne pense pas que ce soit vraiment
ce qui se passe,
Qui sait ? Le noyau 2.4 a une option de configuration CONFIG_OOM_KILLER
qui lorsqu'elle est activée lui permet en cas de manque de mémoire+swap
de tuer des tâches "au mieux" au lieu de tuer systématiquement celle qui
a demandé de la mémoire.
mais si c'était le cas, le "gros" a "retiré de la mémoire
qui était occupée" par "certains".
C'est reproductible (ou presque) en faisant un "swapoff -a" quand la swap est utilisée ;-)
Ce n'est pas comparable. D'un côté, on essaie d'allouer de la mémoire qu'on n'a pas. De l'autre, on retire de la mémoire qui était occupée.
Attends. Le P.O. dit que le fait de lancer l'usine à gaz tue "certains" process parcequ'ils leur "piquent" leur RAM. Je ne pense pas que ce soit vraiment ce qui se passe,
Qui sait ? Le noyau 2.4 a une option de configuration CONFIG_OOM_KILLER qui lorsqu'elle est activée lui permet en cas de manque de mémoire+swap de tuer des tâches "au mieux" au lieu de tuer systématiquement celle qui a demandé de la mémoire.
mais si c'était le cas, le "gros" a "retiré de la mémoire qui était occupée" par "certains".
Je ne vois pas les choses comme ça.
Thierry Boudet
On 2007-05-29, Denis Beauregard wrote:
Euh, des appels BIOS sous Linux ?
Je sais que c'est presqu'une hérésie, mais ici, on parle d'une SGBD sans la nommer.
Il faut suivre, c'est PostgreSQL dont on cause.
Il peut s'agir d'une application Windows roulant dans Wine ou d'une application Linux faite à partir d'une autre écrite d'abord pour Windows et où on aurait laisser du code par oubli.
A mon avis, ça aura du mal à passer l'étape de la compilation.
D'ailleurs, j'ai essayé une application DOS dans DOSEMU, une application que j'ai écrite en ASM (il y a 20 ans) et elle utilise des appels au BIOS.
Elle appelle le bios émulé/virtuel de Dosemu, et les éventuels fuites de mémoire ont lieu _dans_ Dosemu, à ce moment.
-- --{ http://tontonth.free.fr/ }--
On 2007-05-29, Denis Beauregard wrote:
Euh, des appels BIOS sous Linux ?
Je sais que c'est presqu'une hérésie, mais ici, on parle d'une
SGBD sans la nommer.
Il faut suivre, c'est PostgreSQL dont on cause.
Il peut s'agir d'une application Windows
roulant dans Wine ou d'une application Linux faite à partir d'une
autre écrite d'abord pour Windows et où on aurait laisser du code
par oubli.
A mon avis, ça aura du mal à passer l'étape de la compilation.
D'ailleurs, j'ai essayé une application DOS dans
DOSEMU, une application que j'ai écrite en ASM (il y a 20 ans)
et elle utilise des appels au BIOS.
Elle appelle le bios émulé/virtuel de Dosemu, et les éventuels
fuites de mémoire ont lieu _dans_ Dosemu, à ce moment.
Je sais que c'est presqu'une hérésie, mais ici, on parle d'une SGBD sans la nommer.
Il faut suivre, c'est PostgreSQL dont on cause.
Il peut s'agir d'une application Windows roulant dans Wine ou d'une application Linux faite à partir d'une autre écrite d'abord pour Windows et où on aurait laisser du code par oubli.
A mon avis, ça aura du mal à passer l'étape de la compilation.
D'ailleurs, j'ai essayé une application DOS dans DOSEMU, une application que j'ai écrite en ASM (il y a 20 ans) et elle utilise des appels au BIOS.
Elle appelle le bios émulé/virtuel de Dosemu, et les éventuels fuites de mémoire ont lieu _dans_ Dosemu, à ce moment.
-- --{ http://tontonth.free.fr/ }--
Pascal Hambourg
Avant d'utiliser le swap, il devrait songer à récupérer une partie de la mémoire occupée par du cache
- Qu'est-il censé ce passer si la partie physique de/des barette(s) sur lesquelles se trouvaient ce cache sont defectueuses?
Rien de bon, d'après mon expérience qui se limite à la RAM non ECC. Si le cache contient des données en attente d'écriture, des données corrompues seront enregistrées sur le disque. Ensuite, la tâche récupérant l'emplacement mémoire défectueux va voir son code ou ses données corrompues, ce qui se peut se manifester par une erreur de segmentation.
- Est-ce que le noyau "defragmente" ce qui se trouve en RAM (genre: y a une grosse usine qui se pointe, je pousse un peu ce que j'ai déjà pour lui laisser un gros bloc)?
Vois pas l'intérêt, le mécanisme de pagination permettant de masquer la fragmentation de la mémoire physique pour présenter un espace linéaire aux tâches.
Accessoirement, est-ce que les RAM actuelles ont encore besoin d'etre rafraichies?
Oui, à la base c'est toujours de la bonne vieille technologie DRAM (RAM dynamique). Le rafraîchissement peut être géré par le contrôleur mémoire ou directement par la puce de RAM sur les SDRAM. Mais quoi qu'il en soit, c'est transparent pour l'OS.
Avant d'utiliser le swap, il devrait songer à récupérer une partie de la
mémoire occupée par du cache
- Qu'est-il censé ce passer si la partie physique de/des barette(s) sur
lesquelles se trouvaient ce cache sont defectueuses?
Rien de bon, d'après mon expérience qui se limite à la RAM non ECC. Si
le cache contient des données en attente d'écriture, des données
corrompues seront enregistrées sur le disque. Ensuite, la tâche
récupérant l'emplacement mémoire défectueux va voir son code ou ses
données corrompues, ce qui se peut se manifester par une erreur de
segmentation.
- Est-ce que le noyau "defragmente" ce qui se trouve en RAM (genre: y a une
grosse usine qui se pointe, je pousse un peu ce que j'ai déjà pour lui
laisser un gros bloc)?
Vois pas l'intérêt, le mécanisme de pagination permettant de masquer la
fragmentation de la mémoire physique pour présenter un espace linéaire
aux tâches.
Accessoirement, est-ce que les RAM actuelles ont
encore besoin d'etre rafraichies?
Oui, à la base c'est toujours de la bonne vieille technologie DRAM (RAM
dynamique). Le rafraîchissement peut être géré par le contrôleur mémoire
ou directement par la puce de RAM sur les SDRAM. Mais quoi qu'il en
soit, c'est transparent pour l'OS.
Avant d'utiliser le swap, il devrait songer à récupérer une partie de la mémoire occupée par du cache
- Qu'est-il censé ce passer si la partie physique de/des barette(s) sur lesquelles se trouvaient ce cache sont defectueuses?
Rien de bon, d'après mon expérience qui se limite à la RAM non ECC. Si le cache contient des données en attente d'écriture, des données corrompues seront enregistrées sur le disque. Ensuite, la tâche récupérant l'emplacement mémoire défectueux va voir son code ou ses données corrompues, ce qui se peut se manifester par une erreur de segmentation.
- Est-ce que le noyau "defragmente" ce qui se trouve en RAM (genre: y a une grosse usine qui se pointe, je pousse un peu ce que j'ai déjà pour lui laisser un gros bloc)?
Vois pas l'intérêt, le mécanisme de pagination permettant de masquer la fragmentation de la mémoire physique pour présenter un espace linéaire aux tâches.
Accessoirement, est-ce que les RAM actuelles ont encore besoin d'etre rafraichies?
Oui, à la base c'est toujours de la bonne vieille technologie DRAM (RAM dynamique). Le rafraîchissement peut être géré par le contrôleur mémoire ou directement par la puce de RAM sur les SDRAM. Mais quoi qu'il en soit, c'est transparent pour l'OS.
Pascal Hambourg
On 2007-05-29, Denis Beauregard wrote:
Euh, des appels BIOS sous Linux ?
Il peut s'agir d'une application Windows roulant dans Wine [...]
D'ailleurs, j'ai essayé une application DOS dans DOSEMU, une application que j'ai écrite en ASM (il y a 20 ans) et elle utilise des appels au BIOS.
Elle appelle le bios émulé/virtuel de Dosemu, et les éventuels fuites de mémoire ont lieu _dans_ Dosemu, à ce moment.
Et c'est la même chose en natif dans Windows : Windows intercepte les appels au BIOS et gère la mémoire lui-même en émulant les mécanismes XMS/EMS.
On 2007-05-29, Denis Beauregard wrote:
Euh, des appels BIOS sous Linux ?
Il peut s'agir d'une application Windows
roulant dans Wine [...]
D'ailleurs, j'ai essayé une application DOS dans
DOSEMU, une application que j'ai écrite en ASM (il y a 20 ans)
et elle utilise des appels au BIOS.
Elle appelle le bios émulé/virtuel de Dosemu, et les éventuels
fuites de mémoire ont lieu _dans_ Dosemu, à ce moment.
Et c'est la même chose en natif dans Windows : Windows intercepte les
appels au BIOS et gère la mémoire lui-même en émulant les mécanismes
XMS/EMS.
