2011-10-26 4 views
11

J'ai une application très intensive en base de données qui fonctionne pendant plusieurs heures et utilise plusieurs threads, tous en train de parler à Postgresql via JDBC. Le symptôme que je vois est que de temps en temps (une à trois fois sur chaque "run") je me retrouve avec une ou plusieurs connexions JDBC bloquées, qui semblent attendre une réponse de la base de données, mais semblent attendre pour toujours. Le vidage de fil est la suivante:Postgresql 8.4 blocage temporaire avec accès JDBC

"Thread-4367355" daemon prio=6 tid=0x04920c00 nid=0x1e88 runnable [0x04bef000] 
    java.lang.Thread.State: RUNNABLE 
    at java.net.SocketInputStream.socketRead0(Native Method) 
    at java.net.SocketInputStream.read(SocketInputStream.java:129) 
    at org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:135) 
    at org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:104) 
    at org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:73) 
    at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:255) 
    at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1165) 
    at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:191) 
    - locked <0x2c023e10> (a org.postgresql.core.v3.QueryExecutorImpl) 
    at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452) 
    at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:337) 
    at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:329) 

je l'aurais pensé à une sorte de verrouillage question sauf que plusieurs fois un seul thread est bloqué. Au moins une des requêtes que j'ai vues dans cet état était un REINDEX, il est donc possible que la requête prenne pas mal de temps. Dans l'espoir de trouver une solution, j'ai mis à jour le pilote JDBC de 8.4 à 9.1 mais le problème persiste. Il n'y a rien d'inhabituel dans les journaux Postgresql non plus. Des idées pour d'autres diagnostics (autres que l'utilisation de pg_locks)?

+0

Avez-vous réussi à résoudre le problème? Nous sommes confrontés au même 'hang' aussi sur 9.1 –

+0

Je rencontre le même problème, Postgresql 8.4, pilote JDBC 9.1. La requête est une suppression complexe. Le processus sur le serveur commence à utiliser 100% de la CPU puis tombe soudainement à 0% et reste dans 0% pour toujours. Le fil client est bloqué comme ci-dessus. – BrunoJCM

+0

NB que si elle se bloque et dit "BLOQUE attente de l'objet XXX" qui peut signifier votre connexion postgres tente d'être utilisé par plusieurs threads [pas le cas dans cette instance bien sûr, juste comme une note] – rogerdpack

Répondre

1

Il y a une chose évidente que vous pouvez essayer: mettre à jour aussi PostgreSQL à la version 9.1. Vous pouvez également enregistrer tous long running statements, cela pourrait vous donner un indice.

Set log_min_duration_statement = 2000 

Ou quel que soit le seuil qui vous convient.
Je ne sais pas comment interpréter la décharge de fil, mais cette ligne a l'air propre:

  • < 0x2c023e10 verrouillé> (un org.postgresql.core.v3.QueryExecutorImpl)

Qu'est-ce qui est verrouillé? Et vous remarquez que ça ne colle pas "à un org.postgresql.cor ...". Est-ce un artefact de copier-coller ou le message original? Si oui, pourrait aider à trouver l'origine.

+1

verrouillé <0x2c023e10> signifie la méthode a acquis un verrou qui est un objet org.postgresql.core.v3.QueryExecutorImpl. Et l'hexadécimal est l'adresse de la serrure? – crybird

Questions connexes