Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-fr-generale by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group