That answers that question. We were running in .5G.
On Wed, Jun 13, 2012 at 7:52 AM, Andy Seaborne <[email protected]> wrote: > On 13/06/12 12:13, Benson Margulies wrote: >> >> On Wed, Jun 13, 2012 at 5:20 AM, Damian Steer<[email protected]> >> wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 12/06/12 18:47, Benson Margulies wrote: >>>> >>>> I hit the problem I sent mail about most recently whilst trying to >>>> reproduce the following. Is there any reason to think that this is >>>> worse than TDB being unlucky enough to be the allocation straw >>>> that breaks the camel's back? >>> >>> >>> What are you running this on? On 64bit machines TDB should be >>> reasonably light on the heap. >> >> >> "A whole lot of triples"? It's sitting there stuffing triples into the >> store, some, as you see, are reifications, which results in some >> queries, and in other cases we're explicitly querying to decide what >> to insert. Running the whole business with -Xmx1g succeeds. If there >> is some more specific characterization of the process that would help, >> please let me know. I obviously can't deliver the entire circus as a >> test case. > > > You are running 64bit presumably. 1G should be enough for TDB 9bit on the > small side?) but of course it's competing for space with the rest of the > app. > > On the surface, TDB is the unlucky straw, although realistically it is using > a decent proportion of that 1G so it's putting itself in the firing line. > > The main heap memory consumer on a 64bit machine (mapped mode) is the node > table. > > I normally run with 1.5G. > > Andy >
