Java app is using <1% cpu after upgrade from Ubuntu 18.04 to 20.04

I'm working on a Java / MySQL app and test runs of batch processing were taking 3-4seconds on Ubuntu 18.04.

I made the upgrade to Ubuntu 20.04 last night, and kept the same mysql conf file, and now the same app is taking 1min and 45-47 seconds!!!

6.27user 0.41system 1:45.53elapsed 6%CPU (0avgtext+0avgdata 168724maxresident)k
0inputs+384outputs (0major+42056minor)pagefaults 0swaps

I noticed with lscpu that the server is now running in min freq on average. I tried adding "acpi=ht" to /etc/default/grub, and restarted the machine, to turn off power management but the processors is still running at low frequency and presumably frequency boost isn't working.

On-line CPU(s) list:             0-15
Thread(s) per core:              2
Core(s) per socket:              4
Socket(s):                       2
NUMA node(s):                    2
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           44
Model name:                      Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz
Stepping:                        2
Frequency boost:                 enabled
CPU MHz:                         1599.592
CPU max MHz:                     2401.0000
CPU min MHz:                     1600.0000
BogoMIPS:                        4799.75
Virtualization:                  VT-x
L1d cache:                       256 KiB
L1i cache:                       256 KiB
L2 cache:                        2 MiB
L3 cache:                        24 MiB

Using mysqltuner to check the server's InnoDB metrics things look OK, so it seems like this is related to the CPU settings / OS throttling or a Java configuration / code issue.

-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 8
[OK] InnoDB File per table is activated
[OK] InnoDB buffer pool / data size: 9.0G/2.6G
[OK] Ratio InnoDB log file size / InnoDB Buffer pool size: 1.0G * 2/9.0G should be equal 25%
[OK] InnoDB buffer pool instances: 9
[--] Number of InnoDB Buffer Pool Chunk : 72 for 9 Buffer Pool Instance(s)
[OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[OK] InnoDB Read buffer efficiency: 99.90% (2901594 hits/ 2904524 total)
[!!] InnoDB Write Log efficiency: 75.47% (19033 hits/ 25219 total)
[OK] InnoDB log waits: 0.00% (0 waits / 6186 writes)

Running top while the app is running shows that Java is only using <1%cpu usage after startup. For a batch process ideally it'd use all available processing power.

   2113 mysql     20   0   25.7g   2.7g  36264 S   4.3  11.6   0:12.35 mysqld
    353 root      20   0       0      0      0 S   2.7   0.0   0:02.99 md0_raid5
    244 root       0 -20       0      0      0 I   0.7   0.0   0:00.98 kworker/10:1H-kblockd
    248 root       0 -20       0      0      0 I   0.7   0.0   0:00.07 kworker/8:1H-kblockd
    399 root      20   0       0      0      0 D   0.7   0.0   0:00.61 jbd2/md0-8
   2372 bias      20   0 5597164 180592  27784 S   0.7   0.7   0:07.54 java

Running stress I get full cpu usage

   4654 user      20   0    3856    100      0 R 100.0   0.0   0:13.88 stress
   4643 user      20   0    3856    100      0 R 100.0   0.0   0:13.82 stress
   4645 user      20   0  134932   3272    272 R 100.0   0.0   0:13.84 stress
   4646 user      20   0    3856    100      0 R 100.0   0.0   0:13.80 stress

The maven pom.xml file is using the same mysql connector version that the OS has installed for the mysql server 8.0.21

 39     <dependency>
 40        <groupId>mysql</groupId>
 41        <artifactId>mysql-connector-java</artifactId>
 42        <version>8.0.21</version>
 43     </dependency>

Is the java app being throttled by the OS or by the JVM?

Are there known issues with 20.04 and mysql or java?

The MySQL JDBC driver default behavior apparently changed when updating the OS.

The previous driver turned off transaction auto commits for Java batch updates - manually adding/running setAutoCommit(false) on the data connection dropped the run time back to normal (apparently it was running atomic transactions for 1000 some inserts).

This is a good example of why people should defensively code and add intentional code even if the default behavior/configuration is what's used in code - the default can and will change!

https://coderanch.com/t/299833/databases/Batch-update-setAutoCommit-false