Excerpts from Andrew Pimlott's message of Mon Sep 07 13:04:50 -0400 2009: > I am running on a fairly low-memory virtual machine. I think some of > the variability in what I was seeing before had to do with what > other
I'm running sup on real hardware w/1GB physical ram.
> things were running. Sorry about not being aware of this before. In
> the following, I have pretty well controlled for other system memory
> use. All of these tests are done on the same mbox with all indices
> cleared.
>
> Some of the failures I see are out of memory when running gpg
> ("Errno::ENOMEM Exception: Cannot allocate memory - /usr/bin/gpg" ...).
> I stopped at that point in the debugger and found that at this point,
> the ruby backtick operator fails the same way on any command. Using
> strace, I saw a failure in clone:
I found sup crashed this morning too with an ENOMEM on a gpg
operation. I thought I may actually have been at the memory
exhaustion point normally though as I run screen and tend to leave
lots of sessions going all the time.
> Using the xapian index, things are different. It starts at 32M and
> steadily climbs to 77M after ~3500 messages, or around 1M every 100
> messages. It does seem to climb faster at first and then more
> slowly.
I've never paid attention to this before, but currently, my sup
process (running for about 6 hours now) looks like it's using ~77M
virtual with 59 of that resident.
This has only happened to me once, but since you reported it, I
thought I'd chime in with some extra data.
HTH.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
signature.asc
Description: PGP signature
_______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
