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

[Philip Van Hoof <spam pvanhoof be>]

Hi there,

FYI (although most Evolution hackers already know this)

Note that Michael's memory analysis wont include the mailer component's
memory usage. The mailer component's memory is mostly consumed by
camel-folder-summary.c in Camel. Camel runs in the process of Evolution,
not in e-d-s.

This is mostly address and contact records, I'm assuming. Their memory
might also get copied to the UI's process (depending on the active
query).

btw, thanks Michael.


Cheers,


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.
> 
-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be