最近某客户的核心业务系统又出了翻译缓慢的情况。该问题在6月份也出现过，当时进行了一次调整。 我们首先来看下故障时间段的awr报告：
单纯的从TOP 5 event，基本上是看不出任何东西的，可能有人会说这里log file sync等待不是有点高了吗？ 实事求是的讲，12ms确实超过
正常情况的值，但是也不算高，通常遇到log file sync等待之后，我们应该去看下log file parallel write？ 的确，这是大家的常规思路：
我们可以看到，log file parallel write 的平均等待时间为11ms，跟log file sync是差不多的。
虽然从这里来看，log file parallel write 平均等待时间有点偏高，但是从这里11ms 就能说明是存储写能力比较差吗？ 显示不能. 从Oracle 11g开始,awr报告
中一项Wait Event Histogram 数据,可以进一步帮忙我们进行确认,如下:
从这里,我们可以清楚的看到,log file parallel write等待,其中有38.9%的等待是小于8ms的,其他是超过8ms,在8sms和32ms之间.
对于我们来讲,看到的11ms的平均等待时间,仅仅是一个计算后的平均值.
仅仅从上述的信息,我们无法判断的,结合估值前一天同时间段的awr,我们分析发现log file sync和log parallel write的等得几乎类似,差不多.
应该我们也就可以排除这方面的因素.
从数据库层面无法看到有价值的信息,那么我们就得从其他方面入手了,从客户提供的nmon监控数据,我们发现了有价值的信息:
首先对于CPU的利用率而言，SYS%的消耗在故障时间点开始，突然变高，如下：
同时对于内存的使用，freemem也是突然下降的相对比较厉害：
这里就存在2个问题：
1) 为什么内存会下降这么快？
2）为什么物理内存free memory,CPU 的SYS%消耗会这么高？
对于SYS%消耗比较高，我们知道，通常是由于操作系统本身出现异常了，比如swap开始使用了。 这里也是比较奇怪的是：free memory还有那么对，怎么会使用swap？
显示这里swap并没有开始使用，针对这一点，我们也可以从nmon的监控看出，如下：
可以看到swapfree指标并没有改变。
那么内存变化的是什么呢？我们继续来看另外一个指标：
从上面的红色部分内容，我们看出，确实在故障时间点激活了换页操作。也正是从15:55分开始，业务出现缓慢的情况，SYS%消耗比较高。
这一切似乎看起来就比较怪异。对于传统的SMP架构来讲，肯定是不会出现这样的情况，那么既然出现了这样的情况？那说明客户这里并不是用的SMP。
我通过查看客户提供的RDA数据，发现默认启用了NUMA特性，如下：
既然提到了NUMA架构，那么我们就有必要先来了解下NUMA是什么。 NUMA，非统一内存访问(Non-uniform Memory Access),介于SMP和MPP之间。
在NUMA架构中，每一颗CPU被称为一个node，每个node之间的内存使用的独立的。首先我们来看下传统模式SMP的情况：
SMP架构：
我们可以看到，每个CPU之间是绝对平等的，没有优先级之分，访问内存都必须通过系统总线。同时CPU之间的访问也是需要经过系统总线的。
从这个架构大家也可以看到SMP架构的短板是什么地方了。 对于现在动辄数十个甚至几百个CPU的系统来讲，这显然是有问题的。系统的总线将是
整个系统的瓶颈。
因此随着技术的发展，引入了新的一种架构NUMA。 我们来看NUMA架构是什么样的：
NUMA架构：
大家从NUMA架构可以看出，每颗CPU之间是独立的，相互之间的内存是不影响的。每一颗CPU访问属于自己的内存，延迟是最小的。我们这里再混到前面的例子中：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
Using: numactl --show
policy: default
preferred node: current
physcpubind: 0 1 2 3 4 5 6 7
cpubind: 0 1
nodebind: 0 1
membind: 0 1
Back to top
Available Nodes
Using: numactl --hardware
available: 2 nodes (0-1)
node 0 size: 8035 MB
node 0 free: 2216 MB
node 1 size: 8080 MB
node 1 free: 5819 MB
node distances:
node 0 1
0: 10 21
1: 21 10
|
从这里来看，实际上是存在2颗CPU，每颗4线程。 每颗CPU 对应一个node。 即使，上面的node 0和node 1分别对应CPU 0和CPU 1.
这里的SIZE 表示该node NUMA分配的内存总数，从上面我们看出，每个Node分配了8GB，但是node 0的free memory相对有点便宜。
RDA数据的客户事后采集的，因此，我猜测这里node 0的memory变化应该是比较大的。
从目前的情况来看，我们可能不足以认为客户的这个问题是NUMA的问题，但是，我认为应该是比较大的一个嫌疑。
这里补充下关于NUMA的几种方法：
1） BIOS中关闭NUMA设置
2） 在操作系统kernel层面关于numa，例如：
/etc/grub.conf的kernel行最后添加： numa=off
3）Oracle数据库层面关闭：
_enable_NUMA_optimization=false （11g中参数为_enable_NUMA_support）
补充：关于Linux的几个设置注意事项
MIN_FREE_KBYTES的目的是保持物理内存有足够的空闲空间，防止突发性的换页。
Linux swapiness缺省为60，减少swapiness会使系统尽快通过swapout不使用的进程资源来释放更多的物理内存。
vfs_cache_pressure的缺省值是100，加大这个参数设置了虚拟内存回收directory和i-node缓冲的倾向，这个值越大，越倾向于内存回收。
调整这3个参数的目的就是让操作系统在平时就尽快回收缓冲，释放物理内存，这样就可以避免突发性的大规模换页。
sysctl -w vm.min_free_kbytes=409600
sysctl -w vm.vfs_cache_pressure=200
sysctl -w vm.swappiness=40（或者更低）