前言

你是否遇到过数据库服务器的Out Of Memory(OOM)现象?就是数据库的进程把操作系统内存耗尽,触发操作系统对数据库进程执行Kill -9操作。操作系统对某个数据库进程的Kill,会导致整个数据库实例所有实例重启,所有连接会断开,造成一定时间的数据库不可用。OOM对数据库服务影响较大,应该尽量避免。

在我们的HybridDB for PG 云服务中,也可能遇到用户实例耗尽所有可用内存的情况。一般情况下,我们会采用CGROUP机制来限制用户的内存使用,同一实例在同一主机上的所有进程会放入一个CGROUP。当数据库实例使用的内存总量超出限制时,会触发操作系统从CGROUP中找出耗内存较多的进程,执行Kill -9,这会导致我们上面说的数据库服务暂时不可用。这里操作系统的Kill操作我们称为OOM Kill。

发生OOM的因素一般是应用的并发连接数过多、大对象的存取操作、查询用到过多的临时内存,实例内存过小等。从云服务提供者的角度看,我们无法提前预知或限制用户的使用行为。通常是发生OOM Kill后,监控程序检测到操作系统错误日志,我们才会进行处理,而此时往往已经对用户业务造成了影响。就是说,我们无法避免OOM的发生。但能不能更好的处理OOM,避免OOM Kill这种严重后果呢?本文将对此进行讨论。

Greenplum的处理方式

HybridDB for PG 是基于Greenplum开发的。为尽量避免OOM Kill,Greenplum提供了Resource Manager内存限制功能。通过设置Resource Manager参数,可以限制整个实例可以申请的内存。其背后的机制是,在每次数据库内核执行Malloc系统调用,申请操作系统内存时,用一个全局变量累加记录申请的内存量,并它记录的实例内存申请总量是否已经超限,如果超限则报错。

Greenplum这种方法看似可行,但在我们的云服务中却不宜采用。这是因为,操作系统并不是在Malloc被调用的时候,把实际的物理内存返回给调用者,而是等到调用者实际使用(例如做内存拷贝操作)时,才分配物理内存给它。也就是说。记录的Malloc内存总量,是虚拟内存使用量(可以从top命令输出中VIRT字段,查看一个进程的虚拟内存),并不能反映数据库实际使用的内存(实际使用内存量可以从top命令输出中的RSS字段得到)。如果按这种方法做限制,用户实际可用内存会比他购买的规格内存内存少的多。在我们的一个测试中发现,Malloc记录的内存有时是实例实际使用内存的两倍以上!

既然使用Resource Manager记录和限制内存使用的方法不可行,有没有更优雅的方式尽量避免OOM Kill呢?使用HybridDB的用户,如果线下使用过Greenplum,可能会发现,在大量使用内存时,线下会触发OOM Kill的场景在HybridDB可能并未触发(虽然还是会有SQL报错,但并没有触发实例重启)。另一方面,用户可以实际使用到HybridDB规格标称的内存。实际上HybridDB使用了独特的的方式处理OOM,较大程度上避免了OOM Kill被触发。下面我们介绍一下HybridDB的方法。

HybridDB如何处理OOM

下图是个HybridDB实例的例子。主节点、两个子节点分布位于不同的Linux主机上。每个节点都使用CGROUP限制了内存,例如,每个节点限制使用8G内存。

pic

我们假设上述实例的某个节点使用了超过8G的内存,如果按原有机制,此节点所在主机的操作系统,会找出此实例对应CGROUP中使用内存较多的进程,执行Kill -9,此节点的所有进程重启,暂时不可用。更严重的是,这可能使整个HybridDB集群不可用!为避免这种情况,HybridDB使用了如下方法:

a. 创建一个独立的CGROUP,限制例如10G的内存,如下图所示。

pic

b. 将实例的CGROUP内存限制提升20%,即如果用户实例的节点规格是8G的内存,则在CGROUP中,提升为9.6G。这样做的目的是为下面的操作留存空间。

c. 启动一个脚本,实时监控(例如每秒钟扫描一次)主机所有CGROUP的内存水位。操作系统提供了机制,在CGOUP状态信息中可以查到内存的水位信息。当发现某个CGROUP的水位过高(例如超过了100%的规格可用内存,如8G)时,将内存使用最高的进程移入公用CGROUP。如果内存水位未降低到指定水位,如规格内存的80%,则继续在此CGROUP中取出内存占用高的进程,放入公用CGROUP。如下图所示。

pic

d. 启动另一个独立的脚本,不断获取公用CGROUP中的进程,对这些进程发送特殊的信号;HybridDB进程收到这些信号,将执行类似Cancel Query一样的操作,撤销当前正在进行的查询,同时返回给用户如下的提示:

  1. ERROR: out of memory, no enough instance memory available to run this query.

这个步骤如下图所示。

pic

e. b中提到的内存监控脚本在内存降低到指定水位(如规格内存的80%)后,则进入到另一状态,即开始将进程从公用CGROUP移动回原CGROUP,直到水位上升到预设水位(如100%规格内存)。如下图所示。

pic

上述方法的优势有:

1)由于在实例内存不断增长的过程中,实时的监控内存使用,在内存超限时,触发查询的撤销操作,保护了实例,避免的实例的整体不可用。

2)用户可以通过出错信息获知内存不足导致查询失败,进而做进一步处理。如果触发了OOM Kill,用户只能看到连接断开、实例重启,但无法获知发生现象的原因,所以通常会误以为是网络连接问题。

3)由于一台机器的所有实例都共享一个公用CGROUP,而这个CGROUP一般10G左右就满足使用了,所以它并不会增加多少成本。另外虽然为用户提升了20%的内存,但由于超出规格内存时就开始做查询撤销操作了,所以实际上实例并不会长时间多用内存。

4)这种方法实现简单。仅需要编写两个监控脚本,并在HybridDB内核中增加对特殊信号的支持。

需要注意的是,如果公用CGROUP的内存也耗尽了,是会触发OOM Kill的。也就是说这种方法并不会完全避免OOM Kill,但从实践看,大大降低了OOM Kill的发生几率。

总结

HybridDB对OOM的处理方式,虽然没能避免OOM,但大大减少了OOM Kill的发生,避免了整个HybridDB集群不可用的危险后果。可以说这是一种更优雅的OOM处理方式。当然,作为HybridDB的用户,仍然要从应用层做工作,提前降低OOM发生的几率,例如,降低并发度、调优大量使用临时内存的查询、升级实例规格等。