Re: PostgreSQL 8. 1 et grosse volumétrie

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
>