[Dovecot] severe performance problem (mail cache related?)

[Timo Sirainen]

On Fri, 2007-02-16 at 03:05 -0800, Dan Price wrote:
> On Fri 16 Feb 2007 at 02:49AM, Dan Price wrote:
> > > So.. Hmm. Could the problem simply be that the mmap-copy-growing is too
> > > slow? If the user really has some 25MB cache file, that could be it. I
> > > think I could change the code so that it mmap()s immediately enough
> > > memory to fit the whole cache file. Probably a good idea to do anyway.
> 
> One thing I don't totally get is why you mmap anon here, if this is
> really about a cache file?  It seems that you could mmap the cache file
> directly, perhaps with MAP_PRIVATE if you need to make in-memory-only
> changes.

Yes, and it's done as long as you don't have mmap_disable=yes. Hmm.
Weren't you using ZFS directly? Why are you using mmap_disable=yes? :)
Its main purpose is to make indexes work in NFS.

> > I agree that mmaping the whole index.cache in one shot is the way to
> > go-- asking the VM system to do work in little chunks is (at least
> > on Solaris) a real performance killer.
> 
> Another idea I had was that dovecot could take advantage of larger
> pages--especially for its anon mappings-- this cuts TLB footprint and
> is usually "a good thing."
> 
> So for example, on Solaris (SPARC) you can get 8K, 64K, 512K and 4M
> pages.  On Solaris AMD64 it's 4K and 2M.
> 
> This is available via getpagesizes(3c).

I haven't heard about this before. I'll see if I can use it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20070216/e9d1201f/attachment.pgp