Re: [Confirme] Fuite de mémoire système
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] Fuite de mémoire système
Pierre Lo Cicero a crit: Bon alors sous MDK 9.1 et Apache 2 + les mises jour de scurit. 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 mre. MAis trs difficile dterminer. Une chose dont je suis presque sr, 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 problme, mais avec windows. Je ne suis pas certain que ce soit un problme de mmoire, mais. Le problme de ces fuites de mmoires peut-tre du la temprature du processeur, surtout s'il s'agit d'un AMD. En tous les cas, pour les AMD, certains sont livrs avec un ventilo largement sous-dimensionn. Le message d'erreur tait sans quivoque possible. Le simple fait de changer le ventilo en le remplaant par un "maousse costaud" a rgl le problme. A signaler que Linux plantait aussi, mais je n'ai pas cherch savoir pourquoi. Aprs remplacement du ventilo, plus de probs. Ni d'un ct, ni de l'autre. ..et en passant j'ai aussi puis mon stock mmoire en tentant de la changer. En souhaitant que cela t'aide C'est la premire chose que j'ai vrifi. Mais c'est un Celeron 1.0A, bien ventil mme si dans un rack 1U, le CPU doit etre sous 40 Merci de ton aide Cordialement,
[Confirme] RE: [Confirme] RE: [Confirme] Fuite de mémoire système
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
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
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
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
TROLLFinalement on devrait tous faire du windows, comme ca on arreterait de se poser des questions sur les fuites mémoires/TROLL 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
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 fast internet servers
Re: [Confirme] Fuite de mémoire système
Le mar aoû 5 11:05:23 CEST 2003, stephane a écrit: TROLLL euh si ce matin tu etais a 260 Mo, pour moi tu as plutot gagné 200 Mo non ? /TROLL ;-) 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;
Re: [Confirme] Fuite de mémoire système
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] 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;
[Confirme] RE: [Confirme] Fuite de mémoire système
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
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,0 0,2 0:00 vi 11205 root 9 0 284 284 228 S 0,0 0,0 0:00
Re: [Confirme] Fuite de mémoire système
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;
