Hi,
What is I/O load on the new server? on the old server? Was your test set
representative of your production system?
the test system has much older hardware than the pretty new production
server (Xeon 3.4 with RAID5 and SCSI HDs). Old and new server are the
same from the hardware side, we have just changed the software.
You could be running into any number of bottlenecks that you've not
described:
1) disk I/O
2) network I/O
Even syncing from an IMAP server in the internet to my local server was
faster.
3) message size
4) file system format
I guess its none of them. uptime shows
21:04:59 up 1 day, 5:46, 7 users, load average: 29.10, 43.29, 41.94
I can easily copy large amounts of files within the system, so it is
definetely not a problem of the filesystem. Syncing is always slow, of
course large mails take a bit longer, but that isn't the bottleneck.
The question is: What is Cyrus doing in the background when doing an
APPEND in IMAP (I guess thats the way new messages are added)? When I
can copy 20 files within a second in the filesystem, but only 1 in three
seconds through IMAP, whats wrong then?
So both the maildir server and the Cyrus server are on the same box?
We tried both: syncing from the same box or from one to another. It was
slow in both cases.
Do
their spools share the disks? Controllers? How many users? How many
connections? How much mail?
At this moment it is evening here, so there aren't many deliveries
(about 90 per minute).
I guess that the bottleneck is somewhere in Cyrus. We are using
cyrus-imapd-2.2.12 from RHEL4. Is there a problem with berkeley db with
large mailboxes.db? What is Cyrus doing during an IMAP APPEND? Is it
always looking for the folder in mailboxes.db? Is it sync'ing the
harddisk after each APPEND?
You need to better understand the limits of your system. Yes your
development system was fast, but it sounds like you didn't try to
replicate the load of doing everything at once on it, so your
expectations have been set artifically.
Our old way to deliver mails sort of broke down, so we urgently needed a
replacement. We worked on Cyrus for some weeks so we knew enough to
build the right configuration, but we didn't had the time to do a
stresstest.
Regards
Marten
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
