Re: [Confirme] Fuite de mémoire système

2003-08-14 Par sujet Pierre Lo Cicero


Pierre Lo Cicero a écrit :



EuropeanServers - Christophe BAEGERT a écrit :

Bonjour,

j'ai une fuite de mémoire sur un serveur mail, en Mandrake 9.0. Je 
dois le rebooter toutes les 2 jours.

J'ai mis à jour le kernel à la version stock 2.4.21, mais c'est pas 
mieux.
Il a 450Mo de RAM, je l'ai surveillé toute la journée hier, il 
restait à 59Mo réellement utilisé (en excluant cache et buffer), mais 
ce matin il était à 260. En comptabilisant la mémoire prise par les 
applis, rien n'avait changé, c'était toujours 29Mo pour BIND et 30Mo 
pour le reste. J'ai donc perdu 200Mo quelque part, mais où et pourquoi ?

Quelqu'un aurait une idée?
 

Si je peux me permettre :

J'ai eu ce genre de problème, mais avec windows.
Je ne suis pas certain que ce soit un problème de mémoire, mais.
Le problème de ces fuites de mémoires peut-être du à la température du 
processeur, surtout s'il s'agit d'un AMD.
En tous les cas, pour les AMD, certains sont livrés avec un ventilo 
largement sous-dimensionné. Le message d'erreur était sans équivoque 
possible.
Le simple fait de changer le ventilo en le remplaçant par un "maousse 
costaud" a réglé le problème.
A signaler que Linux plantait aussi, mais je n'ai pas cherché à savoir 
pourquoi. Après remplacement du ventilo, plus de probs. Ni d'un côté, 
ni de l'autre.
..et en passant j'ai aussi épuisé mon stock mémoire en tentant de la 
changer.

En souhaitant que cela t'aide

Pierre lo Cicero



Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
Rendez-vous sur "http://www.mandrakestore.com";


Re: [Confirme] Fuite de mémoire système

2003-08-14 Par sujet Christophe BAEGERT
Bonjour,

Le Mercredi 6 Août 2003 09:35, ald a écrit :
> Le mer 06/08/2003 à 07:41, Christophe BAEGERT a écrit :
> > Bonjour,
>
> Salut
>
> Sans pouvoir trop t'aider, il y a qq chose qui me parait bizarre:
> d'aprés tes descriptions cela ne se passe que la nuit. Y a t'il qq chose
> de spécial qui se lance le soir? une sauvegarde? un fantome?

Quelques petits scripts Perl d'administration, rien d'extraordinaire, plus 
évidemment les crons systèmes. A la limite je pourrais essayer de désactiver 
ceux-ci pour une nuit.

Cordialement,
-- 
Christophe BAEGERT   [EMAIL PROTECTED]

>>> http://www.europeanservers.net 

-- Ultra fast internet servers -


Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
Rendez-vous sur "http://www.mandrakestore.com";


Re: [Confirme] Fuite de mémoire système

2003-08-14 Par sujet stephane
Finalement on devrait tous faire du windows, comme ca on
arreterait de se poser des questions sur les fuites mémoires

Je pense que tu devrais arreter les taches les unes apres les autres et
vérifier ce que tu récupères en mémoire après, si d'un coup tu récupères
200 Mo, c'est que tu as trouvé le processus fautif





Christophe BAEGERT wrote:
> 
> Le Mercredi 6 Août 2003 12:56, Teletchéa Stéphane a écrit :
> 
> > Fais plutôt un cat /proc/meminfo et tu devrais avoir quelquechose de
> > plus correct, il me semble que top a un bug ...
> 
> Ca y'est j'ai changé la RAM pour de la Dane-Elec certifiée sur cette carte,
> mais ca recommence !!!
> 
> Voici un meminfo :
>total:used:free:  shared: buffers:  cached:
> Mem:  527663104 512073728 155893760 165416960 97292288
> Swap: 57643827273728 576364544
> MemTotal:   515296 kB
> MemFree: 15224 kB
> MemShared:   0 kB
> Buffers:161540 kB
> Cached:  95012 kB
> SwapCached:  0 kB
> Active: 148880 kB
> Inactive:   138508 kB
> HighTotal:   0 kB
> HighFree:0 kB
> LowTotal:   515296 kB
> LowFree: 15224 kB
> SwapTotal:  562928 kB
> SwapFree:   562856 kB
> 
> Pour l'instant je la laisse tel quelle, est-ce que quelqu'un sais ce que je
> pourrais chercher de plus avant de la rebooter ?
> 
> Comme avant, rien sur ipcs.
> 
> Cordialement,
> --
> Christophe BAEGERT   [EMAIL PROTECTED]
> 
> >>> http://www.europeanservers.net 
> 
> -- Ultra fast internet servers -
> 
>   
> Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
> Rendez-vous sur "http://www.mandrakestore.com";

-- 
Amicalement,
With my best regards,

Stephane BRANGER


*
*Linux Technical and Pre sales Engineer at Prologue Technologies*
*

Fortune of the month:
Steve Ballmer, PDG de Microsoft: «Il y des gens qui choisissent Linux,
mais je
ne crois pas que ça va durer» 
Steve Ballmer, Microsoft CEO: «Some people have made the linux choice,
but I
don't think this will last»

Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
Rendez-vous sur "http://www.mandrakestore.com";


[Confirme] Fuite de mémoire système

2003-08-14 Par sujet EuropeanServers - Christophe BAEGERT
Bonjour,

j'ai une fuite de mémoire sur un serveur mail, en Mandrake 9.0. Je dois le rebooter 
toutes les 2 jours.

J'ai mis à jour le kernel à la version stock 2.4.21, mais c'est pas mieux. 

Il a 450Mo de RAM, je l'ai surveillé toute la journée hier, il restait à 59Mo 
réellement utilisé (en excluant cache et buffer), mais ce matin il était à 260. En 
comptabilisant la mémoire prise par les applis, rien n'avait changé, c'était toujours 
29Mo pour BIND et 30Mo pour le reste. J'ai donc perdu 200Mo quelque part, mais où et 
pourquoi ?

Quelqu'un aurait une idée?

Config de la machine :

MDK 9.0
Bind 9.2.2
Qmail 1.0.3 sous supervise + xxx
serveur NFS
système de fichiers ReiserFS

Voici la liste des processus tournant sur la machine :
 1067 named 11   0 24204  23M  1548 S 0,3  5,3   2:07 named
11440 root   9   0  1032 1032   812 R 0,1  0,2   0:00 top
1 root   8   0   504  504   440 S 0,0  0,1   0:05 init
2 root   9   0 00 0 SW0,0  0,0   0:00 keventd
3 root  19  19 00 0 SWN   0,0  0,0   0:00 ksoftirqd_CPU0
4 root   9   0 00 0 SW0,0  0,0   0:00 kswapd
5 root   9   0 00 0 SW0,0  0,0   0:00 bdflush
6 root   9   0 00 0 SW0,0  0,0   0:01 kupdated
7 root  -1 -20 00 0 SW<   0,0  0,0   0:00 mdrecoveryd
8 root   9   0 00 0 SW0,0  0,0   0:00 kreiserfsd
  764 rpc9   0   532  532   440 S 0,0  0,1   0:00 portmap
  787 root   9   0   596  596   476 S 0,0  0,1   0:01 syslogd
  796 root   9   0  1168 1168   432 S 0,0  0,2   0:00 klogd
  849 root   9   0  1272 1272  1140 S 0,0  0,2   0:00 sshd
  868 root   9   0   292  292   244 S 0,0  0,0   0:00 supervise
  869 root   9   0   292  292   244 S 0,0  0,0   0:00 supervise
  870 root   9   0   292  292   244 S 0,0  0,0   0:00 supervise
  889 root   9   0  1124 1124   836 S 0,0  0,2   0:00 run
  892 root   9   0  1124 1124   836 S 0,0  0,2   0:00 run
  893 root   9   0  1128 1128   836 S 0,0  0,2   0:00 run
  897 qmaild 0   0   472  472   400 S 0,0  0,1   0:00 tcpserver
  898 qmaill 9   0   340  340   280 S 0,0  0,0   0:00 multilog
  899 qmails 9   0   400  400   300 S 0,0  0,0   0:02 qmail-send
  900 qmaill 9   0   340  340   280 S 0,0  0,0   0:00 multilog
  903 root  10   0   304  304   252 S 0,0  0,0   0:00 tcpserver
  904 qmaill 9   0   284  284   232 S 0,0  0,0   0:00 multilog
  911 root   0   0   316  316   252 S 0,0  0,0   0:00 qmail-lspawn
  912 qmailr 7   0   320  320   252 S 0,0  0,0   0:00 qmail-rspawn
  913 qmailq 9   0   320  320   256 S 0,0  0,0   0:00 qmail-clean
  966 root   8   0   664  664   556 S 0,0  0,1   0:00 crond
 1036 root   9   0  1900 1900  1716 S 0,0  0,4   0:00 ntpd
 1082 root   9   0   800  800   664 S 0,0  0,1   0:00 rpc.mountd
 1093 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
 1094 root   9   0 00 0 SW0,0  0,0   0:00 lockd
 1095 root   9   0 00 0 SW0,0  0,0   0:00 rpciod
 1096 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
 1097 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
 1098 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
 1099 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
 1100 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
 1101 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
 1102 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
 1112 stunnel9   0  1564 1564  1212 S 0,0  0,3   0:00 stunnel
 1132 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
 1133 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
 1134 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
 1135 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
 1136 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
 1137 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
 1237 stunnel8   0  1564 1564  1212 S 0,0  0,3   0:00 stunnel
 6616 root   9   0  1996 1996  1672 R 0,0  0,4   0:00 sshd
 6627 root   9   0  1636 1636  1092 S 0,0  0,3   0:00 bash
 6690 root   9   0  1904 1904  1724 S 0,0  0,4   0:00 sshd
 6692 x  9   0  2124 2124  1892 S 0,0  0,4   0:00 sshd
 6693 x  9   0  1576 1576  1096 S 0,0  0,3   0:00 bash
11012 x  9   0  3788 3788  1464 S 0,0  0,8   0:00 mutt
11027 x  9   0  1060 1060   820 S 0,0  0,2   0:00 vi
11205 root   9   0   284  284   228 S 0,0  0,0   0:00 qmail-popup
11206    9   0   328  328   264 S 0,0  0,0   0:00 qmail-pop3d

Cordialement,
-- 
Christophe BAEGERT  [EMAIL PROTECTED]

> http://www.europeanservers.net <
--- Ultra 

Re: [Confirme] Fuite de mémoire système

2003-08-14 Par sujet Christophe BAEGERT
Le Mercredi 6 Août 2003 12:56, vous avez écrit :

> Je ne pense pas qu'il s'agisse d'une fuite de mémoire 'memory leak' car
> sinon tu auras un plantage sauvage ...
Justement, si je reboote la machine à chaque fois, c'est pour éviter le kernel 
panic au bout de quelques heures !

-- 
Christophe BAEGERT   [EMAIL PROTECTED]

>>> http://www.europeanservers.net 

-- Ultra fast internet servers -


Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
Rendez-vous sur "http://www.mandrakestore.com";


Re: [Confirme] Fuite de mémoire système

2003-08-14 Par sujet Teletchéa Stéphane
Le mer 06/08/2003 à 13:00, Christophe BAEGERT a écrit :
> Le Mercredi 6 Août 2003 12:56, vous avez écrit :
> 
> > Je ne pense pas qu'il s'agisse d'une fuite de mémoire 'memory leak' car
> > sinon tu auras un plantage sauvage ...
> Justement, si je reboote la machine à chaque fois, c'est pour éviter le kernel 
> panic au bout de quelques heures !

Aie !
Donc effectivement tu as un problème.
As-tu vérifié la mémoire avec memtest ?
Je pense qu'en enlevant les crons tu ne devrais pas voir cette
augmentation de la consommation mémoire, mais cela ne résoudra que
provisoirement ton problème. Car si ton système plante, tu dois avoir un
problème plus profond.

Stef

-- 
Teletchéa Stéphane <[EMAIL PROTECTED]>


signature.asc
Description: PGP signature


Re: [Confirme] Fuite de mémoire système

2003-08-14 Par sujet EuropeanServers - Christophe BAEGERT
Le jeu aoû  7 12:00:53 CEST 2003, Teletchéa Stéphane a écrit:
> Le mer 06/08/2003 à 13:00, Christophe BAEGERT a écrit :
> > Le Mercredi 6 Août 2003 12:56, vous avez écrit :
> > 
> > > Je ne pense pas qu'il s'agisse d'une fuite de mémoire 'memory leak' car
> > > sinon tu auras un plantage sauvage ...
> > Justement, si je reboote la machine à chaque fois, c'est pour éviter le kernel 
> > panic au bout de quelques heures !
> 
> Aie !
> Donc effectivement tu as un problème.
> As-tu vérifié la mémoire avec memtest ?

C'est toujours la dernière extrémité tellement c'est ch

> Je pense qu'en enlevant les crons tu ne devrais pas voir cette
> augmentation de la consommation mémoire, mais cela ne résoudra que
> provisoirement ton problème. Car si ton système plante, tu dois avoir un
> problème plus profond.

Bon je vais tout de même changer la RAM pour être sur, et tester les anciennes avec 
memtest.

Cordialement,
-- 
Christophe BAEGERT  [EMAIL PROTECTED]

> http://www.europeanservers.net <
--- Ultra fast internet servers --

Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
Rendez-vous sur "http://www.mandrakestore.com";


Re: [Confirme] Fuite de mémoire système

2003-08-14 Par sujet Christophe BAEGERT
Bonjour,

Le Mardi 5 Août 2003 11:55, vous avez écrit :
> Je ne sais pas si un process peut bouffer plus de mémoire qu'affiché sur
> top, ce que je sais c'est que un processus qui utilise les IPC et qui
> par conséquent bouffe de la mémoire en plus des mallocs habituels, ne
> libère pas ces IPCs si il plante violament ou peut etre lorsqu'il est
> mal codé, et ds ce cas la il faut dégager ces IPCs qui ne sont plus
> utilisés par la commande ipcrm.

Ca s'est reproduit cette nuit, voici mon top qui est plus que bizarre (après 
avoir tué tout ce qui est tuable, sans arriver à libérer cette RAM). La 
commande ipcs suit.

  7:36am  up 1 day, 14 min,  1 user,  load average: 0,01, 0,05, 0,01
18 processes: 17 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  1,7% user,  0,5% system,  0,1% nice, 48,2% idle
Mem:   450464K av,  391404K used,   59060K free,   0K shrd,  146088K buff
Swap:  562928K av, 200K used,  562728K free   79732K 
cached

  PID USER PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
1 root   0   0   504  496   468 S 0,0  0,1   0:05 init
2 root   9   0 00 0 SW0,0  0,0   0:00 keventd
3 root  19  19 00 0 SWN   0,0  0,0   0:00 ksoftirqd_CPU0
4 root   9   0 00 0 SW0,0  0,0   0:00 kswapd
5 root   9   0 00 0 SW0,0  0,0   0:00 bdflush
6 root  10   0 00 0 SW0,0  0,0   0:09 kupdated
7 root  -1 -20 00 0 SW<   0,0  0,0   0:00 mdrecoveryd
8 root   9   0 00 0 SW0,0  0,0   0:00 kreiserfsd
  849 root   9   0  1096 1008   892 S 0,0  0,2   0:00 sshd
 1132 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
 1133 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
 1134 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
 1135 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
 1136 root   9   0   400  384   340 S 0,0  0,0   0:00 mingetty
 1137 root   9   0   400  344   344 S 0,0  0,0   0:00 mingetty
30708 root   9   0  1892 1848  1540 S 0,0  0,4   0:00 sshd
30722 root  11   0  1636 1636  1096 S 0,0  0,3   0:00 bash
31168 root  12   0  1000 1000   808 R 0,0  0,2   0:00 top


ipcs :
-- Segments de mémoire partagée 
touche shmid  propriétaire perms  octets nattch statut

-- Tables de sémaphores 
touche semid  propriétaire perms  nsems  statut

-- Files d'attente de messages 
touche msqid  propriétaire perms  octets utilisés messages


Cordialement,
-- 
Christophe BAEGERT   [EMAIL PROTECTED]

>>> http://www.europeanservers.net 

-- Ultra fast internet servers -


Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
Rendez-vous sur "http://www.mandrakestore.com";


Re: [Confirme] Fuite de mémoire système

2003-08-14 Par sujet EuropeanServers - Christophe BAEGERT
Le mar aoû  5 11:05:23 CEST 2003, stephane a écrit:
>  euh si ce matin tu etais a 260 Mo, pour moi tu as plutot gagné
> 200 Mo non ? 

;-)

> 
> Enfin de toute manière qd ton système est à 59 Mo, tu devrais tuer les
> processus un à un et regarder la mémoire à chaque fois pour voir lequel
> de tes processus bouffe toute cette mémoire qu'il doit libérer qd on le
> kill. 

Tu penses qu'un process pourrait bouffer plus de mémoire qu'il l'affiche sur top ?

> Autre paramètre qu'on oublie parfois de regarder: les IPC, tape la
> commande ipcs pour vois les segments de mémoire partagées, il arrive
> parfois que sous nunux, un processus plante et que cette mémoire ne se
> libère pas, une seule solution alors ipcrm pour libérer cette mémoire
> réservée et non utilisée.

OK je testerai ça dès que ça se reproduit. Merci de ton aide.

Cordialement,
-- 
Christophe BAEGERT  [EMAIL PROTECTED]

> http://www.europeanservers.net <
--- Ultra fast internet servers --

Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
Rendez-vous sur "http://www.mandrakestore.com";


[Confirme] RE: [Confirme] RE: [Confirme] Fuite de mémoire système

2003-08-14 Par sujet Duclos Andre

Exact et c'est une bonne chose. Le kernel ne doit pas planter. Il tue quelques process 
pour liberer la memoire. C'est un cas extreme.

Dans le cas present, si un process merde (bouffe la memoire), le kernel doit le tuer 
(et tuer d'autres aussi :( ). Mais il ne doit pas avoir de kernel panic.

@+

-Message d'origine-
De : stephane [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 8 août 2003 09:10
À : [EMAIL PROTECTED]
Objet : Re: [Confirme] RE: [Confirme] Fuite de mémoire système


> 
> Meme si un process merde, il ne doit pas faire planter le kernel.

ouais sauf que cf source du noyau, qd il n'y a plus de mémoire, il kill
les process un peu au hasard sauf ceux qui sont en mode raw avec les
periphs de stockages (disque dur et consort)



> -Message d'origine-
> De : Christophe BAEGERT [mailto:[EMAIL PROTECTED]
> Envoyé : vendredi 8 août 2003 06:51
> À : [EMAIL PROTECTED]
> Objet : Re: [Confirme] Fuite de mémoire système
> 
> Le Mercredi 6 Août 2003 12:56, Teletchéa Stéphane a écrit :
> 
> > Fais plutôt un cat /proc/meminfo et tu devrais avoir quelquechose de
> > plus correct, il me semble que top a un bug ...
> 
> Ca y'est j'ai changé la RAM pour de la Dane-Elec certifiée sur cette carte,
> mais ca recommence !!!
> 
> Voici un meminfo :
>total:used:free:  shared: buffers:  cached:
> Mem:  527663104 512073728 155893760 165416960 97292288
> Swap: 57643827273728 576364544
> MemTotal:   515296 kB
> MemFree: 15224 kB
> MemShared:   0 kB
> Buffers:161540 kB
> Cached:  95012 kB
> SwapCached:  0 kB
> Active: 148880 kB
> Inactive:   138508 kB
> HighTotal:   0 kB
> HighFree:0 kB
> LowTotal:   515296 kB
> LowFree: 15224 kB
> SwapTotal:  562928 kB
> SwapFree:   562856 kB
> 
> Pour l'instant je la laisse tel quelle, est-ce que quelqu'un sais ce que je
> pourrais chercher de plus avant de la rebooter ?
> 
> Comme avant, rien sur ipcs.
> 
> Cordialement,
> --
> Christophe BAEGERT   [EMAIL PROTECTED]
> 
> >>>>>>>>>>>>>>> http://www.europeanservers.net <<<<<<<<<<<<<<<<
> 
> -- Ultra fast internet servers -
> 
>   
> Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
> Rendez-vous sur "http://www.mandrakestore.com";

-- 
Amicalement,
With my best regards,

Stephane BRANGER


*
*Linux Technical and Pre sales Engineer at Prologue Technologies*
*

Fortune of the month:
Steve Ballmer, PDG de Microsoft: «Il y des gens qui choisissent Linux,
mais je
ne crois pas que ça va durer» 
Steve Ballmer, Microsoft CEO: «Some people have made the linux choice,
but I
don't think this will last»


Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
Rendez-vous sur "http://www.mandrakestore.com";


Re: [Confirme] Fuite de mémoire système

2003-08-14 Par sujet Pierre Lo Cicero






Pierre Lo Cicero a écrit :

  
  
Bon alors sous MDK 9.1 et Apache 2 + les mises à jour de sécurité. J'ai
de la peine à me souvenir que le serveur existe.
C'est dire si cela me semble fiable.
Tu peux aussi avoir un probs de carte mère. MAis très difficile à
déterminer.
Une chose dont je suis presque sûr, c'est que ce n'est pas un probs
logiciel.
  
En souhaitant que tu trouves
  
Pierre Lo Cicero
  
EuropeanServers - Christophe BAEGERT a écrit :
  
Le lun aoû 11 14:40:16 CEST 2003, Pierre Lo Cicero a écrit:
  

  Si je peux me permettre :

J'ai eu ce genre de problème, mais avec windows.
Je ne suis pas certain que ce soit un problème de mémoire, mais.
Le problème de ces fuites de mémoires peut-être du à la température du 
processeur, surtout s'il s'agit d'un AMD.
En tous les cas, pour les AMD, certains sont livrés avec un ventilo 
largement sous-dimensionné. Le message d'erreur était sans équivoque 
possible.
Le simple fait de changer le ventilo en le remplaçant par un "maousse 
costaud" a réglé le problème.
A signaler que Linux plantait aussi, mais je n'ai pas cherché à savoir 
pourquoi. Après remplacement du ventilo, plus de probs. Ni d'un côté, ni 
de l'autre.
..et en passant j'ai aussi épuisé mon stock mémoire en tentant de la 
changer.

En souhaitant que cela t'aide



C'est la première chose que j'ai vérifié. Mais c'est un Celeron 1.0A, bien ventilé même si dans un rack 1U, le CPU doit etre sous 40° 

Merci de ton aide

Cordialement,
  
  





Re: [Confirme] Fuite de mémoire système

2003-08-14 Par sujet Teletchéa Stéphane
Le mar 05/08/2003 à 10:53, EuropeanServers - Christophe BAEGERT a
écrit :
> Bonjour,

Salut !

> j'ai une fuite de mémoire sur un serveur mail, en Mandrake 9.0. 
> Je dois le rebooter toutes les 2 jours.

As-tu une bonne raison pour cela ? Des messages d'erreurs, des problèmes
de rapidité qui diminue ???

> J'ai mis à jour le kernel à la version stock 2.4.21, mais c'est pas mieux. 
> 
> Il a 450Mo de RAM, je l'ai surveillé toute la journée hier, 
> il restait à 59Mo réellement utilisé (en excluant cache et buffer),
> mais ce matin il était à 260. En comptabilisant la mémoire prise par les applis, 
> rien n'avait changé, c'était toujours 29Mo pour BIND et 30Mo pour le reste. 
> J'ai donc perdu 200Mo quelque part, mais où et pourquoi ?

Fais plutôt un cat /proc/meminfo et tu devrais avoir quelquechose de
plus correct, il me semble que top a un bug ...

Sinon, je ne vois pas pourquoi tu rebootes, je suppose que tes scripts
perl chargent pas mal de choses en mémoire (perl c'est l'inverse du C :
tout en mémoire, utilisation minimale du proc) et après le système ne
les libère pas tout de suite, car tu n'en as pas besoin.

Je ne pense pas qu'il s'agisse d'une fuite de mémoire 'memory leak' car
sinon tu auras un plantage sauvage ...

Stef
-- 
Teletchéa Stéphane <[EMAIL PROTECTED]>


signature.asc
Description: PGP signature


Re: [Confirme] RE: [Confirme] Fuite de mémoire système

2003-08-12 Par sujet stephane
> 
> Meme si un process merde, il ne doit pas faire planter le kernel.

ouais sauf que cf source du noyau, qd il n'y a plus de mémoire, il kill
les process un peu au hasard sauf ceux qui sont en mode raw avec les
periphs de stockages (disque dur et consort)



> -Message d'origine-
> De : Christophe BAEGERT [mailto:[EMAIL PROTECTED]
> Envoyé : vendredi 8 août 2003 06:51
> À : [EMAIL PROTECTED]
> Objet : Re: [Confirme] Fuite de mémoire système
> 
> Le Mercredi 6 Août 2003 12:56, Teletchéa Stéphane a écrit :
> 
> > Fais plutôt un cat /proc/meminfo et tu devrais avoir quelquechose de
> > plus correct, il me semble que top a un bug ...
> 
> Ca y'est j'ai changé la RAM pour de la Dane-Elec certifiée sur cette carte,
> mais ca recommence !!!
> 
> Voici un meminfo :
>total:used:free:  shared: buffers:  cached:
> Mem:  527663104 512073728 155893760 165416960 97292288
> Swap: 57643827273728 576364544
> MemTotal:   515296 kB
> MemFree: 15224 kB
> MemShared:   0 kB
> Buffers:161540 kB
> Cached:  95012 kB
> SwapCached:  0 kB
> Active: 148880 kB
> Inactive:   138508 kB
> HighTotal:   0 kB
> HighFree:0 kB
> LowTotal:   515296 kB
> LowFree: 15224 kB
> SwapTotal:  562928 kB
> SwapFree:   562856 kB
> 
> Pour l'instant je la laisse tel quelle, est-ce que quelqu'un sais ce que je
> pourrais chercher de plus avant de la rebooter ?
> 
> Comme avant, rien sur ipcs.
> 
> Cordialement,
> --
> Christophe BAEGERT   [EMAIL PROTECTED]
> 
> >>>>>>>>>>>>>>> http://www.europeanservers.net <<<<<<<<<<<<<<<<
> 
> -- Ultra fast internet servers -
> 
>   
> Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
> Rendez-vous sur "http://www.mandrakestore.com";

-- 
Amicalement,
With my best regards,

Stephane BRANGER


*
*Linux Technical and Pre sales Engineer at Prologue Technologies*
*

Fortune of the month:
Steve Ballmer, PDG de Microsoft: «Il y des gens qui choisissent Linux,
mais je
ne crois pas que ça va durer» 
Steve Ballmer, Microsoft CEO: «Some people have made the linux choice,
but I
don't think this will last»

Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
Rendez-vous sur "http://www.mandrakestore.com";


Re: [Confirme] Fuite de mémoire système

2003-08-12 Par sujet Christophe BAEGERT
Le Mercredi 6 Août 2003 12:56, Teletchéa Stéphane a écrit :

> Fais plutôt un cat /proc/meminfo et tu devrais avoir quelquechose de
> plus correct, il me semble que top a un bug ...

Ca y'est j'ai changé la RAM pour de la Dane-Elec certifiée sur cette carte, 
mais ca recommence !!!

Voici un meminfo :
   total:used:free:  shared: buffers:  cached:
Mem:  527663104 512073728 155893760 165416960 97292288
Swap: 57643827273728 576364544
MemTotal:   515296 kB
MemFree: 15224 kB
MemShared:   0 kB
Buffers:161540 kB
Cached:  95012 kB
SwapCached:  0 kB
Active: 148880 kB
Inactive:   138508 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   515296 kB
LowFree: 15224 kB
SwapTotal:  562928 kB
SwapFree:   562856 kB

Pour l'instant je la laisse tel quelle, est-ce que quelqu'un sais ce que je 
pourrais chercher de plus avant de la rebooter ?

Comme avant, rien sur ipcs.

Cordialement,
-- 
Christophe BAEGERT   [EMAIL PROTECTED]

>>> http://www.europeanservers.net 

-- Ultra fast internet servers -


Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
Rendez-vous sur "http://www.mandrakestore.com";


[Confirme] RE: [Confirme] Fuite de mémoire système

2003-08-08 Par sujet Duclos Andre

Salut,

Qu'elle est la version de ton kernel ? 2.4.21 ? vanilla ou patcher ?

Combien de memoire dont tu disposes ? 512 Mo ? Ta carte video est une carte video 
externe ou integre a la carte mere ? Si oui, combien de memoire elle utilise ?

Peux tu desactiver le swap pour tester ?

Peux nous envoyer ton syslog (la partie qui contient le kernel panic) ? C'est le plus 
important.

Meme si un process merde, il ne doit pas faire planter le kernel.
C'est un probleme de memoire (secteur defectieux dans le swap, taille memoire non 
reconnu convenablement (memoire video partage), overclocking, ...)

Si tu peux repondre a toutes ces questions, tu vas t'en sortir.

@+

-Message d'origine-
De : Christophe BAEGERT [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 8 août 2003 06:51
À : [EMAIL PROTECTED]
Objet : Re: [Confirme] Fuite de mémoire système


Le Mercredi 6 Août 2003 12:56, Teletchéa Stéphane a écrit :

> Fais plutôt un cat /proc/meminfo et tu devrais avoir quelquechose de
> plus correct, il me semble que top a un bug ...

Ca y'est j'ai changé la RAM pour de la Dane-Elec certifiée sur cette carte, 
mais ca recommence !!!

Voici un meminfo :
   total:used:free:  shared: buffers:  cached:
Mem:  527663104 512073728 155893760 165416960 97292288
Swap: 57643827273728 576364544
MemTotal:   515296 kB
MemFree: 15224 kB
MemShared:   0 kB
Buffers:161540 kB
Cached:  95012 kB
SwapCached:  0 kB
Active: 148880 kB
Inactive:   138508 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   515296 kB
LowFree: 15224 kB
SwapTotal:  562928 kB
SwapFree:   562856 kB

Pour l'instant je la laisse tel quelle, est-ce que quelqu'un sais ce que je 
pourrais chercher de plus avant de la rebooter ?

Comme avant, rien sur ipcs.

Cordialement,
-- 
Christophe BAEGERT   [EMAIL PROTECTED]

>>>>>>>>>>>>>>> http://www.europeanservers.net <<<<<<<<<<<<<<<<

-- Ultra fast internet servers -



Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
Rendez-vous sur "http://www.mandrakestore.com";


Re: [Confirme] Fuite de mémoire système

2003-08-06 Par sujet ald
Le mer 06/08/2003 à 07:41, Christophe BAEGERT a écrit :
> Bonjour,

Salut

Sans pouvoir trop t'aider, il y a qq chose qui me parait bizarre:
d'aprés tes descriptions cela ne se passe que la nuit. Y a t'il qq chose
de spécial qui se lance le soir? une sauvegarde? un fantome?

A+


ALD

> 
> Le Mardi 5 Août 2003 11:55, vous avez écrit :
> > Je ne sais pas si un process peut bouffer plus de mémoire qu'affiché sur
> > top, ce que je sais c'est que un processus qui utilise les IPC et qui
> > par conséquent bouffe de la mémoire en plus des mallocs habituels, ne
> > libère pas ces IPCs si il plante violament ou peut etre lorsqu'il est
> > mal codé, et ds ce cas la il faut dégager ces IPCs qui ne sont plus
> > utilisés par la commande ipcrm.
> 
> Ca s'est reproduit cette nuit, voici mon top qui est plus que bizarre (après 
> avoir tué tout ce qui est tuable, sans arriver à libérer cette RAM). La 
> commande ipcs suit.
> 
>   7:36am  up 1 day, 14 min,  1 user,  load average: 0,01, 0,05, 0,01
> 18 processes: 17 sleeping, 1 running, 0 zombie, 0 stopped
> CPU states:  1,7% user,  0,5% system,  0,1% nice, 48,2% idle
> Mem:   450464K av,  391404K used,   59060K free,   0K shrd,  146088K buff
> Swap:  562928K av, 200K used,  562728K free   79732K 
> cached
> 
>   PID USER PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
> 1 root   0   0   504  496   468 S 0,0  0,1   0:05 init
> 2 root   9   0 00 0 SW0,0  0,0   0:00 keventd
> 3 root  19  19 00 0 SWN   0,0  0,0   0:00 ksoftirqd_CPU0
> 4 root   9   0 00 0 SW0,0  0,0   0:00 kswapd
> 5 root   9   0 00 0 SW0,0  0,0   0:00 bdflush
> 6 root  10   0 00 0 SW0,0  0,0   0:09 kupdated
> 7 root  -1 -20 00 0 SW<   0,0  0,0   0:00 mdrecoveryd
> 8 root   9   0 00 0 SW0,0  0,0   0:00 kreiserfsd
>   849 root   9   0  1096 1008   892 S 0,0  0,2   0:00 sshd
>  1132 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
>  1133 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
>  1134 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
>  1135 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
>  1136 root   9   0   400  384   340 S 0,0  0,0   0:00 mingetty
>  1137 root   9   0   400  344   344 S 0,0  0,0   0:00 mingetty
> 30708 root   9   0  1892 1848  1540 S 0,0  0,4   0:00 sshd
> 30722 root  11   0  1636 1636  1096 S 0,0  0,3   0:00 bash
> 31168 root  12   0  1000 1000   808 R 0,0  0,2   0:00 top
> 
> 
> ipcs :
> -- Segments de mémoire partagée 
> touche shmid  propriétaire perms  octets nattch statut
> 
> -- Tables de sémaphores 
> touche semid  propriétaire perms  nsems  statut
> 
> -- Files d'attente de messages 
> touche msqid  propriétaire perms  octets utilisés messages
> 
> 
> Cordialement,
-- 
ald <[EMAIL PROTECTED]>


Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
Rendez-vous sur "http://www.mandrakestore.com";


Re: [Confirme] Fuite de mémoire système

2003-08-06 Par sujet EuropeanServers - Christophe BAEGERT
Au temps pour moi c'est une Mandrake 8.2, je suis allé trop vite.

Le mar aoû  5 11:05:23 CEST 2003, EuropeanServers - Christophe BAEGERT a écrit:
> Bonjour,
> 
> j'ai une fuite de mémoire sur un serveur mail, en Mandrake 9.0. Je dois le rebooter 
> toutes les 2 jours.
> 
> J'ai mis à jour le kernel à la version stock 2.4.21, mais c'est pas mieux. 
> 
> Il a 450Mo de RAM, je l'ai surveillé toute la journée hier, il restait à 59Mo 
> réellement utilisé (en excluant cache et buffer), mais ce matin il était à 260. En 
> comptabilisant la mémoire prise par les applis, rien n'avait changé, c'était 
> toujours 29Mo pour BIND et 30Mo pour le reste. J'ai donc perdu 200Mo quelque part, 
> mais où et pourquoi ?
> 
> Quelqu'un aurait une idée?
> 
> Config de la machine :
> 
> MDK 9.0
> Bind 9.2.2
> Qmail 1.0.3 sous supervise + xxx
> serveur NFS
> système de fichiers ReiserFS
> 
> Voici la liste des processus tournant sur la machine :
>  1067 named 11   0 24204  23M  1548 S 0,3  5,3   2:07 named
> 11440 root   9   0  1032 1032   812 R 0,1  0,2   0:00 top
> 1 root   8   0   504  504   440 S 0,0  0,1   0:05 init
> 2 root   9   0 00 0 SW0,0  0,0   0:00 keventd
> 3 root  19  19 00 0 SWN   0,0  0,0   0:00 ksoftirqd_CPU0
> 4 root   9   0 00 0 SW0,0  0,0   0:00 kswapd
> 5 root   9   0 00 0 SW0,0  0,0   0:00 bdflush
> 6 root   9   0 00 0 SW0,0  0,0   0:01 kupdated
> 7 root  -1 -20 00 0 SW<   0,0  0,0   0:00 mdrecoveryd
> 8 root   9   0 00 0 SW0,0  0,0   0:00 kreiserfsd
>   764 rpc9   0   532  532   440 S 0,0  0,1   0:00 portmap
>   787 root   9   0   596  596   476 S 0,0  0,1   0:01 syslogd
>   796 root   9   0  1168 1168   432 S 0,0  0,2   0:00 klogd
>   849 root   9   0  1272 1272  1140 S 0,0  0,2   0:00 sshd
>   868 root   9   0   292  292   244 S 0,0  0,0   0:00 supervise
>   869 root   9   0   292  292   244 S 0,0  0,0   0:00 supervise
>   870 root   9   0   292  292   244 S 0,0  0,0   0:00 supervise
>   889 root   9   0  1124 1124   836 S 0,0  0,2   0:00 run
>   892 root   9   0  1124 1124   836 S 0,0  0,2   0:00 run
>   893 root   9   0  1128 1128   836 S 0,0  0,2   0:00 run
>   897 qmaild 0   0   472  472   400 S 0,0  0,1   0:00 tcpserver
>   898 qmaill 9   0   340  340   280 S 0,0  0,0   0:00 multilog
>   899 qmails 9   0   400  400   300 S 0,0  0,0   0:02 qmail-send
>   900 qmaill 9   0   340  340   280 S 0,0  0,0   0:00 multilog
>   903 root  10   0   304  304   252 S 0,0  0,0   0:00 tcpserver
>   904 qmaill 9   0   284  284   232 S 0,0  0,0   0:00 multilog
>   911 root   0   0   316  316   252 S 0,0  0,0   0:00 qmail-lspawn
>   912 qmailr 7   0   320  320   252 S 0,0  0,0   0:00 qmail-rspawn
>   913 qmailq 9   0   320  320   256 S 0,0  0,0   0:00 qmail-clean
>   966 root   8   0   664  664   556 S 0,0  0,1   0:00 crond
>  1036 root   9   0  1900 1900  1716 S 0,0  0,4   0:00 ntpd
>  1082 root   9   0   800  800   664 S 0,0  0,1   0:00 rpc.mountd
>  1093 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
>  1094 root   9   0 00 0 SW0,0  0,0   0:00 lockd
>  1095 root   9   0 00 0 SW0,0  0,0   0:00 rpciod
>  1096 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
>  1097 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
>  1098 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
>  1099 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
>  1100 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
>  1101 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
>  1102 root   9   0 00 0 SW0,0  0,0   0:00 nfsd
>  1112 stunnel9   0  1564 1564  1212 S 0,0  0,3   0:00 stunnel
>  1132 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
>  1133 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
>  1134 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
>  1135 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
>  1136 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
>  1137 root   9   0   408  408   348 S 0,0  0,0   0:00 mingetty
>  1237 stunnel8   0  1564 1564  1212 S 0,0  0,3   0:00 stunnel
>  6616 root   9   0  1996 1996  1672 R 0,0  0,4   0:00 sshd
>  6627 root   9   0  1636 1636  1092 S 0,0  0,3   0:00 bash
>  6690 root   9   0  1904 1904  1724 S 0,0  0,4   0:00 sshd
>  6692 x  9   0  2124 2124  1892 S 0,0  0,4   0:00 sshd
>  6693 x  9   0  1576 1576  1096 S 0,0  0,3   0:00 bash
> 11012 x  9   0  3788 3788  1464 S 0,0  0,8   0:00 mutt
> 11027 x  9   0  1060 1060   820 S 0