Phone:18180207355 提供专业Oracle&MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

最近某客户的核心业务系统又出了翻译缓慢的情况。该问题在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访问属于自己的内存,延迟是最小的。我们这里再混到前面的例子中:

从这里来看,实际上是存在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(或者更低)

    分享到:
18180207355
加Q咨询