Re: [Dovecot] Zimbra benchmarking
Hi, for me zimbra swapped a lot on 1G of RAM even while serving mailboxes for 3 users. But on 2G it runs such that I can't feel it's slower than previously worked there dovecot. -- Sergey. Timo Sirainen wrote: Now that I have a working kvm setup, I thought I'd finally try how Zimbra works. This is mainly some microbenchmarking, so it may not have much to do with actual performance in real life. Setup: - 1GB memory given to kvm (from host's 2GB) - Intel Core 2 6600 (kvm uses only one CPU) - CentOS 5 - 15GB qcow2 image on XFS filesystem - Zimbra 5.0 RC2 RHEL5 x86_64 - Dovecot latest hg, dbox format Both Zimbra and Dovecot were tested running on the same kvm image. All data could be cached in memory, so this didn't really test disk I/O. Dovecot was run with fsync_disable=no. Running with =yes would have made its performance even better. Zimbra features/bugs Zimbra's SEARCH command doesn't support substring searching as IMAP requires: 1 search text performance * SEARCH 136 183 227 231 232 233 245 1 OK SEARCH completed 2 search text erformance * SEARCH 2 OK SEARCH completed 3 search text performanc * SEARCH 3 OK SEARCH completed It's possible to search performanc in a non-standard way though: 4 search text performanc* * SEARCH 136 183 227 231 232 233 245 4 OK SEARCH completed This means that the upcoming Dovecot v1.1 is probably the only IMAP server that supports IMAP-compatible full text search indexes with incremental updates. (Cyrus Squat requires rebuilding the whole index from scratch just for adding one mail, which makes it kind of impractical.) Zimbra doesn't support SORT or THREAD extensions. I had trouble benchmarking more than 5 simultaneous connections in one mailbox. I'm not sure if this is a configurable setting somewhere, or if there's just some bug. The error messages that my imaptest gave looked like Zimbra was buggy, but I didn't look at them too closely. STORE command also seemed to be buggy, giving lots of STORE failed errors, even with just one connection. Zimbra uses 500MB of memory just to start up, so it's not exactly for hosting small installations. Login+Logout Dovecot: ./imaptest - select=0 secs=10 seed=0 clients=1 Logi Logo 100% 100% 3439 6878 ./imaptest - select=0 secs=10 seed=0 clients=10 Logi Logo 100% 100% 4415 8830 Zimbra: ./imaptest - select=0 secs=10 seed=0 clients=1 Logi Logo 100% 100% 18032 36064 ./imaptest - select=0 secs=10 seed=0 clients=10 Logi Logo 100% 100% 25519 51056 Looks like Dovecot's imap process creation hurts it a lot compared to Zimbra's thread creation. Luckily IMAP connections are usually long-living, so this shouldn't matter much, except for webmails for which you can use imapproxy in the middle. LIST * - Dovecot: ./imaptest - select=0 logout=0 list=100 secs=10 seed=0 clients=1 Logi List 100% 100% 1 181411 ./imaptest - select=0 logout=0 list=100 secs=10 seed=0 clients=10 Logi List 100% 100% 10 133451 Zimbra: ./imaptest - select=0 logout=0 list=100 secs=10 seed=0 clients=1 Logi List 100% 100% 1 1021 ./imaptest - select=0 logout=0 list=100 secs=10 seed=0 clients=10 Logi List 100% 100% 10 972 Yes, Dovecot's LIST is over 100 times faster. STATUS INBOX (MESSAGES UNSEEN RECENT) - 100 messages in INBOX dovecot: ./imaptest - logout=0 select=0 status=100 secs=10 seed=0 clients=1 Logi Stat 100% 100% 1 191003 ./imaptest - logout=0 select=0 status=100 secs=10 seed=0 clients=10 Logi Stat 100% 100% 10 171171 Zimbra: ./imaptest - logout=0 select=0 status=100 secs=10 seed=0 clients=1 Logi Stat 100% 100% 1 3697 ./imaptest - logout=0 select=0 status=100 secs=10 seed=0 clients=10 Logi Stat 100% 100% 10 7009 FETCH 1:* (UID FLAGS ENVELOPE INTERNALDATE BODYSTRUCTURE) - 100 messages in INBOX. dovecot: ./imaptest - logout=0 select=100 fetch=100 secs=10 seed=0 clients=1 Logi Sele Fetc 100% 100% 100% 11 2769 ./imaptest - logout=0 select=100 fetch=100 secs=10 seed=0 clients=5 Logi Sele Fetc 100% 100% 100% 55 2902 Zimbra: ./imaptest - logout=0 select=100 fetch=100 secs=10 seed=0 clients=1 Logi Sele Fetc 100% 100% 100% 11 203 ./imaptest - logout=0 select=100 fetch=100 secs=10 seed=0 clients=5 Logi Sele Fetc 100% 100% 100% 55 258 FETCH ? (BODY[]) Randomly fetch message body from 100 messages Dovecot: ./imaptest - logout=0 select=100 fetch2=100 secs=10 seed=0 clients=1 Logi Sele Fet2 100% 100% 100% 30% 11 51958 ./imaptest - logout=0 select=100 fetch2=100 secs=10 seed=0 clients=5 Logi Sele Fet2 100% 100% 100% 30% 55 141397 Zimbra: ./imaptest - logout=0 select=100 fetch2=100 secs=10 seed=0 clients=1
Re: [Dovecot] locking strategies?
You had to ask that...we're still on 0.99, but we're testing other options as well. We're pretty restricted to RHEL 4.x, but with the help of others on the list we've made some progress with testing 1.0.7 on 4.x as well. We have some clients using a java based IMAP application with some major issues, so we're moving slow on changing our config for one bad application. We've seen this issue and others, and Red Hat says they're recommending dotlock to increase stability of the mboxes for the short-term: - fcntl() failed with mbox file /var/mail/XXX: Resource deadlock avoided - file istream.c: line 93 (i_stream_set_read_limit): assertion failed: (stream-v_size == 0 || v_offset = stream-v_size) - Corrupted modify log file /users/XXX/mail/.imap/INBOX/.imap.index.log.2: Contains more data than expected - Error rewriting mbox file /users/XXX/mail/Folder Name: Unexpected end of file -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Marcus Sent: Friday, November 30, 2007 6:34 PM To: Dovecot Mailing List Subject: Re: [Dovecot] locking strategies? On 11/30/2007 Joe Allesi -X (joallesi - Coyote Creek Consulting at Cisco) wrote: Any known issues with these locking strategies? (RHEL 4.x default) Which version of dovecot?
[Dovecot] Received Date vs Date Header
I am trying to figure out why my mail clients are not correctly showing
me the received date versus the date header date. I am using Dovecot
1.1B9. Here is a copy of the rawlog from Dovecot when I started up the
client. Is Dovecot supposed to be sending the received date and the
date header during this conversation?
* OK [RAWLOG TIMESTAMP] 2007-11-30 16:48:31
* NAMESPACE (( .)) NIL NIL
3 OK Namespace completed.
* LSUB () . Junk E-mail
* LSUB () . Deleted Items
* LSUB () . Drafts
* LSUB () . Ham
* LSUB () . INBOX
* LSUB () . Keep Messages
* LSUB () . Mailing Lists
* LSUB () . Sent Items
* LSUB () . Spam
* LSUB () . Other
* LSUB () . Inbox2
* LSUB () . Dovecot
* LSUB () . MIMEDefang
* LSUB () . Beta
* LSUB () . Debian
* LSUB () . Leafnode
* LSUB () . Sendmail
4 OK Lsub completed.
* LIST (\HasNoChildren) . INBOX
5 OK List completed.
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded $MDNSent
Junk NonJu:
nk)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft
$Forwarded $MDNSent Junk NonJunk \*)] Flags permitted.
* 19 EXISTS
* 2 RECENT
* OK [UNSEEN 17] First unseen.
* OK [UIDVALIDITY 1191346544] UIDs valid
* OK [UIDNEXT 7608] Predicted next UID
6 OK [READ-WRITE] Select completed.
* 1 FETCH (FLAGS (\Seen) UID 5)
* 2 FETCH (FLAGS (\Seen) UID 5707)
* 3 FETCH (FLAGS (\Seen) UID 7042)
* 4 FETCH (FLAGS (\Seen) UID 7103)
* 5 FETCH (FLAGS (\Seen) UID 7110)
* 6 FETCH (FLAGS (\Seen) UID 7183)
* 7 FETCH (FLAGS (\Seen) UID 7237)
* 8 FETCH (FLAGS (\Seen) UID 7334)
* 9 FETCH (FLAGS (\Seen) UID 7353)
* 10 FETCH (FLAGS (\Answered \Seen) UID 7355)
* 11 FETCH (FLAGS (\Seen) UID 7364)
* 12 FETCH (FLAGS (\Seen) UID 7482)
* 13 FETCH (FLAGS (\Seen) UID 7485)
* 14 FETCH (FLAGS (\Seen) UID 7496)
* 15 FETCH (FLAGS (\Seen) UID 7546)
:
* 16 FETCH (FLAGS (\Seen) UID 7555)
* 17 FETCH (FLAGS () UID 7605)
* 18 FETCH (FLAGS (\Recent) UID 7606)
* 19 FETCH (FLAGS (\Recent) UID 7607)
7 OK Fetch completed.
* 18 FETCH (UID 7606 RFC822.SIZE 4589 FLAGS (\Recent) BODY[HEADER.FIELDS
(FROM TO CC SUBJECT DATE MESSAGE-ID PRIORITY X-PRIORITY REFERENCES
NEWSGROUPS IN-REPLY-(END)
TO CONTENT-TYPE)] {352}
Date: Fri, 30 Nov 2007 15:24:32 -0800
Subject: x
From: x
To: x
Message-ID: C375DBB0.416E%x
Content-type: text/plain; charset=US-ASCII
)
* 19 FETCH (UID 7607 RFC822.SIZE 4590 FLAGS (\Recent) BODY[HEADER.FIELDS
(FROM TO CC SUBJECT DATE MESSAGE-ID PRIORITY X-PRIORITY REFERENCES
NEWSGROUPS IN-REPLY-TO CONTENT-TYPE)] {353}
Date: Fri, 30 Nov 2007 15:25:23 -0800
Subject: x
From: x
To: x
Message-ID: C375DBE2.416F%x
Content-type: text/plain; charset=US-ASCII
)
8 OK Fetch completed.
+ idling
I am using Maildir and the date and time of those files from ls -l are
2007-11-30 16:48 and 2007-11-30 16:49. The mail client
(Thunderbird) showed the received date/time and date date/time as
2007-11-30 3:24 and 2007-11-30 3:25
Thanks for any help you can offer me.
Jeff
[Dovecot] Tru64 v5.1 with Sia
./configure --with-sia # ./dovecot --build-options Build options: ioloop=poll ipv6 openssl SQL drivers: Passdb: checkpassword passwd passwd-file Userdb: checkpassword passwd prefetch passwd-file static # ./dovecot --version 1.0.8 # ./dovecot -n # 1.0.8: /usr/local/etc/dovecot.conf protocols: pop3 listen: *:10100 ssl_disable: yes disable_plaintext_auth: no login_dir: /usr/local/var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/pop3-login mail_extra_groups: mail mail_executable: /usr/local/libexec/dovecot/pop3 mail_plugin_dir: /usr/local/lib/dovecot/pop3 pop3_uidl_format: %08Xu%08Xv auth default: passdb: driver: passwd userdb: driver: passwd Configuration simplified to determine why authentication is [still] failing. Any assistance would be greatly appreciated.
Re: [Dovecot] last logon time
On Fri, 30 Nov 2007, Nikolay Shopik wrote: Hi list, How can I detect when user last time logon into their mailbox? For what file I should look and compare change time? On the wiki, see: Post-Login Scripting http://wiki.dovecot.org/PostLoginScripting Specifically: Last-login Tracking http://wiki.dovecot.org/PostLoginScripting#line-20 On the list, I know of at least these two threads (since I participated): [Dovecot] Dovceot user pop3 last connect info? http://dovecot.org/list/dovecot/2007-October/025942.html [Dovecot] dovecot.index mtime http://dovecot.org/list/dovecot/2007-November/026585.html Best, Ben
Re: [Dovecot] Zimbra benchmarking
On Fri, Nov 30, 2007 at 01:16:25PM +0200, Timo Sirainen wrote: On Fri, 2007-11-30 at 12:00 +0100, DINH Vi?t Ho? wrote: On Nov 30, 2007 11:38 AM, Timo Sirainen [EMAIL PROTECTED] wrote: Zimbra is apparently building full text search indexes while appending, so this test doesn't mean much until I can test Dovecot's performance with Squat indexing. Hello, in fact, I'm not that much convinced by full-text search index server side. We consider response time, server side full text search will include client-server round-trip. So that, for example, on etpanX, I do some local indexing on the imap folders, so that when the user does a search, it's given in a fraction of second even if the server is slow. I think Mail.app on Mac OS X is doing the same. Yes, and so do many other clients. But FTS indexes are useful for webmails, mobile clients and other clients that don't have a local cache. Squat indexes are going to work so that the first time you do a TEXT or BODY search the indexes are built for the mailbox. After that they most likely are updated when saving new mails (although maybe only with deliver, not with APPEND/COPY?). If user hasn't done any TEXT/BODY searches for a month or so, the indexes finally get deleted. Or that's my plan currently, those rules are easy to change. I (and other users here) have some mail folder archives that go back several years and a number of those folders won't change, I what I was thinking of doing was do a full text search over ALL of the mail I can possibly access, so I will be all set for future fast searches, which might be of interest only once a year. I was thinking after we get dovecot into full production for at least half or a whole year, evaluating the space used by indexes of any type and make a site specific purge script if desired. It sounds like the indexes, if not automatically deleted, will be worth the more or less permanent disk space for us. Sounds like it would be useful as a configurable option.
Re: [Dovecot] SIGSEGV login process
On Fri, 30 Nov 2007 14:47:24 +0200, Timo Sirainen [EMAIL PROTECTED] wrote: On Fri, 2007-11-30 at 10:19 +0300, Maxim Lougovsky wrote: got it: .. #0 0x08054096 in auth_client_request_continue (request=0x0, data_base64=0x808806b ns1 NAMESPACE) at auth-server-request.c:377 377 auth-server-request.c: No such file or directory. in auth-server-request.c So the client sent ns1 NAMESPACE command before Dovecot had finished handling login. I guess this crash was with 1.0.7? I think there's a very good chance that 1.0.8 has fixed this. 10X. i will try it and report about results.
Re: [Dovecot] SIGSEGV login process
On Fri, 2007-11-30 at 10:19 +0300, Maxim Lougovsky wrote: got it: .. #0 0x08054096 in auth_client_request_continue (request=0x0, data_base64=0x808806b ns1 NAMESPACE) at auth-server-request.c:377 377 auth-server-request.c: No such file or directory. in auth-server-request.c So the client sent ns1 NAMESPACE command before Dovecot had finished handling login. I guess this crash was with 1.0.7? I think there's a very good chance that 1.0.8 has fixed this. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Zimbra benchmarking
On Nov 30, 2007 12:00 PM, DINH Viêt Hoà [EMAIL PROTECTED] wrote: On Nov 30, 2007 11:38 AM, Timo Sirainen [EMAIL PROTECTED] wrote: Zimbra is apparently building full text search indexes while appending, so this test doesn't mean much until I can test Dovecot's performance with Squat indexing. Hello, in fact, I'm not that much convinced by full-text search index server side. We consider response time, server side full text search will include client-server round-trip. So that, for example, on etpanX, I do some local indexing on the imap folders, so that when the user does a search, it's given in a fraction of second even if the server is slow. I think Mail.app on Mac OS X is doing the same. By the way, how does Dovecot index the messsages ? Does it do the following ? - when doing the search, it will collect messages that were not indexed - will index those messages - and do the search on the updated index. -- DINH Viêt Hoà
Re: [Dovecot] Zimbra benchmarking
hi, nice test, but what would be also useful to compare cpu and memory usage! with zimbra it's more important then anything else. i'd like to see a comparison what kind of hardware (cpu and memory) required for: 10, 100, 500, 1000, 2000, 5000 mailbox server. this's where dovecot a big winner even for 10 mailbox. but to be fair zimbra is much more than dovecot it's integrate many things (ldap user and group management, samba domain controller, virus scanner, outlook connector (!) not just for email but also for calendar and address book, etc...) and to put together such a system with dovecot it's more than hard and may be impossible. Timo Sirainen wrote: Now that I have a working kvm setup, I thought I'd finally try how Zimbra works. This is mainly some microbenchmarking, so it may not have much to do with actual performance in real life. Setup: - 1GB memory given to kvm (from host's 2GB) - Intel Core 2 6600 (kvm uses only one CPU) - CentOS 5 - 15GB qcow2 image on XFS filesystem - Zimbra 5.0 RC2 RHEL5 x86_64 - Dovecot latest hg, dbox format Both Zimbra and Dovecot were tested running on the same kvm image. All data could be cached in memory, so this didn't really test disk I/O. Dovecot was run with fsync_disable=no. Running with =yes would have made its performance even better. Zimbra features/bugs Zimbra's SEARCH command doesn't support substring searching as IMAP requires: 1 search text performance * SEARCH 136 183 227 231 232 233 245 1 OK SEARCH completed 2 search text erformance * SEARCH 2 OK SEARCH completed 3 search text performanc * SEARCH 3 OK SEARCH completed It's possible to search performanc in a non-standard way though: 4 search text performanc* * SEARCH 136 183 227 231 232 233 245 4 OK SEARCH completed This means that the upcoming Dovecot v1.1 is probably the only IMAP server that supports IMAP-compatible full text search indexes with incremental updates. (Cyrus Squat requires rebuilding the whole index from scratch just for adding one mail, which makes it kind of impractical.) Zimbra doesn't support SORT or THREAD extensions. I had trouble benchmarking more than 5 simultaneous connections in one mailbox. I'm not sure if this is a configurable setting somewhere, or if there's just some bug. The error messages that my imaptest gave looked like Zimbra was buggy, but I didn't look at them too closely. STORE command also seemed to be buggy, giving lots of STORE failed errors, even with just one connection. Zimbra uses 500MB of memory just to start up, so it's not exactly for hosting small installations. Login+Logout Dovecot: ./imaptest - select=0 secs=10 seed=0 clients=1 Logi Logo 100% 100% 3439 6878 ./imaptest - select=0 secs=10 seed=0 clients=10 Logi Logo 100% 100% 4415 8830 Zimbra: ./imaptest - select=0 secs=10 seed=0 clients=1 Logi Logo 100% 100% 18032 36064 ./imaptest - select=0 secs=10 seed=0 clients=10 Logi Logo 100% 100% 25519 51056 Looks like Dovecot's imap process creation hurts it a lot compared to Zimbra's thread creation. Luckily IMAP connections are usually long-living, so this shouldn't matter much, except for webmails for which you can use imapproxy in the middle. LIST * - Dovecot: ./imaptest - select=0 logout=0 list=100 secs=10 seed=0 clients=1 Logi List 100% 100% 1 181411 ./imaptest - select=0 logout=0 list=100 secs=10 seed=0 clients=10 Logi List 100% 100% 10 133451 Zimbra: ./imaptest - select=0 logout=0 list=100 secs=10 seed=0 clients=1 Logi List 100% 100% 1 1021 ./imaptest - select=0 logout=0 list=100 secs=10 seed=0 clients=10 Logi List 100% 100% 10 972 Yes, Dovecot's LIST is over 100 times faster. STATUS INBOX (MESSAGES UNSEEN RECENT) - 100 messages in INBOX dovecot: ./imaptest - logout=0 select=0 status=100 secs=10 seed=0 clients=1 Logi Stat 100% 100% 1 191003 ./imaptest - logout=0 select=0 status=100 secs=10 seed=0 clients=10 Logi Stat 100% 100% 10 171171 Zimbra: ./imaptest - logout=0 select=0 status=100 secs=10 seed=0 clients=1 Logi Stat 100% 100% 1 3697 ./imaptest - logout=0 select=0 status=100 secs=10 seed=0 clients=10 Logi Stat 100% 100% 10 7009 FETCH 1:* (UID FLAGS ENVELOPE INTERNALDATE BODYSTRUCTURE) - 100 messages in INBOX. dovecot: ./imaptest - logout=0 select=100 fetch=100 secs=10 seed=0 clients=1 Logi Sele Fetc 100% 100% 100% 11 2769 ./imaptest - logout=0 select=100 fetch=100 secs=10 seed=0 clients=5 Logi Sele Fetc 100% 100% 100% 55 2902 Zimbra: ./imaptest - logout=0 select=100 fetch=100 secs=10 seed=0 clients=1 Logi Sele Fetc 100% 100% 100% 11 203 ./imaptest - logout=0 select=100 fetch=100 secs=10 seed=0 clients=5 Logi Sele Fetc 100%
Re: [Dovecot] locking strategies?
On 11/30/2007 Joe Allesi -X (joallesi - Coyote Creek Consulting at Cisco) wrote: Any known issues with these locking strategies? (RHEL 4.x default) Which version of dovecot?
[Dovecot] Zimbra benchmarking
Now that I have a working kvm setup, I thought I'd finally try how Zimbra works. This is mainly some microbenchmarking, so it may not have much to do with actual performance in real life. Setup: - 1GB memory given to kvm (from host's 2GB) - Intel Core 2 6600 (kvm uses only one CPU) - CentOS 5 - 15GB qcow2 image on XFS filesystem - Zimbra 5.0 RC2 RHEL5 x86_64 - Dovecot latest hg, dbox format Both Zimbra and Dovecot were tested running on the same kvm image. All data could be cached in memory, so this didn't really test disk I/O. Dovecot was run with fsync_disable=no. Running with =yes would have made its performance even better. Zimbra features/bugs Zimbra's SEARCH command doesn't support substring searching as IMAP requires: 1 search text performance * SEARCH 136 183 227 231 232 233 245 1 OK SEARCH completed 2 search text erformance * SEARCH 2 OK SEARCH completed 3 search text performanc * SEARCH 3 OK SEARCH completed It's possible to search performanc in a non-standard way though: 4 search text performanc* * SEARCH 136 183 227 231 232 233 245 4 OK SEARCH completed This means that the upcoming Dovecot v1.1 is probably the only IMAP server that supports IMAP-compatible full text search indexes with incremental updates. (Cyrus Squat requires rebuilding the whole index from scratch just for adding one mail, which makes it kind of impractical.) Zimbra doesn't support SORT or THREAD extensions. I had trouble benchmarking more than 5 simultaneous connections in one mailbox. I'm not sure if this is a configurable setting somewhere, or if there's just some bug. The error messages that my imaptest gave looked like Zimbra was buggy, but I didn't look at them too closely. STORE command also seemed to be buggy, giving lots of STORE failed errors, even with just one connection. Zimbra uses 500MB of memory just to start up, so it's not exactly for hosting small installations. Login+Logout Dovecot: ./imaptest - select=0 secs=10 seed=0 clients=1 Logi Logo 100% 100% 3439 6878 ./imaptest - select=0 secs=10 seed=0 clients=10 Logi Logo 100% 100% 4415 8830 Zimbra: ./imaptest - select=0 secs=10 seed=0 clients=1 Logi Logo 100% 100% 18032 36064 ./imaptest - select=0 secs=10 seed=0 clients=10 Logi Logo 100% 100% 25519 51056 Looks like Dovecot's imap process creation hurts it a lot compared to Zimbra's thread creation. Luckily IMAP connections are usually long-living, so this shouldn't matter much, except for webmails for which you can use imapproxy in the middle. LIST * - Dovecot: ./imaptest - select=0 logout=0 list=100 secs=10 seed=0 clients=1 Logi List 100% 100% 1 181411 ./imaptest - select=0 logout=0 list=100 secs=10 seed=0 clients=10 Logi List 100% 100% 10 133451 Zimbra: ./imaptest - select=0 logout=0 list=100 secs=10 seed=0 clients=1 Logi List 100% 100% 1 1021 ./imaptest - select=0 logout=0 list=100 secs=10 seed=0 clients=10 Logi List 100% 100% 10 972 Yes, Dovecot's LIST is over 100 times faster. STATUS INBOX (MESSAGES UNSEEN RECENT) - 100 messages in INBOX dovecot: ./imaptest - logout=0 select=0 status=100 secs=10 seed=0 clients=1 Logi Stat 100% 100% 1 191003 ./imaptest - logout=0 select=0 status=100 secs=10 seed=0 clients=10 Logi Stat 100% 100% 10 171171 Zimbra: ./imaptest - logout=0 select=0 status=100 secs=10 seed=0 clients=1 Logi Stat 100% 100% 1 3697 ./imaptest - logout=0 select=0 status=100 secs=10 seed=0 clients=10 Logi Stat 100% 100% 10 7009 FETCH 1:* (UID FLAGS ENVELOPE INTERNALDATE BODYSTRUCTURE) - 100 messages in INBOX. dovecot: ./imaptest - logout=0 select=100 fetch=100 secs=10 seed=0 clients=1 Logi Sele Fetc 100% 100% 100% 11 2769 ./imaptest - logout=0 select=100 fetch=100 secs=10 seed=0 clients=5 Logi Sele Fetc 100% 100% 100% 55 2902 Zimbra: ./imaptest - logout=0 select=100 fetch=100 secs=10 seed=0 clients=1 Logi Sele Fetc 100% 100% 100% 11 203 ./imaptest - logout=0 select=100 fetch=100 secs=10 seed=0 clients=5 Logi Sele Fetc 100% 100% 100% 55 258 FETCH ? (BODY[]) Randomly fetch message body from 100 messages Dovecot: ./imaptest - logout=0 select=100 fetch2=100 secs=10 seed=0 clients=1 Logi Sele Fet2 100% 100% 100% 30% 11 51958 ./imaptest - logout=0 select=100 fetch2=100 secs=10 seed=0 clients=5 Logi Sele Fet2 100% 100% 100% 30% 55 141397 Zimbra: ./imaptest - logout=0 select=100 fetch2=100 secs=10 seed=0 clients=1 Logi Sele Fet2 100% 100% 100% 30% 11 410 ./imaptest - logout=0 select=100 fetch2=100 secs=10 seed=0 clients=5 Logi Sele Fet2 100% 100% 100% 30% 55 2291 STORE ? FLAGS.SILENT (random flags and keywords) Dovecot: ./imaptest - logout=0 select=100 store=100 secs=10 seed=0
Re: [Dovecot] Zimbra benchmarking
On Nov 30, 2007 11:38 AM, Timo Sirainen [EMAIL PROTECTED] wrote: Zimbra is apparently building full text search indexes while appending, so this test doesn't mean much until I can test Dovecot's performance with Squat indexing. Hello, in fact, I'm not that much convinced by full-text search index server side. We consider response time, server side full text search will include client-server round-trip. So that, for example, on etpanX, I do some local indexing on the imap folders, so that when the user does a search, it's given in a fraction of second even if the server is slow. I think Mail.app on Mac OS X is doing the same. -- DINH Viêt Hoà
[Dovecot] deliver+quota assertion
When stressing dovecot's delivery agent, I sporadically encountered the following assertion failures and the associated errors. I was trickling in ~50 messages per minute to this mailbox via postal. Nov 30 09:38:41 mail deliver([EMAIL PROTECTED]): close(/home/vmail/domains//+/example.com/k/example//Maildir/maildirsize) failed: Bad file descriptor Nov 30 09:38:41 mail deliver([EMAIL PROTECTED]): rename(/home/vmail/domains//+/example.com/k/example//Maildir/maildirsize.lock, /home/vmail/domains//+/example.com/k/example//Maildir/maildirsize) failed : No such file or directory Nov 30 09:38:41 mail deliver([EMAIL PROTECTED]): file_dotlock_replace(/home/vmail/domains//+/example.com/k/example//Maildir/maildirsize) failed: No such file or directory Nov 30 09:38:41 mail deliver([EMAIL PROTECTED]): Internal quota calculation error Nov 30 09:38:41 mail deliver([EMAIL PROTECTED]): file index-transaction.c: line 54 (index_transaction_finish_rollback): assertion failed: (t-mail_ref_count == 0) Nov 30 09:38:41 mail deliver([EMAIL PROTECTED]): Raw backtrace: /usr/lib/dovecot/deliver(i_syslog_fatal_handler+0x2b) [0x80bf0ab] - /usr/lib/dovecot/deliver [0x80beeba] - /usr/lib/dovecot/deliver [0x 808f243] - /usr/lib/dovecot/deliver(index_transaction_rollback+0x1a) [0x808f06a] - /usr/lib/dovecot/modules/lda/lib10_quota_plugin.so [0xb7ea2f13] - /usr/lib/dovecot/deliver(deliver_save+0x212) [0x8059412] - /usr/lib/dovecot/deliver(main+0x12cb) [0x805a79b] - /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xc8) [0xb7ebcea8] - /usr/lib/dovecot/deliver [0x8058611] # dovecot -n # 1.1.beta9: /etc/dovecot/dovecot.conf base_dir: /var/run/dovecot/ protocols: imap imaps pop3 pop3s login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login login_greeting: Nationwide Internet Mail Server ready. verbose_proctitle: yes first_valid_uid: 89 last_valid_uid: 89 first_valid_gid: 89 last_valid_gid: 89 mail_uid: 89 mail_gid: 89 mail_location: maildir:/home/vmail/domains/%h/Maildir mail_debug: yes mmap_disable: yes mail_nfs_storage: yes mail_nfs_index: yes lock_method: dotlock mail_executable(default): /usr/lib/dovecot/rawlog /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/rawlog /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 imap_client_workarounds(default): delay-newmail imap_client_workarounds(imap): delay-newmail imap_client_workarounds(pop3): pop3_uidl_format(default): %08Xu%08Xv pop3_uidl_format(imap): %08Xu%08Xv pop3_uidl_format(pop3): %f pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh auth default: mechanisms: login plain cram-md5 digest-md5 username_format: %Lu verbose: yes debug: yes passdb: driver: sql args: /etc/dovecot/dovecot-sql.conf userdb: driver: sql args: /etc/dovecot/dovecot-sql.conf socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail group: vmail plugin: quota: maildir quota_rule: *:storage=102400 This is the latest hg sources, somewhat after beta9: $ hg tip changeset: 6877:a5a7d38b6df7 branch: HEAD tag: tip user:Timo Sirainen [EMAIL PROTECTED] date:Thu Nov 29 19:38:06 2007 +0200
[Dovecot] locking strategies?
Any known issues with these locking strategies? (RHEL 4.x default) Dovecot: mbox_locks = fcntl Procmail Locking strategies: dotlocking, fcntl() We're considering moving to all dotlocking after a recommendation from RedHat, even though we're not using NFS at all. Thanks!
