'Java 8 Performance Issues In Windows Server 2019

I have recently migrated some scheduled jobs from a Windows Server 2012 virtual server to a new Windows Server 2019 virtual server, and have noticed some notable performance degradation in certain jobs. Particularly, jobs which communicate with our DB2 database using an AS400 JDBC connection pool data source. The database is hosted on an IBM iSeries AS/400.

On Windows Server 2019, using jdk1.8.0_131, I'm running the following command:

java -jar myproject.jar

This project simply connects to the DB2 database and executes an SQL update command. On other servers, the same command will take ~2.5 minutes, but on Windows Server 2019 it takes anywhere from 15 minutes to over an hour. I have monitored CPU, RAM, and network activity on the server and database while the job is running, and nothing stands out. Below are the results of testing on various operating systems and JDKs:

| Server                              | JDK       | Runtime               |
|-------------------------------------|-----------|-----------------------|
| Windows Server 2012                 | 1.8.0_131 | ~2.5 minutes          |
| Windows Server 2016 (Fresh Install) | 1.8.0_131 | ~2.5 minutes          |
| Windows Server 2019 (Production)    | 1.8.0_131 | 15 minutes to an hour |
| Windows Server 2019 (Fresh Install) | 1.8.0_131 | 15 minutes to an hour |
| Windows Server 2019 (Fresh Install) | 1.8.0_202 | 15 minutes to an hour |

As shown above, I tried on a fresh install of server 2016 and did not experience the performance issues, but when I tried on a fresh install of Windows Server 2019, I was able to replicate the performance degradation.

These are all virtual servers with the same amount of CPU, RAM, and running on the same host.



Solution 1:[1]

Java support Server 2019 after 1.8.0_201 only.

https://www.oracle.com/java/technologies/javase/products-doc-jdk8-jre8-certconfig.html

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Mark Rotteveel