c3p0 캐시 개체의 성능 문제 :

이상한 예제를 공유하고 싶습니다. 프로덕션 환경에서 응용 프로그램이 OOM 예외를 throw하는 중, 힙 덤프를 가져 와서 나중에 com.mchange.v2.c3p0.stmt.PerConnectionMaxOnlyStatementCache 인스턴스에 문제가 있음을 분석하기 시작했습니다. 이 개체의 크기는 힙 크기의 약 50 %입니다. 수십억 명의 사용자가 응용 프로그램을 실행하고 서버가 계속해서 다시 작동합니다.c3p0 캐시 개체의 성능 문제 :

이 응용 프로그램은 tomcat 커넥터가 최대 동시 요청 300 개를 허용하고 다음에 c3p0 구성이 실행되는 tomcat에서 실행됩니다.

jdbc.hibernate.c3p0.minPoolSize=2 
jdbc.hibernate.c3p0.maxPoolSize=150 
jdbc.hibernate.c3p0.maxIdleTime=0 
jdbc.hibernate.c3p0.maxStatementsPerConnection=50 
jdbc.hibernate.c3p0.numHelperThreads=6

힙 모니터링 도구에서 우리는 org.apache.catalina.loader.WebappClassLoader @ "에 의해로드 된 다음과 같은 메시지"com.mchange.v2.c3p0.stmt.PerConnectionMaxOnlyStatementCache "의

하나 개의 인스턴스를 얻고있다 0x82f1c58 "은 72 970 824 (57,75 %) 바이트를 차지합니다. 메모리 조언 제발

"0x82f1c58 org.apache.catalina.loader.WebappClassLoader @"에 의해로드 "com.mchange.v2.c3p0.stmt.PerConnectionMaxOnlyStatementCache"의 한 인스턴스에 축적된다 : - 는 이유는 무엇 일 수 있습니다 거대한 기억을 취하는이 사건? 올바른 c3p0 구성으로 실행하고 있습니까? 로드가 많은 응용 프로그램에 권장되는 구성은 무엇입니까?

출처

2012-07-17 user1451493

Tomcat을 사용 중이라고하셨습니다. 왜 Tomcat의 연결 풀링 대신 자신의 C3P0을 사용합니까? – jpkrohling

이 매개 변수를 설정해보십시오. –

-1

는 고성능 연결 풀 BoneCP 시도 사전에

덕분에, 그것은 C3P0 및 아파치 DBCP의 다양한 성능 중심의 문제를 해결합니다.

출처

2012-07-17 08:40:29

답장을 보내 주셔서 감사합니다! 그러나 유감스럽게도 BoneCP를 사용하기 위해 응용 프로그램을 변경할 수 없으며 응용 프로그램이 너무 많은 클라이언트에서 실행됩니다. 이 문제를 해결하는 방법을 찾아야합니다. = "1000" enableLookups = "FALSE" 있는 redirectPort = "8443" acceptCount = "150" 은 ConnectionTimeout을 maxHttpHeaderSize = "8192" maxThreads가 = "500" minSpareThreads = "50" maxSpareThreads 다음과 같이 톰캣 설정은 = "20000" disableUploadTimeout = "true" – user1451493

maxStatementsPerConnection = 50 및 maxPoolSize = 150으로 설정했습니다. 즉, 명령문 캐시에는 드라이버가 명령문과 연관시키는 모든 리소스의 메모리 공간을 포함하여 한 번에 7500 개의 열린 문이있을 수 있습니다. 당신은 기본적으로 c3p0에게 많은 메모리를 사용하도록 요구하고 있습니다. 이론적으로 메모리 비용은 Statement를 준비하는 성능 비용에 비해 낮습니다.

처음에는 문안 캐싱이 일반적으로 실패자이므로 사용하지 말아야합니다. maxStatements와 maxStatementsPerConnection을 모두 0으로 설정 한 상태에서 앱을 벤치마킹하여 Statement 캐싱을 실제로 사용하고 있는지 여부를 테스트해야한다. PreparedStatement 객체에서 많은 구문 분석 및 준비를 캐시하는 드라이버의 경우 명령문 캐싱이 큰 도움이 될 수 있습니다. 그러나 캐시의 메모리 사용량과 사전 캐시 된 진술의 성능 이점 사이의 균형을 맞 춥니 다. Statement 캐싱이 성능에 도움이된다고하더라도 이점이 비용을 초과하는 지점을 초과했음을 분명히 알 수 있습니다.

앱에서 150 개의 준비 문을 자주 사용합니까? 그 숫자를 더 작게, 바람직하게는 훨씬 더 작게 만들 수 있습니까? 드물게 사용되는 명령문이 캐시에서 빠져 나와 좋은 실수를하지 않을 것으로 예상하십니까? 또는 해당 번호 만 남겨도되지만 maxStatementsPerConnection과 전역 maxStatements 설정 (현재 사용중인 암시 적 7500보다 작은 값으로 설정)을 결합하십시오. maxStatementsPerConnection과 maxStatements를 결합하면 각 Connection은 풀이 작을 때 maxStatementsPerConnection을 가질 수 있지만 풀 크기가 커지고 메모리 공간이 위험 해지면 global Statement 제한으로 인해 사용되지 않은 Statement가 시작됩니다 메모리를 보존하기 위해 캐시에서 빠져 나간다.

도움이되기를 바랍니다.

출처

2012-07-17 22:10:57

안녕하세요, 스티브, 감사합니다. – user1451493

maxIdleTime = 0이라고했기 때문입니다.

maxIdleTime을 0이 아닌 값으로 설정하면 C3P0이 풀에서 연결을 제거하고 데이터베이스 리소스를 비울 수 있습니다.

maxIdleTime 0

로 설정되어있을 때이 발생하지 않습니다.

여러분의 연결 고리가 풀에서 제거되지 않는다고 생각합니다. 그래서 힙 크기가 커지고 있습니다.

자세한 내용은 click here.

출처

2013-06-24 13:25:30 user1632989

c3p0 캐시 개체의 성능 문제 :

답변

관련 문제