CODEWITHSUNDEEP
javaeclipseperformancejvmjvisualvm
Cron Merdek
Cron Merdek

Reputation: 1124

Eclipse huge CPU spikes

I am desperately trying to find the issue of my Eclipse to freeze for moments (up to 2-3 sec) caused by CPU spiked (18-19 cores with 100% load). During the spikes nothing works, whole eclipse just unresponsive. Life got better since I modified eclipse.ini to use proper heap size and garbage collector. Nevertheless, freezes are still present. I have used jvisualvm to rule out garbage collector. As you can see on the screen below, there is no dependency between CPU spikes and heap size.

Could you please advise me how I can identify the issue (CPU spikes) by using either jvisualvm or any other tool avaliable for Linux?

Tech details:

$ java -version
java version "1.7.0_65"
OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.12.04.1)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

Spikes in CPU

$ cat /opt/eclipse/eclipse.ini
-startup
plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.200.v20140116-2212
-showsplash org.eclipse.platform
--launcher.defaultAction openFile
--launcher.appendVmargs
-vmargs
-Xss2M
-Xms3G
-server
-XX:MaxPermSize=2048M

-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
-XX:G1HeapWastePercent=5
-XX:InitiatingHeapOccupancyPercent=83
-XX:MaxGCPauseMillis=500

Full thread dump here

Most suspicious thread:

  "RJHelper [Thread-1]" daemon prio=10 tid=0x00007fe128009000 nid=0xe37a waiting for monitor entry [0x00007fe13f5f9000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:172)
    - locked <0x00000003a4539c40> (a java.util.ArrayList)
    at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:129)
    at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:194)
    at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:148)
    at com.sun.proxy.$Proxy16.runAsync(Unknown Source)
    at de.walware.rj.server.client.AbstractRJComClient.runAsyncPing(AbstractRJComClient.java:754)
    at de.walware.rj.server.client.AbstractRJComClient$KeepAliveRunnable.run(AbstractRJComClient.java:178)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - <0x000000039a4ee240> (a java.util.concurrent.ThreadPoolExecutor$Worker)

Upvotes: 0

Views: 491

Answers (1)

kohlerm
kohlerm

Reputation: 2624

Jvisualvm also supports threaddumps and even thread dump based profiling,which should help you to identify what is going on quickly.

Upvotes: 1

Related Questions