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

[Srinivasa Ragavan <sragavan novell com>]

Michael,

http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=7798
and
http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=7797
were some of the issues I mentioned.

My previous statement was wrong. It wasn't the cache, that is appended,
but the summary of the contacts. 

Just check 
.evolution/addressbook/<account>/<book_name>.summary -- Summary which is
in memory for fast autocompletion
and
.evolution/cache/addressbook/<account>/<book_name>/cache.db --Acutal
cache of contacts

If you see these with groupwise, at times the summary will be more than
the cache. Which is what the revision fixes. Just check and lemme know.

-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.
>