Hibernate et performance CPU

Version imprimable

31/08/2009, 15h31
Sniper37

Hibernate et performance CPU

Bonjour,

j'utilise Hibernate 3, Spring 2. dans une application web, lorsque l'utilisateur se connecte, j'ai besoin de lancer plusieurs requêtes pour charger des objets (ses droits) en session.
quand j'essaye des tests de charges, pour 10 utilisateurs virtuels, la CPU monte à plus de 90% à la connexion d'un utilisateur,
j'ai essayé de regarder ce qui se passe, je pense que le chargement des objets hibernates utilise beaucoup la CPU.

Est ce que celà est normal? comment peut on réduire cette utilisation excessive de la CPU?

Merci..
02/09/2009, 10h07
Rei Ichido

Le mieux serait probablement de réduire le nombre d'appels, en les synthétisant. Tu peux par exemple faire appel à une procédure stockée qui te renverrait un gros bloc d'informations dans une map.
02/09/2009, 10h14
fr1man

Difficile de donner un avis avec ces infos.
Affiche le logs d'Hibernate (sql) pour voir les requêtes qui sont envoyées vers ta base.
Installe un outil genre p6spy pour voir le temps que tu passes dans tes requêtes.

Ca semble quand même bizarre vu le peu d'utilisateurs simultanés..
02/09/2009, 10h45
Sniper37

Je vois les requêtes qui causent le problèmes, c'est une requête qui a beaucoup de colonnes en retour, ou c'est un ensemble de requêtes: load de plusieurs listes et chaque liste a pas mal de colonnes aussi.. je ne sais pas si ça vient de la configuration d'hibernate ou d'ailleurs, les requetes en base s'exécutent avec un temps raisonnable, la CPU de mon serveur est de 3Ghz, je ne veux pas demander plus sans savoir si le problème ne serait pas applicatif.

à la fin des requêtes le serveur 'se calme', je suis certain que c'est le traitement hibernate qui prend charge la CPU.

NB: hibernate 3.2.GA + c3p0+ spring 2.5
02/09/2009, 11h05
fr1man

Combien de colonnes "remontes" tu ?
Est-ce que tes requêtes ramènent juste les données dont tu as besoin, ou plus ?
As-tu désactivé le lazy-loading ?
02/09/2009, 11h09
OButterlin

Citation:

Envoyé par fr1man

Combien de colonnes "remontes" tu ?
Est-ce que tes requêtes ramènent juste les données dont tu as besoin, ou plus ?
As-tu désactivé le lazy-loading ?

Je pense également que son problème vient de là...
02/09/2009, 11h25
Sniper37
Citation:

Envoyé par fr1man

Combien de colonnes "remontes" tu ?
Est-ce que tes requêtes ramènent juste les données dont tu as besoin, ou plus ?
As-tu désactivé le lazy-loading ?

yes, je désactive le lazy-loading, c'est désactivé par défaut avec hibernate 3 je pense ..

j'ai entre 20 et + de 50 colonnes, suivant les requetes, sachant que je n'ai pas besoin de toutes les colonnes mais, je ne peux pas dire à hibernate de ne pas prendre par exemple une colonne qui n'est jamais renseigné ou pour un join ne pas prendre toutes les colonnes.
mais même sans jointure, le load des listes prend baecuou de ressources:
Exemple:
Code:

1 2 List result = getHibernateTemplate().find("from Role order by name")
02/09/2009, 11h36
OButterlin

Peux-tu montrer le mapping par hasard ?
Également la log (pour voir les requêtes générées) ?

un exemple de mapping:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<hibernate-mapping>
    <class name="com.xx.model.domain.Company" table="COMPANY">
        <id name="companyId" type="long">
            <column name="COMPANY_ID" precision="18" scale="0" />
            <generator class="identity" />
        </id>
     	<many-to-one name="clientOf" class="com.xx.model.domain.Company" >
            <column name="CLIENT_OF" precision="18" scale="0" />
        </many-to-one>
 
        <property name="name" type="string">
            <column name="NAME" length="100" not-null="true" unique="true" />
        </property>
        .. 
        ...
 
</hibernate-mapping>

et la requete générée (le join est fait en requete HQL)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
  select
        this_.COMPANY_ID as COMPANY1_5_1_,
        this_.CLIENT_OF as CLIENT2_5_1_,
        this_.ID_TEAM as ID3_5_1_,
        this_.NAME as NAME5_1_,
        this_.MAILING_ADDRESS as MAILING5_5_1_,
        this_.LOCATION as LOCATION5_1_,        
        this_.COMPANY_COMMENT as COMPANY8_5_1_,
        this_.UPDATE_DATE as UPDATE9_5_1_,
        this_.UPDATED_BY as UPDATED10_5_1_,
        company2_.COMPANY_ID as COMPANY1_5_0_,
        company2_.CLIENT_OF as CLIENT2_5_0_,
        company2_.ID_TEAM as ID3_5_0_,
        company2_.NAME as NAME5_0_,
        company2_.MAILING_ADDRESS as MAILING5_5_0_,
        company2_.LOCATION as LOCATION5_0_,        
        company2_.COMPANY_COMMENT as COMPANY8_5_0_,
        company2_.UPDATE_DATE as UPDATE9_5_0_,
        company2_.UPDATED_BY as UPDATED10_5_0_ 
    from
        COMPANY this_ 
    left outer join
        COMPANY company2_ 
            on this_.CLIENT_OF=company2_.COMPANY_ID 
    order by
        this_.NAME asc

J'ai stressé l'application en activant tous les logs d'hibernate, je remarque que ce qui prend du temps c'est la construction des objets, à la fin lorsque le serveur est saturé, j'ai une exception

Citation:

java.lang.NullPointerException
at org.apache.log4j.LogManager.getLogger(LogManager.java:188)
at org.apache.log4j.Logger.getLogger(Logger.java:104)
at org.apache.commons.logging.impl.Log4JLogger.getLogger(Log4JLogger.java:229)
at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:193)

02/09/2009, 14h13
OButterlin

As-tu la même "lourdeur" en ne faisant qu'une simple liste de "company" ?
(sans la jointure)
02/09/2009, 15h08
Sniper37

Citation:

Envoyé par OButterlin

As-tu la même "lourdeur" en ne faisant qu'une simple liste de "company" ?
(sans la jointure)

oui j'ai testé, 20 utilisateurs virtuels qui lancent la requete sans jointure, et ça prend pas mal de CPU plus de 96%, mais, c'est rapide, et le serveur retombe à moins de 1% après.
02/09/2009, 16h03
OButterlin

C'est la première opération sur les données de ta base ?
Tu as la même montée en charge par la suite ?
02/09/2009, 16h26
Sniper37

Citation:

Envoyé par OButterlin

C'est la première opération sur les données de ta base ?
Tu as la même montée en charge par la suite ?

il y'a bien plus de montée en charge la première opération, mais, d'autre requêtes par la suite causent des problèmes.
même au démarrage de tomcat la JVM prend 97% de la CPU..
02/09/2009, 16h56
OButterlin

La première fois qu'on fait appel à Hibernate, c'est plus long, mais ça dépend du mapping... plus il y en a, plus c'est long...

Maintenant, pour moi, 97% de CPU ne posent pas plus de problèmes que ça... s'il n'y a pas d'autre processus en attente, pourquoi il ne prendrait pas toute la ressource...
02/09/2009, 18h06
Sniper37

Citation:

Envoyé par OButterlin

La première fois qu'on fait appel à Hibernate, c'est plus long, mais ça dépend du mapping... plus il y en a, plus c'est long...

Maintenant, pour moi, 97% de CPU ne posent pas plus de problèmes que ça... s'il n'y a pas d'autre processus en attente, pourquoi il ne prendrait pas toute la ressource...

oui mais ça peut monter à 99%, et quand j'ajoute plusieurs users, ça plante. normalement la CPU ne doit pas dépasser 80% pour une utilisation normale.
03/09/2009, 09h23
fr1man

Ca ne viendrait pas de ton serveur ou de ton serveur d'application ou autres.
Ou alors ton serveur est sous dimensionné.
03/09/2009, 09h30
Sniper37

Citation:

Envoyé par fr1man

Ca ne viendrait pas de ton serveur ou de ton serveur d'application ou autres.
Ou alors ton serveur est sous dimensionné.

C'est possible, je suis entrain de tester en modifiant les paramètres du serveur d'application: tomcat 6.0.18.

Le processeur du serveur :

Code:

Intel(R) Xeon(R) CPU X5355 @ 2.66GHz

Il doit avoir 2Go de mémoire, mais, elle n'est jamais utilisée à plus de 60%.

Je ne voulais pas demander un double proc sans trouver d'où vient le problème.
08/09/2009, 15h55
Sniper37

Re.....

J'ai profiler un peu le serveur, en modifiant pas mal d'options JVM, je remarque que le problème vient toujours d'un thread de gestionnaire de pool de connexion c3p0, la méthode createConnection prend consomme beaucoup de cpu, et elle est appelée plusieurs fois..
quelqu'un a une idée?
08/09/2009, 15h58
fr1man

A tout hasard, n'y a t il pas un bug reconnu avec ta version de C3P0 ?
08/09/2009, 16h03
Sniper37

aucune idée:roll:
j'utilise la 0.9.1.2
08/09/2009, 16h08
fr1man

Et si tu essayais avec un autre pool de connexion ?
08/09/2009, 16h11
OButterlin

Quels sont tes paramètres c3p0 ?
08/09/2009, 16h12
fr1man

Ton pool est suffisamment grand ?

J'utilise le driver jdbc pour SQL Server 2005, ja'i essayé de mettre le pool plus grand mais c'est pareil..

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
<bean class="com.mchange.v2.c3p0.ComboPooledDataSource" id="dataSource"
		destroy-method="close">
		<property name="driverClass">
			<value>${datasource.driver}</value>
		</property>
		<property name="jdbcUrl">
			<value>${datasource.url}</value>
		</property>
		<property name="user">
			<value>${datasource.username}</value>
		</property>
		<property name="password">
			<value>${datasource.password}</value>
		</property>
		<property name="acquireIncrement">
			<value>5</value>
		</property>
		<property name="minPoolSize">
			<value>10</value>
		</property>
		<property name="maxPoolSize">
			<value>100</value>
		</property>
 
		<property name="initialPoolSize">
			<value>50</value>
		</property>
		<property name="checkoutTimeout">
			<value>90000</value>
		</property>
		<property name="maxStatements">
			<value>0</value>
		</property>
		<property name="maxStatementsPerConnection">
			<value>5</value>
		</property>
		<property name="automaticTestTable">
			<value>c3p0_test_table</value>
		</property>
		<property name="numHelperThreads">
			<value>20</value>
		</property>
</bean>

08/09/2009, 17h16
OButterlin

Tu pourrais déjà faire un test en retirant "automaticTestTable"
08/09/2009, 17h42
Sniper37

Citation:

Envoyé par OButterlin

Tu pourrais déjà faire un test en retirant "automaticTestTable"

oui c'est très légèrement mieux, mais reste toujours des piques de CPU, 99.9%..:(
08/09/2009, 17h46
OButterlin

Ça peut également venir du driver JDBC, mais là... c'est une autre histoire :aie:
08/09/2009, 17h59
Sniper37

Citation:

Envoyé par OButterlin

Ça peut également venir du driver JDBC, mais là... c'est une autre histoire :aie:

Justement je viens de télécharger la dernière version du driver, je teste et je vous tiens au courant, même si j'ai le sentiment que ce n'est pas là le problème :)
09/09/2009, 11h22
Sniper37

même avec la dernière version du driver; j'ai le même problème, je vais tester un autre gestionnaire de pool.

re bonjour,

j'ai testé avec un autre gestionnaire de pool et pas d'amélioration, par contre, je remarque que sur tomcat5.5 l'usage de CPU augmente si j'ai boucp d'utilisateurs en même temps mais le pique sur 99% dure plus longtemps, avec tomcat 6, même avec 5 utilisateurs, le serveur monte à 99% mais cela ne dure pas longtemps si je mets entre 50 et 100 utilisateurs, il reste un moment entre 97 et 99.9%, le serveur ne tombe pas mais le temps de réponse est très long.
Je pense toujours que le problème vient du chargement des objets hibernate, voilà ma config hibernate si quelqu'un voit un problème:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
 
<bean class="org.springframework.orm.hibernate3.LocalSessionFactoryBean"
		id="sessionFactory" singleton="true">
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect"> org.hibernate.dialect.SQLServerDialect </prop>
<prop key="current_session_context_class"> thread</prop>
<prop key="hibernate.max_fetch_depth">2</prop>
<prop key="hibernate.show_sql">true</prop>
<prop key="hibernate.format_sql">true</prop>
<prop key="hibernate.cache.provider_class">org.hibernate.cache.OSCacheProvider</prop>
<prop key="hibernate.cache.use_query_cache">true</prop>
<prop key="hibernate.cache.use_second_level_cache">false</prop>
<prop key="hibernate.cglib.use_reflection_optimizer">true</prop>
<prop key="hibernate.jdbc.bach_size">40</prop>
<prop key="hibernate.generate_statistics">false</prop> 
<prop key="hibernate.connection.release_mode"> auto </prop>
<prop key="default_schema">dbo</prop>
</props>
</property>
<property name="dataSource">
<ref local="dataSource" />
</property>
<property name="mappingResources">
<list>
<value>xxxx.hbm.xml</value>
...
</list>
</property>
 
</bean>	
<bean id="hibernate-type-logging-workaround" class="com.filmat.kb.logger.LogHibernateHelper" singleton="true"  />
	<!-- Spring Data Access Exception Translator Defintion -->
	<bean id="jdbcExceptionTranslator"
		class="org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator">
		<property name="dataSource">
			<ref bean="dataSource" />
		</property>
	</bean>
<!-- Hibernate Template Defintion -->
	<bean id="hibernateTemplate" class="org.springframework.orm.hibernate3.HibernateTemplate">
		<property name="sessionFactory">
			<ref bean="sessionFactory" />
		</property>
		<property name="jdbcExceptionTranslator">
			<ref bean="jdbcExceptionTranslator" />
		</property>
	</bean>	
<bean class="com.xx.model.dao.hibernate.ServerDAOImpl" id="serverDao">
		<property name="sessionFactory">
			<ref bean="sessionFactory" />
		</property>
</bean>
<bean class="com.xx.model.service.impl.ServerServiceImpl"
id="serverService">
		<property name="serverDao">
			<ref bean="serverDao" />
		</property>
</bean>

02/10/2009, 11h34
HadanMarv

problème toujours d'actualité ou as-tu trouvé une solution ?
02/10/2009, 12h13
Sniper37

Citation:

Envoyé par HadanMarv

problème toujours d'actualité ou as-tu trouvé une solution ?

ouii malheureusement le problème est toujours d'actualité ..