MogDB 学习笔记系列之 — 认识bgwriter线程

MogDB是云和恩墨公司基于openGauss所做的商业发行版，这里的商业发行版并非简单包装，换个壳，而是做了不少Bug修复和增强，目前也在研发相关的数据库迁移、数据比对、高可用管理，性能分析等工具，这里做说。

为了便于大家更好的学习和掌握MogDB，我打算陆续分享一些MogDB的技术知识，仅限于个人学习测试，不代表公司观点。

[root@ecs-1461 ~]# ps -ef|grep mogdb|grep -v grep
omm 110702 1 0 Sep03 ? 10:38:52 /u01/mogdb/bin/mogdb -D /data/mogdb/data/db1
[root@ecs-1461 ~]# ps -T -p 110702
PID SPID TTY TIME CMD
110702 110702 ? 00:00:23 mogdb
110702 110703 ? 00:00:00 jemalloc_bg_thd
110702 110706 ? 00:00:00 mogdb
110702 110707 ? 00:00:12 syslogger
110702 110708 ? 00:00:00 jemalloc_bg_thd
110702 110709 ? 00:05:22 alarm
110702 110710 ? 00:00:06 reaper
110702 110711 ? 00:00:00 jemalloc_bg_thd
110702 110712 ? 00:00:00 jemalloc_bg_thd
110702 110737 ? 00:01:35 checkpointer
110702 110738 ? 00:01:12 pagewriter
110702 110739 ? 01:34:06 pagewriter
110702 110740 ? 00:00:37 bgwriter
110702 110741 ? 00:00:37 bgwriter
110702 110742 ? 04:30:46 WALwriter
110702 110743 ? 00:00:00 WALwriteraux
110702 110744 ? 00:00:05 AVClauncher
110702 110745 ? 00:05:11 Jobscheduler
110702 110746 ? 00:00:13 statscollector
110702 110747 ? 00:46:06 snapshotworker
110702 110748 ? 01:09:16 percentworker
110702 110749 ? 01:26:18 ashworker
110702 110750 ? 00:34:03 TrackStmtWorker
110702 110751 ? 00:00:07 auditor
110702 110752 ? 00:00:20 2pccleaner
110702 110753 ? 00:00:00 faultmonitor
110702 110754 ? 00:00:52 WLMworker
110702 110755 ? 00:10:56 WLMmonitor
110702 110756 ? 00:00:05 WLMarbiter

由于MogDB是openGauss的商业发行版本,因此数据库内核层面几乎继承了原生openGauss内核，我司内核团队在其基础之上做了一些优化和Bug修复。
我们不难看出，MogDB采用了单进程，多线程架构，这一点跟MySQL类似（原生PostgreSQL是多进程架构).

对于关系数据库来讲，我们知道，最核心的进程（或者线程）其实就那么几个。因此对于MogDB 的学习笔记系列，我们就从线程开始讲起。

熟悉我们来看bgwriter线程。可以看到默认情况下，有2个bgwriter线程，这里我们查看一下数据库相关参数配置：

postgres=# select name,setting,category,context from pg_settings where name like '%bgwriter%';
name | setting | category | context
-------------------------+---------+------------------------------------+------------
bgwriter_delay | 2000 | Resource Usage / Background Writer | sighup
bgwriter_flush_after | 64 | Resource Usage / Background Writer | sighup
bgwriter_lru_maxpages | 100 | Resource Usage / Background Writer | sighup
bgwriter_lru_multiplier | 2 | Resource Usage / Background Writer | sighup
bgwriter_t

接下来我们同MogDB提供的gstrace 工具来跟踪一下，看看能否有些发现：

[omm@ecs-1461 shm]$ gstrace start -p 110702
Shared memory buffer has been initialized.
[GAUSS-TRACE] start Success!
[omm@ecs-1461 shm]$ gstrace dump -p 110702 -o /tmp/110702.dump
Shared memory buffer has been dumped to file: /tmp/110702.dump.
[GAUSS-TRACE] dump Success!
[omm@ecs-1461 shm]$ gstrace dump -p 110702 -o /tmp/110702.dump
Shared memory buffer has been dumped to file: /tmp/110702.dump.
[GAUSS-TRACE] dump Success!
[omm@ecs-1461 shm]$ gstrace detail -f /tmp/110702.dump -o /tmp/110702.detail
Found 1058496 trace records and formatted 1058496 of them
[GAUSS-TRACE] detail Success!
[omm@ecs-1461 shm]$ gstrace analyze -f /tmp/110702.dump -o /tmp/110702.analyze
Found 1058496 trace records and formatted 1058496 of them(most recent)
[GAUSS-TRACE] analyze Success!
[omm@ecs-1461 shm]$ gstrace codepath -f /tmp/110702.dump -o /tmp/110702.codepath
Found 1058496 trace records and formatted 1058496 of them(most recent)
[GAUSS-TRACE] codepath Success!
 
[root@ecs-1461 tmp]# cat 110702.analyze
MODULE FUNCTION #CALL ELAPSETIME(total) ELAPSETIME(avg.) ELAPSETIME(max.) ELAPSETIME(min.) SEQUENCE(max.) SEQUENCE(min.)
access XLogFileInit 8 134 17 17 16 71326 483349
access CreateCheckPoint 3 2601457 867152 2426568 56951 650587 650909
access CheckPointGuts 3 2401684 800561 2384169 5218 650579 650738
access StartTransaction 226 3052 14 21 5 24 650629
access KeepLogSeg 3 60 20 24 18 650903 650581
access RemoveOldXlogFiles 3 44459 14820 44419 20 650743 650584
access dw_truncate 3 2370936 790312 2354311 4768 650577 650736
access heap_page_prepare_for_xid 501029 682082 1 50897 0 689398 155
access ExtendCSNLOG 2 2 1 1 1 143 143
access PreallocXlogFiles 3 2 1 1 0 650586 650745
executer ExecutorStart 2 184 92 92 92 141 141
executer ExecCheckRTPerms 2 13 6 7 6 650926 67
executer ExecInitNode 4 287 72 76 67 139 138
executer ExecInitExpr 68 205 3 51 0 650994 650948
executer InitPlan 2 175 88 88 87 650999 140
executer ExecCheckRTEPerms 6 6 1 2 0 62 66
storage CheckPointBuffers 3 2374838 791613 2358204 4772 650578 650737
storage fsm_search 12946 31775 2 11150 0 877716 2113
storage fsm_set_and_search 14927 18816 1 213 0 238319 9957
tcop PortalStart 2 8 4 5 3 56 650915
tcop PortalRun 1 6805278 6805278 6805278 6805278 650490 650490
 
[root@ecs-1461 tmp]# cat 110702.codepath |grep "tid: "
pid: 110702 tid: 110737
pid: 110702 tid: 110742
pid: 110702 tid: 110743
pid: 110702 tid: 110744
pid: 110702 tid: 110745
pid: 110702 tid: 110754
pid: 110702 tid: 475866
pid: 110702 tid: 476092
pid: 110702 tid: 476162
pid: 110702 tid: 476178
pid: 110702 tid: 476290
pid: 110702 tid: 476317
pid: 110702 tid: 476320
pid: 110702 tid: 476321
pid: 110702 tid: 476322
pid: 110702 tid: 476343
pid: 110702 tid: 476429
pid: 110702 tid: 476441
pid: 110702 tid: 476445
pid: 110702 tid: 476461
pid: 110702 tid: 476462
pid: 110702 tid: 476465
pid: 110702 tid: 476466
pid: 110702 tid: 476467
pid: 110702 tid: 476508
pid: 110702 tid: 476515
pid: 110702 tid: 476543
pid: 110702 tid: 476584
pid: 110702 tid: 476599
pid: 110702 tid: 476639
pid: 110702 tid: 476675
pid: 110702 tid: 476691
pid: 110702 tid: 476692
pid: 110702 tid: 476693

从gstrace跟踪来看，主要是用来诊断数据库性能的，并不能跟踪到bgwriter线程的工作情况。看来还是要用通用的操作系统工具来进行。

+++session 插入部分数据

enmotech=# insert into test20211019 select * from test20211019;
INSERT 0 2465792
enmotech=# insert into test20211019 select * from test20211019;
 
INSERT 0 4931584
enmotech=#
enmotech=#
enmotech=# SELECT OID,relname FROM pg_class where relname='test20211019';
oid | relname
-------+--------------
16421 | test20211019
(1 row)
 
enmotech=#

+++session 2 进行strace跟踪

[root@ecs-1461 tmp]# strace -T -tt -f -e trace=read,open,write,pwrite64,pread64 -o /tmp/110740_trace.log -p 110740
strace: Process 110740 attached with 30 threads
strace: Process 477119 attached
^Cstrace: Process 110740 detached
strace: Process 110702 detached
strace: Process 110703 detached
strace: Process 110706 detached
strace: Process 110707 detached
strace: Process 110708 detached
strace: Process 110709 detached
strace: Process 110710 detached
strace: Process 110711 detached
strace: Process 110712 detached
strace: Process 110737 detached
strace: Process 110738 detached
strace: Process 110739 detached
strace: Process 110741 detached
strace: Process 110742 detached
strace: Process 110743 detached
strace: Process 110744 detached
strace: Process 110745 detached
strace: Process 110746 detached
strace: Process 110747 detached
strace: Process 110748 detached
strace: Process 110749 detached
strace: Process 110750 detached
strace: Process 110751 detached
strace: Process 110752 detached
strace: Process 110753 detached
strace: Process 110754 detached
strace: Process 110755 detached
strace: Process 110756 detached
strace: Process 476599 detached
 
[root@ecs-1461 tmp]#

进一步分析了一下trace log发现，目前对于数据落盘写入，还无法进行合并，仍然是单块写入（默认情况下)。
从这点来看，对于大数据量大写入，这里可能会是一个潜在的性能瓶颈，我们知道Oracle其实在很早版本就实现了IO 合并写入的。

[root@ecs-1461 tmp]# cat /tmp/110740_trace.log |grep 110740|grep 'pwrite64(1'| head -10
110740 15:31:08.398007 pwrite64(109, "\0\0\0\0\310\272\341o\326\274@\0\304\0\10\1\0 \6 \0\0\0\0\3745\0\0\0\0\0\0"..., 8192, 933101568 <unfinished ...>
110740 15:31:08.421058 pwrite64(109, "\0\0\0\0\220\341\341o.\357@\0\304\0\340\0\0 \6 \0\0\0\0\3745\0\0\0\0\0\0"..., 8192, 933109760 <unfinished ...>
110740 15:31:08.446235 pwrite64(109, "\0\0\0\0 \10\342o\373\206@\0\300\0\350\0\0 \6 \0\0\0\0\3745\0\0\0\0\0\0"..., 8192, 933117952 <unfinished ...>
110740 15:31:08.468787 pwrite64(109, "\0\0\0\0\240{\342oW\256@\0\324\0\10\1\0 \6 \0\0\0\0\3745\0\0\0\0\0\0"..., 8192, 933142528 <unfinished ...>
110740 15:31:08.491750 pwrite64(109, "\0\0\0\0\240\310\342ot\2@\0\274\0\10\1\0 \6 \0\0\0\0\3745\0\0\0\0\0\0"..., 8192, 933158912 <unfinished ...>
110740 15:31:08.514866 pwrite64(109, "\0\0\0\0\250\26\343o\343\217@\0\334\0\370\0\0 \6 \0\0\0\0\3745\0\0\0\0\0\0"..., 8192, 933175296 <unfinished ...>
110740 15:31:08.538839 pwrite64(109, "\0\0\0\0p>\343o\307\304@\0\340\0(\1\0 \6 \0\0\0\0\3745\0\0\0\0\0\0"..., 8192, 933183488 <unfinished ...>
110740 15:31:08.562886 pwrite64(109, "\0\0\0\0\0e\343o\371Y@\0\300\0\340\0\0 \6 \0\0\0\0\3745\0\0\0\0\0\0"..., 8192, 933191680 <unfinished ...>
110740 15:31:08.586776 pwrite64(109, "\0\0\0\0p\260\343o\0234@\0\254\0\310\0\0 \6 \0\0\0\0\3745\0\0\0\0\0\0"..., 8192, 933208064 <unfinished ...>
110740 15:31:08.610725 pwrite64(109, "\0\0\0\0\330\"\344o\33\3@\0\304\0`\1\0 \6 \0\0\0\0\3745\0\0\0\0\0\0"..., 8192, 933232640 <unfinished ...>
[root@ecs-1461 tmp]# cat /tmp/110740_trace.log |grep 110740|grep 'pwrite64(1'| tail -20
110740 15:32:18.279547 pwrite64(123, "\0\0\0\0P\243\304\302]\7@\0\244\0\350\0\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013366784 <unfinished ...>
110740 15:32:18.279623 pwrite64(123, "\0\0\0\0\320\25\305\302\253\332@\0\304\0X\1\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013391360) = 8192 <0.000014>
110740 15:32:18.279691 pwrite64(123, "\0\0\0\0h<\305\302\22%@\0\300\0\320\0\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013399552) = 8192 <0.000013>
110740 15:32:18.279765 pwrite64(123, "\0\0\0\0\250b\305\302\311a@\0\274\0\10\1\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013407744 <unfinished ...>
110740 15:32:18.279844 pwrite64(123, "\0\0\0\0\340T\307\302?\313@\0\310\0 \1\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013514240) = 8192 <0.000014>
110740 15:32:18.279912 pwrite64(123, "\0\0\0\0\300\332\310\3021~@\0\334\0\30\1\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013596160) = 8192 <0.000013>
110740 15:32:18.279985 pwrite64(123, "\0\0\0\0x'\311\302p\263@\0\270\0\270\0\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013612544 <unfinished ...>
110740 15:32:18.280064 pwrite64(123, "\0\0\0\0 r\311\302\314/@\0\300\0000\1\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013628928) = 8192 <0.000013>
110740 15:32:18.280132 pwrite64(123, "\0\0\0\0p\231\311\302\301\313@\0\304\0\360\0\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013637120) = 8192 <0.000013>
110740 15:32:18.280205 pwrite64(123, "\0\0\0\0\220\f\312\302\16\4@\0\300\0\310\0\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013661696 <unfinished ...>
110740 15:32:18.280284 pwrite64(123, "\0\0\0\0\320\200\312\302\273\365@\0\314\0\0\1\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013686272) = 8192 <0.000013>
110740 15:32:18.281656 pwrite64(123, "\0\0\0\0000\302\314\302\311\362@\0\264\0\330\0\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013751808) = 8192 <0.000012>
110740 15:32:18.281746 pwrite64(123, "\0\0\0\0\230t\314\3022\21@\0\274\0\30\1\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013792768) = 8192 <0.000015>
110740 15:32:18.281832 pwrite64(123, "\0\0\0\0\30\352\314\302\\\215@\0\304\0@\1\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013817344 <unfinished ...>
110740 15:32:18.281915 pwrite64(123, "\0\0\0\0`6\315\302\36[@\0\270\0\370\0\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013833728) = 8192 <0.000015>
110740 15:32:18.281984 pwrite64(123, "\0\0\0\0\370\206\315\302\206\346@\0\334\0\10\1\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013850112) = 8192 <0.000013>
110740 15:32:18.282059 pwrite64(123, "\0\0\0\0\300C\316\302\345\277@\0\304\0\200\1\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013891072 <unfinished ...>
110740 15:32:18.282138 pwrite64(123, "\0\0\0\0\20\335\316\302e\220@\0\300\0\320\0\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013907456) = 8192 <0.000015>
110740 15:32:18.282208 pwrite64(123, "\0\0\0\0\220\266\316\302f\323@\0\274\0\300\0\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013915648) = 8192 <0.000014>
110740 15:32:18.282282 pwrite64(123, "\0\0\0\0\230\347\316\302\375N@\0L\0X\27\0 \6 \0\0\0\0\3765\0\0\0\0\0\0"..., 8192, 1013932032 <unfinished ...>
[root@ecs-1461 tmp]#

到这里有一些疑惑，于是问了一位同事，熟悉MogDB 内核的同事，提到可能跟增量检查点和Double write机制有关。

这里我也是用vscode 看了一下原来openGauss的内核的bgwriter.cpp 源码文件，确实也发现了一些信息，不过不太懂。这里我还是尝试通过测试来进行验证，更为直观一些。

我们关掉double write机制和增量检查的后，再试试看。

[omm@ecs-1461 db1]$ cat postgresql.conf|grep double_write
enable_double_write=off
[omm@ecs-1461 db1]$ cat postgresql.conf|grep checkpoint
#checkpoint_segments = 64 # in logfile segments, min 1, 16MB each
#checkpoint_timeout = 15min # range 30s-1h
#checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0
#checkpoint_warning = 5min # 0 disables
#checkpoint_wait_timeout = 60s # maximum time wait checkpointer to start
enable_incremental_checkpoint = on # enable incremental checkpoint
incremental_checkpoint_timeout = 60s # range 1s-1h
#log_checkpoints = off
enable_incremental_checkpoint=off
[omm@ecs-1461 db1]$

调整参数之后，我们再次重启mogdb，然后再进行相关的数据写入和strace跟踪测试。

[root@ecs-1461 tmp]# ps -ef|grep mog
omm 487595 1 2 13:01 pts/2 00:00:00 /u01/mogdb/bin/mogdb -D /data/mogdb/data/db1
[root@ecs-1461 fd]# ps -T -p 487595
PID SPID TTY TIME CMD
487595 487595 pts/2 00:00:00 mogdb
487595 487597 pts/2 00:00:00 jemalloc_bg_thd
487595 487600 pts/2 00:00:00 mogdb
487595 487601 pts/2 00:00:00 syslogger
487595 487602 pts/2 00:00:00 alarm
487595 487603 pts/2 00:00:00 reaper
487595 487605 pts/2 00:00:00 jemalloc_bg_thd
487595 487606 pts/2 00:00:00 jemalloc_bg_thd
487595 487607 pts/2 00:00:00 jemalloc_bg_thd
487595 487631 pts/2 00:00:00 checkpointer
487595 487632 pts/2 00:00:00 bgwriter
487595 487633 pts/2 00:00:05 WALwriter
487595 487634 pts/2 00:00:00 WALwriteraux
487595 487635 pts/2 00:00:00 AVClauncher
487595 487636 pts/2 00:00:00 Jobscheduler
487595 487637 pts/2 00:00:01 statscollector
487595 487638 pts/2 00:00:00 snapshotworker
487595 487639 pts/2 00:00:01 percentworker
487595 487640 pts/2 00:00:01 ashworker
487595 487641 pts/2 00:00:00 TrackStmtWorker
487595 487642 pts/2 00:00:00 auditor
487595 487643 pts/2 00:00:00 2pccleaner
487595 487644 pts/2 00:00:00 faultmonitor
487595 487645 pts/2 00:00:00 WLMworker
487595 487646 pts/2 00:00:00 WLMmonitor
487595 487647 pts/2 00:00:00 WLMarbiter
487595 487749 pts/2 00:00:08 worker
 
[root@ecs-1461 tmp]# strace -T -tt -f -e trace=read,open,write,pwrite64,pread64 -o /tmp/487632.log -p 487632
strace: Process 487632 attached with 27 threads
strace: Process 487749 attached
strace: Process 487750 attached
^Cstrace: Process 487632 detached
strace: Process 487595 detached
strace: Process 487597 detached
strace: Process 487600 detached
strace: Process 487601 detached
strace: Process 487602 detached
strace: Process 487603 detached
strace: Process 487605 detached
strace: Process 487606 detached
strace: Process 487607 detached
strace: Process 487631 detached
strace: Process 487633 detached
strace: Process 487634 detached
strace: Process 487635 detached
strace: Process 487636 detached
strace: Process 487637 detached
strace: Process 487638 detached
strace: Process 487639 detached
strace: Process 487640 detached
strace: Process 487641 detached
strace: Process 487642 detached
strace: Process 487643 detached
strace: Process 487644 detached
strace: Process 487645 detached
strace: Process 487646 detached
strace: Process 487647 detached
strace: Process 487749 detached
 
[root@ecs-1461 tmp]# cat /tmp/487632.log |grep 'write64' | awk '{print $1}'|sort|uniq
487631
487749
[root@ecs-1461 tmp]#
[root@ecs-1461 tmp]# cat /tmp/487632.log |grep 'write64(89' | more
487631 13:15:23.531485 pwrite64(89, "\1\0\0\0\260\374\241\231\321\n@\0\300\0\30\1\0 \6 \0\0\0\0Z8\0\0\0\0\0\0"..., 8192, 522158080 <unfinished ...>
487631 13:15:23.531585 pwrite64(89, "\1\0\0\0000C\242\231\25r@\0\300\0\30\1\0 \6 \0\0\0\0Z8\0\0\0\0\0\0"..., 8192, 522166272) = 8192 <0.000015>
487631 13:15:23.531662 pwrite64(89, "\1\0\0\0\230\210\242\231\204\377@\0\264\08\1\0 \6 \0\0\0\0Z8\0\0\0\0\0\0"..., 8192, 522174464) = 8192 <0.000014>
487631 13:15:23.531740 pwrite64(89, "\1\0\0\0\360\255\242\231\23\207@\0\274\0\340\1\0 \6 \0\0\0\0Z8\0\0\0\0\0\0"..., 8192, 522182656 <unfinished ...>
487631 13:15:23.531850 pwrite64(89, "\1\0\0\0\10\260\242\231\370\215@\0,\0 \36\0 \6 \0\0\0\0Z8\0\0\0\0\0\0"..., 8192, 522190848) = 8192 <0.000022>
[root@ecs-1461 tmp]# cat /tmp/487632.log |grep 487749|grep 'write64(89'|more
487749 13:15:18.020492 pwrite64(89, "\1\0\0\08\316\1\227\312\323\300\0\274\0\20\1\0 \6 \0\0\0\0X8\0\0\0\0\0\0"..., 8192, 241106944 <unfinished ...>
487749 13:15:18.020579 pwrite64(89, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192, 522182656) = 8192 <0.000016>
487749 13:15:18.020700 pwrite64(89, "\1\0\0\0\270\276y\226\0230@\0\244\0\310\0\0 \6 \0\0\0\0Z8\0\0\0\0\0\0"..., 8192, 498163712) = 8192 <0.000015>
487749 13:15:18.020865 pwrite64(89, "\1\0\0\0\310\24\2\227A\210\300\0\350\0\360\0\0 \6 \0\0\0\0X8\0\0\0\0\0\0"..., 8192, 241115136) = 8192 <0.000015>
487749 13:15:18.020943 pwrite64(89, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192, 522190848) = 8192 <0.000024>
[root@ecs-1461 tmp]#

不难看出，如果关掉增量检查点和double write机制的话，那么对于脏数据落盘写入，则由checkpoint进程以及起work线程来负责了，跟bgwriter线程无关。

总的来看，目前MogDB对于脏数据落盘写入，目前来看仍然是单块写入，不过大家也不用担心这里会有多么严重的性能问题，其实对于绝大部分应用场景来讲，这里并非瓶颈。

不过后续我司内核团队应该会着手优化这个点。