导读:在使用数据库的过程中,内存不足常常会引起数据库异常。但是内存不足,又会为数据库带来哪些具体的影响呢?本次,我们将通过某客户现场数据库在某个时段内性能严重下降的案例来展示由于主机内存不足而造成数据库日志写入卡顿的问题分析过程。通过本案例,我们也可以对相关问题的分析方法及解决建议有一些深入的了解。 问题描述2020年1月15号凌晨2点左右客户产线异常,应用后台消息报错业务处理超时。此外,在16号凌晨2点左右和下午2点左右,也发生业务处理超时,影响较大。 故障时段数据库的等待事件信息如下: 问题分析查看数据库故障时间段的ash信息,可以看到确实在1:56~1:57分的时候,等待比较严重:
根据故障处理经验来判断,LGWR抖动比较严重,怀疑物理IO出现了问题。
而该sql_id的sql_text则是: 对故障时间点的ASH报告进行分析,故障时间点这个select 1 from dual占用的cpu最高,这个sql一般是weblogic等中间件测试连接池连接用的,一般不会引起CPU的使用问题,且总体CPU使用率并没有撑满。故在这里可以排除CPU使用影响的情况,由于这套数据库平时内存的使用率就是98%左右,只剩2G空闲内存,而故障时点,只剩几百兆内存。 因此,分析到这里基本可以定位是内存消耗过高引起的问题,这里考虑到触发故障的时间点有高度规律性,于是考虑可能是由于一些定时任务引起的,于是检查了crontab,job定时任务、备份等,但都没发现有故障时间的运行的信息。 这个时候考虑数据库主机层面上定时任务和进程分析一些信息,由于以前出现故障的时候,有让客户开启oswatch采集,故这次也同样从osw中top的采样时间进行检查,且最终发现在异常时osw的采样时间也变长了,说明故障出现的时候整个操作系统都有受影响。
将osw采样的时间加大到42秒的和正常15秒内的两个时间进行比对,可以发现故障出现的事件点内,多出来的一个进程是CVU的JAVA进程。故怀疑是cvu的java进程对主机的内存造成了大量的消耗。 查看cvu的运行日志,可以看到cvu是6小时执行一次,而在1:56和13:56的时候主机确实都运行了这个进程。当然,cvu服务停用并不影响数据库实例正常使用,只是在运行cluvfy时有调用到,而在01:56:25~01:57:07这个中间系统中是卡着的,且内存的free一直减少。 从vmstat上看,也验证了异常时主要是内存问题,交换空间页面切换和系统调用次数也在加大。 综合以上的分析,可以确认是cvu定时调用导致内存消耗过大,而内存本身就不足,在调用的那一瞬间引起了数据库主机内存抖动,引起了数据库主机的卡顿,临时处理方法是停止cvu服务,在之后的跟踪中没有发现同样的故障发生,故障处理完成。 cvu定时任务是集群软件调用cvu工具定时检查集群运行状态,记录到日志文件中的。它的运行导致现有服务器内存资源过于紧张,导致几乎所有进程都变慢。 问题解决本次案例出现的主要原因是由于cvu定时任务进程的调用导致现有服务器内存资源过于紧张,引起了数据库主机内存抖动,造成数据库卡顿。临时处理方法是停止cvu服务,在之后的跟踪中没有发现同样的故障发生,故障处理完成。
|