背景

同事再跟神通数据库的李老师沟通时获取了一套iotest的脚本.
但是发现iotest的脚本数据与fio的测试结构有所偏差.
然后就找到了我这边. 
我这边帮忙简单看了下. 发现主要如下:

甲方sa使用的是 fio 并且增加了iodepth=128的设置.
数据库dba写的程序里面应该是 iodepth=1 并且 numjobs=1
所以dba的测试结果,远小于sa的测试结果. 

结论不到十分钟就验证了出来.
但是中午突然想到一个问题:
fio 应该如何设置参数才能模拟数据库的写入进程数量? 

因为信创数据库的资料比较少, 所以计划先从Oracle数据库开始看起.

Oracle数据库的落盘进程

Oracle数据库主要是两种落盘的进程
dbwn和lgwr 进程

dbwn 是一组数据文件的写入进程
lgwr 是日志文件的写入进程
除非之后,监听进程可能写入监听日志
oracle$pid 进程也会写入很多其他日志信息. 

咱们这里主要考虑 数据文件的落盘, 也就是:
dbwr和lgwr

Oracle数据库落盘进程的数量-dbwr

关于dbwr :
官方资料是:
1 or CPU_COUNT / 8, 
whichever is greater. 
If the number of processor groups is less than 100 
but greater than the number of Database Writer Processes, 
then the number of Database Writer Processes is adjusted 
to be a multiple of the number of processor groups. 
If the number of Database Writer Processes is greater than or equal 
to the number of processor groups, then there is no adjustment.

For Oracle Solaris on SPARC systems, 
the default value of this parameter is calculated using an internal algorithm.

一般情况下 dbwr的进程就是 CPU线程数/8 
超线程的话 也计算为number of processor 

这里举例如下:
ps -ef |grep oracle |grep dbw |grep ora19c
oracle    94173      1  0  2022 ?        15:18:40 ora_dbw0_ora19c
oracle    94177      1  0  2022 ?        15:24:27 ora_dbw1_ora19c
oracle    94181      1  0  2022 ?        15:47:42 ora_dbw2_ora19c
oracle    94185      1  0  2022 ?        15:53:34 ora_dbw3_ora19c
oracle    94189      1  0  2022 ?        16:19:04 ora_dbw4_ora19c
oracle    94193      1  0  2022 ?        16:21:36 ora_dbw5_ora19c
oracle    94197      1  0  2022 ?        16:41:19 ora_dbw6_ora19c
oracle    94201      1  0  2022 ?        16:44:48 ora_dbw7_ora19c
oracle    94205      1  0  2022 ?        17:07:58 ora_dbw8_ora19c
oracle    94209      1  0  2022 ?        17:14:56 ora_dbw9_ora19c
oracle    94213      1  0  2022 ?        17:25:24 ora_dbwa_ora19c
oracle    94217      1  0  2022 ?        17:20:38 ora_dbwb_ora19c
oracle    94222      1  0  2022 ?        17:05:11 ora_dbwc_ora19c
oracle    94226      1  0  2022 ?        16:41:12 ora_dbwd_ora19c
oracle    94230      1  0  2022 ?        16:00:46 ora_dbwe_ora19c
oracle    94234      1  0  2022 ?        14:50:09 ora_dbwf_ora19c
oracle    94238      1  0  2022 ?        13:29:18 ora_dbwg_ora19c
oracle    94242      1  0  2022 ?        12:19:13 ora_dbwh_ora19c


CPU的信息为:
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                144
On-line CPU(s) list:   0-143
Thread(s) per core:    2
Core(s) per socket:    18
Socket(s):             4
NUMA node(s):          4

所以很明显, 他的计算公式算的是线程数, 而不是核心数. 
而且明显可以看到 CPU 使用时间还是比较均衡的.

Oracle数据库落盘进程的数量-lgwr

一般情况下认为:
在Oracle12c之前 lgwr只有一个进程在落盘
但是12c之后进行了一些性能优化: 

在oracle 12.1版本之前,oracle日志写进程LGWR为单进程,
oracle 12.1开始实现了SCALABLE LGWR多进程，
采用多个LGWR协同对redo log日志进行并行写入,
这是Oracle数据库内部最重要的改进，解决了最后的并发瓶颈点

SCALABLE LGWR主要受到隐藏参数:
_use_single_log_writer和_max_outstanding_log_writes的控制

_use_single_log_writer参数主要有三个可选值:
true,false,adaptive,默认值为adaptive
其中: 
false,adaptive:如果CPU个数大于一个则会有多个lg0n进程
true:不生成多个lg0n进程，如同12.1之前那样仅有单个LGWR
_max_outstanding_log_writes参数默认值为2
                        
来源：https://blog.csdn.net/lusklusklusk/article/details/111218889

比如我这边的情况为: 
ps -ef |grep oracle |grep lg |grep ora19c
oracle    94246      1  0  2022 ?        6-23:34:28 ora_lgwr_ora19c
oracle    94254      1  1  2022 ?        10-23:14:31 ora_lg00_ora19c
oracle    94260      1  0  2022 ?        00:21:52 ora_lg01_ora19c
oracle    94264      1  0  2022 ?        00:17:25 ora_lg02_ora19c
oracle    94274      1  0  2022 ?        17:54:38 ora_lg03_ora19c
oracle    94284      1  0  2022 ?        00:16:47 ora_lg04_ora19c
oracle    94288      1  0  2022 ?        00:15:20 ora_lg05_ora19c

可以看到虽然有多个 进程, 我这边至少有 6个 lgwr的进程
但是大部分的CPU使用量都几种与 lg00 的进程上面. 

关于fio的模拟

fio的模拟应该仿照oracle数据库的 dbwr+lgwr的进程数来进行 numjobs参数的设置
关于队列数字, 我这一块暂时没有想到比较好的验证何解办法.  

可以等后续有机会继续研究.