On 11/03/18 21:27, Adrian Gschwend wrote:
On 10.03.18 00:36, Andy Seaborne wrote:
Hi Andy,
Executes in 2m 20s (java8) for me (and 1m 49s with java9 which is .
Default heap which is IIRC 25% of RAM or 8G. Cold JVM, cold file cache.
wow, did you do that with TDB commandline tools? Default heap in terms
of default settings of Fuseki?
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.
On Linux/Mac, set and export JVM_ARGS=-Xmx8G and make sure it gets
passed to the script. On Windows, I think you need to edit the scripts.
If you have an 8G machine, an 8G heap may cause problems (swapping).
I have 16 gigs on my local system.
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.
and if Linux, set "swappiness" to zero.
https://askubuntu.com/questions/103915/how-do-i-configure-swappiness
otherwise it kernel keeps some free space. Ttat does not cause the CPUs
to go wild.
Don't over allocate - the TDB files are memory mapped files and that dos
not come out heap.
Does the CPU load go up very high, on all cores? That's a sign of a full
GC trying to reclaim space before a OOME.
yes that's exactly what is happening. What is OOME?
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.
Andy
If you get the same with TDB2, then the space isn't going in
transactions in TDB1.
not sure what that means but ok :)
regards
Adrian
