在OOM现场 谈一谈数据库内存分配, 以及审计的重要性
标签
PostgreSQL , Linux , OOM , SQL审计 , palloc , rss
背景
数据库是比较重内存的应用软件之一，比如排序、聚合、使用较大的列、使用很长的SQL（值SQL本身的内容长度），或者传入很大的变长类型值时，都可能使得单个连接就会消耗很大的内存。
而另一方面，每个连接会消耗一定的内存，比如SYSCACHE , RELCACHE，随着访问的对象变多，如果是长连接，消耗的内存也会越多。 通常来说，长连接当访问了很多元数据时，可能占用几十MB到上百MB不等。
当使用了cgroup来限制数据库实例的总内存时，随着数据库占用的RSS部分的内存越来越多，如果数据库连接在申请内存时，超出了cgroup的限制，则连接可能被OOM掉。
当然，即使不使用cgroup，Linux也会根据内核的配置，以及用户申请内存的动作，当时的剩余内存等情况综合，发生OOM。
有几篇文章可以参考一下
《精确度量Linux下进程占用多少内存的方法》
《一个笛卡尔积的update from语句引发的(内存泄露?)问题》
《PostgreSQL relcache在长连接应用中的内存霸占"坑"》
《Linux page allocation failure 的问题处理 - lowmem_reserve_ratio》
当发生了OOM后，如何找到引起OOM的那个会话，他是罪魁祸首（指单个会话申请了过多的内存），还是压死骆驼的最后一根稻草（指连接数过多）呢？
数据库又是如何申请内存的呢？
rss和cache
简单讲一下rss和cache.
rss是程序申请的内存，不能被内核自动释放，由用户自己来管理它什么时候被释放。
cache，通常指缓存，比如文件系统的缓存，不由用户进程来管理，它可以被内核释放。
我们所指的内存不足，是指即使cache完全被释放，也无法分配足够的内存给用户请求。
在cgroup的memory子系统中，我们可以看到这两个部分，rss很多，cache很少时，就要注意了，可能会发生OOM。
# cat memory.stat
数据库申请内存举例
以PostgreSQL数据库为例，为了管理方便，pg使用统一的内存分配和释放API，便于管理，详见src/backend/utils/mmgr/mcxt.c。
用得比较多的比如palloc，它申请的内存某些时候可以自动被回收，比如事务结束，会话断开，QUERY结束时，使用palloc申请的某些内存，会自动被释放。
还有一些内存分配接口详见src/backend/utils/mmgr/mcxt.c。
* mcxt.c
处理单个值时，内存限制。单条SQL的内存限制也是1GB。
* memutils.h
用户可以根据mem context存储内存分配和释放的方法，应对不同的使用场景，这样保证了接口依旧是palloc。
* memnodes.h
我们可以在数据库的类型处理中，大量的用到了palloc，同时也可以很清晰的了解，每一种类型，在使用是需要消耗多少内存。
cd postgresql-9.6.1/src/backend/utils
$grep -r palloc *|less
比如字符串，数组，全文检索，这些属于变长类型，最长允许1GB，在申请内存时，根据被处理的值的实际的大小申请。
cgroup例子
为了方便在一台物理机中启动多个实例，隔离资源，使用cgroup是一个很不错的方法。
# mount -t cgroup -o cpu,memory cpu_and_mem /cgroup/memory
把实例进程号写入tasks即可。
为了测试方便，我这里限制了100MB， 并且只将测试会话的backend process加入tasks
postgres=# select pg_backend_pid();
# echo 85938 > tasks
查看当前状态
# cat memory.stat
模拟数据库进程被OOM
因为限制了100MB，所以这个数据库backend process需要申请超过100MB的内存，才会被OOM。
根据前面讲的，排序、聚合、使用较大的列、使用很长的SQL（值SQL本身的内容长度），或者传入很大的变长类型值时，都可能使得单个连接就会消耗很大的内存。
注意每次被OOM后，重连，并将新的BACKEND PID写入CGROUP的tasks再测试下一轮.
1. 以使用较大的列为例，将1亿个值，聚合为一个数组，由于数组属于变长类型，最长可以放1GB，1亿已经超过1GB了，所以触发了OOM。
postgres=# explain (analyze,verbose,timing,costs,buffers) select array_agg(id::text) from generate_series(1,10000000) t(id);
2. 对较大的表排序，并且设置较大的work_mem
postgres=# set work_mem ='101MB';
使用较小的work_mem不会被OOM，因为使用了临时文件。
postgres=# set work_mem ='10MB';
3. autovacuum worker进程启动后，单个WORKER进程可能需要申请的内存大小为maintenance_work_mem或者vacuum_work_mem。
4. 并行QUERY
5. 带有多个hash join，多个排序操作的复杂QUERY，可能消耗多份WORK_MEM。
这种操作不需要很多内存：
比如查询了一张很大的表，返回了大批量（比如一亿）记录，即使不使用流式接收，也不需要很多内存。
审计
终于说到审计了，没错，当OOM发生后，我们怎么找到压死骆驼的最后一根稻草，或者是罪魁祸首呢？
由于OOM发的是KILL -9的信号，被KILL的进程根本无法通过捕获信号来记录当时正在执行的QUERY或者当时的状态。
那么审计就很有用了。
有这么几个参数
postgres=# set log_statement='all'; // 在SQL请求时就写日志
显然，如果我们需要在OOM后，还能找到被OOM进程当时执行QUERY的蛛丝马迹，方法1:在请求时就记录下它在执行什么(开启log_statement='all')，方法2:记录detail字段，postmaster进程会收集这部分信息，不管什么方法，超过track_activity_query_size长度的QUERY都被截断。
例如开启log_statement='all';后，我们能在日志中看到这样的信息。
开启了log_statement='all';后，在客户端发起QUERY请求时的日志。
参考
《精确度量Linux下进程占用多少内存的方法》
《一个笛卡尔积的update from语句引发的(内存泄露?)问题》
《PostgreSQL relcache在长连接应用中的内存霸占"坑"》
《Linux page allocation failure 的问题处理 - lowmem_reserve_ratio》