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.
| Summary: | Netbeans Super Slow while "Finding Packages" | ||
|---|---|---|---|
| Product: | platform | Reporter: | mclaborn <mclaborn> |
| Component: | Filesystems | Assignee: | Jaroslav Havlin <jhavlin> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 8.1 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: | https://netbeans.org/bugzilla/show_bug.cgi?id=262355 | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
IDE log
Stack trace while very slow IDE log from latest occurence THIS is the messages.log from latest occurence Experimental patch to speedup FileUtil.toFile() Visual VM snapshot IDS log that matches Visual VM snapshot |
||
Created attachment 155744 [details]
Stack trace while very slow
Product Version = NetBeans IDE 8.1 Beta (Build 201508041349) Operating System = Linux version 3.13.0-62-generic running on amd64 Java; VM; Vendor = 1.8.0_51 Runtime = Java HotSpot(TM) 64-Bit Server VM 25.51-b03 Reassigning for further evaluation. Please attach CPU snapshot of the time when NetBeans was slow http://wiki.netbeans.org/FaqProfileMeNow and also attach the messages.log from that time. Thanks. messages.log is already attached. No CPU snapshot is available for the problem instance reported. If this happens again with the beta I will attempt to capture a profile. In the previous occurrence, the entire system was extremely slow. It may not be possible to get a profile, but I'll do my best. (In reply to mclaborn from comment #5) > messages.log is already attached. > No CPU snapshot is available for the problem instance reported. > > If this happens again with the beta I will attempt to capture a profile. In > the previous occurrence, the entire system was extremely slow. It may not be > possible to get a profile, but I'll do my best. Thanks. We need messages.log and CPU snapshot (npss file) from the same run. So when it happens again, please attach both. Of course if you are able to provide steps to reproduce, it will be even better. Happened again. I was in the middle of creating a new web project. Can't say exactly when during that process the problem started. The other instances were NOT during creating a web project. Snapshot and messages log coming shortly. Created attachment 155924 [details]
IDE log from latest occurence
Comment on attachment 155924 [details]
IDE log from latest occurence
Sorry - that last attachment is the profiler snapshot.
Created attachment 155925 [details]
THIS is the messages.log from latest occurence
(In reply to mclaborn from comment #8) > Happened again. I was in the middle of creating a new web project. Can't > say exactly when during that process the problem started. The other > instances were NOT during creating a web project. Snapshot and messages log > coming shortly. Thanks for the snapshot, although it would be better if you could attach npss (not naps) file next time - there is event special action in toolbar ("Attach IDE snapshot to bug..") which attaches npss file directly to bug. Most of the time is spent in org.openide.filesystems.FileUtil.toFile() and consequently in org.openide.filesystems.URLMapper.findURL(). Several "Data System Nodes" threads are accessing disk in parallel together with "org.netbeans.spi.java.project.support.ui.PackageRootNode" thread. It looks like you are browsing jar(s) content in the project view. Number of "Data System Nodes" was increased to 10 by fix of issue #252073. So one solution could be to revert this change and use single-threaded processor. This will prevent simultaneous I/O access from several "Data System Nodes". Another possibility would be to improve speed of org.openide.filesystems.FileUtil.toFile() - this method will return null for FileObject-s from jars, but it first construct expensive URL via org.netbeans.core.startup.layers.ArchiveURLMapper.getURL(). This could be improved by simply checking for JarFilesystem. See attached patch. Reassigning to platform/filesystem for further evaluation. Created attachment 155942 [details]
Experimental patch to speedup FileUtil.toFile()
I'm quite certain I was not intentionally browsing JAR file content in the project view and I don't see how that could happen accidentally. Are there other actions in NetBeans that might trigger this type of scanning? Do you need further diagnostics? > Experimental patch to speedup FileUtil.toFile() Integrated, see http://hg.netbeans.org/core-main/rev/c70bc28359a1. Thank you, Tomas. > I'm quite certain I was not intentionally browsing JAR file content in the > project view and I don't see how that could happen accidentally. Are there > other actions in NetBeans that might trigger this type of scanning? Yes, e.g. browsing project libraries or JDK packages, probably several others. > Do you need further diagnostics? It seems that we have all we need for now. Thank you very much. > Number of "Data System Nodes" was increased to 10 by fix of issue #252073. > So one solution could be to revert this change and use single-threaded > processor. This will prevent simultaneous I/O access from several > "Data System Nodes". http://hg.netbeans.org/core-main/rev/cc9d38e2cdbe The changeset has been reverted. Closing this issue as fixed. Please verify. Thank you for reporting and help. How do I verify this fix? Download a nightly build from http://bits.netbeans.org/download/trunk/nightly/latest/ ?? I've test with the latest dev build (201509080002). When the "Finding packages..." operation is running it no longer completely locks up NetBeans, but it still has a significant impact on performance. NetBeans periodically becomes unresponsive (UI thread) for 15 - 20 seconds at a time, then recovers. I don't have hard evidence to back it up, but it seems like this "Finding packages..." is running more frequently in 8.1 than it did in 8.0. I don't recall ever having seen that in 8.0 and now I'm seeing it daily or more. Revision to my earlier comment: After a while, NetBeans became so unresponsive as to be essentially useless. It was "Finding packages in /usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/rt.jar" for a LONG time (15+ minutes). I was unable to get a NetBeans snapshot, but I do have a Visual VM snapshot, will attach it shortly. Created attachment 155990 [details]
Visual VM snapshot
Created attachment 155991 [details]
IDS log that matches Visual VM snapshot
> How do I verify this fix? Download a nightly build from
> http://bits.netbeans.org/download/trunk/nightly/latest/ ??
Yes, but please wait until the fix is integrated into the build.
You will be automatically notified (by a comment in this issue) when it is available (it can take a few days).
If the problems remain in fixed build, please feel free to reopen the issue again.
Thank you.
Integrated into 'main-silver', will be available in build *201509100002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/c70bc28359a1 User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #254845: NetBeans Super Slow while "Finding Packages" |
Created attachment 155743 [details] IDE log Netbeans all of a sudden turned SUPER SLOW. Seeing tasks at the bottom like "Finding packages in blahblahblah.jar". CPU was extremely high. Could not even get NB to respond enough to submit the bug report from inside NB. This has happened twice in the 8.1 beta.