Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian mémoire vive qui grossit de jour en jour (rpi2 - jessie)

mémoire vive qui grossit de jour en jour (rpi2 - jessie)

5 réponses
Avatar
Patrice Go
--001a114a7c468ea9ca052c82b4af
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonjour,

sur un serveur (raspberrypi2), en debian jessie, qui contient juste en
service un apache2 (owncloud), MySQL, exim4 et nrpe, j'ai la m=C3=A9moire v=
ive
qui grossit de jour en jour. elle commence avec les services au d=C3=A9marr=
age
avec 21 % de m=C3=A9moire, lorsque les services sont utilis=C3=A9s, ils son=
t
habituellement =C3=A0 ~ 40%. Mais malgr=C3=A9 qu'ils ne soient pas utilis=
=C3=A9s, la
m=C3=A9moire vive grossit toute seule jusqu'=C3=A0 arriver =C3=A0 99%. malg=
r=C3=A9 le rajout
d'une swap et demandant le basculement vers la swap, =C3=A0 partir de 40%
restant sur la m=C3=A9moire vive, =C3=A7a ne fonctionne pas.

=C3=A7a devient probl=C3=A9matique car je dois red=C3=A9marrer le serveur t=
ous les 3-4
jours, pour que =C3=A7a puisse =C3=AAtre utilisable.

le rpi2 est un quadricoeur qui utilise donc irqbalance (le plus grand
utilisateur de m=C3=A9moire d'apr=C3=A8s la liste des processus ci dessous)=
. On peut
voir les processus qui utilisent le plus de m=C3=A9moire : ps -efFH --sort =
rss

root 371 1 0 43076 25224 1 f=C3=A9vr.17 ? 00:00:42
/usr/sbin/apache2 -k start
www-data 17024 371 0 44858 23456 0 08:46 ? 00:00:00
/usr/sbin/apache2 -k start
www-data 17025 371 0 44858 23464 0 08:46 ? 00:00:00
/usr/sbin/apache2 -k start
www-data 15786 371 0 44330 24000 0 06:25 ? 00:00:04
/usr/sbin/apache2 -k start
www-data 15788 371 0 44396 24628 0 06:25 ? 00:00:01
/usr/sbin/apache2 -k start
www-data 16673 371 0 44396 24824 0 08:06 ? 00:00:01
/usr/sbin/apache2 -k start
www-data 15789 371 0 44598 25424 0 06:25 ? 00:00:03
/usr/sbin/apache2 -k start
www-data 15785 371 0 44408 25552 0 06:25 ? 00:00:03
/usr/sbin/apache2 -k start
www-data 17023 371 0 44695 26068 0 08:46 ? 00:00:01
/usr/sbin/apache2 -k start
www-data 17026 371 0 44860 26108 1 08:46 ? 00:00:01
/usr/sbin/apache2 -k start
www-data 16674 371 0 44546 26588 0 08:06 ? 00:00:03
/usr/sbin/apache2 -k start
root 115 1 0 13108 39384 2 f=C3=A9vr.17 ? 00:04:10
/lib/systemd/systemd-journald
root 214 1 0 103310 411592 1 f=C3=A9vr.17 ? 00:56:09
/usr/sbin/irqbalance --pid=3D/var/run/irqbalance.pid

y a t il un moyen de conna=C3=AEtre le processus qui fait grossir la m=C3=
=A9moire
ainsi ?
si oui, y a t il moyen de limiter la m=C3=A9moire utilis=C3=A9 pour un proc=
essus ?

merci.

patg
--
Linux sec2 3.18.0-trunk-rpi2 #1 SMP PREEMPT Debian 3.18.5-1~exp1.co1
(2015-02-02) armv7l GNU/Linux

--001a114a7c468ea9ca052c82b4af
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Bonjour,<br><br></div>sur un serveur (raspberryp=
i2), en debian jessie, qui contient juste en service un apache2 (owncloud),=
MySQL, exim4 et nrpe, j&#39;ai la m=C3=A9moire vive qui grossit de jour en=
jour. elle commence avec les services au d=C3=A9marrage avec 21 % de m=C3=
=A9moire, lorsque les services sont utilis=C3=A9s, ils sont habituellement =
=C3=A0 ~ 40%. Mais malgr=C3=A9 qu&#39;ils ne soient pas utilis=C3=A9s, la m=
=C3=A9moire vive grossit toute seule jusqu&#39;=C3=A0 arriver =C3=A0 99%. m=
algr=C3=A9 le rajout d&#39;une swap et demandant le basculement vers la swa=
p, =C3=A0 partir de 40% restant sur la m=C3=A9moire vive, =C3=A7a ne foncti=
onne pas.<br><br></div><div>=C3=A7a devient probl=C3=A9matique car je dois =
red=C3=A9marrer le serveur tous les 3-4 jours, pour que =C3=A7a puisse =C3=
=AAtre utilisable.<br></div><div><br></div><div><div><div>le rpi2 est un qu=
adricoeur qui utilise donc irqbalance (le plus grand utilisateur de m=C3=A9=
moire d&#39;apr=C3=A8s la liste des processus ci dessous). On peut voir les=
processus qui utilisent le plus de m=C3=A9moire : ps -efFH --sort rss<br><=
br>root=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 371=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0 0 43076 25224=C2=A0=C2=A0 1=
f=C3=A9vr.17 ?=C2=A0=C2=A0=C2=A0=C2=A0 00:00:42=C2=A0=C2=A0 /usr/sbin/apac=
he2 -k start<br>www-data 17024=C2=A0=C2=A0 371=C2=A0 0 44858 23456=C2=A0=C2=
=A0 0 08:46 ?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00:00:00=C2=A0=C2=
=A0=C2=A0=C2=A0 /usr/sbin/apache2 -k start<br>www-data 17025=C2=A0=C2=A0 37=
1=C2=A0 0 44858 23464=C2=A0=C2=A0 0 08:46 ?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 00:00:00=C2=A0=C2=A0=C2=A0=C2=A0 /usr/sbin/apache2 -k start<br=
>www-data 15786=C2=A0=C2=A0 371=C2=A0 0 44330 24000=C2=A0=C2=A0 0 06:25 ?=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00:00:04=C2=A0=C2=A0=C2=A0=C2=A0=
/usr/sbin/apache2 -k start<br>www-data 15788=C2=A0=C2=A0 371=C2=A0 0 44396=
24628=C2=A0=C2=A0 0 06:25 ?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00:0=
0:01=C2=A0=C2=A0=C2=A0=C2=A0 /usr/sbin/apache2 -k start<br>www-data 16673=
=C2=A0=C2=A0 371=C2=A0 0 44396 24824=C2=A0=C2=A0 0 08:06 ?=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 00:00:01=C2=A0=C2=A0=C2=A0=C2=A0 /usr/sbin/apac=
he2 -k start<br>www-data 15789=C2=A0=C2=A0 371=C2=A0 0 44598 25424=C2=A0=C2=
=A0 0 06:25 ?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00:00:03=C2=A0=C2=
=A0=C2=A0=C2=A0 /usr/sbin/apache2 -k start<br>www-data 15785=C2=A0=C2=A0 37=
1=C2=A0 0 44408 25552=C2=A0=C2=A0 0 06:25 ?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 00:00:03=C2=A0=C2=A0=C2=A0=C2=A0 /usr/sbin/apache2 -k start<br=
>www-data 17023=C2=A0=C2=A0 371=C2=A0 0 44695 26068=C2=A0=C2=A0 0 08:46 ?=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00:00:01=C2=A0=C2=A0=C2=A0=C2=A0=
/usr/sbin/apache2 -k start<br>www-data 17026=C2=A0=C2=A0 371=C2=A0 0 44860=
26108=C2=A0=C2=A0 1 08:46 ?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00:0=
0:01=C2=A0=C2=A0=C2=A0=C2=A0 /usr/sbin/apache2 -k start<br>www-data 16674=
=C2=A0=C2=A0 371=C2=A0 0 44546 26588=C2=A0=C2=A0 0 08:06 ?=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 00:00:03=C2=A0=C2=A0=C2=A0=C2=A0 /usr/sbin/apac=
he2 -k start<br>root=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
115=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 13108 3=
9384=C2=A0=C2=A0 2 f=C3=A9vr.17 ?=C2=A0=C2=A0=C2=A0=C2=A0 00:04:10=C2=A0=C2=
=A0 /lib/systemd/systemd-journald<br>root=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 214=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 0 103310 411592 1 f=C3=A9vr.17 ?=C2=A0=C2=A0=C2=A0=C2=A0 00:56=
:09=C2=A0=C2=A0 /usr/sbin/irqbalance --pid=3D/var/run/irqbalance.pid<br><br=
></div><div><div>y a t il un moyen de conna=C3=AEtre le processus qui fait =
grossir la m=C3=A9moire ainsi ?<br></div><div>si oui, y a t il moyen de lim=
iter la m=C3=A9moire utilis=C3=A9 pour un processus ?<br></div><br></div><d=
iv>merci.<br></div><div><br></div><div>patg<br></div><div>--<br>Linux sec2 =
3.18.0-trunk-rpi2 #1 SMP PREEMPT Debian 3.18.5-1~exp1.co1 (2015-02-02) armv=
7l GNU/Linux<br></div></div></div></div>

--001a114a7c468ea9ca052c82b4af--
Signaler un problème avec ce contenu

5 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Pascal Hambourg
Patrice Go a écrit :

j'ai la mémoire vive qui grossit de jour en jour.



Quelle chance. Si seulement la RAM de mon PC pouvait faire de même...
Avatar
Patrice Go
--001a114326524d158a052c93f76a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

j'ai réduit la valeur du MaxRequestPerChild dans
mods-enabled/mpm_prefork.conf, et effectivement la mémoire semble rest er
stable depuis hier.
le problème semble donc résolu, merci :).

j'ai la mémoire vive qui grossit de jour en jour.


Quelle chance. Si seulement la RAM de mon PC pouvait faire de même.. .



le rpi c'est magique ;)

Le 24 février 2016 à 15:49, honeyshell > a écrit :

Bonjour Patrice Go,

Tu trouveras surement le bonheur sur ces optimisations :
http://lea-linux.org/documentations/Leapro-pro_sys-dimensionnement-apache .
Tu es sous RPi je suppose?





--001a114326524d158a052c93f76a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div></div><div>j&#39;ai réduit la valeur du MaxReque stPerChild dans mods-enabled/mpm_prefork.conf, et effectivement la mém oire semble rester stable depuis hier.<br></div><div>le problème sembl e donc résolu, merci :).<br><span class="im"><br>
&gt;&gt; j&#39;ai la mémoire vive qui grossit de jour en jour.</span>< br>&gt; Quelle chance. Si seulement la RAM de mon PC pouvait faire de mà ªme...<br><br></div><div>le rpi c&#39;est magique ;)<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 24 février 201 6 à 15:49, honeyshell <span dir="ltr">&lt;<a href="mailto:honeyshe " target="_blank"></a>&gt;</spa n> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bonjour Patrice Go,<br>
<br>
Tu trouveras surement le bonheur sur ces optimisations :<br>
<a href="http://lea-linux.org/documentations/Leapro-pro_sys-dimensionneme nt-apache" rel="noreferrer" target="_blank">http://lea-linux.org/docume ntations/Leapro-pro_sys-dimensionnement-apache</a>.<br>
Tu es sous RPi je suppose?<br>
<br>
</blockquote></div><br></div>

--001a114326524d158a052c93f76a--
Avatar
honeyshell
j'avais eu des soucis similaires avec fail2ban :
http://www.honeyshell.com/?p12
Avatar
Patrice Go
--001a113a6e86974abe052d20cd3f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

pour info : finalement, avec la modification mpm, ça a pris plus de te mps
pour arriver à 99%, mais ça y arrive malgré cela. Finalement comme
irqbalance utilise la moitié de la mémoire (alors que ça fon ctionne bien
sans), je l'ai arrêté, et mis au ban -> 0. du coup, plus de probl ème de
mémoire qui grimpe sans cesse (depuis deux jours). Si ça peut aid er
d'autres...

Le 25 février 2016 à 09:38, honeyshell > a écrit :

j'avais eu des soucis similaires avec fail2ban :
http://www.honeyshell.com/?p12





--001a113a6e86974abe052d20cd3f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr">pour info : finalement, avec la modification mpm, ça a pris plus de temps pour arriver à 99%, mais ça y arrive malgr é cela. Finalement comme irqbalance utilise la moitié de la mà ©moire (alors que ça fonctionne bien sans), je l&#39;ai arrêt é, et mis au ban -&gt; 0. du coup, plus de problème de mémoi re qui grimpe sans cesse (depuis deux jours). Si ça peut aider d&#39;a utres...<br></div><div class="gmail_extra"><br><div class="gmail_quote" >Le 25 février 2016 à 09:38, honeyshell <span dir="ltr">&lt;<a href="mailto:" target="_blank"> yshell.com</a>&gt;</span> a écrit :<br><blockquote class="gmail_quot e" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> j&#39;avais eu des soucis similaires avec fail2ban :<br>
<a href="http://www.honeyshell.com/?p12" rel="noreferrer" target= "_blank">http://www.honeyshell.com/?p12</a><br>
<br>
</blockquote></div><br></div>

--001a113a6e86974abe052d20cd3f--
Avatar
Eric Degenetais
ça semble indiquer une fuite de mémoire sur ta version d'irqbalan ce =>
sais-tu si c'est documenté? s'il y a une version où le bug est r ésolu?
dans le cas contraire ça vaudrait peut-être le coup de rapporter le problème
______________
Éric Dégenètais
Henix



http://www.henix.com
http://www.squashtest.org



Le 3 mars 2016 à 09:29, Patrice Go a écri t :
pour info : finalement, avec la modification mpm, ça a pris plus de temps
pour arriver à 99%, mais ça y arrive malgré cela. Finaleme nt comme
irqbalance utilise la moitié de la mémoire (alors que ça f onctionne bien
sans), je l'ai arrêté, et mis au ban -> 0. du coup, plus de pro blème de
mémoire qui grimpe sans cesse (depuis deux jours). Si ça peut a ider
d'autres...

Le 25 février 2016 à 09:38, honeyshell om> a écrit :

j'avais eu des soucis similaires avec fail2ban :
http://www.honeyshell.com/?p12