MogDB 学习笔记系列之 — 认识bgwriter线程
本站文章除注明转载外，均为本站原创： 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客
本文链接地址: MogDB 学习笔记系列之 — 认识bgwriter线程
MogDB是云和恩墨公司基于openGauss所做的商业发行版，这里的商业发行版并非简单包装，换个壳，而是做了不少Bug修复和增强，目前也在研发相关的数据库迁移、数据比对、高可用管理，性能分析等工具，这里做说。
为了便于大家更好的学习和掌握MogDB，我打算陆续分享一些MogDB的技术知识，仅限于个人学习测试，不代表公司观点。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
[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线程，这里我们查看一下数据库相关参数配置：
|
1 2 3 4 5 6 7 8 9 |
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_thread_num | 2 | Write-Ahead Log / Checkpoints | postmaster (5 rows) |
接下来我们同MogDB提供的gstrace 工具来跟踪一下，看看能否有些发现：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 |
[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 插入部分数据
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
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跟踪
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
[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 合并写入的。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
[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机制和增量检查的后，再试试看。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
[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跟踪测试。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 |
[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对于脏数据落盘写入，目前来看仍然是单块写入，不过大家也不用担心这里会有多么严重的性能问题，其实对于绝大部分应用场景来讲，这里并非瓶颈。
不过后续我司内核团队应该会着手优化这个点。
Leave a Reply
You must be logged in to post a comment.