Thanks, but we did ran teste in the disks, and the problem was find file, not actuly writing or reading them, so we guess is a ofs2 problem, thats why now we are thinking in mdbox, to reduce the "find files" problem one thing that realy helped the performance was give lots of ram in the virtual machines where dovecot is running, with lots of ram, the kernel makes cache of "location" and it finds much faster the files. As matter fact the space provide to us, we might have to give back some of it. Buying hardware is not an option yet. So we keep thinking how to imprive performance tunning everything up.
I am thinking of chancge io schelduler also. But have not research a lot to try this yet, but it is in the plans.
The backup problem is because the machine that backups ( it joins the ocfs2 cluester just to backup files ) we are not able to make cache. Cause as much as we give RAM the bacula just eat up all ram we gave. I guess it is because of accurate option, still find a way to limit bacule ram use, so the kernel became able to cache some inodes.
Thanks for your reply and i am glad you remembered that old posts.
But i still looking for some info about mdbox.
Before we thought of using mdbox but we did not want to stick with dovecot, i mean, we like the ideia we could be able to change the imap server and etc. But as someone said, what are the other choises we have for opensource imap server ? Even with cyrus we still need to come acroos a big convertion, so it does not make much diference.
About the index files you said, SSD disks are not an possibility, but i though of using another partition as place for index files. Does it will make lot of diference ? As i said, we are using ldiretord with lbrlc that keeps track of ip address to some servers, is not ALWASY send it to the same server, but i tries to do it.
[]'sf.rique
On Sun, Apr 10, 2011 at 5:54 PM, Stan Hoeppner <stan@hardwarefreak.com>wrote:
Henrique Fernandes put forth on 4/10/2011 12:29 PM:
We are using dovecot 2.0.6 with maildir in an ocfs2 partiton.
It is pretty slow access in peak time, but it is related to ocfs2 as i said before, i am trying to mimimize the ocfs2 latancy by using mdbox. Another problem that we have are Full backup that takes about 24h and incremental takes about 13h
Last you posted here you didn't have enough spindles in the array for the size of the workload, and you didn't have a dedicated quality GbE switch for strictly OCFS traffic between Dovecot hosts. Has any of this been rectified? If not, changing mailbox formats isn't going to fix your problems. If you really want to test this theory to the limit, converting to mbox (yes, good old mbox, without the d) will reduce metadata load more than mdbox, by a huge margin.
Given the constraints on your ability to reconfigure the disks in the EMC array (as someone else owns it and you're borrowing space) to meet your needs, and your apparent lack of funding allowing purchasing your own array, the things you should really do to fix most of your problems are:
- Stick with maildir
- Configure a Dovecot director box to achieve stickiness
- Put a quality 200GB SSD drive in each Dovecot IMAP server (smaller if you can get away with it to save $$, larger if if 200GB isn't enough)
- Change the index location on each server to the local SSD drive
Over time the user indexes will be gradually rebuilt onto the local fast SSD drive. This will eliminate the bulk of the IOPS load on OCFS, and should fix your performance issues pretty thoroughly. Well, except for the slow backup. The only way around that is more spindles in the EMC array LUN where mailboxes reside.
-- Stan