>In fact, 100 000 users represent more or less 600 000 folders &
> subfolders. The choice of murder is high availability, even if one
> backend falls down, only 25% of the users will loose the mail service.
I see.
> Any idea on optimizing Berkeley DB cache?
I assume reading berkeley
> John Madden wrote:
>>>I have to deal with increasing charge of by now 500 users that will grow
>>>up to 100 000.
>>>All mailboxes exist, for a 65Mb mailboxes.db on mupdate
>>
>> Is murder even necessary for such a configuration? Based on the numbers
>> on Cyrus'
>> pages, I assumed 200k accounts
In fact, 100 000 users represent more or less 600 000 folders &
subfolders. The choice of murder is high availability, even if one
backend falls down, only 25% of the users will loose the mail service.
Each server has 2 CPU & 5 GB RAM.
Any idea on optimizing Berkeley DB cache?
Laurent.
Joh
John Madden wrote:
I have to deal with increasing charge of by now 500 users that will grow
up to 100 000.
All mailboxes exist, for a 65Mb mailboxes.db on mupdate
Is murder even necessary for such a configuration? Based on the numbers on
Cyrus'
pages, I assumed 200k accounts on one big, beefy
> I have to deal with increasing charge of by now 500 users that will grow
> up to 100 000.
> All mailboxes exist, for a 65Mb mailboxes.db on mupdate
Is murder even necessary for such a configuration? Based on the numbers on
Cyrus'
pages, I assumed 200k accounts on one big, beefy box would be ok
Hello,
running CyrusIMAP 2.2.8 on Debian Sarge, with a murder of 2 frontends &
3 backends, (4 & 4) at the end.
I have to deal with increasing charge of by now 500 users that will grow
up to 100 000.
All mailboxes exist, for a 65Mb mailboxes.db on mupdate
1- Mupdate slows down informing Frontend
