Re: [Evolution] Evolution performance

On Wed, 2014-05-28 at 12:25 -0400, Reid Vail wrote:
Hello Adam -
Thanks for the advise.  
Answering your earlier question, yes there is about 500meg, I think,
in local mail (inbox) and at least that much more in folders.  The
Inbox is of course under "On this computer", but so are all of the
folders.  I'm not sure if that's part of the problem or not.
I can't tell for sure if 3.6.4 is mbox or maildir.  I've looked for
documentation and haven't been able to figure that out yet.  I think
it's maildir.  And I'm honestly not sure what the steps would be to
migrate from mbox to maildir.

It is probably maildir, so not a problem there.  Only way it would be
mbox is if you upgraded the account from Evolution 2.x.

I have tried a few of your suggestions; purging the .cashe and also
emptying the trash but there didn't appear to be performance impact.

Nope, if the mail is under "On this computer" the cache shouldn't be the

I did try a different tack; I installed Mint17 on Vituralbox,
installed Evolution (rev 3.10.4, migrated my wife's mail data to that
and saw a big improvement. 

GOOD MAN!  Testing in a virtual machine before breaking things!!!! Man,
I wish more people would take that approach! :)

Indeed, the post 3.6.x releases of Evolution are in my experience each
noticeably more responses than the last.  3.8.x was a big improvement.

But there are major differences in her architecture and mine.  I have
much faster CPU and a SSD drive.  So, I think my plan is this.... get
her on a an upgraded OS, install the new Evolution and see if that
helps.  If not, put in an SSD, and then upgrade the CPU if needed.
Does that make sense?

Data on an SSD never hurts. :)  The CPU seems an unlikely culprit,
anything even a few generations old probably has plenty of HP for a
desktop.  Kludegy I/O subsystems kill responsiveness.  If you can watch
with top, or even better dstat, when Evolution starts then you can see
if you begin paging and just to see the general I/O pattern - we are
interested in disk & memory, not really so much with CPU [a saturated
I/O subsystem can spike CPU utilization - making CPU *look* like the
bottleneck when the spike is actually an effect not a cause].

These tests work best [are most telling] after a cold start or flushing
the buffers.  

   sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

The above makes LINUX forget what it has buffered, and [nearly anyway]
start from scratch - which keeps things it has previously cached from
messing up test results.

You can also watch I/O in extreme detail:

Otherwise beyond I/O the debugging page is always a good read:

Adam Tauno Williams <mailto:awilliam whitemice org> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]