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.
Created attachment 131537 [details] Profile of the IDE showing performance degradation. I have maintain copies of my MySQL procedures in SQL files. I used the IDE to modify the files and then connect to the database to apply my changes. After connecting and executing a SQL file the performance of the IDE begins to degrade to the point of it becoming unusable. However, the PC doesn't seem to degrade in performance - only the IDE. See attached IDE profile file. FYI, I started with a fresh start-up, opened two SQL files and, executed them both and let the IDE sit. You should see the IDE degrade. FYI, This problem has been around since netbeans 7.0. I'm finally fed up with it. Product Version: NetBeans IDE 7.2 (Build 201207171143) Java: 1.6.0_27; OpenJDK 64-Bit Server VM 20.0-b12 System: Linux version 3.2.0-37-generic running on amd64; UTF-8; en_US (nb) User directory: /home/vstokes/.netbeans/7.2 Cache directory: /home/vstokes/.cache/netbeans/7.2
It seems there are many threads running org.netbeans.api.db.explorer.node.ChildNodeFactory.createKeys() in parallel the cpu is finally consumed mostly by java.net.SocketInputStream.socketRead0 or by adding of listeners reassigning to db
@vstokosrj: can you provide the SQLs you executed - there are hooks triggering db metadata invalidation. It would be good to search targeted. @Petr: How do you come to the conclusion, that the child node creation of the DB module is the core problem? I look at the same snapshot and see a real CPU hog: The "File Watcher" Thread. I looks as if it's quite busy (318s active while running 318s). In contrast even taking into account that there are 3 Thread actively creating column nodes, they are all only active a quater of the execution time - the other time is spend in locks and waiting. This is at least my interpretation if the cpu runtime. It would nice if you could give me a pointer where to look a bit more.
The SQL statements being run are DROP/CREATE Procedures and Functions. The IDE always slows down at some point AFTER I execute the first SQL statement. It appears to slow down faster if the SQL server returns an error (as if there is a syntax error in the procedure). Attached (APCostGetExpVoy.sql) is one of the procedure scripts I DID use to cause the slow down.
Created attachment 131581 [details] One of the SQL scripts that cause the IDE to slow down. This is one of the SQL scripts I did run to cause the IDE to slow down. I think you can cause the IDE to slow down faster by creating a syntax error in the script so that the MySQL server (5.5.29) fails it.
Fir(In reply to comment #2) > @vstokosrj: > can you provide the SQLs you executed - there are hooks triggering db metadata > invalidation. It would be good to search targeted. > > @Petr: > How do you come to the conclusion, that the child node creation of the DB > module is the core problem? I look at the same snapshot and see a real CPU hog: > The "File Watcher" Thread. I looks as if it's quite busy (318s active while > running 318s). "File Watcher" thread is certainly not the problem - try for example to take snapshot of totally idle IDE - you will see, that it also "consumes" the full time. It is just the theory, not conclusion, that there is problem with db nodes - it would be great to have .npss file instead of .nps (in 7.2 you can find it in your temp dir when you take the self-sampling snapshot) that way we will conclusively see what is going on in a given moment (whether the "nodes" threads are running in parallel or consecutively) > In contrast even taking into account that there are 3 Thread actively creating > column nodes, they are all only active a quater of the execution time - the > other time is spend in locks and waiting. This is at least my interpretation if > the cpu runtime. The npss would be needed to decide this, but I can assure you that the file watcher is red herring and we need to look elsewhere. > It would nice if you could give me a pointer where to look a bit more. Also it would be nice to include not only npss, but also your messages.log to see some further info about your setup...
Since this is a reproducable event I will reproduce it and get the .npss file and the log file. Since I run Linux, where will these files be stored? /tmp? Is there a configuration option I must set? Where is the messages.log kept?
Created attachment 131611 [details] NPSS file of the first NPS file provided. I found the NPSS file that I believe belongs to the previous NPS file I uploded. It was still in my /tmp directory. Unfortunately the messages.log was gone - nb only keeps three versions. Does the team want me to recreate the all the files (nps, npss and log) or will this suffice?
Thank you for the NPSS. (In reply to comment #7) > Does the team want me to recreate the all the files (nps, npss and log) or will > this suffice? The log file wouldn't probably contain much info about the performance problem itself, but it would tell us something about your setup. If you could describe your system configuration (JDK, CPU, number of cores), the files that you've already attached should suffice. From the NPSS, it seems that you have expanded a lot of tables with lot of columns, and refreshing of them consumes a lot of CPU cycles. How many columns do you have under you connection? If you refresh you connection from context menu (Right-click the connection node -> Refresh), is the slowdown the same as if you run the SQL query? Thanks.
Created attachment 131630 [details] Screenshot of database connections Perhaps it's my database configuration causing this problem. I have several connections representing different databases to the same server. The database server (MySQL 5.5.29) has a lot of databases (40) and some of these databases are large. Some databases have 100+ tables and some of those tables have 100+ columns. Not sure it will help by please look at the attached screen shot and let me know if it's my connection configuration. More about my PC Configuration: CPU: Intel(R) Core(TM)2 Duo CPU E7600 @ 3.06GHz RAM: 4GB OS: Ubuntu 12.04 x64 (kernel 3.2.0-37-generic) java version "1.7.0_13" OpenJDK Runtime Environment (IcedTea7 2.3.6) (7u13-2.3.6-0ubuntu0.12.04.1) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
Thank you for the info. > Perhaps it's my database configuration causing this problem. > I have several connections representing different databases to the > same server. This is OK. > The database server (MySQL 5.5.29) has a lot of databases (40) and some of > these databases are large. Some databases have 100+ tables and some of those > tables have 100+ columns. I guess this is the problem. If you execute an SQL that modifies database schema (create or drop something), the whole schema is refreshed. If you have hundreds of tables with hundreds of columns, this is a lot of work. (Related code is at db.core\src\org\netbeans\modules\db\sql\loader\SQLEditorSupport.java:362.) > Not sure it will help by please look at the attached > screen shot and let me know if it's my connection configuration. The configuration is correct, but the schema is too complex and contains too many elements. Of course, NetBeans should manage it better. This could be fixed by more specific refreshing (not the whole connection, but only parent of modified element - this would require some non-trivial SQL parsing). Simpler, but not very user-friendly, way it to turn off automatic refreshing if the schema is too complex (but it's difficult to define what is complex).
OK, where do I turn off the Database Auto Refresh? I don't see and obvious way to do this. I tried Tools->Options and tried Right-Clicking the connection and I didn't see anything to modify.
(In reply to comment #11) > OK, where do I turn off the Database Auto Refresh? I don't see and obvious way > to do this. I'm sorry, I was just thinking about solutions that would fix this problem, but it has to be fixed in the source code. I cannot find any workaround for the current version of NetBeans.
It would be good if you could retest with a recent nightly build. There were changes that reduced the amount of nodes and refreshes, which should in theory also benefit this bug. Thank you!
I am running 8.02 and I no longer have this issue.
Thank you guys for evaluation and verification!