我们一起聊聊 Oracle 的Lgwr Worker

我们一起聊聊 *** 的Lgwr Worker

这些年***发展的太快，我从12C之后就比较少参与运维工作，顶多帮着客户看看AWR报告，所以多*** 12C以后的很多细节实际上了解不多。搞了二十多年***，从5.1用到11.2，*** 10G出来的时候，我就说这应该是我学习的最后一个版本的***了。没想到没搂住，11G又搞了10年。12C后因为不怎么做一线运维了，所以就没怎么关注了。

前几天群里朋友在讨论PG WAL写入存在性能问题的时候。群里有个朋友就问，难道PG这么土，不支持多个WALWRITER并发写吗？我当时想都没想就说，***也不支持啊，早期***支持过LGWR SLAVER，不过因为BUG太多，没什么人用，到12C以后，好像就没有SLAVER这码子事儿了。当时那个朋友就蒙圈了，***咋能不支持多个LGWR并发写呢？事后我问了问同事，他们说好像你记错了，12C之后***所有的SLAVER都被统一改成WORKER了。在12C里LGWR worker是自动开启的。

昨天正好有点空，我找了一些关于12C LGWR worker的资料看了看。在公司的测试环境上也找了一套19.15的环境检查了一下。发现还真如同事所说，12C开始，***已经自动开启LGWR并发写了。在12C里增加了LGnn进程，用于实际写入REDO数据，LGWR完全不管写Redo Log文件的事情，只负责发布一些和REDO落盘的消息了。

目前我看的关于LGWR worker的资料不多，从一些资料和我对LGWR的理解，LGWR worker应该是和*** Redo Strand有关的。***的LGWR worker都是分配到GROUP的，GROUP的数量如果是和Redo public Strand相关，那么每个group就之间就不需要通过锁机制来同步写入工作。LGWR 也不需要在多个worker之间做协同，而仅仅需要做和消息公告相关的共组了，这种机制应该是最为高效的。如果多个worker之间写REDO文件还需要闩锁来做串行化，那么效率肯定是不会好的。

Redo Strand从*** 11开始就已经被用来加速REDO性能了，Strand的目的是为了提高并发写入Redo Log buffer和Redo Log文件时候的性能，减少因为串行化闩锁等待导致的REDO性能问题。***会根据CPU_COUNT的值，自动的调整Redo srand的数量。

***会根据CPU_COUNT/16来设定Strand的数量，在LOG BUFFER中会按照Strand数量划分为N个子池，写入REDO数据的时候，可以并发的写入不同的STRAND，这样可以减少高并发LOG BUFFER写入的性能。为了确保这一机制起作用，在Redo Log文件中，也是按照Strand的方式分配Redo Log文件，这种模式可以让Redo Log文件的写入也可以高速并发。Redo Strand为12C的LGWR worker称为默认开启的功能打下了一个良好的基础。

我这个环境的CPU_COUNT是16，而每个实例的Redo Strand最小值是2，因此启动实例的时候也启动了2个LGWR worker，这说明数据库实例有两个LGWR worker group，当系统空闲，没有什么需要写入的REDO数据的时候，LGnn都在等待空闲等待事件LGWR worker group idle，而lgwr进程在等待rdbms ipc message。

通过strace看lgwr，也只是在做一些信号量方面的操作。我们再来看看空闲时的LGnn。

也是在相同的信号量上休眠。

可以看出LGWR的等待事件发生了变化，而LGnn的等待事件也和以前的LGWR十分类似。从等待事件上看，当一个worker完成工作后，会处于Ordering等待，等待获取另外的写任务。在具体实现算法上，还并没有和我想象的一样不需要调度。我们再来TRACE一下LGWR。

可以看出LGWR还是十分频繁的在操作那个信号量，这很可能是LGWR在积极参与日志写的调度协调。

从worker的行为上也看到了和LGWR之间的互动。这说明***并发日志写还是需要多进程之间的同步行为，不是完全自主的无阻塞的。因此在某些场景下，可能会导致当WORKER数量过多时，引发Log file parallel write的等待时间过长，从而引起LOG FILE SYNC的增加，影响数据库的性能。

当年***的REDO STRAND成为默认开启的时候，也出现过类似的问题，因为STRANDS数量时和CPU_COUNT相关的。十多年前在*** 11g上就有人发现了当CPU数量很多的时候，log file sync会莫名其妙的变坏。

当时的建议时通过_log_parallelism_max参数来减少Strand的数量，解决过多的Strand带来的性能问题。对于LGWR worker机制，***也提供了一个类似的参数来进行控制，这个参数就是“_max_log_write_parallelism”。

在*** 12C或者以后版本中，也经常会出现因为LGWR worker导致的性能问题。***可以通过“_use_single_log_writer”参数来进行调整。默认情况下这个参数的值时ADAPTIVE，这意味着***会自己根据工作负载来选择工作模式。如果遇到这方面的性能问题的时候，可以将这个参数设置为TRUE，强制使用单个LGWR，也就是恢复以前的工作模式。如果你发现你的数据库从11G升级到12C之后，log file sync变坏了，从而导致了一些性能问题，你可以考虑调整这个参数。

数据库的应用场景十分复杂，我们享受某些应用场景受益于一个新技术的时候，难免会引发一些新的问题，某些场景可能和新技术的适应性不够好。另外加上一些新技术刚刚开始使用时，对某些特殊场景的算法不够优化，也会引发一些问题。我想，随着今后***数据库版本的迭代，LGWR worker的机制也会越来越成熟。

实际上我看到一些国产数据库现在也在考虑使用多个WAL WRITER提升高并发WAL写入的性能，从而更为充分的利用***等现代硬件。不过WAL写入对于延时十分敏感，算法写不好，就容易引发更为严重的闩锁串行问题。***的Redo Strand与LGWR worker相结合的机制应该是目前最值得借鉴的方法了。如果不针对WAL BUFFER做Strand分区，那么多个WAL WRITER的并发控制的成本会更高。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。