Can you pls help us answering the below questions.
1) While tracing/profiling a JAVA based web application using jprofiler is there any way to find out if the calls are parallel or sequential ?
2) While running Jprofiler on JVM where Wily tracing tool is already there, the jprofiler is mostly detecting the the overhead due to Wily tool rather than the actual application. Is there any way we can enable the jpropfiler filter to ignore Wily probes (e.g. ignore anything that starts with com.wily.. Even after putting this filter in jprofiler exclude class filter, still jprofiler detects the Wily probes with com.wily.). Can you pls suggest how to fix this in exclude filter ?
Also, is there any known conflicts/issues of jprofiler with Wily tool ?
Thanks,
PR
is there any way to find out if the calls are parallel or sequential
No, the call tree cannot show this.
Even after putting this filter in jprofiler exclude class filter, still
jprofiler detects the Wily probes with com.wily.
That is because the calls from profiled classes are always shown and Wily instruments your code. You can configure a ignored method by right-clicking the Wily method in the call tree and choosing "Add filter from selection->Ignore method ...".
In general, I would not recommend to use multiple profilers or monitoring tools at the same time.
Related
I was working on the Cucumber report then found the parallel option, as of now I am running only #1 thread and using parallel =false in the feature file. As per my understanding, we cant use parallelism with the karate.robot as it needs one activated window with a title. Please correct me if I am wrong?
I think the main challenge is that most of the UI interactions assume that the "active" window is "on top", visible and has focus. If you can figure out a way to use Element.invoke() for everything, maybe - but you will need to experiment.
Personally I feel that the better strategy is to split your test suite across multiple cloud nodes, and maybe virtual-machines or EC2 instances will work, provided you get the RDP stuff sorted out.
Note that Karate has a way to run distributed tests: https://github.com/intuit/karate/wiki/Distributed-Testing - it may need some research though.
How do you debug an RTOS application? I am using KEIL µVision and when I hit debug, the program steps through the main function until the function that initializes the RTOS kernel and then you can't step any further. The code itself works though. It is not mine btw, but I have to work on it. Is this normal behavior with RTOS applications or is this related to the program?
Yes, this is normal. You need to set breakpoints in the source code for the tasks that were created in main(): the only purpose of main() in a FreeRTOS application is to :
initialize the hardware,
create the resources (timers, semaphores...) and tasks your application will need,
start the scheduler
The application should never return from vTaskStartScheduler() if they were enough resources available.
Put break-points at the entry point of each task you need to debug. When you step the over the scheduler start (or simply run) the debugger will halts at the first task that runs. When that task blocks, some other task will be selected to run according to the scheduling rules.
Generally when debugging and you reach a blocking call, step-over it, other tasks may run and the debugger will stop at the next line only when the task becomes ready (depending on the nature of the blocking call). Often you will want to predict what task will run as a result of the call, and put a breakpoint in that task. For example if you issue a message send, you might place a breakpoint after the message receive call of the receiving task.
The point is you cannot "step-through" a context switch unless you have the RTOS source or do it at the assembler level, which is seldom useful or productive, and will not work for preemption.
You get a somewhat better RTOS debug experience and tool support in Keil if you use Keil's own RTX5 RTOS rather then FreeRTOS, but all of the above remains true.
Yes, this is an expected behaviour. The best way to debug a RTOS application is to place breakpoints at all tasks, key function entry points and step debug.
The debugger supports various methods of single-stepping through an application as in below link.
http://www.keil.com/products/uvision/db_exe_step.asp
Typical challenges in debugging RTOS application can be dealing with interrupt handling, synchronization issues and register/memory corruption.
Keil µVision's System Analyzer enables one to view the program execution time frame, status of each thread. It shall also help in viewing interrupts, exceptions if tracer is enabled.
Recently, I've been digging in to JVM heap dumps using Eclipse MAT. I like it, but the one feature that I seem to use the most is the Dominator Tree. Eclipse's example screenshot:
Anyways, I find that a lot of the time, I usually get the most value out of just looking at that table and getting the first few entries. Since the turnaround time for getting this is:
Create Heap Dump (jcmd <pid> GC.heap_dump)
Download/Pull heapdump to a location (MAT isn't installed on our servers)
Run Eclipse MAT's ParseHeapDump.sh tool to build the various trees
Open MAT, click Dominator Tree icon.
Analyze
Is there a way to get this equivalent information off of a running JVM programmatically? I'd like to run some kind of gather_dominators.sh <pid> script on a host and get the Top X Objects from a JVM, but I don't know where to start.
If by "running jvm" You meant - "getting the info without doing stop-world heap-dump" then the obvious answer is: in order to do such thing without "full-scan" - the data needs to be collected throughout system life-time by tapping creation/release of each object and by maintaining the statistics. You could achieve such things by instrumentation or by using a ready-made custom agents (jol/jamm/etc). Note that many GCs are already doing similar work to collect (and print) statistics. IIRC - newer JVMs even keep track of such info within the class-metadata area (so getting statistics is instant).
https://github.com/google/allocation-instrumenter
(google-allocation-instumenter)
http://blog.javabenchmark.org/2013/07/compute-java-object-memory-footprint-at.html (with JAMM)
https://github.com/jbellis/jamm (JAMM src)
In Java, what is the best way to determine the size of an object? (JOL/etc here)
http://www.javaworld.com/article/2074458/core-java/estimating-java-object-sizes-with-instrumentation.html (short DYI guide)
https://www.youtube.com/results?search_query=Understanding+Java+GC
(webCast on how GC traverses objects for similar purposes)
On other hand - if You're fine to grab a heap-dump (which should be fine on any production system with any proper node-redundancy in place, designed for handling unavoidable Sun-JVM stop-world GC pauses), then Jhat, MAT-api, YourKit and Jol are probably Your best friends:
Programmatically analyze java heap dump file
How to analyse the heap dump using jmap in java
It is important to note that currently-existing heap-dump format loses the info about actual sizes of objects, so all tools (MAT/etc) are just trying to GUESS it properly:
http://shipilev.net/blog/2014/heapdump-is-a-lie/ (What Heap Dumps Are Lying To You About, by Aleksey Shipilёv)
HTH :)
I am evaluating different multiprocessing libraries for a fault tolerant application. I basically need any process to be allowed to crash without stopping the whole application.
I can do it using the fork() system call. The limit here is that the process can be created on the same machine, only.
Can I do the same with MPI? If a process created with MPI crashes, can the parent process keep running and eventually create a new process?
Is there any alternative (possibly multiplatform and open source) library to get the same result?
As reported here, MPI 4.0 will have support for fault tolerance.
If you want collectives, you're going to have to wait for MPI-3.something (as High Performance Mark and Hristo Illev suggest)
If you can live with point-to-point, and you are a patient person willing to raise a bunch of bug reports against your MPI implementation, you can try the following:
disable the default MPI error handler
carefully check every single return code from your MPI programs
keep track in your application which ranks are up and which are down. Oh, and when they go down they can never get back. but you're unable to use collectives anyway (see my opening statement), so that's not a huge deal, right?
Here's an old paper (back when Bill still worked at Argonne. I think it's from 2003):
http://www.mcs.anl.gov/~lusk/papers/fault-tolerance.pdf . It lays out the kinds of fault tolerant things one can do in MPI. Perhaps such a "constrained MPI" might still work for your needs.
If you're willing to go for something research quality, there's two implementations of a potential fault tolerance chapter for a future version of MPI (MPI-4?). The proposal is called User Level Failure Mitigation. There's an experimental version in MPICH 3.2a2 and a branch of Open MPI that also provides the interfaces. Both are far from production quality, but you're welcome to try them out. Just know that since this isn't in the MPI Standard, the function prefixes are not MPI_*. For MPICH, they're MPIX_*, for the Open MPI branch, they're OMPI_* (though I believe they'll be changing theirs to be MPIX_* soon as well.
As Rob Latham mentioned, there will be lots of work you'll need to do within your app to handle failures, though you don't necessarily have to check all of your return codes. You can/should use MPI error handlers as a callback function to simplify things. There's information/examples in the spec available along with the Open MPI branch.
Could guys please tell me what exactly I need to do in order to use com.jprofiler.agent.Controller in my code ?
I have GWT/GAE application which I'm running under debugger of IntelliJ IDEA 11. I have JProfiler 7.0.1.
I googled a little and it seems I need to pass this "-agentpath:C:\Program Files (x86)\jprofiler7\bin\windows\jprofilerti.dll,config=C:\Program Files (x86)\jprofiler7\api\samples\common\config.xml"
"-Xbootclasspath/a:S:\Program Files (x86)\jprofiler7\bin\agent.jar" to JVM but it doesn't seem to work.
Generally,
-agentpath:[path to jprofilerti.dll]
is enough. The process will wait for the JProfiler GUI to connect. This is so it can use the correct profiling settings with a minimum overhead.
To get immediate startup, pass
-agentpath:[path to jprofilerti.dll],nowait
The profiling agent will then have to retransform classes, depending on your filter settings.
And using the JProfiler plugin from the plugin manager will make all of this unnecessary.