从一个案例看关闭NUMA的必要性

回到这个案例，这个客户近期遇到了多次系统卡顿的情况，经过分析发现卡顿的时候的主要等待事件是Log file sync，于是设置了_use_adaptive_log_file_sync=false。不过关闭了自适应日志同步功能后，问题并未好转，还是经常会出现卡顿。老白首先看了卡顿期间的ASH报告

前台进程中出现了log file sync等待， 这五分钟里的平均等待Log file sync的会话有9.55个，确实比出问题前的时段要多：

不过和CPU+WAIT FOR CPU的比较（52.52），9.55这个数值还不算太高。似乎Log file sync并不是造成这1分钟卡顿的主要原因。

从AWR报告上看：

log file sync占到TOP EVENT的7.3%，平均3毫秒，这个指标还是可以接受的。其他的等待事件也不是很高。难道是有部分log file sync等待十分长，导致了卡顿？

从等待事件直方图上看，好像也没这个问题，只有0.1%的等待大于32毫秒，而绝大多数的等待都在4毫秒以内。于是只能再仔细看看ash的详细信息。从ASH数据上看，Log file sync等待一直存在，在卡顿的时间段里，只是更多一些而已，并没有特别之处。这套系统定期进行批量数据载入，因此主要的等待事件基本上都是log file sync。从数据库层面看不出有特别的问题，那么刚才那个CPU+WAIT FOR CPU等待就十分可疑了。幸好客户采集了OSW的数据，于是我们立即查看了iostat和vmstat的数据（IO出现短时间的延时抖动或者VM出现抖动都可能导致类似的卡顿）。

从iostat上看，卡顿时期的IO延时都是十分正常的，客户使用了ssd盘，IO负载虽然挺高，不过还是很稳定。查看VMSTAT的时候，我们终于抓到了问题的关键：

虽然从CPU使用率上，并无太大的变化，不过在一点四分20秒的采样中还是看到了十分异常的东西，居然b队列高达1200+。这也就能解释ash报告中的CPU等待问题了，出问题的时候，这台2路服务器上（18核的服务器，72线程）的运行队列中居然有超过1000线程在等待非CPU的资源。而刚才我们看到的iostat数据十分正常，不大可能是因为IO问题导致的这个b队列问题。那是什么问题呢？我们可以看到，在b队列出现前的free内存是16237924，而b出现之后，变成了25708616，增加了9g的空闲内存，而CACHE从41739700变成了31528652，减少了9G的CACHE。这意味着，当时出现了大规模的CACHE DROP。好端端的还有16G的空闲内存，为啥要做如此大规模的CACHE DROP呢？我们来看看numactl -H的检查结果：

这个服务器上有2个numa node，在这两个节点上各有128G的物理内存，而两个节点上的物理内存使用量是不均衡的，节点2的物理内存剩余仅有2GB。老白前几天发过一篇关于NUMA架构的文章，里面详细介绍了NUMA的一些基本原理，这里就不做重复描述了，有兴趣的朋友可以去查看这篇文章。由于NUMA分配的不平衡，当某个NUMA NODE出现内存不足的时候，OS首先会对这个NUMA NODE的内存进行回收（此时系统的物理内存总的空闲量可能还是很大的），这种时候，根据swappiness设置的策略，OS会优先选择FILE CACHE或者匿名内存块进行内存回收，回收FILE CACHE只需要把脏块写入文件，而回收匿名内存块需要SWAP部分内存。

从上面的情况看，要解决这个问题，根本的策略是关闭服务器的NUMA（在服务器层面关闭，而不是在DB层面），而这个操作需要重启机器，因此作为临时措施，可以先设置vfs_cache_pressure=200，尽可能让系统更倾向于回收inode缓存，让内存回收变得平缓一些。因为这种运行ORACLE数据库，并且有OGG复制的环境来说，文件缓冲的使用十分频繁，当某个NUMA节点FREE空间不足的时候，进行大规模CACHE DROP操作时产生的影响十分大，平时更积极的回收INODE缓冲，可以缓解这种趋势。

在上一篇老白关于NUMA架构的文章中，老白更主要谈了NUMA的性能问题，实际上，对于大多数系统来说NUMA的性能还不是最关键的问题，NUMA架构将物理内存分为多个节点，不同节点单独进行空闲内存管理的模式带来的CACHE DROP问题，可能会导致数据库的间歇性卡顿。对于智能制造系统来说，这种抖动可能会造成致命的影响，值得大家注意。