【性能调优】一次监控数据错误的性能调优经历

负责的消息中心推送服务出现接口耗时较长的现象，结合链路系统排查，发现在获取数据库连接这一步耗时很久。处理正常的业务流量外，应用本身还有一些定时任务，最为频繁的是每十分钟1次。经过观察后，将该时间调整为30min。查看应用的数据库连接池监控，发现。

现象 某个下午，某个服务的测试环境突然出现大量接口延时告警，从监控上看，接口p99耗时基本都达到了5s以上，而且接口延时越来越长 随着业务方的不断超时重试，数据库线程被打满，等待线程数飙高，大量线程阻塞 初步排查过程 1、通过APM链路监控，我们发现所有链路的主要耗时都集中在了DataSource#getConnection这个过程中 2、初步怀疑，可能是因为存在SQL 慢查询导致，但后来发现根因并不在此，因为监控显示，当时最慢的SQL99线是56.99ms，qps低于0.01（基本可以排除SQL慢查

druid

有天，用户突然反馈系统页面查询缓慢，影响使用，我查了日志报： druid 连接池异常 GetConnectionTimeoutException wait millis 9120, active 20, maxActive 20 creating 0

PreparedStatement Cache的分析 PreparedStatement Cache使用分析_wliang578的博客-CSDN博客 性能压测基于oracle数据库的11.2的版本 优化后:增加了pscache。 压测场景: 1 两条简单的查询语句 orm框架：hibernate 数据库连接池:druid 缓存最大的pscache数量：20 从上述的对比来看，增加了pscache耗时还有增加，出乎意料。 从各大线程池（dbcp,druid）提供方，都说增加pscach

有一台运行oracle11 的服务器，从客户端连接非常慢。登录到本机上，用sqlplus很快，用jdbc连接，getConnection很慢。一般都要10秒以上。 检查后发现是设置了dns，而dns的链接有事错误的。主要删除/etc/resolv.conf的设置就好了。 ...

在Java项目中,我使用的是ojdbc6 jarcom.oracleojdbc611.2.0.1.0compile我运行一天的第一次,dataSource.getConnection()很快.第二次通常没关系.接下来的几次大约需要45秒.之后,需要几分钟.一旦我有一个给定应用程序运行的FIRST连接,我得到的任何新连接都非常快.此延迟仅为给定运行获取FIRST连接.是什么让我的第一次连接变得如此缓...

继上次将大数据查询改为分页查询或者流式查询后，系统在生产环境运行时Tomcat9仍然会持续出现内存每天都增加，tomcat无法回收=====还在内存溢出OOM中于是继续将heap导出jmap -dump:format=b,file=heap.bin 5760在MAT中分析，发现升级了dbcp2及log4j2后，log4j2在大内存中出现的次数比较多，而且在visualvm线程dump中发现很多由此查找log4j2 导致的Unsafe.park问题。

为什么需要连接池 当并发量很低的时候，连接可以临时建立，但当服务吞吐达到几百、几千的时候，频繁 建立连接 Connect 和 销毁连接 Close 就有可能会成为服务的一个瓶颈，那么当服务启动的时候，先建立好若干个连接并存放于一个队列中，当需要使用时从队列中取出一个并使用，使用完后再反还到队列去，而对这个队列数据结构进行维护的，就是连接池。 连接池案例 Hyperf官方文档中有一个简单连接池的案例： <?php use Hyperf\Pool\SimplePool\PoolFactory;

DriverManager.getConnection()部署到linux服务器后连接延迟问题 一，Linux中/etc/resolv.conf文件简析 /etc/resolv.conf是DNS客户机配置文件，用于设置DNS服务器的IP地址及DNS域名，还包含了主机的域名搜索顺序。 该文件是由域名解析 器（resolver，一个根据主机名解析IP地址的库）使用的配置文件。 二，删除Linux中/etc/resolv.conf 该配置文件影响DriverManager.getConnecti

本章，我们将通过实际案例讲解一个Web应用的内存溢出问题，该内存溢出问题的排查涉及Tomcat的一些底层原理，最终排查发现是由于请求超时问题导致，我们先来看下系统的背景。本章，我们通过一个实际案例分析了因为请求超时引起的内存溢出问题，以及相应的排查思路。解决这类问题的思路其实都是一致的，需要一步步去分析，在实践中积累经验，举一反三。

1、环境准备1）编写脚本2）执行压测3）打印快照2、问题定位1）在快照中，搜索是否存在BLOCKED 或者 TIMED_WAITING字段2）查看TIMED_WAITING日志中是否存在，跟自身业务相关的日志信息3）检查是否存在getconnection的关键字，便是数据库连接等待3、问题分析1）查看压测中的应用，数据库链接数执行压测，应用服务器输入命令：安装netstat：gerp 10.196.130.102：3306 为过滤数据库服务器；grep 39671 为过滤应用程序；