有一段时间,某数据库在整点期间总是会发出几条连接失败的告警,如下
2019-08-14 10:00:22, 29.211.?.?/??db can not connect, Warning from 5.223-mon_pri_conn.sh! |
1.分析监听日志发现监听存在重启行为
14-AUG-2019 10:00:16 * (CONNECT_DATA=(SERVICE_NAME=dbinst1)(CID=(PROGRAM=sqlplus)(HOST=localhost.bss_rh6_dqjkj01_35.176)(USER=ftpuser))) * (ADDRESS=(PROTOCOL=tcp)(HOST=29.211.35.176)(PORT=19573)) * establish * dbinst1 * 0 TNS-12540: TNS:internal limit restriction exceeded .... 14-AUG-2019 10:00:20 * 12582 ---异常前每秒短连接 11 14-AUG-2019 09:59:55 ---异常整个期间数据库等待事件正常,无明显高消耗 |
2.排查问题期间的os负载情况
OSWBB_ARCHIVE_DEST /u01/osw/oswbb/archive zzz ***Wed Aug 14 10:00:10 CST 2019 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 31 6 0 446655712 33212 1998720 0 0 1 3 0 0 1 1 98 0 021 22 0 446779968 35236 2008236 0 0 16300 96 259964 240440 11 3 83 3 0 25 27 0 446795360 37040 2020368 0 0 29096 48 235608 212541 11 3 82 4 0 zzz ***Wed Aug 14 10:00:24 CST 2019 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 6 18 0 443893696 72420 2204804 0 0 1 3 0 0 1 1 98 0 0 13 12 0 444055840 74432 2228936 0 0 22880 16 90258 85804 5 2 88 6 0 6 17 0 444172864 76036 2250128 0 0 19980 100 70041 61176 4 3 86 7 0 zzz ***Wed Aug 14 10:00:36 CST 2019 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 6 20 0 444360928 83052 2341764 0 0 1 3 0 0 1 1 98 0 0 6 24 0 444552928 83740 2098432 0 0 4436 1212 67242 61741 4 3 85 8 0 125 220 0 444898240 84812 2102292 0 0 3892 1544 174504 140362 12 13 55 19 0 1.10秒的时候 r21 b22, 该机器为ssd存储,平常cpu-b不到5,这里值已经有点异常 2.36秒的时候出现r 125 b220,可能为监听重启积压导致,且异常时间点在监听重启后,不能确认是该问题导致故障。 |
top - 10:00:36 up 288 days, 14:24, 2 users, load average: 215.59, 68.64, 29.25 1.近一分钟load达到215,且较5分钟、15分钟load值出现直线上升。 2.通常在linux平台 load avg为系统整体load, 包含 cpu load, io load等等.简单理解为 R+D状态的process,不代表cpu使用率,但load高一定存在某一方面的高负载情况. |
重点排查一下异常期间的ps 数据,排除S(sleep)状态进程,可以看到大量的IO相关D进程 [oracle@dbserver1 tmp]$ cat /tmp/ps1024.txt | awk {print $1,$9,$10,$13,$14} | sort | uniq -c [oracle@dbserver1 tmp]$ cat /tmp/ps1024.txt | grep 10:00 | awk {print $1,$9,$10,$11,$13,$14} | sort | uniq -c 115 oracle filp_o D 10:00:15 oracledbinst11 (LOCAL=NO) <--------- 10:00:15建立的短连接 115 积压的大量短连接积处于filp_o 状态,io可能存在异常 75 oracle filp_o D 10:00:16 oracledbinst11 (LOCAL=NO) 排查ash信息再次确认数据库负载较低,io响应也在毫秒级,无明显异常 使用strace跟踪测试建立连接期间,发现监听派生 LOCAL=NO进程后会读取大量的ORACLE_HOME本地lib库,并进一步排查/u01文件系统状态 [oracle@dbserver1 tmp]$ cat /tmp/stsqlplus.txt | grep 12.2.0/db [oracle@dbserver1 tmp]$ lsblk ..... zzz ***Wed Aug 14 10:00:11 CST 2019 <-------cpu整体使用率不高,iowait整体也不高Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util <-------- sda-- /u01--ORACLE_HOME文件系统IO居高不下 await出现明显等待 <--------sda-- /u01--ORACLE_HOME文件系统 iowait持续居高不下 |
1.通过与应用侧沟通了解到在整点期间app营业厅会推出抢购活动导致短连接明显的上升
2.主机管理员反馈由于本地盘RAID出现故障盘导致响应异常,以至于大量短连接挂死在ORACLE_HOME的lib库读取上,达到监听队列上限值后引发监听重启.
1.推进应用程序短连接进行连接池化整改。
2.更换本地盘为SSD存储提升ORACLE_HOME的读写性能。
注:本次故障版本为oracle12.2,在oracle12c之后的版本中,数据库会持续写出大量的垃圾trace信息不仅影响IO性能且影响文件系统正常使用率,建议多带带指定diag目录以及使用SSD存储安装ORACLE_HOME 。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/130031.html
摘要:更多关于阿里云弹性公网的介绍请移步这里。你下载的版本可能比钢哥的高,不过安装步骤是一样的。总结至此,数据库的完整开发环境就搭建好了。在接下来的文章里,钢哥将带你做进一步的优化,敬请期待。 本文是钢哥的Oracle APEX系列文章中的其中一篇,完整 Oracle APEX 系列文章如下: Oracle APEX 系列文章1:Oracle APEX, 让你秒变全栈开发的黑科技 Orac...
阅读 1249·2023-01-11 13:20
阅读 1558·2023-01-11 13:20
阅读 1012·2023-01-11 13:20
阅读 1680·2023-01-11 13:20
阅读 3971·2023-01-11 13:20
阅读 2519·2023-01-11 13:20
阅读 1355·2023-01-11 13:20
阅读 3486·2023-01-11 13:20