IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PostgreSQL Discussion :

Acces tres lent


Sujet :

PostgreSQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    77
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 77
    Par défaut Acces tres lent
    Bonjour,

    CONTEXTE
    Une table (myTable) contenant :
    • 5 champs (int8, timestamp, float8, int8 char(1)).
    • 110 millions de lignes
    • Une clef primaire de 4 champs
    • Une clef etrangere referencée par une table de 8 champs avec une cle primaire d'un champ.

    1 PC sous Windows XP pro:
    • Biprocesseur IntelPentium(R) D CPU 2.80GHz
    • 3Go RAM
    • Disque dur: WDC WD2500JS-75NCB1(229Go)


    1 PC sous Windows Server 2003:
    • Biprocesseur Xeon CPU 3GHz
    • 3Go de RAM
    • Disque dur: IBM ServeRAID SCSI Disk Device (136Go)

    Base de donnée sur les 2 PC : Postgres SQL 8.1
    Fichier de configuration : Celle d'origine, puis en changeant suivant http://sitening.com/seo-tools/postgresql-benchmark/ en multipliant par 3/8 (c'est une config pour 8G de RAM)


    Probleme
    En lançant la commande "SELECT count(*) FROM myTable;", il se passe 8 minutes avant d'avoir une réponse. Ce qui me parrait enorme. D'autant plus que le CPU ne décole pas et le Disque Dur n'a pas l'air de réagir (DEL qui ne s'allume que tres rarement)
    J'ai exactement le meme temps de reponse sur les deux bécanes.

    Est-ce normal? Quoi faire dans le cas contraire?

  2. #2
    jnore
    Invité(e)
    Par défaut
    8 minutes...Ca fait beaucoup !!!
    C'est le temps que la lumière du soleil met pour atteindre la terre


    As-tu fait un vacuum sur ta base ainsi qu'un Reindex database?

  3. #3
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    77
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 77
    Par défaut
    J'avais fait des vacuums (j'ai presque essayé toutes les options ^^)
    Ca me prennait generalement une heure ou deux pour se finir.

    J'ai rajouté aussi un index sur la premiere colonne (create index).

    Le Reindex est en cours (mais il me semble que je l'avais deja fait)

    Pour 110 millions de ligne, quelle est l'ordre d'idée concernant le temps d'un count(*)?

  4. #4
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    77
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 77
    Par défaut
    En local, ma requete dure maintenant 4 minutes.
    La deuxieme requête me ramene à 3 minutes.
    Il y a un utilitaire de surveillance intégré à windows Server qui me dit qu'il lit à 50Mb/s.
    En données brutes, 110 millions * 33 octets / 50 000 000 = 1.2 minutes
    En gros, c'est comme si il essayait de lire le double de données :/

  5. #5
    jnore
    Invité(e)
    Par défaut
    Si tu essaies de faire un count uniquement sur un champ indexé plutôt que sur tous les champs de la table, est-ce que cela n'est pas mieux?

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    SELECT count(champ_indexe) 
    FROM table

  6. #6
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    77
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 77
    Par défaut
    J'ai 3 minutes d'execution.

    Ma configuration (postgres.conf) :

    max_connections = 100

    shared_buffers = 3750
    temp_buffers = 10000
    work_mem = 12288
    maintenance_work_mem = 98304
    max_stack_depth = 8192

    max_fsm_pages = 393216
    max_fsm_relations = 12288


    vacuum_cost_delay = 50
    wal_buffers = 24
    checkpoint_segments = 6
    effective_cache_size = 259753
    log_destination = 'stderr'
    redirect_stderr = on
    log_line_prefix = '%t '
    stats_start_collector = on
    stats_row_level = on
    autovacuum = on
    lc_messages = 'C'
    lc_monetary = 'C'
    lc_numeric = 'C'
    lc_time = 'C'

Discussions similaires

  1. [wifi]transfert de données tres lent
    Par Grimaud dans le forum Hardware
    Réponses: 5
    Dernier message: 30/01/2006, 12h34
  2. [FB 1.5.2] Requetes tres lentes via VPN
    Par gudul dans le forum Connexion aux bases de données
    Réponses: 8
    Dernier message: 05/01/2006, 18h52
  3. NFS : Mount très lent
    Par litbos dans le forum Réseau
    Réponses: 2
    Dernier message: 28/12/2005, 14h23
  4. Impression très très lente avec Samba
    Par Daav dans le forum Réseau
    Réponses: 4
    Dernier message: 29/12/2004, 18h45
  5. Réponses: 6
    Dernier message: 29/09/2004, 12h45

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo