0
munmap(0x3390, 790528) = 0
mmap2(NULL, 682827776, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = -1 ENOMEM (Cannot allocate memory)
fatal error: Virtual memory exhausted
So it really tries to allocate a rather large chunk! I guess that's one
more reason to swit
On Mon, Jul 13, 2009 at 02:09:40PM +0200, Sebastian Hagedorn wrote:
> >4 GB limit of 32 bit binaries?
>
> Perhaps, although I haven't seen it.
That's only 3GB by default, 1GB of address space is reserved for the
kernel. Also, the stack, the executable, and all the shared libraries
the executable
--On 13. Juli 2009 14:53:31 +0200 Pascal Gienger
wrote:
Sebastian Hagedorn schrieb:
fatal error: Virtual memory exhausted
Of course it's possible that it then tried to allocate one huge chunk,
but I can't see that. Are there better tools to monitor the memory
allocation of
Sebastian Hagedorn schrieb:
>>> fatal error: Virtual memory exhausted
> Of course it's possible that it then tried to allocate one huge chunk,
> but I can't see that. Are there better tools to monitor the memory
> allocation of a process?
Swap file/partition f
--On 13. Juli 2009 13:20:42 +0200 Pascal Gienger
wrote:
Sebastian Hagedorn schrieb:
Processing index character 101, 681642 total words, temp file size is
2107147
fatal error: Virtual memory exhausted
4 GB limit of 32 bit binaries?
Perhaps, although I haven't seen it.
How much RAM
Sebastian Hagedorn schrieb:
> Processing index character 101, 681642 total words, temp file size is
> 2107147
> fatal error: Virtual memory exhausted
4 GB limit of 32 bit binaries?
How much RAM does squatter allocate before it dies?
--
Pascal Gienger
University of Konstanz, IT
, 140247 total words, temp file size is 457214
Processing index character 99, 243003 total words, temp file size is 782841
Processing index character 100, 262183 total words, temp file size is 833170
Processing index character 101, 681642 total words, temp file size is
2107147
fatal error: Virtual
lock_vec_cyrus_imapd_db (dbenv=0x823dac0,
locker=2149230760, flags=0, list=0xbfcc4be0, nlist=2,
-Message d'origine-
De : Bron Gondwana [mailto:[EMAIL PROTECTED]
Envoyé : mardi 25 mars 2008 23:28
À : Brasseur Valery; info-cyrus@lists.andrew.cmu.edu
Objet : Re: ctl_mboxlist virtual memo
On Tue, 25 Mar 2008 09:31:40 +0100, "Brasseur Valery" <[EMAIL PROTECTED]> said:
> Hi,
>
> I am running 2.3.11, with 2 Millions users (4M mailboxes ;-)
>
> when trying to do a ctl_mboxlist -m, after some time (a few second !) I
> got a "virtual memory exh
Hi,
I am running 2.3.11, with 2 Millions users (4M mailboxes ;-)
when trying to do a ctl_mboxlist -m, after some time (a few second !) I got a
"virtual memory exhausted", and i can see that the process is allocating more
than 3Gb of memory !
did some of you encontered this ?
any way
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
penSSL 0.9.7d 17 Mar
2004; Running w/OpenSSL 0.9.7d 17 Mar 2004; CMU Sieve 2.2; mmap =
nommap; lock = fcntl; nonblock = fcntl; auth = unix; idle = idled")
2 OK Completed
3 select nntp.name.of.that.newsgroup
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Seen)]
*
On Fri, 2004-07-16 at 22:40, andrey wrote:
> When doing ctl_mboxlist -m we see: Fatal error: Virtual memory exhausted
> The size of mailboxes.db is 57 Mb. If anyone know the reason and the way of solving
> this problem?
> Thanks. OS FreeBSD 4.10
Perhaps check your ulimit to see what
When doing ctl_mboxlist -m we see: Fatal error:
Virtual memory exhausted
The size of mailboxes.db is 57 Mb. If anyone know the reason and the way of
solving this problem?
Thanks. OS FreeBSD 4.10
Andrey
Semakin
Good day.
When doing ctl_mboxlist -m we see: Fatal error:
Virtual memory exhausted
The size of mailboxes.db is 57 Mb. If anyone know the reason and the way of
solving this problem?
Thanks.
Andrey Semakin
removeflag "\\Flagged";
> }
>
>
> It is generated by Horde Ingo. lmtpd breaks with "4.3.0 virtual memory
> exhausted". Ok the "removeflag" is worthless because the message is already
> in the INBOX - but it should be silently ignored.
>
> When
is not a DB problem, it IS a sieve problem:
Look at this piece of sieve code:
if header :contains "From" "Muchsel" {
addflag "\\Flagged";
fileinto "INBOX";
removeflag "\\Flagged";
}
It is generated by Horde Ingo. lmtpd breaks with &
Pascal Gienger wrote:
I am using Cyrus IMAP 2.1.12 (Suse Linux package, no source install
allowed here), and we see some errors from lmtpd saying "Virtual
memory exhausted".
ulimits are unlimited for every resource (no limit), and there are 4
Gigabytes of swap used by 5% and 2 Gi
I investigated and found a curiosity:
That user has installed a sieve script to sort mail.
In his script he used the keyword
keep;
to keep the mail in his INBOX.
This "keep" is going havoc ("virtual memory exhausted").
After replacing "keep" with 'fileint
I am using Cyrus IMAP 2.1.12 (Suse Linux package, no source install allowed
here), and we see some errors from lmtpd saying "Virtual memory exhausted".
ulimits are unlimited for every resource (no limit), and there are 4
Gigabytes of swap used by 5% and 2 Gigabytes of RAM.
System is
ing imtest and the default
authorization. When I try to login using cyradm, I get a Perl error "Virtual
memory exhausted...line 125". This is totally confusing.
Rather than explain all the details, I have created a clean installation as
an example. I'm sorry this is so long.
27 matches
Mail list logo
