Hi Maurizo,
Technically, even if you were using duplicate suppression it would not
be a huge loss to store it on a local filesystem.
You don't usually see duplicate id's unless someone's MTA goes
bonkers; or their MUA is stupid; oh and SPAM.
So yeah go for it, that'll save you a good deal of
> > Using the flat configuration for the mailbox.db the slow start
> > disapepars. May I use a flat database for 4300+ mailbox?
> > Do you think I could have other performance problems in
> > delivery/accessing the mailbox?
>
> I considered creating a GFS spool for a 5 mailbox system, but durin
On Mon, May 19, 2008 at 10:48:32AM +0200, Maurizio Lo Bosco wrote:
> Hi all,
> Bron has analysed the problem of the low start and it seams due to the
> locking
> on the mailbox.db for each mailbox. Something like
> //for mailbox in $mailbox_list
> // lock mailbox
> // do something
> // unlo
Hi all,
Bron has analysed the problem of the low start and it seams due to the locking
on the mailbox.db for each mailbox. Something like
//for mailbox in $mailbox_list
// lock mailbox
// do something
// unlock
The lock/unlock seams to be a bottleneck for the GFS.
Using the flat configurat
If you wish to do load balancing,
I suggest looking at nginx.
For documentation ... http://wiki.codemongers.com/Main
I don't have a lot of experience with GFS1 or OCFS, however I don't
expect great performance. I would imagine worse then ext3 or about
the same is the best you will be able
> Given that he's got two machines, I might suggest mupdate_config:
> replicated and definitely have mailboxes.db on local disk.
I'm taking a look at the configuration of the mupdate replicated architecture.
As stated in an old post on this list (20-Dec-2005), the Cyrus 2.3 replicated
configurati
Scott Likens wrote:
> Can someone please remove this user from the list?
Done.
Thanks,
Dave
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
I try to reply to every one.
Bron, that's the cyrus log on a start.
-
May 14 16:41:55 ariel master[28238]: process started
May 14 16:41:55 ariel master[28240]: about to
exec /usr/lib/cyrus-imapd/ctl_cyrusdb
May 14 16:41:56 ariel ctl_cyrusdb[28240]: recovering cyrus databases
M
Can someone please remove this user from the list?
...
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: May 14, 2008 12:57:34 PM PDT
To: "Scott Likens" <[EMAIL PROTECTED]>
Subject: NDN: Re: Cyrus - GFS slow start and poor performace
Sorry. Your message could not
Going to toss in my 10 cents.
I'm assuming the GFS is the same lun/id on both servers, and you are
using GFS to read-write between 2 or more servers.
You could try OCFS2 instead of GFS... Other then that the only thing I
can think of is using DRBD in a read-write configuration. However
tha
Given that he's got two machines, I might suggest mupdate_config:
replicated and definitely have mailboxes.db on local disk.
:wes
On 14 May 2008, at 06:30, Bron Gondwana wrote:
> Depending on your requirements, it may make sense to place your
> mailboxes.db on local
> disk (it's pretty small)
On Wed, 14 May 2008 10:59:33 +0200, "Maurizio Lo Bosco" <[EMAIL PROTECTED]>
said:
> Hi all,
> I know that the usage of the GFS has been discussed for long time on this
> mailing list but I would like to know if it is normal to have a very slow
> start (15 minutes) with just 4300 users (the cyru
[reply number 2 - addressing bits I missed in the first reply...]
On Wed, 14 May 2008 10:59:33 +0200, "Maurizio Lo Bosco" <[EMAIL PROTECTED]>
said:
> The dump of the database takes 7 minutes but the disk usage is definitely
> low
> (less than 5%)
A dump of the database visits all records in alp
Hi all,
I know that the usage of the GFS has been discussed for long time on this
mailing list but I would like to know if it is normal to have a very slow
start (15 minutes) with just 4300 users (the cyrus db is composed of 20940
lines).
It happens only with the GFS and the skiplist database; u
14 matches
Mail list logo
