Re: [Evolution-hackers] massive e-d-s memory leak persuit ...
- From: Srinivasa Ragavan <sragavan novell com>
- To: michael meeks novell com
- Cc: evolution <evolution-hackers gnome org>
- Subject: Re: [Evolution-hackers] massive e-d-s memory leak persuit ...
- Date: Fri, 25 Jan 2008 00:00:04 +0530
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.
.evolution/addressbook/<account>/<book_name>.summary -- Summary which is
in memory for fast autocompletion
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.
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 ?
] [Thread Prev