Trying to run a JMH benchmark on Windows using WinPerfAsmProfiler gives the following error:
ERROR: No address lines detected in assembly capture, make sure your JDK is PrintAssembly-enabled:
https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly
The problem, as the link suggests, is that you must install a disassembler plugin. There are several implementations. However, for reasons of self-censorship and copyright nazism, Windows binaries of most implementations are hard to come by. Additional info can be found in this SO question (in which I've updated the suggested build steps and won't repeat them here).
The other issue you'll hit is that you must run the profiling session as an administrator.
Additional information about the system properties which configure perfasm, can only be found in the source code of AbstractPerfAsmProfiler and WinPerfAsmProfiler (at least, as of version 1.9.2).
A possibly useful tip: You can increase xperf's sampling frequency from 1KHz to 8KHz (and have more precise timing information) by running xperf-setprofint 1221 cached in any Administrator command prompt.
Related
I have laptop 8 GB ram and I5 processor, Grails 2.4.4 and Java 7.
while running application it taking to much time 7 to 8 min.
is need to set JAVA_OPTS or GRAILS_OPTS.
Using intellji 14 IDE.
Sometimes people write a question without actually considering that the people it is presented to have no idea what it is the end user has going on at their end.
The problem with a question like above is the lack of actual information as to the real information of what it is you are trying to achieve.
You should always consider when you say a grails application from a basic grails create-app to where you are is your concept no one out there has any ideas of what it is you are asking it to do. They will in their minds compare it to a basic app.
When hitting an issue in an application these are the things to consider
Enabling logging for the database - Look into enabling your database to generate logs. You can also enable logs within mysql or what ever database you are using to get more of an idea of what is being crunched through.
Enable logging on your application look into adding this to build.gradle :
console "org.grails:grails-console"
Then in
logback.groovy
at the very end of the file add something like this:
logger("com.mypackage", DEBUG, ["CONSOLE"])
logger("com.mypackage", INFO, ["CONSOLE"])
logger("com.mypackage", WARN, ["CONSOLE"])
logger("com.mypackage", ERROR, ["CONSOLE"])
Then hopefully your own code should output the debug error statements - Enable logging for your schedule tasks as the app start - measure the start end time - compare them -
this will give you an idea as to how long those things are taking.
In regards to grails and JVM it all depends on what version of JVM you are running JDK 8 is slightly different to JDK7.
export GRAILS_OPTS="-Xmx1G -Xms1024m -XX:MaxPermSize=1024m"
export MAVEN_OPTS="-XX:MaxPermSize=1024m -Xms1024m -Xmx1024m"
export JAVA_OPTS='-server -Xms1024m -Xmx1024m -XX:PermSize=1024m -XX:MaxPermSize=1024m'
That is for Linux you can find out how to export out the variables for windows and increase decrease them.
So far as I am running 8 gig and 16 processor. Again it is all based on JVM configuration. If I have the same but then have it configured to run as 256k JVM. Well all the rest is sitting there not doing much for the actual JVM.
Hope it is making a little more sense and hope if anything you understand that when raising a question you need to think of the audience that will read it and their conception of what you mean for example of I am running an app. You need to elaborate you should really be asking a more specific question after you have done some of above and worked out a more specific issue that someone could better answer. At the moment it is a needle in a haystack
In regards to plugins, always take a read at their documentation for example spring security can have logging enabled. Have you looked into that as yet ? to see what this is doing or how about disabling spring security as a test ?
grails.plugin.springsecurity.active = false
You see there is a lot you could have already been doing to help yourself be in a better poisition of understanding the fault. When my toe hurts it only hurts me not the person sitting next to me :)
I currently have a OSB project with a set of 21 modules that take roughly 4 minutes to build on my local 2 core/12GB ram laptop running Windows using no threading, just a simple build install. It takes 10-20 seconds per module.
When building this exact same project on my CI server running on Ubuntu, with 8 cores/16GB RAM build time is closer to 110 minutes, using around 4 minutes per module.
Some details on the Linux build:
Most of these 4 minutes per module is spent sitting idle on 0% CPU utilization.
MAVEN_OPTS are "-Xmx512m -Xms512m"
Same build time on Java 7 and 8
When running with the -X flag it spends most of it's time at "-- end configuration --"
I have tried increasing the file descriptor limit, thinking this was the problem. This did not do anything to the build time.
After profiling maven with VisualVM both on Windows and Linux I found that on Linux it spent abnormal amounts of time generating a random seed.
So by changing to (the slighty less secure) /dev/./urandom build time went from 110 minutes down to 1minute 47seconds.
An example of how to do this is by passing in the setting as a flag:
-Djava.security.egd=file:/dev/./urandom
If you would like to set this permanently, this can be done in the file jdk1.7.0_75/jre/lib/security/java.security by changing:
securerandom.source=file:/dev/urandom to
securerandom.source=file:/dev/./urandom.
This might bring some security implications of which you should do some research first if you need to do this.
There are a lot of variables here. I can't provide an answer, but in general, I try to pare the problem down as small as possible. You're saying it's around ~21 projects. Is it equally slow with 1? I know you said you get it with 4min/module, but that's not the same as a project with 1 module in it. The sheer scope of the file descriptors (ulimit) can be really troublesome, even if you're only looking at one module at a time during the build.
Second, ensure your own laptop's environment variables are similar. Windows to Linux is not exactly the easiest to compare to, but you should be able to determine if JAVA_OPTS, MAVEN_OPTS, the various -X/-D flags are the same, whether -Xms/-Xmx are set the same, etc. etc.
Further, have you reviewed any of the Google-able results I found?
Why is my Maven so slow on Ubuntu?
http://zeroturnaround.com/rebellabs/your-maven-build-is-slow-speed-it-up/
The difficult part with your problem is we're not looking at even remotely close environments. We don't know
environment variables
settings.xml (and /etc/.../.settings.xml)
Is the CI server software running the build or are you just running the same mvn clean install on both your local machine and the remote?
etc. etc.
And I can't say that this site would even be the best place to have someone troubleshoot. If you're building an OSB set of projects, you might have better luck filing an SR with Oracle Support and asking them to help you out, per your support plan. At least in the SR, there's a bit more back-and-forth in the communication. Here, you're expected to provide all the possible information, and then people spitball the answer to you. Without any data on your question, we have nowhere to go, and wild assumptions/guesses to make.
I have found the DTrace intriguing but have personally failed to see a use-case that allow me to get information that I cannot get otherwise anyway without using DTrace.
Hence, I would like to hear what I have overlooked. What can I do on my vmware OpenIndiana build 148 with DTrace that can make a difference when creating stand-alone applications and Java EE web applications (most of which communicate heavily with a legacy backend using sockets)?
Non-trivial Dtrace scripts are very welcome.
I had some good experiences with DTrace.
I had a client running our Java code on a production server running 24x7. We had some performance issues with the applications. It was impossible to stop the JVMs in order to attach the profiler. Moreover the behavior was not present in our lab under the same load.
We solved the issue using DTrace with the JVM related probes as I could attach it to the running JVMs and the overhead introduced was minimal (1.3% on a Netra T2000 SPARC machine).
The bonus of the method was that all the debugging was done via a dial-up (33kbps) line to the customer's lab. It is almost impossible to run any other profiler/debugger with this constraints (JDWP is quite verbose for this bandwidth). With my DTrace script I filtered only what it was interesting for me.
For some hints see:
http://java.dzone.com/articles/java-profiling-dtrace?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+javalobby/frontpage+(Javalobby+/+Java+Zone)
http://download.oracle.com/javase/6/docs/technotes/guides/vm/dtrace.html
I have adapted those scripts
http://blogs.oracle.com/ahl/date/20050418#dtracing_java
Another big plus are the aggregated values that can be easily used to create custom statistics.
But, if you have appropriate conditions, everything can be done easier with othe tools. DTrace is very powerfull but it targets more bare-metal conditions (maybe DLight project would help).
I'm attempting to profile junit tests in eclipse on OSX using TPTP. I installed the TPTP package from eclipse with no problem, I went to profile some code and it tells me:
Agent Controller is unavailable under port 10002.
Make sure that the service is started and the port number is correct
under preferences.
I searched around on the internets and discovered many complains about Agent Controller not being available for os X. Almost all of the java developers I know run eclipse under os x. Why would eclipse not support os x? Why even make the TPTP packages available for os x if os x can't run agent controller? Purely for remote debugging purposes?
Os X is built on BSD, Linux has an Agent Controller port. Has this been ported to os x?
Any ideas or success stories getting TPTP to work on os x (remote debugging on linux, agent controller replacements)?
What other options are there (Netbeans, VisualVM, JProfiler) and how good are they?
What does stackoverflow suggest I do?
Note: I am interested in profiling on class and method, of the number of times each method is called, and the amount of time the program spends in each method. Due to the complexity of the code using System.nanotime() statements are not an option.
According to the Eclipse TPTP FAQ
What platforms and environments does TPTP support?
The user interface components of the
TPTP Infrastructure can run on any
Eclipse-supported platform. The
various test execution, monitoring and
tracing components typically run on a
broad range of infrastructure and
interface with a broad range of
systems. One notable deficiency at
present is that the various trace
facilities are currently
Java-specific, although the project
has a goal to extend additional
language support in due course. For
the other agents there is a reasonable
coverage implemented or planned for
popular operating systems, application
servers, web servers etc, with a
particular focus on providing support
for other open source products.
Related Questions:
How can I see what parts of my code are running the most
Using java to get os level system information
if you have a java application that is consuming cpu when it isnt doing anything
Related Links:
Open Source Profilers for Java
As far as other Java profilers go, I think this is the best Stack Overflow question:
Please Recommend a Java Profiler
I personally would recommend YourKit Java Profiler, I've found it much more user-friendly than TPTP, and (while I haven't tested it) it should work on OS X.
Have you seen if the Netbeans profiler works under OS X? It is the original of which jvisualvm is a subset. It might just work...
I spent the last 4 hours trying to set up Eclipse TPTP memory
profiling on a Tomcat instance that must be run remotely (i.e. not in
Eclipse). This should be possible according to the TPTP and Agent
Controller docs.
I installed the TPTP components (4.6.0) into my Eclipse (Galileo)
workbench, along with the Agent Controller according to the
instructions on the website. To enable the agent, I added the
following options to the command line that starts the Tomcat instance:
-agentlib:JPIBootLoader=JPIAgent:server=enabled;HeapProf:allocsites=true
and added the following directories to the front of the PATH:
D:\dev\tools\ac\plugins\org.eclipse.tptp.javaprofiler
D:\dev\tools\ac\bin
When attempting to start Tomcat I consistently got the following error
message:
ERROR: JDWP unable to get necessary JVMTI capabilities. ["debugInit.c",L279]
I did a lot of Googling but found nothing relevant; I tried
reinstalling TPTP and various versions of the Agent Controller.
In the end the problem turned out to be that I was starting Tomcat
with the "jpda" option, which catalina.bat translates into
-Xdebug -Xrunjdwp:transport=.....
Removing the "jpda" command argument caused JVMTI to start working.
SO, the question is: I found nothing during any of my searches to
indicate that a JVMTI agent is incompatible with debugging. Can
someone explain what is going on and why JVMTI + JDWP is not a valid
setup?
None of the answers so far are correct and this is the first hit that comes up on Google if you query the error mentioned, so I feel some clarification is needed.
JVMTI and JDWP do work together, in fact they generally must be used together. You will get ERROR: JDWP unable to get necessary JVMTI capabilities if -Xrunjdwp (and/or possibly -agentlib:jdwp) is specified more than once on the command line. To fix it, make sure you only have one of -Xrunjdwp or -agentlib:jdwp in your command line.
For more details, read on...
JVMTI (Java Virtual Machine Tool Interface) is the successor to JVMDI (Java Virtual Machine Debug Interface) and JVMPI (Java Virtual Machine Profiling Interface). It incorporates the functionality of both JVMDI and JVMPI, both of which were deprecated in Java 5 and removed in Java 6. It is the API that exposes the internals of the JVM for the purposes of debugging and profiling.
JDWP (Java Debug Wire Protocol) is a protocol that describes a simple mechanism for transmitting commands and responses. As far as I know, it is the only way for a debugger sitting outside the JVM to communicate with it and to interface with the JVMTI.
JDI (Java Debugger Interface) is a client-side (debugger-side) API which exposes some of the features of JVMTI while making use of JDWP more or less transparently.
The bug mentioned in Bob Dobbs's answer concerns the misleading error message, and the fact that the JVM will try to load JDWP once for every time it is specified on the command line. It doesn't state anywhere that JDWP and JVMTI cannot be used together.
More info here: https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rzaha/jpdebuga.htm
I ran into the same problem as you, but I came up with a JVM bug report (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6354345) that cast some light on the issue. It basically comes down to the Java agent library not ever being intended to be loaded twice into the same VM. Sucks, but seems like it's basic limitation of the agent system that you can't do both at the same time.
For me it was the same issue as Code Bling post, they were duplicate -Xrunjdwp didn't realize there were a second -Xrunjdwp as it was hidden in the variable %JAVA_OPTIONS%, check your Application Server start script.