Hello, I experimented with dovecot the whole evening yesterday and the mailserver worked fine since there haven't been that much users connecting to it. I'm using dovecot 1.0.alpha5 as pop3 and pop3s server. The maildirs are mounted through NFS and since there is no nfslockd running I disabled mmap in the config and told dovecot to use dotlock. Also I experienced, that dovecot was much faster when using one login-process per connection instead of sharing them throughout several connections. Sharings seems to be a greater performance problem (bottleneck) than additional fork()s. However, under normal load at business time the server load increased to a value that made it impossible to download emails without timeouts, so we switched back to tcpserver/qmail-pop3d for pop3 and only kept dovecot for doing the pop3s part. Dovecot is really fine, but it still isn't NFS ready. Especially when using dovecot as pop3 only this index-stuff must be disengageable. What is the use of generating a complex index file for hundreds of messages, that will be deleted in the next step after downloading them? But the index is also a problem when using IMAP over NFS. Access to the files is too slow, so the connections keep hanging around and the i/o waiting value is raised to a maximum which slows down the whole machine. It simply doesn't make sense to build and update an index every time the maildir is accessed (which is very cpu and timeconsuming), while search operations (the only moment when the index is actually used and not just heavily updated) don't affect even 1% of all IMAP calls (and such a command doesn't even exist for pop3). I would be much obliged if you could create an option called "--disable-index" in the configure-script or something like "disable-index = yes" in dovecot.conf that makes dovecot ignoring existing index files and doesn't care for related operations, so NFS should work much faster and IMAP search would simply parse the files directly instead of looking in the index. I would really appriciate this very much and I'm absolutely sure, that a lot of people beside me are waiting for this. Regards Marten
On 2006-01-13 18:04:15 +0100, Marten Lehmann wrote:> I experimented with dovecot the whole evening yesterday and the > mailserver worked fine since there haven't been that much users > connecting to it. I'm using dovecot 1.0.alpha5 as pop3 and pop3s server. > The maildirs are mounted through NFS and since there is no nfslockd > running I disabled mmap in the config and told dovecot to use dotlock. > Also I experienced, that dovecot was much faster when using one > login-process per connection instead of sharing them throughout several > connections. Sharings seems to be a greater performance problem > (bottleneck) than additional fork()s. > > However, under normal load at business time the server load increased to > a value that made it impossible to download emails without timeouts, so > we switched back to tcpserver/qmail-pop3d for pop3 and only kept dovecot > for doing the pop3s part.can we have some numbers? how many concurrent connections? how did you compile dovecot? do you use epoll/inotify?> Dovecot is really fine, but it still isn't NFS ready. Especially when > using dovecot as pop3 only this index-stuff must be disengageable. What > is the use of generating a complex index file for hundreds of messages, > that will be deleted in the next step after downloading them? But the > index is also a problem when using IMAP over NFS. Access to the files is > too slow, so the connections keep hanging around and the i/o waiting > value is raised to a maximum which slows down the whole machine. It > simply doesn't make sense to build and update an index every time the > maildir is accessed (which is very cpu and timeconsuming), while search > operations (the only moment when the index is actually used and not just > heavily updated) don't affect even 1% of all IMAP calls (and such a > command doesn't even exist for pop3).for me the index even helps for just opening the folder via imap. having an up2date index speeds up reading the folder via imap drastically. did you try to store the indexes locally on the disk? you can configure that at runtime.> I would be much obliged if you could create an option called > "--disable-index" in the configure-script or something like > "disable-index = yes" in dovecot.conf that makes dovecot ignoring > existing index files and doesn't care for related operations, so NFS > should work much faster and IMAP search would simply parse the files > directly instead of looking in the index. > > I would really appriciate this very much and I'm absolutely sure, that a > lot of people beside me are waiting for this.hope this helps. darix
Marten Lehmann wrote:> I would be much obliged if you could create an option called > "--disable-index" in the configure-script or something like > "disable-index = yes" in dovecot.conf that makes dovecot ignoring > existing index files and doesn't care for related operations, so NFS > should work much faster and IMAP search would simply parse the files > directly instead of looking in the index.Either store indexes on a local disk or use nonpersistent memory indexes: default_mail_env = maildir:/nfs/%d/%u/Maildir:INDEX=MEMORY Tomi
Marten Lehmann wrote:> Dovecot is really fine, but it still isn't NFS ready. Especially when > using dovecot as pop3 only this index-stuff must be disengageable. What > is the use of generating a complex index file for hundreds of messages, > that will be deleted in the next step after downloading them?Well, part of the issue is that Dovecot is _primarily_ an IMAP server, where these indexes prove invaluable to its performance. The POP3 side is more of an added bonus.> But the index is also a problem when using IMAP over NFS.This is why you can configure Dovecot to use indexes on the local disk, or in memory, as I believe someone else has already mentioned. > Access to the files is> too slow, so the connections keep hanging around and the i/o waiting > value is raised to a maximum which slows down the whole machine. It > simply doesn't make sense to build and update an index every time the > maildir is accessed (which is very cpu and timeconsuming), while search > operations (the only moment when the index is actually used and not just > heavily updated) don't affect even 1% of all IMAP calls (and such a > command doesn't even exist for pop3).I was fairly sure Timo has the index doing more than what you'd at first expect.> > I would be much obliged if you could create an option called > "--disable-index" in the configure-script or something like > "disable-index = yes" in dovecot.conf that makes dovecot ignoring > existing index files and doesn't care for related operations, so NFS > should work much faster and IMAP search would simply parse the files > directly instead of looking in the index.All that being said, I do agree that this option could well have its place. I suspect Timo might even say it's possible to have a "no-index" plug-in to handle this. -- Curtis Maloney cmaloney@cardgate.net
Hello,> can we have some numbers?between 09:00 and 09:59 there were 24586 logins, between 10:00 and 10:59 there were 26296.> how many concurrent connections?Its to laborious to check in detail, but with 7.3 logins per seconds and an average download time of at least 20-30 seconds (usually faster, but the system slowed down) there are a lot and all of them are waiting for NFS-calls to finish.> how did you compile dovecot?I compiled with: ./configure \ --prefix=/pop3/dovecot-%{version} \ --with-rundir=/pop3/dovecot-%{version}/var \ --disable-ipv6 \ --without-bsdauth \ --without-checkpassword \ --without-ldap \ --without-pam \ --without-passwd \ --without-prefetch-userdb \ --without-shadow \ --without-static-userdb \ --without-vpopmail \ --with-ssl=openssl \ --with-storages=maildir> do you use epoll/inotify?I guess now (unless its default), but I have never heard of.> for me the index even helps for just opening the folder via imap.Yes, for IMAP it may be fine. But I'm talking about a plain POP3-dovecot where an index is not required.> having > an up2date index speeds up reading the folder via imap drastically.I'm not sure about this using NFS.> did you try to store the indexes locally on the disk? you can configure > that at runtime.Why do I have to store indexes at all? I don't want a second folder for all the indices. And after all, they wouldn't make sense, because more than one pop3 server could be accessing the NFS-mailboxes at the same time (thats what the outsourcing of the mailboxes to an NFS-share was ment for). Regards Marten
Hello,> Either store indexes on a local disk or use nonpersistent memory > indexes: > > default_mail_env = maildir:/nfs/%d/%u/Maildir:INDEX=MEMORYmy default_mail_env is more complex, so its read from a file by passwd and userdb. How can I define the default_mail_env (or at least the index=memory thing) without changing the maildir? Regards Marten