We are already in the process of making 11 connections and the number of simultaneous builds has been throttled to 10

 

Caused by: java.sql.SQLException: We are already in the process of making 11 connections and the number of simultaneous builds has been throttled to 10

情况一

但是我的最大值都是120了，是非常大的，不知道怎么回事提示了一个10，经过查询

simultaneous-build-throttle :

This is the maximum number of connections we can be building at any one time. That is, the number of new connections that have been requested but aren`t yet available for use. Because connections can be built using more than one thread (for instance, when they are built on demand) and it takes a finite time between deciding to build the connection and it becoming available we need some way of ensuring that a lot of threads don`t all decide to build a connection at once. (We could solve this in a smarter way - and indeed we will one day) Default is 10.

 

相应的解决方案也就出来了

把

10

改成

20

情况二

服务器端jboss控制台报如下错误:

java.sql.SQLException: We are already in the process of making 501 connections and the number of simultaneous builds has been throttled to 500
开始认为是proxool连接池连接太少了,我增加到2000个,重启jboss然后一下子就变成了
java.sql.SQLException: We are already in the process of making 2001 connections and the number of simultaneous builds has been throttled to 2000  

在google.com(不是.cn)找到这个地方:http://www.quickfixj.org/jira/browse/QFJ-316?&decorator=printable
There is a bug in the proxool library. The default parameter defined in the documentation are not set. Therefore parameter like MaximumConnectionCount are not set. JdbcUtil from QuickFixJ sets this parameter. But the parameter SimultaneousBuildThrottle is not set and therfore 0. This leads to SQLExcption under high load. I changed JdbcUtil.getDataSource() with the line
ds.setSimultaneousBuildThrottle(10);
after the line

ds.setMaximumConnectionCount(10);

Now I do not get SQLException anymore.

我以为原来用的proxool.properties配制项少了什么,然后换成proxool.xml的配制还是一样

然后我使用MySQLAdministrator查看是那个连接过多,发现unauthenticated user这个启动系统时狂增
google之
找到如下两个方法:
http://blog.i918.cn/html/06/5806-2122.html
在經過多方測試，以及詢問官方原廠的回應下
發現這屬於官方一個系統上的特殊設定，亦可稱呼他為 mysql 的 bug
不管連結的的方式是經過 hosts 或是 IP 的模式，他都會對 DNS 做反查
會嘗試去反查 IP -> dns ，由於反查解析過慢，無法應付快速多量的查詢
反查是上層 ISP 所掌控，並不是我們可以解決及要求的

在知道問題的癥結點後，要解決這個問題就有相對應的方法
其方法分為兩個步驟，第一是開啟 Mysqld 的時候加入特定的參數啟動
第二就是修改 mysql 的連線設定等，如下所示

    啟動參數； with --skip-name-resolve =>這樣就可以關閉反查動作
    更改 my.cnf；加強以下設定
    [mysqld]
    datadir=/services/mysql/
    socket=/tmp/mysql.sock
    port=3306
    set-variable = key_buffer_size=64M
    set-variable = max_connections=1024
    set-variable = interactive_timeout=30
    set-variable = wait_timeout=30
    set-variable = join_buffer_size=10M
    set-variable = long_query_time=20
    set-variable = table_cache=256
    set-variable = sort_buffer=4M
    set-variable = record_buffer=1M
    set-variable = back_log=500

    [mysqld.server]
    user=mysql
    basedir=/usr/local

經過以上的設定及重新啟動過後，直到現在還沒有看到一個 unauthenticated user 的情況發生
近日還是會持續的觀察 Mysql 的運作情況，如有問題將會持續的稟報及解決。

http://blog.csdn.net/eroswang/archive/2008/07/10/2633237.aspx
 1、启动时带参数　 --skip-name-resolve
 2、访问的主机授权时用IP，最好把该主机的IP及主机名写到/etc/hosts文件中
 我们这边的管理员是做如下处理:
/etc/my.cnf
下mysqld
随便一行加skip-name-resolve