我们在tomcat 7.0.30中有grails应用程序破坏。 Grails版本为2.2.4,去年运行非常稳定。 我试图将grails版本切换到2.3.4,在测试环境中它表现正常(没有任何问题)。 但是当我在20分钟后投入生产时,我开始得到以下例外
[ajp-bio-9009-exec-430] Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:100; busy:100; idle:0; lastwait:30000].. Stacktrace follows:
org.apache.tomcat.jdbc.pool.PoolExhaustedException: [ajp-bio-9009-exec-430] Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:100; busy:100; idle:0; lastwait:30000].
at grails.gorm.DetachedCriteria$_count_closure4.doCall(DetachedCriteria.groovy:686)
at grails.gorm.DetachedCriteria$_withPopulatedQuery_closure10.doCall(DetachedCriteria.groovy:931)
at org.grails.datastore.gorm.GormStaticApi$_withDatastoreSession_closure20.doCall(GormStaticApi.groovy:680)
at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:302)
at org.grails.datastore.gorm.AbstractDatastoreApi.execute(AbstractDatastoreApi.groovy:37)
at org.grails.datastore.gorm.GormStaticApi.withDatastoreSession(GormStaticApi.groovy:679)
at grails.gorm.DetachedCriteria.withPopulatedQuery(DetachedCriteria.groovy:913)
at grails.gorm.DetachedCriteria.count(DetachedCriteria.groovy:684)
at grails.gorm.DetachedCriteria.count(DetachedCriteria.groovy:683)
at com.webbfontaine.wftaglib.BeanDataLoadController.doLoadData(BeanDataLoadController.groovy:30)
at com.webbfontaine.wftaglib.BeanDataLoadController$_closure1.doCall(BeanDataLoadController.groovy:14)
at grails.plugin.cache.web.filter.PageFragmentCachingFilter.doFilter(PageFragmentCachingFilter.java:195)
at grails.plugin.cache.web.filter.AbstractFilter.doFilter(AbstractFilter.java:63)
at org.josso.tc70.agent.SSOAgentValve.invoke(SSOAgentValve.java:684)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
在我们的应用程序中,所有对DB的查询都是通过Grails GORM完成的,我们不使用任何SQL或HQL查询。
我的猜测是grails 2.3.4本身出了问题(某些连接未正确关闭/返回池中)。
我错过了什么或它的grails问题? 有什么想法吗?
答案 0 :(得分:5)
Grails 2.3.x replaced Commons DBCP with Tomcat JDBC,这可能是您的申请有所不同的原因。您可以检查池配置的差异。
答案 1 :(得分:5)
有a few bugs in Grails in dataSource default settings。这些问题将在Grails 2.3.6中修复。
以下是MySQL
的优化数据源设置示例dataSource {
pooled = true
dbCreate = "update"
url = "jdbc:mysql://localhost:3306/my_database"
driverClassName = "com.mysql.jdbc.Driver"
dialect = org.hibernate.dialect.MySQL5InnoDBDialect
username = "username"
password = "password"
properties {
// Documentation for Tomcat JDBC Pool
// http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Common_Attributes
// https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/jdbc/pool/PoolConfiguration.html
jmxEnabled = true
initialSize = 5
maxActive = 50
minIdle = 5
maxIdle = 25
maxWait = 10000
maxAge = 10 * 60000
timeBetweenEvictionRunsMillis = 5000
minEvictableIdleTimeMillis = 60000
validationQuery = "SELECT 1"
validationQueryTimeout = 3
validationInterval = 15000
testOnBorrow = true
testWhileIdle = true
testOnReturn = false
ignoreExceptionOnPreLoad = true
// http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#JDBC_interceptors
jdbcInterceptors = "ConnectionState;StatementCache(max=200)"
defaultTransactionIsolation = java.sql.Connection.TRANSACTION_READ_COMMITTED // safe default
// controls for leaked connections
abandonWhenPercentageFull = 100 // settings are active only when pool is full
removeAbandonedTimeout = 120
removeAbandoned = true
// use JMX console to change this setting at runtime
logAbandoned = false // causes stacktrace recording overhead, use only for debugging
// JDBC driver properties
// Mysql as example
dbProperties {
// Mysql specific driver properties
// http://dev.mysql.com/doc/connector-j/en/connector-j-reference-configuration-properties.html
// let Tomcat JDBC Pool handle reconnecting
autoReconnect=false
// truncation behaviour
jdbcCompliantTruncation=false
// mysql 0-date conversion
zeroDateTimeBehavior='convertToNull'
// Tomcat JDBC Pool's StatementCache is used instead, so disable mysql driver's cache
cachePrepStmts=false
cacheCallableStmts=false
// Tomcat JDBC Pool's StatementFinalizer keeps track
dontTrackOpenResources=true
// performance optimization: reduce number of SQLExceptions thrown in mysql driver code
holdResultsOpenOverStatementClose=true
// enable MySQL query cache - using server prep stmts will disable query caching
useServerPrepStmts=false
// metadata caching
cacheServerConfiguration=true
cacheResultSetMetadata=true
metadataCacheSize=100
// timeouts for TCP/IP
connectTimeout=15000
socketTimeout=120000
// timer tuning (disable)
maintainTimeStats=false
enableQueryTimeouts=false
// misc tuning
noDatetimeStringSync=true
}
}
}
答案 2 :(得分:2)
我首先检查是否存在“卡住”的线程并保持数据库连接。您可以从JVM threaddump中看到这一点。
您可以通过向Java进程PID发送SIGQUIT(3)信号在unix中执行线程转储。 您可以使用“kill -3 PID”命令执行此操作。 threaddump转到stdout(默认情况下会转到tomcat上的catalina.out)。它不会终止Java进程,因此您通常可以在生产环境中使用此方法。
获取threaddump的另一种方法是使用“jstack PID”命令。
通常值得做一些后续转储几秒钟的一部分。通过这种方式,您可以对转储进行区分,以查看哪些更改以及哪些更改保持不变。您通常必须手动进行差异化。