Yeah, that's a good point. I use sync_batch_size of 100,000.
Regarding the original question, there are other operations that will
exhaust memory as well. We've had two recent reports of Thunderbird
users who unexpectedly developed extremely large cyrus.* files in
their trash. Since cyru
On 18 Apr 2007, at 01:27, Simon Matter wrote:
I'm still wondering why the code is there, can anybody comment on
this?
The buffer in question is dynamically sized. I gather that an
earlier version of the code pre-allocated 5 paths. A later version
allowed an arbitrary number, adjusting th
On Tue, Apr 17, 2007 at 04:28:04PM -0400, Wesley Craig wrote:
> You probably encountered a single very large mailbox. This patch:
>
> --- cyrus-imapd-2.3.8/imap/sync_support.c 2006-11-30
> 12:11:20.0 -0500
> +++ cyrus-imapd-2.3.8p3/imap/sync_support.c 2007-04-12
> 13:27:49.0
> You probably encountered a single very large mailbox. This patch:
>
> --- cyrus-imapd-2.3.8/imap/sync_support.c 2006-11-30
> 12:11:20.0 -0500
> +++ cyrus-imapd-2.3.8p3/imap/sync_support.c 2007-04-12
> 13:27:49.0 -0400
> @@ -914,9 +914,9 @@
> result = xzmalloc(sizeof(s
Wesley Craig wrote:
You probably encountered a single very large mailbox. This patch:
Thanks for the patch, applied it, rebuilt and wiped out test replica
config and spool. One puzzling thing so far: At first try, rolling
replication started "by itself", replicating the complete spool. At thi
You probably encountered a single very large mailbox. This patch:
--- cyrus-imapd-2.3.8/imap/sync_support.c 2006-11-30
12:11:20.0 -0500
+++ cyrus-imapd-2.3.8p3/imap/sync_support.c 2007-04-12
13:27:49.0 -0400
@@ -914,9 +914,9 @@
result = xzmalloc(sizeof(struct sync_messa
After performing an initial sync of 65G worth of mailboxes the above
error occurred. I kept an eye on the process initally but saw nothing
worrying, then it died about halfway through the sync.
Could I have hit some system limits? Vanilla FreeBSD 6.2.
I'm starting off fresh now again to try to
