|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-20
还有一个问题就是：
先前能在5秒左右一次插入1W条记录。 但是当插入到20W的时候，再每次插入1W时，速度明显降低，每次逐步从20秒递增。 |
| 返回顶楼 | |
|
发表时间：2010-09-20
lvp 写道 还有一个问题就是：
先前能在5秒左右一次插入1W条记录。 但是当插入到20W的时候，再每次插入1W时，速度明显降低，每次逐步从20秒递增。 这个问题不好说，可能是IO的瓶颈。同时，批处理的话，一次Commit用的一次IO传输。 |
| 返回顶楼 | |
|
发表时间：2010-09-21
MySQL会在连接8个小时不活动后关掉连接，而且再连也没用。
DBCP连接池没有处理MySQL的这个问题，所以只要8小时后你的连接不活动，那就得重启服务器， C3P0默认已经处理好了这个问题，会定时的测试连接，不让连接被MySQL在这种情况下杀掉。 |
| 返回顶楼 | |
|
发表时间：2010-09-21
引用 第2,最严重的是,我怀疑程序在启动的时候并没有像想象那样预先先分配若干个可以直接使用的连接对象. 我检查过 -> mysql -> show processlist; 除了MySql 本地连接外, processlist中就没有其他的记录. 所以是不是几乎或者根本就没有创建已经可以连接的Connection对象呢,这个代码的写法? 要设置initialSize参数，先设为5吧 ，默认值为0， 连接池启动时创建的初始化连接数量,1.2版本后支持 。 引用 for (int i = 0; i < 1000; i++) { manager.testInsert(); } 在一个线程中循环插入1000条，理论上只须要使用一个Connection对象就够了。 |
| 返回顶楼 | |
|
发表时间：2010-09-21
下文引用于网络
DBCP的bug非常多，因此Hibernate3已经不再支持DBCP连接池，而推荐使用C3PO。建议你更换数据库连接池。 然后跑去Hibernate官方论坛看，果然，在Please migrate away from DBCP看到Gavin说： 引用: Guys, after many problems with DBCP, I have decided to remove built-in support for DBCP from Hibernate3, and deprecate DBCP in Hibernate 2.1. I advise everyone to migrate away from DBCP to something that actually works, like C3P0 or Proxool. (If you /must/ use DBCP, you can always write your own connection provider.) Actually, it is probably about time we remove any remaining dependencies to Apache commons stuff, since historically they have caused just /so/ much trouble. The only Apache things that do seem to work very well are Ant and log4j. Even commons-logging is a PIA, especially in Tomcat. C3P0是Hibernate3.0默认的自带数据库连接池，DBCP是Apache开发的数据库连接池。我们对这两种连接池进行压力测试对比，发现在并发300个用户以下时，DBCP比C3P0平均时间快1秒左右。但在并发400个用户时，两者差不多。 速度上虽然DBCP比C3P0快些，但是有BUG：当DBCP建立的数据库连接，因为某种原因断掉后，DBCP将不会再重新创建新的连接，导致必须重新启动Tomcat才能解决问题。DBCP的BUG使我们决定采用C3P0作为数据库连接池。 |
| 返回顶楼 | |
|
发表时间：2010-09-21
jorneyR 写道 MySQL会在连接8个小时不活动后关掉连接，而且再连也没用。
DBCP连接池没有处理MySQL的这个问题，所以只要8小时后你的连接不活动，那就得重启服务器， C3P0默认已经处理好了这个问题，会定时的测试连接，不让连接被MySQL在这种情况下杀掉。 我已经说过了,现在讨论的是DBCP和MySQL. 不是我想用C3P0就能用的. 我提出的问题可能和MySQL的优化有关,也可能和我连接池写法有关。但是不能说我用DBCP出现现在的几个问题,大家就告诉我应该用C3P0。那如果我问C3P0的问题是不是又要告诉我应该用什么。 解决问题不能回避！ 另外MySQL会在连接8小时不活动后关掉连接. DBCP完全可以搞定这个问题。 |
| 返回顶楼 | |
|
发表时间：2010-09-21
mercyblitz 写道 lvp 写道 还有一个问题就是：
先前能在5秒左右一次插入1W条记录。 但是当插入到20W的时候，再每次插入1W时，速度明显降低，每次逐步从20秒递增。 这个问题不好说，可能是IO的瓶颈。同时，批处理的话，一次Commit用的一次IO传输。 我CPU显示的不是很正常，在前面5秒能插入的时候，CPU几乎90%~100%。 但是当我发现CPU占用率下降到30%~50%的时候我很开心，但是结果发现再插入1W的数据时 时间越来越长。 |
| 返回顶楼 | |
|
发表时间：2010-09-21
elf8848 写道 引用 第2,最严重的是,我怀疑程序在启动的时候并没有像想象那样预先先分配若干个可以直接使用的连接对象. 我检查过 -> mysql -> show processlist; 除了MySql 本地连接外, processlist中就没有其他的记录. 所以是不是几乎或者根本就没有创建已经可以连接的Connection对象呢,这个代码的写法? 要设置initialSize参数，先设为5吧 ，默认值为0， 连接池启动时创建的初始化连接数量,1.2版本后支持 。 引用 for (int i = 0; i < 1000; i++) { manager.testInsert(); } 在一个线程中循环插入1000条，理论上只须要使用一个Connection对象就够了。 我也在看看，昨天一晚上睡觉都在考虑这些个问题！ 我使用了不同的DBCP的3套代码，测下来的结果大同小异，我现在怀疑是我程序的参数配置和MySQL的参数配置配合的问题！ 我不知道用过DBCP的朋友有遇到这样的问题没，但是数据量确实不算很大才几十W就出现这样的问题，费神。 |
| 返回顶楼 | |
|
发表时间：2010-09-21
这个和连接池有关系吗？连接池资源耗尽了吗？找两个相同的硬件环境测一下吧，mysql是本机的话和你磁盘的io有很大关系
|
| 返回顶楼 | |
|
发表时间：2010-09-21
你insert数据,没有批处理吗！
1、APATCH有自带物理连接池，你不需要理会。 2、需要看看你需要的是大数据量，还是小数据量！ 3、建议删除你的pool.然后使用完连接后CLOSE（APATCH自带有物理连接池） |
| 返回顶楼 | |
