similar to: Dovecot imaptest on RHEL4/GFS1, RHEL6/GFS2, NFS and local storage results

I thought I'd try benchmarking with dbmail (v2.2.4) to see how much slower a SQL backend could actually be. Skip to bottom for the conclusions. Originally I ran the tests with the databases being in XFS filesystem. MySQL's performance was horrible. It went 3-7x faster with ext3. MySQL 5.0.30 backend (innodb): ./imaptest clients=1 - append=100 seed=1 secs=30 msgs=1000000 logout=0

http://dovecot.org/patches/1.1/maildir-dirty-syncs.diff This patch adds a new maildir_very_dirty_syncs setting. If set to "yes", Dovecot assumes it's the only one changing the cur/ directory (so other MDAs can add mails to new/ without problems). This makes it possible to avoid rescanning the cur/ directory all the time looking for filenames. It also looks like (in stress testing)

Greetings - I've now got as far as playing with the imaptest10 test utility to see if I can stress-test our development server. imaptest10 is built against dovecot-1.0rc28 It may just be that I'm excessively heavy handed, but when I let imaptest10 rip with the command... ./imaptest10 user=test%03d host=testserver.imap.york.ac.uk clients=50 mbox=./dovecot.mbox msgs=1000 secs=30

dovecot-1.1.beta16]# gcc imaptest.c -o imaptest -g -Wall -W -I. -Isrc/lib-mail -Isrc/lib -Isrc/lib-imap -Isrc/lib-storage/index/mbox -DHAVE_CONFIG_H src/lib-storage/index/mbox/mbox-from.o src/lib-imap/libimap.a src/lib-mail/libmail.a src/lib/liblib.a imaptest.c: In client_append function: imaptest.c:1492: error: too many arguments for i_stream_create_limit function

v1.1 plans have changed a bit. I'll release v1.1.alpha1 soon and hope to have a stable v1.1 in a month or two. The rest of the features that didn't make it into v1.1 will go to v1.2. I'll write more about this when v1.1 alpha is released. I also did a bit of benchmarking. v1.1's performance improvements are looking pretty great, it seems to be twice as fast as v1.0. v1.0:

Hi, The measurements were created under the following conditions : ? operating system : Red Hat Enterprise Linux Server release 6.6 (Santiago) kernel in version 2.6.32-504.el6.x86_64 ? virtual server (VMware) with an Intel(R) Xeon(R) 4vCPU E5649 x 2,526 GHz (2 cores per virtual socket) and 4 GB RAM ? 7,200 RPM SATA 1TB (FC SAN IBM System Storage N3400) ? all file systems had been formated in

I wasted too much time today doing this, but they do show a few interesting things: 1) mmap_disable=yes is faster than mmap_disable=no. I didn't expect this. I'm not yet sure why this is, but possibly because then it updates the mail index by reading the changes from dovecot.index.log, instead of reopening and re-mmaping dovecot.index. At least that's the biggest difference between

Some new features in CVS HEAD are: - v1.0 saves most of the data to dovecot.index.cache only when the client is FETCHing the messages. With mboxes the message headers are saved while parsing the mbox, which is almost the same thing. With CVS HEAD the dovecot.index.cache file is updated already when the new messages are being saved (with deliver or IMAP APPEND). This avoids reading the message

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,

Hi, all this days I'm testing a dovecot setup using lvs, director and a cluster email backend with two nodes using rhel5 and gfs2. In the two nodes of the email backend I configured mail location this way: mail_location = sdbox:/var/vmail/%d/%3n/%n/sdbox:INDEX=/var/indexes/%d/%3n/%n /var/vmail is shared clustered filesystem with GFS2 shared by node1 and node2 /var/indexes is a local

I cleaned up the lib-storage code a bit so that it's easier to write support for new mailbox formats. It could still use a bit of cleaning up. Anyway, I thought I'd try how easy it would be to implement Cyrus-like mail store which would consist of only Dovecot's index files and "<uid>." message files. Flags and everything else is kept only in Dovecot's index files

I've been doing some stress testing in the last few days and fixing all the errors I saw. I'm hoping that I've finally really fixed all the index/mbox problems. So, again I think the only thing left for v1.0 is the documentation. Please test this nightly snapshot before I'll release rc27 tomorrow: http://dovecot.org/nightly/dovecot-latest.tar.gz If you've seen any of the

Today I will try Dovecot Director for a setup using a Cluster Backend with GFS2 on rhel5, my question is if is Director stable for use in production for large sites, I know is mainly designed for NFS but I believe it will do the job also for a cluster filesystem like GFS2 and should solve the mail persistence problem with a node and locking issues. I plan to add a layer behind a load balancer to

Centos CSGFS is at this time really outdated compared to current rh updates and fixes, is the centos team still giving support to this version???. Best regards

Hi All, We're on migration stage to a new 2-node active/active cluster with shared iSCSI storage,? everything is ready, but we are in the process of I/O testing, before we going to in production. Cluster info: 2 nodes with CentOS 7.4 balancer ( keepalived + ldirectord ), 2 dovecot directors, 2 dovecot IMAP backends, 2 Postfix SMTP, gfs2 ( corosync + dlm ), LMTP between Postfix and Dovecot

Hi to all in the list, we are trying to do some tests lab for a large scale mail system having this requirements: - Scale to maybe 1million users(Only for testing). - Server side filters. - User quotas. - High concurrency. - High performance and High Availability. We plan to test this using RHEL5 and maybe RHEL6. As a storage we are going to use an HP EVA 8400 FC(8 GB/s) We defined this

Hello list, we continue our tests using Dovecot on a RHEL 6.1 Cluster Backend with GFS2, also we are using dovecot as a Director for user node persistence, everything was ok until we started stress testing the solution with imaptest, we had many deadlocks, cluster filesystems corruptions and hangs, specially in index filesystem, we have configured the backend as if they were on a NFS like setup

The biggest problem with getting v1.0 out was getting its index file code stable. v1.1 plans included doing large changes to the index file code, so it's important to get the new code stable as soon as possible. Since I've managed to stay pretty productive for the last few weeks, I've been mostly just coding the index changes. Once I'm sure that the code is again fully working

Hi list, I want to test performance of dovecot-1.0.5 on OpenBSD and FreeBSD. I want to implement a small pop3s/imaps server with ~3000 users. I had tested dovecot-1.0.5 with vpopmail+mysql but I don't know if the performance is ok. Anybody have test with imaptest? OpenBSD 4.1 amd64 SMP dovecot-1.0.5 vpopmail-5.4.22 ./imaptest seed=1 secs=60 Totals: Logi List Stat Sele Fetc Fet2 Stor Dele

Hi list, I've been trying to update my csgfs stuff to 4.7 this week but I notice that current csgfs is built against kernel-2.6.9-78.0.1 and is required as a dependence, right now current kernel is 2.6.9-78.0.5 it would be great if csgfs can be rebuilt or updated to this, so dependences works ok??? Best regards