用的proxool的数据库连接池，怎么把cpu占用率降下去

现在常用的开源数据库连接池主要有c3p0、dbcp、proxool三种，其中：

Spring 推荐使用dbcp；

Hibernate 推荐使用c3p0和proxool；

1、 DBCP：apache

DBCP（DataBase connection pool）数据库连接池。是apache上的一个 java连接池项目，也是 tomcat使用的连接池组件。单独使用dbcp需要3个包：common-dbcp.jar,common-pool.jar,common-collections.jar由于建立数据库连接是一个非常耗时耗资源的行为，所以通过连接池预先同数据库建立一些连接，放在内存中，应用程序需要建立数据库连接时直接到连接池中申请一个就行，用完后再放回去。dbcp没有自动的去回收空闲连接的功能。

2、 C3P0：

C3P0是一个开源的jdbc连接池，它实现了数据源和jndi绑定，支持jdbc3规范和jdbc2的标准扩展。c3p0是异步 *** 作的，缓慢的jdbc *** 作通过帮助进程完成。扩展这些 *** 作可以有效的提升性能。目前使用它的开源项目有Hibernate，Spring等。c3p0有自动回收空闲连接功能。

3、 Proxool：Sourceforge

Proxool是一种Java数据库连接池技术。是sourceforge下的一个开源项目，这个项目提供一个健壮、易用的连接池，最为关键的是这个连接池提供监控的功能，方便易用，便于发现连接泄漏的情况。

对比：

1>相同时间内同等量的线程数和循环次数下：通过对三个连接池的三个标志性性能测试参数（Average,median,90%Line）进行比较发现：性能dbcp<=c3p0<proxool；

2>不同情况下的同一数据库连接池测试：通过观察 Average,median,90%Line三个参数发

现三个连接池的稳定性（三种连接池的三个测试参数的变化情况）依次：稳定性dbcp>=c3p0>proxool。

结论：

通过对三种数据库连接池的性能测试发现，proxool和 c3p0能够更好的支持高并发，但是在稳定性方面略逊于 dpcp；

CPU占用过高诊断思路

mpstat -P ALL 1，查看cpu使用情况，主要消耗在sys即os系统调用上

perf top，cpu主要消耗在_spin_lock

生成perf report查看详细情况

CPU主要消耗在mutex争用上，说明有锁热点。

采用pt-pmp跟踪mysqld执行情况，热点主要集中在mem_heap_alloc和mem_heap_free上。

Pstack提供更详细的API调用栈

Innodb在读取数据记录时的API路径为

row_search_for_mysql --》row_vers_build_for_consistent_read --》mem_heap_create_block_func --》mem_area_alloc --》malloc --》  _L_unlock_10151 --》__lll_unlock_wait_private

row_vers_build_for_consistent_read会陷入一个死循环，跳出条件是该条记录不需要快照读或者已经从undo中找出对应的快照版本，每次循环都会调用mem_heap_alloc/free。

而该表的记录更改很频繁，导致其undo history list比较长，搜索快照版本的代价更大，就会频繁的申请和释放堆内存。

Linux原生的内存库函数为ptmalloc，malloc/free调用过多时很容易产生锁热点。

当多条 SQL 并发执行时，会最终触发os层面的spinlock，导致上述情形。

解决方案

将mysqld的内存库函数替换成tcmalloc，相比ptmalloc，tcmalloc可以更好的支持高并发调用。

修改my.cnf，添加如下参数并重启

[mysqld_safe]malloc-lib=tcmalloc

上周五早上7点执行的 *** 作，到现在超过72小时，期间该实例没有再出现cpu长期飙高的情形。

以下是修改前后cpu使用率对比

---