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