Forum Programmation.SQL Optimisation Postgre pour requetes de stats

Posté par  (site web personnel) .
Étiquettes : aucune
0
19
mar.
2010
Bonjour, je travaille sur une base assez grosse, chargée une seul fois pour toute, avec pour objectif de réaliser pas mal de statistiques sur les données de celle-ci (que des select).
Je cherche à configurer les paramètres de postgresql.conf au mieux afin d'avoir les meilleurs perfs possibles.
Je viens vers vous pour avoir quelques conseils issus de votre expérience éventuelle sur ce genre de cas très particulier.

Mes contraintes/caractéristiques :

Hardware : Macbook = Core Duo 1,8 Ghz , 2 Go de mémoire, DD 7200 tours (perfs honorables, pointes à 40 Mo/s en random access)
Base : 2 tables, l'une de 300 k lignes, l'autre de 5 millions. *** Tables chargée une seule et dernières fois : plus d'ajout ***,
Objectifs : Etablir toutes sortes de statistiques sur mes données => uniquement des select ; bcp d'aggrégations, calculs...

Sur ma table de 5 millions de lignes, j'ai 4 données de base + un lien ident vers un autre table.
Lors de la construction, j'essaye d'updater une dizaine de champs pour chaque ligne de cette table
A l'heure ou j'en suis, les requetes d'update sont extrêmement longue : Au bout d'une journée, toujours pas finies !!

Ma question :
J'ai consulté la doc pour améliorer les params dans postgresql.conf, mais je me demande s'il y a qq chose à améliorer.
J'ai senti une nette amélioration sur les requetes d'insert into select.
Mes params postgresql.conf (j'ai laissé les params désactivé avec #)


Résumé :

shared_buffers = 490MB # min 128kB
# (change requires restart)
temp_buffers = 8MB # min 800kB

max_connections = 3

effective_cache_size = 1024MB

J'ai activé les Genetic Query Optimizer (peut être une mauvaise idée ) ?



Le fichier de conf (settings liés à l'optim)




# - Memory -

shared_buffers = 490MB # min 128kB
# (change requires restart)
temp_buffers = 8MB # min 800kB
#max_prepared_transactions = 0 # zero disables the feature
# (change requires restart)
# Note: Increasing max_prepared_transactions costs ~600 bytes of shared memory
# per transaction slot, plus lock space (see max_locks_per_transaction).
# It is not advisable to set max_prepared_transactions nonzero unless you
# actively intend to use prepared transactions.
#work_mem = 1MB # min 64kB
#maintenance_work_mem = 16MB # min 1MB
#max_stack_depth = 2MB # min 100kB
# - Kernel Resource Usage -

#max_files_per_process = 1000 # min 25
# (change requires restart)
#shared_preload_libraries = '' # (change requires restart)

# - Cost-Based Vacuum Delay -

#vacuum_cost_delay = 0ms # 0-100 milliseconds
#vacuum_cost_page_hit = 1 # 0-10000 credits
#vacuum_cost_page_miss = 10 # 0-10000 credits
#vacuum_cost_page_dirty = 20 # 0-10000 credits
#vacuum_cost_limit = 200 # 1-10000 credits

# - Background Writer -

#bgwriter_delay = 200ms # 10-10000ms between rounds
#bgwriter_lru_maxpages = 100 # 0-1000 max buffers written/round
#bgwriter_lru_multiplier = 2.0 # 0-10.0 multipler on buffers scanned/round

# - Asynchronous Behavior -

#effective_io_concurrency = 1 # 1-1000. 0 disables prefetching
#fsync = on # turns forced synchronization on or off
synchronous_commit = on # immediate fsync at commit
#wal_sync_method = fsync # the default is the first option
# supported by the operating system:
# open_datasync
# fdatasync
# fsync
# fsync_writethrough
# open_sync
#full_page_writes = on # recover from partial page writes
wal_buffers = 1024kB # min 32kB
# (change requires restart)
#wal_writer_delay = 200ms # 1-10000 milliseconds

#commit_delay = 0 # range 0-100000, in microseconds
#commit_siblings = 5 # range 1-1000
effective_cache_size = 1024MB

# - Genetic Query Optimizer -

geqo = on
geqo_threshold = 12
geqo_effort = 5 # range 1-10
geqo_pool_size = 0 # selects default based on effort
geqo_generations = 0 # selects default based on effort
geqo_selection_bias = 2.0 # range 1.5-2.0


je n'ai pas touché au reste...


Merci !
  • # 300K x 5M...

    Posté par  . Évalué à 2.

    max_connections = 3
    Si tu nous sors ça, c'est que t'as vraiment aucune idée de l'utilisation de ces paramères.

    Si tu commençais à nous sortir tes schéma de table et ta requête, ça parlera beaucoup plus.
    • [^] # Re: 300K x 5M...

      Posté par  (site web personnel) . Évalué à 1.

      3 connexions parce que je serai le seul à faire des requetes dessus, et mon serveur est en local..
      Où est le problème ?

      Pour le schéma, j'ai 2 tables, une de 300 k lignes, l'autre de 5 millions.

      ce qui rame, c'est l'update sur la table de 5 millions, qui consiste à calculer la variance de 3 valeurs.
      Il met 8ms par lignes, soit 11h pour toute la table

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: 300K x 5M...

        Posté par  . Évalué à 5.

        Comme tu le constates, nous donner la max_conn ne sert à rien.

        8 ms c'est 125 updates / sec. Donc c'est pas top.
        Sans rien savoir sur les types de données, les index et la requête, on ne pourra rien en dire.

        En aveugle, je te dirais donc déjà de mettre un cache table de la taille de la table (si elle rentre) et en priorité un buffer d'index de la taille de l'index.
        • [^] # Commentaire supprimé

          Posté par  . Évalué à 2.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: 300K x 5M...

            Posté par  (site web personnel) . Évalué à 1.

            Heu nan, parce j'adore le SQL et j'ai pas envie de me prendre la tête à coder des boucles pour récups mes infos..

            Sur les forums Pgsql, ils m'ont conseillé de faire une transaction complète pour encadrer les insertions, de mettre le minimum d'indexs. Ce qui rejoint la remarque de facatergnie plus haut sur les 8ms pour l"insert : il y avait autocommit, on avait donc un temps d'accès disque.

            Les résultats sont spectaculaires ! Ca prend toujours qq heures, mais plus 2 jours.

            Donc c'est toujours possible.


            Mais franchement ton idée est intéressante, et j'y penses souvent, il faudrait juste un sql interne à un langage aussi puissant que SQL voire HQL. On a passé pas mal de temps à imaginer une syntaxe sympa en Lisaac avec l'auteur du langage, et j'espère qu'un jour ça deviendra réalité.

            Mais là encore, je suis pas sûr qu'on soit toujours plus rapide : c'est qd même bien foutu un SGBD.

            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 2.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: 300K x 5M...

                Posté par  (site web personnel) . Évalué à 2.

                > SQLite ? C'est juste une librairie...
                On a un pot SQlite,
                nan ce qui serait intéressant, ce serait de pouvoir mettre toute sortes de fonction dans le where, des fonctions de ton code, et pas se limiter au filtrage offert par SQL.

                Et tu ne peux pa faire de requete imbriquées avec SQlite, donc ça limite.

                Ca n'enlève rien que cette lib est merveilleuse !

                « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # Partitionnement ?

    Posté par  . Évalué à 1.

  • # Data warehousing!

    Posté par  . Évalué à 4.

    Pour des tables de plusieurs millions de lignes, il devient malin de travailler un peu sur le schéma de la DB.

    En gros, plus ces tables sont petites sur le disque, plus les opérations dessus seront rapides. En effet, le facteur limitant devient les I/O, et tu veux les optimiser.

    Donc je te conseille un peu de lecture sur le datawarehousing - en bon Français on devrait probablement utiliser un autre terme -.

    En particulier, les notions de dimension et de cubes peuvent grandement t'aider.

    Ceci dit, si tu nous donnais plus d'informations sur tes tables - par exemple sur leur structure, leur indexaction, le nombre de données distinctes pour chaque champ - on pourrait potentiellement t'aider.

    Bon courage !

    (au pire, tu peux prendre un gros serveur du type Amazon EC2 pour faire tes calculs pendant les quelques heures dont tu en as besoin)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.