0

For SQL parsing we use General SQL Parser (GSP) in our Java web application. If we deploy our application with GSP on Windows Server 2008 R2 with Java 7 we see a 100% CPU peak during class loading which could last up to some minutes. After initial class loading everything works fine until we shut down the application server and the classes gets unloaded: the 100% CPU peak is back. If we deploy the identical code base to a Windows Server 2012, Windows 7 Enterprise, OS X or a Linux server there is no such peak. Using Java 8 on Windows Server 2008 R2 improves startup slightly.

With Microsoft`s Process Monitor we saw much time was wasted while loading classes from this jar. Class files in gsp.jar are obfuscated. We could rule out any other causes than the new added jar. Just by parsing a SQL statement cold startup time is significantly increased. Disabling antivirus has no effect. Upgrading to a newer Windows Server version is not an option for all of our customers.

We are running this GSP version:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.1
Created-By: 1.5.0_09-b01 (Sun Microsystems Inc.)
Built-By: Gudu Software
Vendor: Gudu Software
Title: General SQL Parser Java Version
Version: 1.6.0.5

This test program needs more than 40 seconds to execute with Windows Server 2008 R2, on OS X it took 1.5 seconds.

package com.stackoverflow;

import gudusoft.gsqlparser.EDbVendor;
import gudusoft.gsqlparser.TGSqlParser;

public class TestGSP {
    public static void main(String[] args) {
        TGSqlParser parser = new TGSqlParser(EDbVendor.dbvmssql);
        parser.setSqltext("select a from b where c = d");
        parser.parse();
    }
}

Does anybody have an idea what causes this problem and how to avoid it?


Edit I took a fresh Windows Server 2008 R2 and run the test program with different RAM/JVM settings:

e.g.: java -Xmx1G -classpath ".\;.\gsp.jar" com.stackoverflow.TestGSP

+--------------+-----------+----------------+
| Java version | RAM in GB | Duration in ms |
+--------------+-----------+----------------+
| 1.7.0_79     |         1 |          33438 |
| 1.7.0_79     |         2 |          33640 |
| 1.7.0_79     |         4 |          33484 |
| 1.8.0_66     |         1 |           5437 |
| 1.8.0_66     |         2 |           5563 |
| 1.8.0_66     |         4 |           5703 |
+--------------+-----------+----------------+

If I run the same test on OS X I get this durations:

+--------------+-----------+----------------+
| Java version | RAM in GB | Duration in ms |
+--------------+-----------+----------------+
| 1.7.0_79     |         1 |           1024 |
| 1.7.0_79     |         2 |            999 |
| 1.7.0_79     |         4 |            968 |
| 1.8.0_65     |         1 |            601 |
| 1.8.0_65     |         2 |            601 |
| 1.8.0_65     |         4 |            603 |
+--------------+-----------+----------------+

Changing JVM version helps, but increasing RAM doesn't solves the problem.

mystygage
  • 371
  • 1
  • 3
  • 6
  • Are you loading classes from a network share or something like that? – Stephen C Oct 27 '15 at 09:47
  • @Stephen: no, classes and jars are local. We use Tomcat as application sever and jars are in WEB-INF/lib – mystygage Oct 27 '15 at 10:06
  • Do you have enough RAM? Seriously, I think the problem with the server and the way it is configured ... not Java, per se. – Stephen C Oct 27 '15 at 10:46
  • @StephenC Server has 6GB RAM total and 2GB are assigned to the web application process. I'll re-run my test with more RAM. I also do not think it is primary a Java, but more a Windows problem. – mystygage Oct 27 '15 at 11:14
  • @StephenC I updated my question with some measures – mystygage Oct 29 '15 at 11:42

0 Answers0