Re: [pgsql-fr-generale] PostgreSQL 8. 1 et grosse volumétrie

From: david delannoy <david(dot)delannoy(at)avignon(dot)inra(dot)fr>
To: David Tokmatchi <david(dot)tokmatchi(at)gmail(dot)com>
Cc: Jean-Samuel Reynaud <reynaud(at)elma(dot)fr>, pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: [pgsql-fr-generale] PostgreSQL 8. 1 et grosse volumétrie
Date: 2008-12-03 09:14:30
Message-ID: 49364DF6.5000900@avignon.inra.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

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

In response to

Browse pgsql-fr-generale by date

  From Date Subject
Next Message BPascal 2008-12-09 10:08:35 Outils logiciels complémentaires à postgresql
Previous Message georges.simon 2008-12-03 09:00:35 Re: [Fwd: Quel est le codage le plus efficace]