Utilisation élevée de la mémoire lors de l'utilisation d'Hibernate

J'ai un code côté serveur de l'application avec java sur serveur linux.
J'utilise hibernate d'ouvrir la session de base de données, utilisez sql natif, à interroger et à toujours fermer cette session par un try, catch, finally.

Mon serveur de requêtes DB de l'utilisation d'hibernate avec une très haute fréquence.

J'ai déjà définir MaxHeapSize pour elle est de 3000 mais il y a généralement une utilisation de 2,7 GO de RAM, il peut diminuer, mais plus lent que de l'augmenter. Parfois, il se développer jusqu'à 3,6 GO, l'utilisation de la mémoire, plus que mon MaxHeapSize définir le moment de commencer.

Lorsque la mémoire utilisée est de 3.6 GO, j'essaie de faire un dump avec jmap commande et a obtenu un heapdump avec la taille de 1.3 GO.

Im en utilisant eclipse MAT pour l'analyser, ici, est le dominateur de l'arbre à partir de TAPIS
Utilisation élevée de la mémoire lors de l'utilisation d'Hibernate
Je pense que hibernate est le problème, j'ai tellement de org.apache.commons.les collections.carte.AbstractReferenceMap$ReferenceEntry comme ça. Il peut-être ne peut pas être jeter par la collecte des ordures ou le pouvez, mais lent.

Comment puis-je résoudre ce problème?

OriginalL'auteur Viet | 2014-06-23

  1. 10

    Vous avez 250k entrées dans votre liste DE requête. Même une requête native va mettre la base de données à ses genoux. Oracle limites de la requête EN inscription de 1000 pour des raisons de performance de sorte que vous devriez faire de même.

    En lui donnant plus de RAM ne va pas résoudre le problème, vous devez limiter votre sélection/mises à jour des lots de plus de 1000 entrées, en utilisant la pagination.

    Le Streaming est une option ainsi, mais, pour un tel grand jeu de résultats, jeu de clés de la pagination est généralement la meilleure option.

    Si vous pouvez faire tout le traitement dans la base de données, alors vous n'aurez pas à déplacer 250k enregistrements de la DB à l'application. Il y a une très bonne raison pourquoi la plupart des SGBDR avancé langues procédurales (par exemple, PL/SQL, T-SQL).

    Pouvez-vous m'apprendre un peu plus? J'ai peu d'expérience sur la base de données oracle de l'interaction.
    Vous avez besoin de la chercher à N entrées, les mettre à jour, puis aller chercher le lot suivant et ainsi de suite.
    je suis toujours confus, dans ma requête de mise à JOUR " .. OÙ .. ( ... )", DANS la liste de requêtes est petit et qu'il ne peut pas atteindre les 1000. Et quand je l'étendre à la feuille de Dominator arbre dans eclipse MAT, je trouve ma requête select ('sqlQueryCheckSet" dans mon code), beaucoup de lui, et je pense que c'
    Cochez cette Hibernate. Set: "mise en veille prolongée.de la requête.plan_cache_max_soft_references" et "mise en veille prolongée.de la requête.plan_cache_max_strong_references" à certaines valeurs appropriées.
    Ce travail, merci à vous

    OriginalL'auteur Vlad Mihalcea

  2. 3

    Avis que, même si le nombre d'objet dans le queryPlanCache peut être configuré et limité, il n'est probablement pas normal d'avoir autant de.

    Dans notre cas, nous étions en train d'écrire des requêtes hql similaire à ceci:

    hql = String.format("from Entity where msisdn='%s'", msisdn);

    Ce qui a entraîné N requêtes différentes allant à la queryPlanCache. Lorsque nous avons changé cette requête:

    hql = "from Blacklist where msisnd = :msisdn";
...
query.setParameter("msisdn", msisdn);

    la taille de queryPlanCache a été réduite de façon spectaculaire à partir de 100 mo à près de 0. Cette deuxième requête est traduite en un seul et unique preparedStament résultant juste un objet à l'intérieur de la cache.

    OriginalL'auteur jalogar

  3. 1

    Merci Vlad Mihalcea avec votre lien Hibernate, c'est le bug sur la mise en veille prolongée, il corrigé sur la version 3.6. Je viens de mettre à jour mon hibernate version 3.3.2 de la version 3.6.10, utiliser la valeur par défaut de "mise en veille prolongée.de la requête.plan_cache_max_soft_references" (2048), "mise en veille prolongée.de la requête.plan_cache_max_strong_references" (128) et mon problème a disparu. Pas plus forte utilisation de la mémoire.

    je suis confronté genre de performance similaires problème , le module qui exactement vous avez mis à niveau à 3.6.10

    OriginalL'auteur Viet