数据库超线程效果的一个验证

背景

元旦加班期间,一直跟着同事再查一个项目的卡顿问题. 

自己想到了一个提高测试环境性能的方法. 然后趁着元旦用的人少进行了一下验证.

在业务空闲期间, 批量进行Oracle数据库的统计信息更新动作. 

自己一开始担心的是 如果数据量很大, 执行时间很长,如果影响到正常业务会导致比较严重的问题. 

所以一直在验证这个统计信息收集消耗时间相关的情况.

发现可以验证到超线程相关, 感觉还是比较有意想不到的收获的

环境说明

数据库情况 200G的数据文件 20000张表. 
数据库配置 4 * Golden6170 2.7Ghz 18Core 1T内存
CPU信息合计  72Cores  144Threads
磁盘信息: 12块1.92TSSD raid10 

验证情况

我这边执行了如下的三个SQL, 其他条件完全一样, 只是并行度不同:
我也验证了 第一次的时间和后续的时间变化基本上不大, 我先试用 72 并行度 生成完成之后再进行三次验证, 分别的时间为:


exec dbms_stats.gather_schema_stats(ownname =>'mydbname',options => 'GATHER',estimate_percent => dbms_stats.auto_sample_size, method_opt => 'for all columns size repeat', degree => 72)
Elapsed: 00:26:29.11
SAR监控信息     CPU     %user     %nice   %system   %iowait    %steal     %idle
02:40:01 PM     all      1.90      0.00     13.93      0.08      0.00     84.09
02:50:01 PM     all      1.99      0.00     19.71      0.03      0.00     78.27
03:00:01 PM     all      2.11      0.00     24.91      0.03      0.00     72.95

exec dbms_stats.gather_schema_stats(ownname =>'mydbname',options => 'GATHER',estimate_percent => dbms_stats.auto_sample_size, method_opt => 'for all columns size repeat', degree => 144)
Elapsed: 00:51:40.06
SAR监控信息     CPU     %user     %nice   %system   %iowait    %steal     %idle
03:20:01 PM     all      1.64      0.00     13.57      0.03      0.00     84.77
03:30:01 PM     all      1.90      0.00     35.82      0.02      0.00     62.26
03:40:01 PM     all      1.79      0.00     67.85      0.01      0.00     30.36
03:50:01 PM     all      2.00      0.00     53.62      0.02      0.00     44.37
04:00:01 PM     all      2.03      0.00     49.40      0.01      0.00     48.56
04:10:01 PM     all      2.20      0.00     49.96      0.01      0.00     47.83

exec dbms_stats.gather_schema_stats(ownname =>'mydbname',options => 'GATHER',estimate_percent => dbms_stats.auto_sample_size, method_opt => 'for all columns size repeat', degree => 36)
Elapsed: 00:20:22.54
SAR监控信息     CPU     %user     %nice   %system   %iowait    %steal     %idle
04:40:01 PM     all      6.21      0.00      4.24      0.04      0.00     89.50
04:50:01 PM     all     17.36      0.00      3.83      0.02      0.00     78.80

如果修改为一个核心上面的所有核心数
exec dbms_stats.gather_schema_stats(ownname =>'mydbname',options => 'GATHER',estimate_percent => dbms_stats.auto_sample_size, method_opt => 'for all columns size repeat', degree => 18)
Elapsed: 00:17:36.09
SAR监控信息     CPU     %user     %nice   %system   %iowait    %steal     %idle
05:08:01 PM     all      2.52      0.00      0.76      0.03      0.00     96.70
05:09:01 PM     all      2.58      0.00      0.85      0.02      0.00     96.55
05:10:01 PM     all     16.82      0.00      0.98      0.03      0.00     82.17
05:11:01 PM     all      3.35      0.00      0.95      0.03      0.00     95.68
05:12:01 PM     all      3.46      0.00      1.48      0.04      0.00     95.02
05:13:01 PM     all      3.92      0.00      1.10      0.03      0.00     94.95
05:14:01 PM     all      3.77      0.00      1.27      0.03      0.00     94.93
05:15:01 PM     all      6.63      0.00      2.89      0.02      0.00     90.46
05:16:02 PM     all      3.05      0.00      0.98      0.03      0.00     95.94
05:17:01 PM     all      3.80      0.00      1.91      0.04      0.00     94.26
05:18:01 PM     all      3.23      0.00      1.04      0.03      0.00     95.71
05:19:01 PM     all      2.57      0.00      1.34      0.03      0.00     96.07
05:20:01 PM     all      3.16      0.00      1.40      0.03      0.00     95.41
05:21:01 PM     all      2.45      0.00      0.94      0.03      0.00     96.58
05:22:01 PM     all      3.07      0.00      1.51      0.03      0.00     95.39
05:23:01 PM     all      5.10      0.00      1.58      0.02      0.00     93.30
05:24:01 PM     all      1.94      0.00      0.70      0.02      0.00     97.34
05:25:01 PM     all      2.48      0.00      0.72      0.02      0.00     96.78

简单总结

数据库还是建议关闭超线程

如果使用线程数的CPU进行数据库的大量消耗操作时明显可以看到, 数据库的消耗要搞很多,
需要花费更多的时间, 消耗更多的CPU. 压力更大时间更慢

跟CPU的核心数一样的情况下:        SYSCPU的平均压力才20%, 用户态的压力 2%
但是跟CPU的超线程数量一样的情况下: SYSCPU的平均压力才50%, 用户态的压力 2%

时间是两倍, CPU的压力是 2.5倍 
理论上增加了 5 倍的CPU计算周期. 只干出来完全相同的结果. 

四路服务器上面, 仅使用一般的核心数, 那么时间只有使用全部核心数的 80%
并且CPU的使用率从核心态到了用户态, 还是有很大的优化空间的. 

减少到只使用一个插座上面的核心数的并行度时: 时间更快
并且系统态的使用是是最短的. 


静下新来还是能看到很多比较有效果的事情的. 

阿里云机器上面的验证

一个 8C/64G的虚拟机
上面数据库的大小为: 13G
表的数量为 10k
比较奇怪的是 阿里云上面虚拟机的并行度 基本上没有影响. 这一块再学习和了解一下. 

degree 1 
Elapsed: 00:03:45.09
17时00分01秒     all     12.47      0.00      0.14      1.78      0.00     85.61
17时01分01秒     all     12.79      0.00      0.19      2.24      0.00     84.77
17时02分01秒     all     12.44      0.00      0.16      2.13      0.00     85.27

degree 2 
Elapsed: 00:03:47.89
17时07分01秒     all     12.54      0.00      0.17      1.90      0.00     85.39
17时08分01秒     all     12.73      0.00      0.18      1.82      0.00     85.27
17时09分01秒     all     12.61      0.00      0.18      2.26      0.00     84.95

degree 4
Elapsed: 00:03:47.88
17时12分01秒     all     12.58      0.00      0.13      1.76      0.00     85.53
17时13分01秒     all     13.21      0.00      0.32      2.22      0.00     84.25
17时14分01秒     all     12.69      0.00      0.18      2.09      0.00     85.03

degree 8
Elapsed: 00:03:49.01
17时22分01秒     all     12.62      0.00      0.29      1.87      0.00     85.22
17时23分01秒     all     12.71      0.00      0.17      1.63      0.00     85.49
17时24分01秒     all     13.42      0.00      0.29      2.38      0.00     83.91
17时25分01秒     all     10.03      0.00      0.13      1.63      0.00     88.20

degree 9
Elapsed: 00:03:47.09
17时27分01秒     all     12.58      0.00      0.16      1.99      0.00     85.27
17时28分01秒     all     13.45      0.00      0.21      2.13      0.00     84.21
17时29分01秒     all     12.81      0.00      0.26      2.29      0.00     84.64

degree 16
Elapsed: 00:03:46.52
17时32分01秒     all     12.65      0.00      0.19      1.95      0.00     85.21
17时33分01秒     all     13.78      0.00      0.32      2.04      0.00     83.86
17时34分01秒     all     12.80      0.00      0.19      2.43      0.00     84.58