Re: [Evolution-hackers] massive e-d-s memory leak persuit ...

[Srinivasa Ragavan <sragavan novell com>]

Hey Michael,

We are aware of some situations (I did that in addressbook) where the
memory built up can happen. They were fixed later to SLED/SP1 release
during late 2.12 and aren't in SLED but are part of trunk already.
Candidate for the next support pack. Chen is doing a extensive job of
profiling EDS currently for SLED/2.22 releases. 

Once thing is that the Groupwise Addressbook cache, on a update,
wouldn't clear the previous one and just appends everything. Which means
if you have 100 and you have a update of 10. Next time your cache would
have 210 where as ideally it should have just 110. Just to see, if this
is a culprit for you. Just move the
".evolution/cache/addressbook/<account>/Novell GroupWise Address Book"

some where else and make it resync (showdown evo/eds and start evo and
go to addressbook). If the sizes vary a lot, they are affected by that
syndrome. There were quite a few bits like these they were fixed post
SP1 and are in trunk/2.12 already.

GQuarks seems to be a nice idea. I will look at it in some time. Thanks
Meeks.

-Srini.


On Thu, 2008-01-24 at 17:46 +0000, Michael Meeks wrote:
> Hi dudie,
> 
> 	So - I started to look at the e-d-s memory explosion situation quickly,
> took a nice dump from gdb, ran strings on it and the heap has a ton of
> strings around the place (as you would expect) - [ currently running at
> only ~60Mb
> 
> strings /tmp/eds-heap | sort | uniq -c | sort -n 
> 
> gives me:
> 
>    1666 -CONTACT-UID
>    1666 -NAME
>    1736         ION-DEST-NAME
>    1894 OLUTION-BOOK-URI
>    2100 -EMAIL
>    2184         ION-DEST-EMAIL
>    2318 OLUTION-FILE-AS
>    2506 OLUTION-LIST
>    2992 ION-LIST
>    3058 comp
>    3321         OLUTION-DEST-EMAIL
>    3329         OLUTION-DEST-CONTACT-UID
>    3993         OLUTION-DEST-NAME
>    4534 pwise://mmeeks prv1-3 novell com/;Novell GroupWise Address Book
>    5343 BEGIN:VCARD
>    5372 ION-DEST-EMAIL
>    5504 END:VCARD
>    5505 VERSION:3.0
>    6786 ION-DEST-NAME
>    8606 para
>   12739 ION-DEST-CONTACT-UID
>   13642 OLUTION-DEST-CONTACT-UID
>   18082 OLUTION-DEST-NAME
>   19252 OLUTION-DEST-EMAIL
>   21991 prop
>   32508 ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;
>   40253         pA,
> 
> 
> 	Where the first column is the count ... 32508 copies of that ATTENDEE
> string seems a little excessive, as do the (apparently mangled?)
> OLUTION-DEST-... strings.
> 
> 	Does that provide any insight wrt. code to audit for this huge leak ?
> apparently it afflicts everything from SLED10-SP1 onwards. Also - in
> general to reduce the (high) e-d-s memory usage, should we be using
> GQuarks for some of these field names as we store them ?
> 
> 	Thanks,
> 
> 		Michael.
>