On 12.03.18 14:37, Andy Seaborne wrote:

> Yes - all this was just using the command line tools.
> Default heap but that's different for me and for you.  I'm running with
> 8G heap (25% of 32G).
> 4G didn't work.

right I tested it now, for the current set 7GB seems to be the barrier.
> Earlier:
> """
>   And I once allocated almost all I had on my system (> 8GB)
> """
> I'm afraid it sounds like that didn't get set - if you can see the
> commandline for the running java process via system tools, it will have
> the -Xmx setting.  Or your data/query are different - I see %% stuff in
> the update.

jup I said something wrong there, it was on 3g, sorry about.

> Don't over allocate - the TDB files are memory mapped files and that dos
> not come out heap.

is there a rule of thumb for that? I now assigned 7GB on a 8GB machine.
But this is a VM spin up for that particular job (in Gitlab) and then
destroyed right afterwards.
> It's about to run out of heap.  java8 has a peculiar feature that when
> heap usage grows, it tries to full GC to create space, then tries again
> and again, ... to the point where the machine is only doing GCs which
> are parallel hence all the CPUs go crazy.

ok that explains. Is that something I should add to the docs for others?
I've seen this pattern quite often but never made that link to memory.



Reply via email to