2012-12-06 18 views
15

Po problemach z wyciekiem połączenia i zakleszczeniami w DBCP podjęliśmy decyzję o zastąpieniu go pulą JDBC Tomcata. Oczywiście migracja była naprawdę prosta.Zwiększanie obciążenia i zmniejszanie wydajności podczas zastępowania DBCP do puli JDBC Tomcat

Ale po wdrożeniu w środowisku produkcyjnym zauważyłem, że obciążenie serwera z uruchomieniem dwóch Tomcatów wzrośnie z 4-4,5 do 5,5. Nie zrobiliśmy nic więcej poza zmianą puli. Ponadto wydajność mierzona za pomocą JMeter zmniejsza się o około 5%.

Spędziłem trochę czasu, aby dostroić parametry basenu, ale bez widocznych efektów. I wklejony mój obecny config (z <GlobalNamingResources> w server.xml) poniżej:

<Resource name="jdbc/xxxxxx" 
      auth="Container" 
      type="javax.sql.DataSource" 
      factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" 
      initialSize="10" 
      maxActive="100" 
      minIdle="10" 
      maxIdle="50" 
      maxWait="10000" 
      testOnBorrow="true" 
      testOnReturn="false" 
      testOnConnect="false" 
      testWhileIdle="false" 
      validationQuery="SELECT 1 from dual" 
      validationInterval="30000" 
      suspectTimeout="60" 
      timeBetweenEvictionRunsMillis="30000" 
      removeAbandonedTimeout="60" 
      removeAbandoned="true" 
      logAbandoned="true" 
      abandonWhenPercentageFull="50" 
      minEvictableIdleTimeMillis="60000" 
      jmxEnabled="true" 
      username="xxxxx" 
      password="xxxxx" 
      driverClassName="oracle.jdbc.OracleDriver" 
      url="jdbc:oracle:oci:xxxxx"/> 

FairQueue i PoolSweeperEnabled są prawdziwe

na wiosnę ApplicationContext-jdbc.xml mam tylko:

<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean"> 
    <property name="resourceRef"> 
     <value>true</value> 
    </property> 
    <property name="jndiName"> 
     <value>java:comp/env/jdbc/PortalDB</value> 
    </property> 
    </bean> 

Co mam robić źle? Pomyślałem, że JDBC_pool powinien być szybszy od DBCP po wyjęciu z pudełka.

+0

Spróbuj testWhenIdle = "true", a także spróbuj zminimalizować liczbę maxActive od 100 do około 20. Być może zbyt wiele połączeń w puli spowalnia działanie. –

+1

Czy używasz tego samego zapytania sprawdzającego, co poprzednio? – rootkit

+0

@ rootkit007 - nie, z dbcp nie użyłem kwerendy sprawdzania poprawności. – Dzinek

Odpowiedz

0

Twoja diagnoza jest dziwna: DBML lib AFAIK Tomcat jest po prostu przepakowaną wersją commons-dbcp ... więc zmiana z jednego na drugi nie powinna powodować żadnych zmian w zachowaniu ani wydajności. (patrz here)

Co może się jednak zmienić, jeśli używasz wersji: w szczególności, uważaj na różnice w wersji 1.3/1.4. (zobacz here)

W każdym razie konfiguracja wydaje się być w porządku (i rzeczywiście działa pomimo problemów, które mogą wystąpić). Aktualizacja bibliotek była prawdopodobnie jedynym sposobem na rozwiązanie problemów bez wchodzenia w tryb debugowania ...

Czy moglibyście dokładniej określić, co rozumiecie przez "problemy z wyciekiem połączenia i zakleszczeniami w DBCP"? To dość precyzyjna diagnoza, aby ustalić, czy istnieje powiązanie między zakleszczeniami a pulą połączeń: jak do tego doszło? Mogą występować zakleszczenia, ponieważ twoje instrukcje SQL są podatne na powstawanie zakleszczeń, podczas gdy puli tylko to umożliwia, zapewniając wiele połączeń jednocześnie - co jest właśnie jego pracą.

+0

OP mówi o puli jdbc Tomcata, która różni się od przepakowanego dbcp Tomcata. http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html – dnault

1

Twoje ustawienia i strojenie są poprawne. Zwiększenie obciążenia może wynikać z tego, że serwer obsługuje jednocześnie więcej jednoczesnych żądań. DBCP mogło uniemożliwić serwerowi przejęcie tego obciążenia z powodu sposobu zablokowania puli ze wszystkich wątków. Pula jdbc tego nie robi, więc teraz zwiększyłeś swoją współbieżność. A jeśli obciążenie wzrasta, odpowiedź może się zmniejszyć, ale zwiększy się przepustowość.

zacząłbym strojenie

maxActive 

dopasować swoje maxThreads w celu obsługi współbieżności.

Powiązane problemy