Java 应用程序在从 Ubuntu 18.04 升级到 20.04 后使用 <1% CPU



我正在开发Java/MySQL应用程序,批处理的测试运行在Ubuntu 18.04上需要3-4秒。

我昨晚升级到Ubuntu 20.04,并保留了相同的mysql conf文件,现在相同的应用程序需要1分45秒至47秒!!!

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

我注意到lscpu的服务器现在平均以最小频率运行。我试着添加";acpi=ht";到/etc/default/grub,然后重新启动机器,以关闭电源管理,但处理器仍在低频率下运行,可能频率提升不起作用。

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

使用mysqltuner检查服务器的InnoDB指标,看起来一切正常,所以这似乎与CPU设置/OS节流或Java配置/代码问题有关。

-------- 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)

在应用程序运行时运行top显示Java仅使用<启动后1%的cpu使用率。理想情况下,对于批处理过程,它将使用所有可用的处理能力。

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

运行压力我得到完整的cpu使用

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

maven pom.xml文件使用的mysql连接器版本与操作系统为mysql服务器8.0.21 安装的版本相同

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

java应用程序是被操作系统限制还是被JVM限制?

20.04和mysql或java是否存在已知问题?

MySQL JDBC驱动程序的默认行为在更新操作系统时明显发生了变化。

以前的驱动程序关闭了Java批处理更新的事务自动提交-在数据连接上手动添加/运行setAutoCommit(false)使运行时间恢复正常(显然它正在运行1000多个插入的原子事务(。

这是一个很好的例子,说明了为什么人们应该防御性地编写代码并添加有意的代码,即使默认行为/配置是代码中使用的内容——默认行为可以也会改变!

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

相关内容

  • 没有找到相关文章

最新更新