利用晚上时间跑个12小时稳定性,第二天发现TPS曲线图成了这个样子. 排查步骤: 1.观察TPS图发现,几乎每两个小时TPS掉一次坑,是周期性的,而且TPS有掉到0的现象.LR上也有失败的交易,猜想是TPS掉坑的时候交易才报错,因为之前测负载的时候并没有交易报错. 2.查看服务器日志,发现报连接池不够错误.加大连接池晚上再跑一次稳定性. 3.重跑稳定性后没有周期性掉坑的现象了.分析掉坑原因是因为连接池太小,达到一定请求后,weblogic连接池断开连接,所以TPS降到0,自动创建连接后可以正常请…
转自:某局Weblogic 连接池问题(现场报告)(Connection has been administratively disabled. Try later.) 目录 1. 概述 3 1.1 概述: 3 1.2 系统信息: 3 2. 连接池问题 5 2. 1 问题描述 5 2.2 错误日志分析 5 2.3连接池问题总结 14 3. 其他问题 14 3. 1 部署 14 3. 1 部署类型 15 1. 概述 1.1 概述: 应客户的要求,某局BATCH系统存在的问题进行诊断.经过日志分析及…
    由于最近某客户的系统性能比较差,所以今天又上去跟踪了一下.看了一下Default Data Cache,发现已经从10G调整到了20G,所以可以确定应该是客户的管理员已经将双机从低配置的机器切换到了高配置的机器上了.经过一段时间的观察,发现数据库(SYBASE)的负载已经回落,各项指标都已经正常,正在准备想退出,但心里总感觉有点不对劲."为什么连接数才500多?一般情况下应该是1K多的连接才对呀!“,难道,是部分应用节点没起吗?于是QQ联系运维组的同事上去应用服务器检查是否有节点没有启动…
import pymysqlfrom redis import Redisimport time h, pt, u, p, db = '192.168.2.210', 3306, 'root', 'nfwt&2016', 'xl_product_DONOT_REMOVE' h, pt, u, p, db = '192.168.2.130', 3306, 'root', 'root', 'xl_product_DONOT_REMOVE' def mysql_fetch(sql, res_type=…
记weblogic 连接池满无法链接故障诊断过程 前段时间公司负责建行的一个票据系统在,上线前几个分行试运行环境下,每天后台日志都会报oracle.jdbc.xa.OracleXAException,前台无法正常访问 通过使用weblogic的测试数据库链接,弹出无法链接提示信息,但是发现连接池使用才10个,而最大连接数60个,监控分析没有发现连接数使用满的迹象. 那个时候我们公司的老总以及客户方项目领导非常着急,都忙着找人帮忙解决,客户方也请了他们建行自己的高手过来解决,我们公司老总也打电话四…
问题: 进程启动后,线程数迅速上升至最小线程数后,缓慢上升(线程池限制)到数千,然后由于线程过多,CPU飙升到90%. 对外表现为Api无响应或连接超时. 背景 有些数据存在于另一个机房,通过内网专线连接.一个服务程序有4个数据库,其中3个在本地机房,1个在外地. 各种排查,没有解决. 最终的处理方法 Dump进程 使用进程管理器,创建进程Dump文件. 使用VisualStudio打开该Dump文件并进行托管调试 查看并行堆栈,发现大部分线程均处于MySql.Data.MySqlClient.…
1.在 使用JDBC连接池的过程中,最常见的一个问题就是连接池泄漏问题.一个池里面的资源是有限的,应用用完之后应该还回到池中,否则池中的资源会被耗尽. WebLogic Server提供了一个Inactive Connection Timeout选项,默认是60秒,如果一个连接被应用拿走之后,超过这个时间还没有还回来,WebLogic Server会强制将这个连接回收.如果应用中不存在连接泄漏的问题,则不需要这个选项.设置为0即可禁用 2.V$SESSION 记录当前连接数据库的 Session…
该问题产生的现象 页面刷新几次后,就卡住,线上就得需要重新部署(还好是测试环境,不是真正生产环境) 过程及原因 查看日志线程池满了 Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is com.alibaba.druid.pool.GetConnectionTimeoutException: wait mill…
事件背景 我在凤巢团队独立搭建和运维的一个高流量的推广实况系统,是通过HttpClient 调用大搜的实况服务.最近经常出现Address already in use (Bind failed)的问题.很明显是一个端口绑定冲突的问题,于是大概排查了一下当前系统的网络连接情况和端口使用情况,发现是有大量time_wait的连接一直占用着端口没释放,导致端口被占满(最高的时候6w+个),因此HttpClient建立连接的时候会出现申请端口冲突的情况. 具体情况如下: 于是为了解决time_wait…