PostgreSQL 8. 1 et grosse volumétrie

Bonjour,

je suis en train d'alimenter une base de données de sorties de
simulation. La base de données pèse environ 500 Go et devrait atteindre
à son maximum 2,5 To. Mon programme d'intégration est écrit en JAVA et
est multi-threadé afin d'utiliser au mieux les 4 processeurs du serveur.
Depuis 2 semaines, je suis confronté au problème suivant :
* Au bout d'une heure, une 1h30, mon programme JAVA est mis en attente
par le serveur PostgreSQL. Au bout de plusieurs minutes, il tombe en
timeout et l'intégration est interrompue.
* Malgrè le log intensif effectué sur mon programme client, aucune
erreur n'est détectée. Tout se passe bien, jusqu'à ce que le programme
soit mis en attente
* Sous Pgadmin, l'état du serveur semble bon : aucune transaction en
cours, aucun verrou.

J'avoue être dérouté par ce problème. Auriez-vous des pistes?

Merci de votre réponse,
David

--
David DELANNOY
Ingénieur en Bioinformatique
Unité Agroclim
Site Agroparc
INRA AVIGNON
david(dot)delannoy(at)avignon(dot)inra(dot)fr
04 32 72 24 13

Bonjour,

Plusieurs questions pour tenter de cerner le problème:
- Quelle version de PostgreSQL est utilisée ?
- Quelle version du driver JDBC ?
- Tu dis utiliser des threads, chaque thread dispose de sa propre
connexion ?
- ou est-ce une connexion commune ? Si elle est commune, tu
dois sûrement avoir un sémaphore ou autre.. N'as tu pas
d'interbloquage ?
- Si tu es sous un unix tu peux tenter un strace du processus java
pour voir où il en est (il doit y avoir un truc équivalent sous
windows)
- Est-ce toujours au même moment que ça fige ?
- Tu vides la base avant de recommencer. Tu utilise quoi comme
méthode ? (delete,truncate, drop databse+create, drop table+create,
initdb)
- Tu fais tourner ton java sur la même machine que le postgresql ?

Voila ce à quoi de pense dans un premier temps...

Le Mon, 01 Dec 2008 16:49:08 +0100, david delannoy
<david(dot)delannoy(at)avignon(dot)inra(dot)fr> a écrit :

> Bonjour,
>
> je suis en train d'alimenter une base de données de sorties de
> simulation. La base de données pèse environ 500 Go et devrait
> atteindre à son maximum 2,5 To. Mon programme d'intégration est écrit
> en JAVA et est multi-threadé afin d'utiliser au mieux les 4
> processeurs du serveur. Depuis 2 semaines, je suis confronté au
> problème suivant :
> * Au bout d'une heure, une 1h30, mon programme JAVA est mis en
> attente par le serveur PostgreSQL. Au bout de plusieurs minutes, il
> tombe en timeout et l'intégration est interrompue.
> * Malgrè le log intensif effectué sur mon programme client, aucune
> erreur n'est détectée. Tout se passe bien, jusqu'à ce que le
> programme soit mis en attente
> * Sous Pgadmin, l'état du serveur semble bon : aucune transaction en
> cours, aucun verrou.
>
> J'avoue être dérouté par ce problème. Auriez-vous des pistes?
>
> Merci de votre réponse,
> David
>

Bonjour

En absence de détail sur la provenance des données source, et pour ce
genre de volumétrie je préférerais une approche plutôt base de
données. Dans le sens où avant de mettre en avant les threads java,
j'essaie d'utiliser tous les leviers de la base de données d'abord.
Cela ne sert à rien de paralléliser des threads Java si la charge
revient sur la même table de la base de données.

Il est préférable de paralléliser l'imports des données par schéma, ou
à défaut par groupement de tables. Scinder les tables en simplement 4
listes distincte, en lançant 4 fois le même programme. Il est fort
probable que les volumes les plus élevés soient contenus dans un
nombre assez restreints de tables. La récupération de ces quelques
tables(ou dizaine de tables), va présenter l'essentiel du travail. A
ce stade, il faudra s'assurer que les threads travaillent de manière
non concurrente c'est à dire sur des tables différentes.

L'avantage de procéder par groupement de table, en cas de reprise sur
erreur, serais de procéder par élimination. Une table entièrement
récupérée sort de la liste.

Pour améliorer les performances, il ne faut pas négliger l'archivage
ou les paramètres du noyau. Si on a le moyen de pouvoir recommencer
l'import, durant la récupération de données, il faudra désactiver
l'archivage (archive_command='')et Autovaccum. Normalement, 500Go
devra pouvoir être traité en maximum 24h, en considérant d'avoir un
serveur correct. Evidemment il faudra utiliser les ressources de la
machine en augmentant tant que possible les buffers mémoires(sur
lesquels il y a de nombreux postes).

D.

Le 2 décembre 2008 10:06, Jean-Samuel Reynaud <reynaud(at)elma(dot)fr> a écrit :
> Bonjour,
>
> Plusieurs questions pour tenter de cerner le problème:
> - Quelle version de PostgreSQL est utilisée ?
> - Quelle version du driver JDBC ?
> - Tu dis utiliser des threads, chaque thread dispose de sa propre
> connexion ?
> - ou est-ce une connexion commune ? Si elle est commune, tu
> dois sûrement avoir un sémaphore ou autre.. N'as tu pas
> d'interbloquage ?
> - Si tu es sous un unix tu peux tenter un strace du processus java
> pour voir où il en est (il doit y avoir un truc équivalent sous
> windows)
> - Est-ce toujours au même moment que ça fige ?
> - Tu vides la base avant de recommencer. Tu utilise quoi comme
> méthode ? (delete,truncate, drop databse+create, drop table+create,
> initdb)
> - Tu fais tourner ton java sur la même machine que le postgresql ?
>
> Voila ce à quoi de pense dans un premier temps...
>
> Le Mon, 01 Dec 2008 16:49:08 +0100, david delannoy
> <david(dot)delannoy(at)avignon(dot)inra(dot)fr> a écrit :
>
>> Bonjour,
>>
>> je suis en train d'alimenter une base de données de sorties de
>> simulation. La base de données pèse environ 500 Go et devrait
>> atteindre à son maximum 2,5 To. Mon programme d'intégration est écrit
>> en JAVA et est multi-threadé afin d'utiliser au mieux les 4
>> processeurs du serveur. Depuis 2 semaines, je suis confronté au
>> problème suivant :
>> * Au bout d'une heure, une 1h30, mon programme JAVA est mis en
>> attente par le serveur PostgreSQL. Au bout de plusieurs minutes, il
>> tombe en timeout et l'intégration est interrompue.
>> * Malgrè le log intensif effectué sur mon programme client, aucune
>> erreur n'est détectée. Tout se passe bien, jusqu'à ce que le
>> programme soit mis en attente
>> * Sous Pgadmin, l'état du serveur semble bon : aucune transaction en
>> cours, aucun verrou.
>>
>> J'avoue être dérouté par ce problème. Auriez-vous des pistes?
>>
>> Merci de votre réponse,
>> David
>>
>
> --
> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-fr-generale
>

Bonsoir,

david delannoy a écrit :
> J'avoue être dérouté par ce problème. Auriez-vous des pistes?

La description du contexte n'est pas exhaustive mais je me risque à une
hypothèse :

Vous injectez 500 Go de données dans une base vide et vous utilisez
une requête préparée pour optimiser l'insertion.

Si tel est le cas, vous êtes dans la situation que j'ai connue il y a un
peu plus de trois ans et dont j'avais fait part ici même. Une bonne âme
m'avait alors donné la clé de l'énigme.

L'optimiseur de PostgreSQL sélectionne la stratégie d'attaque de la base
lors de la préparation de la requête. Comme vous partez d'une base vide,
il décide d'opter pour un parcours séquentiel des tables car il serait
contre-productif de passer par les index dans ce cas. Ce raisonnement
qui vaut pour 1 000 enregistrements, ne tient plus pour 1 000 000. Du
coup, au fur et à mesure que vos tables grossissent, les temps de
traitement s'allongent. Vous insérez 100 données par seconde, puis 10
puis 1 avant de mettre 10 secondes pour en insérér une puis 100 puis
1000, etc.

Peut-être que dans votre cas, le pilote intègre un time-out qu'il finit
par atteindre.

Si votre problème est bien celui-ci, quel est le remède ? Il y a trois
ans, j'ai pris le parti de clore la requête préparée toutes les 10 000
insertions pour la ré-ouvrir dans la foulée et mon problème s'est
volatisé. Mais je ne suis pas l'actualité de PostgreSQL de très près.
Peut-être qu'aujourd'hui une solution plus élégante et satisfaisante
existe.

Voilà, en espérant que cela vous aidera.

Sébastien

--
Sébastien Dinot, sebastien(dot)dinot(at)free(dot)fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Bonjour et merci de tes conseils que je vais tenter de suivre.

David

David Tokmatchi a écrit :
> Bonjour
>
> En absence de détail sur la provenance des données source, et pour ce
> genre de volumétrie je préférerais une approche plutôt base de
> données. Dans le sens où avant de mettre en avant les threads java,
> j'essaie d'utiliser tous les leviers de la base de données d'abord.
> Cela ne sert à rien de paralléliser des threads Java si la charge
> revient sur la même table de la base de données.
>
> Il est préférable de paralléliser l'imports des données par schéma, ou
> à défaut par groupement de tables. Scinder les tables en simplement 4
> listes distincte, en lançant 4 fois le même programme. Il est fort
> probable que les volumes les plus élevés soient contenus dans un
> nombre assez restreints de tables. La récupération de ces quelques
> tables(ou dizaine de tables), va présenter l'essentiel du travail. A
> ce stade, il faudra s'assurer que les threads travaillent de manière
> non concurrente c'est à dire sur des tables différentes.
>
> L'avantage de procéder par groupement de table, en cas de reprise sur
> erreur, serais de procéder par élimination. Une table entièrement
> récupérée sort de la liste.
>
> Pour améliorer les performances, il ne faut pas négliger l'archivage
> ou les paramètres du noyau. Si on a le moyen de pouvoir recommencer
> l'import, durant la récupération de données, il faudra désactiver
> l'archivage (archive_command='')et Autovaccum. Normalement, 500Go
> devra pouvoir être traité en maximum 24h, en considérant d'avoir un
> serveur correct. Evidemment il faudra utiliser les ressources de la
> machine en augmentant tant que possible les buffers mémoires(sur
> lesquels il y a de nombreux postes).
>
> D.
>
> Le 2 décembre 2008 10:06, Jean-Samuel Reynaud <reynaud(at)elma(dot)fr> a écrit :
>
>> Bonjour,
>>
>> Plusieurs questions pour tenter de cerner le problème:
>> - Quelle version de PostgreSQL est utilisée ?
>> - Quelle version du driver JDBC ?
>> - Tu dis utiliser des threads, chaque thread dispose de sa propre
>> connexion ?
>> - ou est-ce une connexion commune ? Si elle est commune, tu
>> dois sûrement avoir un sémaphore ou autre.. N'as tu pas
>> d'interbloquage ?
>> - Si tu es sous un unix tu peux tenter un strace du processus java
>> pour voir où il en est (il doit y avoir un truc équivalent sous
>> windows)
>> - Est-ce toujours au même moment que ça fige ?
>> - Tu vides la base avant de recommencer. Tu utilise quoi comme
>> méthode ? (delete,truncate, drop databse+create, drop table+create,
>> initdb)
>> - Tu fais tourner ton java sur la même machine que le postgresql ?
>>
>> Voila ce à quoi de pense dans un premier temps...
>>
>> Le Mon, 01 Dec 2008 16:49:08 +0100, david delannoy
>> <david(dot)delannoy(at)avignon(dot)inra(dot)fr> a écrit :
>>
>>
>>> Bonjour,
>>>
>>> je suis en train d'alimenter une base de données de sorties de
>>> simulation. La base de données pèse environ 500 Go et devrait
>>> atteindre à son maximum 2,5 To. Mon programme d'intégration est écrit
>>> en JAVA et est multi-threadé afin d'utiliser au mieux les 4
>>> processeurs du serveur. Depuis 2 semaines, je suis confronté au
>>> problème suivant :
>>> * Au bout d'une heure, une 1h30, mon programme JAVA est mis en
>>> attente par le serveur PostgreSQL. Au bout de plusieurs minutes, il
>>> tombe en timeout et l'intégration est interrompue.
>>> * Malgrè le log intensif effectué sur mon programme client, aucune
>>> erreur n'est détectée. Tout se passe bien, jusqu'à ce que le
>>> programme soit mis en attente
>>> * Sous Pgadmin, l'état du serveur semble bon : aucune transaction en
>>> cours, aucun verrou.
>>>
>>> J'avoue être dérouté par ce problème. Auriez-vous des pistes?
>>>
>>> Merci de votre réponse,
>>> David
>>>
>>>
>> --
>> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-fr-generale
>>
>>

--
David DELANNOY
Ingénieur en Bioinformatique
Unité Agroclim
Site Agroparc
INRA AVIGNON
david(dot)delannoy(at)avignon(dot)inra(dot)fr
04 32 72 24 13