Do you have now enough info for figuring out what's going on? It's a bug that can be fixed?

I guess this is not related to concurrency issue I sent on another thread? Both issues are happening on same setup.

Br

On 6.2.2018 14:18, Andy Seaborne wrote:
Expections in alloc-write seem to be a cause of you rother issues so, maybe, this is the same rot cause with a different manifestation.  It would have been useful to know this at the start of the thread. It could be the broken alloc-write is simply asking for a huge amount of RAM becaue it says:

report_vm_out_of_memory

so it is not the system killing Fuseki, its the JVM exiting.

With a single TDB, 12G is way too much heap (try 2G) but the figure may include mapped files.

    Andy

On 06/02/18 09:56, Mikael Pesonen wrote:

Hi,

ok I'll try that. I had out of memory error on other server now. Is there a place I could post log files, if they help?

[2018-02-06 11:48:51] BindingTDB ERROR get1(?o)
org.apache.jena.tdb.base.file.FileException: In the middle of an alloc-write      at org.apache.jena.tdb.base.objectfile.ObjectFileStorage.read(ObjectFileStorage.java:311)
...
[2018-02-06 11:48:52] BindingTDB ERROR get1(?o)
java.nio.BufferOverflowException
     at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:214)
     at sun.nio.ch.IOUtil.read(IOUtil.java:200)
     at sun.nio.ch.FileChannelImpl.readInternal(FileChannelImpl.java:741)
     at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:727)
     at org.apache.jena.tdb.base.file.BufferChannelFile.read(BufferChannelFile.java:112)



Stack: [0x00007f1956dda000,0x00007f1956edb000], sp=0x00007f1956ed9720, free space=1021k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xaba7ea]  VMError::report_and_die()+0x2ba
V  [libjvm.so+0x4f9e3b]  report_vm_out_of_memory(char const*, int, unsigned long, VMErrorType, char const*)+0x8b V  [libjvm.so+0x91b613]  os::Linux::commit_memory_impl(char*, unsigned long, bool)+0x103 V  [libjvm.so+0x91b6dc]  os::pd_commit_memory(char*, unsigned long, bool)+0xc V  [libjvm.so+0x91518a]  os::commit_memory(char*, unsigned long, bool)+0x2a V  [libjvm.so+0x9198af]  os::pd_create_stack_guard_pages(char*, unsigned long)+0x7f
V  [libjvm.so+0xa6049e] JavaThread::create_stack_guard_pages()+0x5e
V  [libjvm.so+0xa69e14]  JavaThread::run()+0x34
V  [libjvm.so+0x91d9d8]  java_start(Thread*)+0x108
C  [libpthread.so.0+0x8182]  start_thread+0xc2

On 6.2.2018 10:57, Laura Morales wrote:
kernel: Killed process 29037 (java) total-vm:12745796kB
12.7GB? Used by Fuseki? Or does this account other processes as well? There is no way Fuseki is using 12GB of memory for a few thousands of triples, unless maybe memory is leaked during update operations. You should try try:

1. start Fuseki with your database
2. run a lot of live update queries (insert/delete/update data) and monitor how your VM responds


Sent: Tuesday, February 06, 2018 at 9:22 AM
From: "Mikael Pesonen" <mikael.peso...@lingsoft.fi>
To: users@jena.apache.org
Subject: Re: Limit memory usage of Fuseki server?
Hi,

config.ttl is defaut, Fuseki is ran as service, here is the log from
around the kill (notice fairly high VM)

  kernel: Out of memory: Kill process 29037 (java) score 807 or
sacrifice child
  kernel: Killed process 29037 (java) total-vm:12745796kB,
anon-rss:3458140kB, file-rss:0kB

systemd[1]: apache-jena-fuseki.service: Main process exited,
code=killed, status=9/KILL
  systemd[1]: apache-jena-fuseki.service: Unit entered failed state.
  systemd[1]: apache-jena-fuseki.service: Failed with result 'signal'.

Usage is not much, around few thousands of triplets, post, get and
delete, using Fuseki's GSP over HTTP. Uptime was around one week.

Sorry can't think of anything else to tell about the system.

Br


On 5.2.2018 18:08, ajs6f wrote:
Can you tell us more about your configuration, data, workload, and the timing of the problem?

ajs6f

On Feb 5, 2018, at 7:08 AM, Laura Morales <laure...@mail.com> wrote:

You can tell the Kernel to limit memory usage per process or per user. If you set the limit too low your process will be killed because it can't allocate more memory, but you can tell the Kernel to only limit resident memory while using up all the virtual memory it wants. You can do this with cgroups.



Sent: Monday, February 05, 2018 at 12:56 PM
From: "Mikael Pesonen" <mikael.peso...@lingsoft.fi>
To: users@jena.apache.org
Subject: Limit memory usage of Fuseki server?
We have a cloud server with 4gb of memory and after a while system is
killing Fuseki server java process for using up all memory. Is it
possible to limit memory usage, and what would be the performance
penalty for doing that?

Thanks.

--
Lingsoft - 30 years of Leading Language Management

www.lingsoft.fi[http://www.lingsoft.fi][http://www.lingsoft.fi[http://www.lingsoft.fi]]

Speech Applications - Language Management - Translation - Reader's and Writer's Tools - Text Tools - E-books and M-books

Mikael Pesonen
System Engineer

e-mail: mikael.peso...@lingsoft.fi
Tel. +358 2 279 3300

Time zone: GMT+2

Helsinki Office
Eteläranta 10
FI-00130 Helsinki
FINLAND

Turku Office
Kauppiaskatu 5 A
FI-20100 Turku
FINLAND

--
Lingsoft - 30 years of Leading Language Management

www.lingsoft.fi[http://www.lingsoft.fi]

Speech Applications - Language Management - Translation - Reader's and Writer's Tools - Text Tools - E-books and M-books

Mikael Pesonen
System Engineer

e-mail: mikael.peso...@lingsoft.fi
Tel. +358 2 279 3300

Time zone: GMT+2

Helsinki Office
Eteläranta 10
FI-00130 Helsinki
FINLAND

Turku Office
Kauppiaskatu 5 A
FI-20100 Turku
FINLAND


--
Lingsoft - 30 years of Leading Language Management

www.lingsoft.fi

Speech Applications - Language Management - Translation - Reader's and Writer's 
Tools - Text Tools - E-books and M-books

Mikael Pesonen
System Engineer

e-mail: mikael.peso...@lingsoft.fi
Tel. +358 2 279 3300

Time zone: GMT+2

Helsinki Office
Eteläranta 10
FI-00130 Helsinki
FINLAND

Turku Office
Kauppiaskatu 5 A
FI-20100 Turku
FINLAND

Reply via email to