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://[EMAIL PROTECTED]/;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. > _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
