This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 209617 - CPU at 100%
Summary: CPU at 100%
Status: RESOLVED FIXED
Alias: None
Product: ide
Classification: Unclassified
Component: Performance (show other bugs)
Version: 7.1.1
Hardware: PC Windows 7
: P3 normal with 1 vote (vote)
Assignee: Tomas Hurka
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-15 13:38 UTC by js-java
Modified: 2013-02-08 09:57 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Requested profiling (118.79 KB, application/octet-stream)
2012-03-16 13:04 UTC, js-java
Details
Another profiling (396.79 KB, application/octet-stream)
2012-04-17 12:00 UTC, js-java
Details
Another new snapshot (247.45 KB, application/octet-stream)
2012-04-23 16:02 UTC, js-java
Details
Next snapshot (82.05 KB, application/octet-stream)
2012-04-24 09:20 UTC, js-java
Details
Next snap (362.15 KB, application/octet-stream)
2012-04-26 12:42 UTC, js-java
Details
Next snapshot (202.84 KB, application/octet-stream)
2012-05-02 12:17 UTC, js-java
Details
netbeans.conf (1.65 KB, application/octet-stream)
2012-05-23 12:50 UTC, js-java
Details
New snap (216.13 KB, application/octet-stream)
2012-06-04 16:04 UTC, js-java
Details
messages (269.78 KB, application/octet-stream)
2012-06-04 16:06 UTC, js-java
Details

Note You need to log in before you can comment on or make changes to this bug.
Description js-java 2012-03-15 13:38:37 UTC
After working several hours Netbeans starts taking 100% of one CPU core. Editor is poorly slow, no message at window bottom reporting scan or something else. Restarting Netbeans helps. However, a running Tomcat has to bestopped then, so this is a big break during work.

Leaving editor window (eg. writing this issue) will help for a few minutes, CPU load goes down. But after typing several characters back in the editor will increase load.
Comment 1 Tomas Hurka 2012-03-15 13:52:45 UTC
Can you please send us snapshot taken via <http://wiki.netbeans.org/FitnessViaPartnership> so that we can analyze what is going on in your case. Thanks.
Comment 2 js-java 2012-03-15 14:11:12 UTC
After pressing this button Netbeans came completely inresponsive. I will continue to wait for few minutes more then I have to kill the process!
Comment 3 js-java 2012-03-16 13:04:03 UTC
Created attachment 116798 [details]
Requested profiling
Comment 4 js-java 2012-03-16 13:25:54 UTC
I continued to work with this slow NetBeans with profiling running. But when I stopped profiling "save snapshot" didn't finish even after 20 minutes.
Comment 5 js-java 2012-04-17 12:00:42 UTC
Created attachment 118397 [details]
Another profiling
Comment 6 js-java 2012-04-23 16:02:46 UTC
Created attachment 118644 [details]
Another new snapshot
Comment 7 js-java 2012-04-24 09:20:35 UTC
Created attachment 118676 [details]
Next snapshot
Comment 8 js-java 2012-04-26 12:42:27 UTC
Created attachment 118807 [details]
Next snap

Working with NetBeans becomes impossible for me!
Comment 9 Petr Cyhelsky 2012-05-02 04:52:31 UTC
Various things are going on in different snapshots, but in 2nd, 3rd and 5th of them Parsing & Indexing loop is consuming a lot of time and it doesn't seem like there is anything else going on - reassigning to parsing&indexing for evaluation
Comment 10 js-java 2012-05-02 12:17:10 UTC
Created attachment 118973 [details]
Next snapshot
Comment 11 js-java 2012-05-02 12:18:58 UTC
I had this experience: when I use another program, so NetBeans lost focus, CPU load decreases. When I click back into NetBeans to give it the focus CPU load increases.
Comment 12 Tomas Zezula 2012-05-02 13:40:07 UTC
>I had this experience: when I use another program, so NetBeans lost focus, CPU
>load decreases. When I click back into NetBeans to give it the focus CPU load
>increases.
Seems as FileSystem check for external changes which possibly may start indexing.
Comment 13 js-java 2012-05-02 13:45:11 UTC
Just to make it sure: CPU load increases after few hours of work (typical office day). Then NetBeans becomes really slow, starting task manager show the load but after few seconds load decreases. So I continue work with NetBeans but load increases again. No message about changes checking or something else. Just high load. Restarting NetBeans solves the problem.
Comment 14 Tomas Zezula 2012-05-02 14:02:03 UTC
The snapshots come from different features, in some of them no java nor lang infrastructure is active at all.

From your description (fixed after restart) as well as from the nps files (when the nps contains indexing the OnePassCompileWorker goes out of memory and falls back to MultiPassCompileWorker ) it seems as a memory leak.

It seems we will need a heap dump of the  "frozen" IDE to find out what is held by who.

First find the pid of the IDE by:
jps

Second generate heap dump:
jmap -dump:file=nb.bin <pid_found_by_jps>

The heap dump will be quite big, please compress it and Petr will tell you how to share it with us.
Thanks!
Comment 15 js-java 2012-05-08 11:40:01 UTC
I have a file for you!

Some things I saw:

- a moved (reforctoring) a class file from one project to another (which is a class collection project to included by 

the other)
- NetBeans has to have focus
- I have to have a source file open, if I close all source files CPU load goes down to normal

File is 53 MB. So how do I upload the file? How much information on the souces do you get from this? It is a company project, so source if closed!

Is it correct that NetBeans is still usable after creating the dump?
Comment 16 Petr Cyhelsky 2012-05-23 12:40:14 UTC
Tomas's comment about low memory is valid - you have Xmx=256m which is very low for your machine which I assume (from some of your exception reports) has 4GB of memory. If it is the default setting, than there is perhaps a bug in launcher.

Did you change your netbeans.conf to use Xmx=256m or did you pass it on command line?

please attach your $netbeans_installation\etc\netbeans.conf and messages.log
Comment 17 js-java 2012-05-23 12:50:47 UTC
Created attachment 119774 [details]
netbeans.conf

I had to modify netbeans.conf due to bug 183941 which still occures on my system.
Comment 18 js-java 2012-05-24 09:23:35 UTC
I increased value to 512MB. If you are right, problem should not occure again or maybe take longer until it occures.
Comment 19 Petr Cyhelsky 2012-05-28 07:53:00 UTC
If you still get the problem from issue #183941 on current version of IDE you should reopen that issue. Xmx=256m is simply not enough memory for efficient run of J2EE or bigger edition. FYI the launcher should launch NB with Xmx=(physical memory)/5 which should in your case be around 800m.

closing as worksforme feel free to reopen if it happens with the increased heap size setting.
Comment 20 js-java 2012-06-04 16:04:58 UTC
Created attachment 120330 [details]
New snap

Bad news! Now I have the same problems on my Vista 64 system with only one open project and no modified netbeans.conf at all.
Comment 21 js-java 2012-06-04 16:06:09 UTC
Created attachment 120331 [details]
messages

I had to stop NetBeans the hard way to stop it as you'll see in the messages-log.
Comment 22 Petr Cyhelsky 2012-06-11 07:11:09 UTC
I don't see anything suspicious in the new snapshot. Some parsing was going on, but only for 21s out of 72s snapshot. The suspicious things are in messages log, there are many parsing - related exceptions there -> reassigning to parsing&indexing.
Comment 23 Tomas Zezula 2012-06-11 09:33:17 UTC
>there are many parsing - related exceptions there -> reassigning to parsing&indexing.
Nothing related to parsing.api (as I already explained above) -> the logged messages are the standard scan cancelled report (3 successive thread dums, scheduler stack, indexer statistics).

Looking at the snapshot: There is parsing of java file but the IO in it seems to be pretty slow.

To reporter: Are you able to reproduce the problem without running the tomcat integration?
Also there are several cygwin bash started from the IDE, what is it?
Can you try NB 7.2 (dev build) instead of the 7.1.x.

>Some parsing was going on, but only for 21s out of 72s snapshot.
Looking at snapshot the parsing took 7seconds (~10 parses of file, 5 of them were full file reparse after non local modification or after metadata change).

My suggestion is:
Try to reproduce with a dev build.
Separate the reproduction into simple cases:
  1st) No tomcat and other modules starting external processes -> if it works fine.
  2nd) Start the tomcat -> if it works fine
  3rd) Start the other features.
This will help to find out where is the problem.
Comment 24 js-java 2012-06-11 10:21:39 UTC
Last occurance on Vista was without Tomcat at all. Cygwin bash is started by the terminal window of Netbeans.

Netbeans is used for a commercial product, so I can't switch to a dev build. However, when 7.2 is released we will switch over.
Comment 25 Tomas Hurka 2012-06-11 10:25:24 UTC
I see. I am closing it as INCOMPLETE until we have info from 7.2
Comment 26 js-java 2012-06-19 08:27:02 UTC
Back to Windows 7: Even with increased memory settings, 100% CPU. A new information: I had NetBeans running all over the night after I left office. This morning when I started working NetBeans was slow. Maybe this can help you reproduce this.
Comment 27 d_a_n_i_e_I 2012-07-11 09:41:24 UTC
I've same problem using Ubuntu 10.04,
after setting in Options/General 'no proxy'
cpu java decrease in few seconds after focus Netbeans 6.8.
regards.
Comment 28 js-java 2012-08-13 13:53:01 UTC
Using 7.2 now for 2 weeks, problem didn't occure again.
Comment 29 Tomas Hurka 2012-09-24 10:55:25 UTC
(In reply to comment #28)
> Using 7.2 now for 2 weeks, problem didn't occure again.
OK, closing.
Comment 30 tn_trujillo 2012-10-01 21:28:11 UTC
Not fixed.  Still high cpu usage when I open a JPA project
Comment 31 Puls 2013-02-08 09:57:22 UTC
Hi I have the same problem with Netbean 7.2. It always happens when I edit files in a clas library project which contains a lot of JPA entities (e.g. whgen editing NamedQueries). Using Windows 64, Core i5, 8GB of Ram. I alredy tried to increse xmx to 2GB with no luck. When it happens the TaskManager shows 60-90% cpu usage and 1.9GB of used memory for the Netbeans process. It definately seems to be triggered by the JPA entities though.