From mboxrd@z Thu Jan 1 00:00:00 1970 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 07 Sep 2009 14:14:41 -0400 Subject: [sup-talk] sup-sync and xapian memory usage In-Reply-To: <20090907170450.GO14010@pimlott.net> References: <20090907170450.GO14010@pimlott.net> Message-ID: <1252347051-sup-135@ntdws12.chass.utoronto.ca> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: