Geoff,
As you may be aware, RSS does not mean anything with respect to memory use.
RSS stands for Resident Set Size. It is the size of RAM used by the process
at that moment. And that includes (parts of) libs, exe, data and stack.
If you have a machine with lots of memory and few processes it is quite
possible that RSS equals the total memory use of the process. However, if
you have the reverse, a machine with not too much memory and many running
processes, it may well be that the RSS is only 10% or less of total process
size.
-- Jan Evert
> -----Original Message-----
> From: geoff [SMTP:ot0006@0x29a.org.uk]
> Sent: Thursday, December 04, 2003 7:43 PM
> To: users@subversion.tigris.org
> Subject: Re: Big memory use after update
>
> On Fri, 28 Nov 2003 11:10:45 +0100, Roland Schwingel
> <Roland.Schwingel@onevision.de> wrote:
>
> >
> >Hi...
> >
> >> Memory for the Apache process went straight up from 270 MB to ~900 MB!
> >> And it didn't go down after the update and the rest of operations
> >> (delete the files, commit, status, etc.). I've had to manually restart
> >> Apache.
> >>
> >> Is that normal/expected?
> >I am making similar observations since 0.29.0 (ok, maybe I haven't
> checked
> >that earlier).
> >I made a test last weekend. Normally I do have eg. php also in apache and
> I
> >did
> >not knew whether this might be related to this additional software or
> not.
> >
> >I removed anything from apache except svn and restarted apache to get
> back
> >memory
> >on my server. On weekend there where 6 complete checkouts of my repos
> from
> >one
> >certain client, and just 2 very small checkins (everything script
> >controlled).
> >Besides that no svn usage in the network.
> >
> >On monday morning I made similiar observations. Memory grew to ~800MB.
> And
> >I
> >needed 4 apachectl stop calls to get rid of all running httpds. After one
> >apachectl start everything is fine for me again. But just for about 24
> >hours.
> >
> >I do this stopping and starting apache every day since about 3 weeks. As
> of
> >the fact
> >I couldn't find any reports for this problem on the list I was thinking
> it
> >is a home made
> >problem. But now, it does not seem so...
> >
> >Affected environment for my weekend thing:
> >server: apache 2.0.48, bdb 4.0.14, svn 0.33.1, linux 2.4.20
> >client: apache 2.0.48 (without svn), svn 0.33.0, linux 2.4.20
> >
> >So it appears there might be some leaking...
>
> Subversion 0.31
> Apache 2.0.47
> Berkeley-db 2.0.14
> kernel 2.4.19 SMP
> SuSe 8.2
>
> This system is a single-user archive. I've been using it for some
> medium-sized projects (<3000 files) and I notice that some of my seven
> httpd processes balloon up to 14Mb RSS as reported by top after remote
> svn operations involving a commit of most of the files.
>
> It's hard to tell which part of the operation causes the memory use. I
> can see httpd processes consuming cpu without apparently growing in
> size.
>
> This looks scary, huh? However while the processes sometimes get
> bigger than 14Mb (I've seen up to 25) they fall back to 14 almost
> immediately. Even more interestingly, after a ~24 hours they're all
> back to 8000-3000.
>
> I'm not an Apache expert but this looks like Apache keeping buffers on
> the grounds you might need them again rather than a leak.
>
> I tried MaxMemFree as suggested by Sander in
> <1070017333.3749.173.camel@localhost.localdomain> at the global level
> but it seemed to make no difference.
>
> Any Apache experts know for sure what's going on here? Would the same
> thing happen in W32?
>
> --
> best,
> geoff
>
> regrettably the email address above will bounce
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
=== E U R O N E X T - D I S C L A I M E R =============================
This e-mail and its attachments are only intended for the individual(s) or
entity(entities) named above to whom they are addressed and may contain
personal and/or confidential information. Please notify us immediately if
you are not the intended recipient. Any dissemination, duplication,
publication to third parties or other use of the contents of this e-mail or
its attachments is forbidden. Although this information has been compiled
with great care, neither Euronext N.V. nor its subsidiaries shall accept any
responsibility for any errors, omissions or other inaccuracies in this
information or for the consequences thereof, nor shall it be bound in any
way by the contents of this e-mail or its attachments. In the event of
incomplete or incorrect transmission please return the e-mail to the sender.
Cet e-mail et ses annexes sont uniquement destinés à la (aux) personne(s),
ou à l' (aux) entité(s) à laquelle (auxquelle(s)) il est adressé, visée (s)
en tête du présent message. Il peut contenir des informations personnelles
ou confidentielles. Merci de nous notifier immédiatement si cet e-mail vous
a été adressé par erreur. Toute diffusion, copie, publication à des tiers ou
toute autre utilisation de son contenu est interdite. Bien que cette
information ait été rassemblée avec une grande attention, ni Euronext N.V.
ni aucune de ses filiales, ne peut être tenue responsable des erreurs,
omissions ou inexactitudes contenues dans cette information, ni ne peut être
liée d'aucune manière par le contenu de cet e-mail ou ses annexes. En cas de
transmission incorrecte ou incomplète, nous vous prions de retourner cet
e-mail à son émetteur.
Deze e-mail en zijn bijlagen zijn uitsluitend bestemd voor de
geadresseerde(n) als op dit e-mailblad vermeld. Het is mogelijk dat deze
e-mail persoonlijke en/of vertrouwelijke informatie bevat. Wanneer u niet de
geadresseerde bent, verzoeken wij u dringend ons daarvan te berichten. Elke
verspreiding, vermenigvuldiging, gebruik of openbaarmaking aan derden van de
inhoud van deze e-mail en zijn bijlagen, is verboden. Hoewel deze informatie
met de meeste zorg is samengesteld is Euronext N.V., en de tot Euronext N.V.
behorende werkmaatschappijen, op geen enkele wijze aansprakelijk voor
eventuele fouten, omissies of andere onjuistheden in deze informatie of de
gevolgen daarvan noch op enigerlei wijze gebonden aan de inhoud van de
e-mail of zijn bijlagen. Gelieve, in geval van onjuiste of onvolledige
ontvangst, deze e-mail terug te sturen naar de afzender.
================================
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 5 10:00:58 2003