PostgreSQL
La base de données la plus sophistiquée au monde.

Ouverture de session

Navigation

Contactez-nous

Administration du site :
"equipe chez postgresqlfr point org"

Contact presse :
"fr chez postgresql point org"

Contact association :
"bureau chez postgresqlfr point org"

Questions PostgreSQL :
 IRC :
  serveur irc.freenode.net
  canal #postgresqlfr

Recherche

Accéder aux archives

« Octobre 2008  
Lun Mar Mer Jeu Ven Sam Dim
  2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  

Syndication

Flux XML

Sondage

Quelle est la version de PostgreSQL la plus répandue sur vos serveurs ?
8.3
10%
8.2
42%
8.1
40%
8.0
2%
7.4
6%
7.3 ou antérieure
0%
Nombre de votes: 48

Acces lecture tres lente

Technique - général | Acces lecture tres lente

Par ledjlale le 04/07/2007 - 14:34

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.
-Un index sur le premier 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 [url]http://sitening.com/seo-tools/postgresql-benchmark/[/url] en multipliant par 3/8 (c'est une config pour 8G de RAM)

J'ai fait des vacuums (j'ai presque essayé toutes les options ^^)
Ca me prennait generalement une heure ou deux pour se finir.

PROBLEME
En lançant la commande "SELECT count(*) FROM myTable;", il se passe 8 minutes avant d'avoir une réponse (sans index). 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.

En local, ma requete dure 4 minutes avec l'index sur la premiere colonne.
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 :/

J'ai 3 minutes d'execution en utilisant la commande :
SELECT count(1er_champ) FROM myTABLE;

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'

Quelqu'un d'autre Ă  essayer de faire Ă  peu pres la meme chose sur sa becane :
"Pour essayer j'ai crée de mon coté une table avec 134 000 00 de lignes.
Un select count(*) se déroule en 25 minutes environ!!!

A savoir que ma config est très modeste:
Sempron 2600+
512 mo de ram
disque dur de 4200tr/min (disque dur de PC portable)

A noter aussi que je n'ai indéxé aucun champ.
"

Je ne trouve pas normal cette lenteur. Confirmez-vous cela? Est-ce normal? Quoi faire dans le cas contraire?

Merci.

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder les paramètres" pour activer vos changements.

Bonjour Votre Windows 2003

Christophe Chauvet/ = 4 Juillet, 2007 - 16:38

Bonjour

Votre Windows 2003 est une version 32 bits ou 64 Bits ?

Car Windows 2003 32 Bits ne sait pas gérér plus de 2Go de mémoire pour un process, ce qui peut être problématique dans votre cas.

par contre votre shared_buffer est bien petit sachant que par défaut il vaut 32Mo, ainsi que temp_buffer

Cordialement.

Christophe Chauvet
KrysKool.org


count(*) n'est pas le meilleu

jmreymond/ = 4 Juillet, 2007 - 16:54

count(*) n'est pas le meilleur critère car il faut balayer tout le disque séquentiellement. Il serait préférable de faire une "vraie" requête pour avoir une idée plus précise des performances.

Jean-Max Reymond
CKR Solutions Open Source
http://www.ckr-solutions.com


Ok. Windows server est en 32

ledjlale/ = 6 Juillet, 2007 - 14:16

Ok. Windows server est en 32 bits. Mais les processus postgres ne depassent pas les 20Mo (?)

Pour ce qui est du share_buffer, cette valeur était au début à 1000 (fichier postgresql.conf initial, apres la premiere installation).
En la mettant Ă  64000 ainsi que temp_buffer, les processus ne depassent pas les 50Mo.

Un SELECT champ_indexé FROM table GROUP BY champ_indexé; met un peu plus de 3 minutes à s'executer. (j'espere que c'est un bon critere ^^)


shared_buffers

SAS/ = 10 Juillet, 2007 - 15:36

Il est tout de même étonnant que vous allouiez moins de mémoire pour les shared_buffers que pour work_mem.

Librement,
Stéphane Schildknecht
dalibo
PostgreSQLFr


Le sujet est intéressant, ma

Jnore/ = 10 Juillet, 2007 - 22:21

Le sujet est intéressant, mais quels sont donc les réglages les plus justes?

Quel est le raisonnement pour les paramétrer au mieux?


© PostgreSQLFr, tous droits rĂ©servĂ©s.
Site déclaré à la CNIL sous le numéro 1074678, conformément à la Loi en vigueur.