Re: Deliverdb in a memcached
> On a very busy Imap server , duplicate suppression sometimes becomes the > bottleneck > I have seen that If I disable duplicate suppression , my lmtp deliveries > are speeded up. > > Duplicate suppression is important , but the database need not persist > for very long. > I have seen in most of the cases if there is a duplicate mail ( due to > forwards , groups etc ), it arrives within 10 minutes of the first mail > ( Any exception to this is too minor and can be ignored ) > > > IMHO There should be a configuration that the deliverdb can be, > optionally, stored in memcached or directly in memory. > Of course there are cons .. like loss of data on restart etc. But these > are OK. I think storing it in tmpfs would be what you want. The init script could then save a permanent copy on shutdown and put it in place on startup. That way you won't loose anything on normal restart procedure. Simon Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Deliverdb in a memcached
On 2011-08-23 at 14:01, Ram wrote: > On a very busy Imap server , duplicate suppression sometimes becomes the > bottleneck > I have seen that If I disable duplicate suppression , my lmtp deliveries > are speeded up. > > Duplicate suppression is important , but the database need not persist > for very long. > I have seen in most of the cases if there is a duplicate mail ( due to > forwards , groups etc ), it arrives within 10 minutes of the first mail > ( Any exception to this is too minor and can be ignored ) > > > IMHO There should be a configuration that the deliverdb can be, > optionally, stored in memcached or directly in memory. > Of course there are cons .. like loss of data on restart etc. But these > are OK. A number of cyrus' databases are volatile and can be placed on tmpfs. memcached seems overkill, and as of cyrus version 2.4.8 there are options to specify the location of most databases, and thus be able to point some of the to a tmpfs based directory. We currently use the following: mboxname_lockpath: /uio/PKG/tmpfs/lock proc_path: /uio/PKG/tmpfs/proc duplicate_db_path: /uio/PKG/tmpfs/deliver.db statuscache_db_path: /uio/PKG/tmpfs/statuscache.db tlscache_db_path: /uio/PKG/tmpfs/tls_sessions.db and it reduces IO on the storage a lot. -- Øyvind Kolbu Postmaster Universitetet i Oslo pgpJEQTyrn4cP.pgp Description: PGP signature Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Deliverdb in a memcached
On a very busy Imap server , duplicate suppression sometimes becomes the bottleneck I have seen that If I disable duplicate suppression , my lmtp deliveries are speeded up. Duplicate suppression is important , but the database need not persist for very long. I have seen in most of the cases if there is a duplicate mail ( due to forwards , groups etc ), it arrives within 10 minutes of the first mail ( Any exception to this is too minor and can be ignored ) IMHO There should be a configuration that the deliverdb can be, optionally, stored in memcached or directly in memory. Of course there are cons .. like loss of data on restart etc. But these are OK. Thanks Ram Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
