2

As I indicated in another post, I'm having trouble with some SPIN constructors taking an excessive amount of time to execute quite limited data. I thought I'd take a different approach and see if I can profile the execution of the constructors to gain insight into where specifically they are spending excessive time.

How do I go about profiling the execution of constructors under RDF4J Server? I'm instantiating via SPARQL update (INSERT DATA) queries. Here's the System Information on RDF4J workbench:

RDF4J Workbench Summary

I've attempted to profile the Tomcat server under which the RDF4J Server runs using jvisualvm.exe, but I have not gained much insight. Ideally, I'd like to get down to the class/method level within RDF4J so that I can post a more detailed request for help on my slow execution problem or perhaps fix my queries to be more efficient themselves.

So here's the version of Java Visual VM:

Java Visual VM Version Info

RDF4J is running under Apache Tomcat 8.5.5:

enter image description here

I can see overview information on Tomcat:

enter image description here

I can also see the monitor tab and threads:

enter image description here

enter image description here

HOWEVER, what I really want to see is the profiler so that I can see where my slow queries are spending so much time. That hangs on Calibration since I don't have the profiler calibrated for Java 1.8.

enter image description here

This attempting to connect box will persist indefinitely. Canceling it leads to the Performing Calibration message which doesn't actually do anything and is a dead-end hang requiring the Java VisualVM to be killed.

enter image description here

After killing the Java Visual VM and restarting and looking at Options-->Profiling-->Calibration Data, I see that only Java 7 has calibration data.

enter image description here

I have tried switching Tomcat over to running on Java 7, and that did work:

enter image description here

The profiler did come up with Tomcat:

enter image description here

However, when I tried to access the RDF4J workbench while Tomcat ran on Java 7, I could not get the workbench running:

enter image description here

So, I'm still stuck. It would appear that RDF4J requires Tomcat running under Java 1.8, not 1.7. I can't profile under Java 1.8.

I have seen other posts on this problem with Java VisualVM, but the one applicable solution seems to be to bring everything up in a development environment (e.g. Eclipse) and dynamically invoke the profiler at a debugger breakpoint once the target code is running under Java 1.8. I'm not set up to do that with Tomcat and RDF4J and would need pointers. My intention was not to become a Tomcat or RDF4J contributer (because my tasking doesn't allow that... I wouldn't be paid for the time) but rather to get a specific handle on what's taking so long for my SPIN constructor(s) in terms of RDF4J server classes and then ask for help from the RDF4J developer community on gitub.

Can Java VisualVM calibration be bypassed? Could I load a calibration file or directory somewhere for Java VisualVM to use instead of trying to measure calibration data which fails? I'm only interested in the relative CPU loading of classes, not absolute metrics, and I don't need to compare to measurements on other machines.

Thanks.

Greg Cox
  • 287
  • 1
  • 12
  • 2
    The web application you actually want to profile is RDF4J Server, not Workbench. Workbench is merely the client UI. Execution of all SPIN reasoning takes places in the Server app. – Jeen Broekstra Sep 07 '16 at 03:00
  • It's not really clear to me what the exact problem is. If you profile/sample using jvisualvm on Tomcat, you should be able to zoom in on class/methods of rdf4j fairly quickly. Where exactly are you stuck? – Jeen Broekstra Sep 07 '16 at 04:44
  • 1
    Thanks @JeenBroekstra. You've confirmed that I _should_ be able to see what I want using jvisualvm, but I can't. This means that I actually have a jvisualvm problem to solve first. I can already see Tomcat in jvisualvm and use every tab _except_ profiler. The profiler gets stuck trying to connect to the VM during calibration. I see several posts on that, so I'll have to study them and try to rectify the profiler problem. Hopefully if I can get that fixed, then I can use jvisualvm.exe to see the RDF4J server classes. Thanks again. – Greg Cox Sep 07 '16 at 16:36
  • 1
    Does sampling work? it's not quite as accurate as profiling, but less resource-intensive and it should still give you a good idea of probable bottlenecks. – Jeen Broekstra Sep 08 '16 at 22:30
  • Yes, @JeenBroekstra, sampling does work. Good call. I'll update my slow queries question with the information from sampling. As a preview, the org.eclipse.rdf4j.common.concurrent.locks.LockManager.createLock() and org.eclipse.rdf4j.common.concurrent.locks.LockManager$1.release() are taking an inordinate amount of time for a simple case, taking around 23 seconds between them for one instantiation. – Greg Cox Sep 09 '16 at 00:14
  • @JeenBroekstra, could you have a look at [my slow constructor question](http://stackoverflow.com/q/39212922/6501799) please? I'm wondering whether my constructor is causing a deadlock of some sort between threads, causing excessive time in the lock/unlock methods. Is there enough there to post on github or do I need to do more homework? If so, specifically what? Thanks! – Greg Cox Sep 11 '16 at 00:50
  • 1
    I'm currently in the middle of a house move so unable to look at this. But feel free to open a gh issue or else to post to rdf4j-users forum. Include a link back to SO questions if possible. – Jeen Broekstra Sep 11 '16 at 19:42
  • Thanks @JeenBroekstra. Good luck with your move; I know that's a lot of work. I did both (gh and forum). Pulquero pointed me to [prior posts of yours](https://openrdf.atlassian.net/browse/SES-2388) off of my gh issue. This looks quite similar to the slow performance issue I'm seeing. – Greg Cox Sep 13 '16 at 23:12

0 Answers0