数据库连接数过多，单进程架构数据库谨防隐形杀手

摘要：可能大多数DBA都觉得数据库就是数据库，不同的数据库可能在企业级特性上，性能上，稳定性上有些差别，其他的也就

原文链接：https://www.modb.pro/db/22495?cyn

可能大多数DBA都觉得数据库就是数据库，不同的数据库可能在企业级特性上，性能上，稳定性上有些差别，其他的也就不去管了。今天老白和大家聊聊单进程架构数据库与多进程架构数据库之间的一些差异性的东西。老DBA都了解Oracle数据库是一种多进程架构的数据库，所有的服务和前台进程都是独立的进程，而Mysql是一种单进程多线程架构的数据库，整个数据库服务是一个进程，所有的前台与后台会话都是一个线程。我们来看看一些主流的数据库，Oracle、PostgreSQL、人大金仓是多进程架构的，SQL SERVER、Mysql、Gaussdb 100(Gaussdb 200的基础是PostgreSQL ,和Pg是一样架构的）、达梦等是单进程架构的。

前些年一直在争论两种架构的优缺点，很多人认为Mysql这类单进程架构的数据库代表了更新的技术，实际上也没必要纠结技术的新与不新，两种架构是各有优缺点的。多线程架构，线程之间通讯的效率直接可以通过内存，通过线程锁实现串行化，其开销是十分小的，这对于大规模并发十分有利。不过这种架构也有其缺陷，线程数量太多，线程调度的开销将十分大，因此这种架构比较适合大并发，但是每个访问都较短的场景。对于海量并发场景，可能并不能比多进程架构有优势。另外一点就是，多进程架构每个服务都是独立的进程，隔离比较好，某个会话出现问题，包括内存泄漏等BUG都比较容易解决，而单进程架构下，这种缺陷会被放大。

数据库管理系统选择多进程还是单进程架构是和其企业有关系的，单进程下的CURSOR共享会变得高效与简单，就不需要搞Oracle SHARED POOL这么复杂的结构了，oracle公司也不怕，在SHARED POOL方面独步天下的技术保证了就是用多进程架构，性能上也不惧怕任何竞争对手，这是Oracle的底蕴。

数据库连接数过多，接下来进入正题，我们来看看单进程多线程架构的数据库在运维方面需要注意的一点，就是内存控制。刚才也提到了，内存是这种架构的数据库的一个十分要命的地方，那么最严重的情况会出现什么呢？我们选择大多数非ORACLE数据库都运行在LINUX上，那么我们就以LINUX操作系统为例，来介绍一下对单进程架构数据库具有致命影响的一个LINUX特性-OOM KILLER。

单进程数据库在操作系统中看到的就是一个独立的服务进程

在一个运行这样数据库的系统中，内存使用率排在前面的往往就是这些数据库的服务进程。比如上面的高斯100数据库占用了这个系统的超过50%的内存。这种情况有什么风险呢？

在你的服务器的物理内存十分充裕的情况下，OOM KILLER的风险是不存在的，而当你的物理内存存在问题，出现了SWAP使用率较高的问题的时候，这种风险就十分高了。当LINUX操作系统认为物理内存将出现OUT OF MEMORY (OOM）的时候，OOM KILLER这个杀手就会被激活了。操作系统必须杀掉一些风险较高的进程，从而确保整个操作系统不会因为OOM而彻底挂掉。

那么杀手会如何选择要杀的进程呢？我们来看看每个进程下的OOM相关的文件：

单用户数据库系统优缺点？

有三个和oom相关的文件，oom_score里存放的是这个进程的oom评分：

我们发现，高斯的服务进程的oom_score高达370分，目前是整个服务器上最高的。如果这个时候，服务器的内存出现了OOM的风险，那么LINUX可不会管你是华为的还是甲骨文的，拿SCORE最高的开刀就没错了。

从这里我们可以得到一条经验，对于单进程架构的数据库，一定要确保物理内存不要出现过度使用，如果无法确保足够的物理内存供给（这种情况在云环境下很可能经常会遇到），那么，确保有足够的SWAP空间，从而避免OOM的出现。

除此之外，我们还有什么防御措施吗？当然有，就是oom_adj/oom_score_adj这两个参数（oom_adj是早期linux的参数，为保证兼容性保留的，新版本都使用oom_score_adj了），通过设置某个进程的这个参数，可以让这个进程的oom_score保持低位，确保不会被杀手杀掉。

linux查看进程、

上面的例子里，我们把高斯的进程的oom_score_adj设置为-1000，这个服务进程的oom_score立马就变成0了，这样杀手就找不到它了。