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

Lenteurs inexpliquées sur des insert.

From: julien WICQUART <j(dot)wicquart(at)newtech(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Lenteurs inexpliquées sur des insert.
Date: 2006-06-06 14:06:58
Message-ID: 44858C02.1070800@newtech.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generale
Bonjour,

j'utilise un serveur postgresql 7.4 (2 serveurs en mode actif/secours) travaillant sur une partition
en raid réseau pour les datas et le WAL (mode fsync).

Descriptif des serveurs :
- bi-xéon 3,4Ghz
- 3Go DDRAM
- disque système : 18Go ultra320 SCSI 10000tr/mn
- disque data et WAL postgres : 146Go ultra320 SCSI 15000tr/mn (c'est sur ce disque qu'est montée la
partition drbd)
- interfaces réseau 1Gbps
- debian sarge
- kernel 2.6.8-3-686-smp
- postgresql 7.4 (7.4.7) - je n'ai pas la possibilité de passer en version 8.1 (du fait de
l'ancienneté des clients utilisés).
- drbd 0.7 (0.7.10)

Le raid réseau est assuré par le logiciel drbd (0.7) en mode synchrone avec un lien point à point 1
gigabits entre les serveurs. Les benchs disponibles sur le net et mes tests montrent une lenteur
apportée par la couche DRBD en écriture. Celle-ci n'est néanmoins pas significative et n'explique
pas le problème suivant.


J'ai environ 1000cnx/mn sur une base de 45 tables dont les plus grosses n'exédent pas 1,5 millions
de lignes.
Je n'ai pas activé les traces donc je ne sais pas quelles sont les tables les plus utilisées.
Je ne maitrise pas les clients, je ne peux donc pas minimiser le nombre d'ouverture et de fermeture
de session (si ce n'est par l'ajout d'un proxy).

Mon problème est le suivant :
certains insert peuvent prendre jusqu'à 90s et ceci :
- alors que la majorité des insert prennent un temps correct (moins d'1 seconde)
- aléatoirement dans le temps (aucune corrélation possible avec des traitements)
- aléatoirement sur les tables (pas une table en particuliers)
- sans lock utilisé sur les tables
- alors qu'un vacuum analyze est fait toutes les nuits
- alors qu'autovacuum fonctionne (j'ai bien validé que ce n'était pas autovacuum qui crée ces problèmes)
- alors qu'un reindex des tables système est fait toutes les semaines
- alors qu'un reindex des tables système et des tables de données est fait tous les mois


A la vue de ces informations, avez-vous une idée des principaux problèmes pouvant causé ces lenteurs
à l'insertion ?


Voici ci joint la conf de postgresql adaptée en fonction du site de Varlena :

tcpip_socket = true
max_connections = 1000
shared_buffers = 56250
sort_mem = 5120
vacuum_mem = 300000
max_fsm_pages = 200000
max_fsm_relations = 10000
wal_buffers = 256
checkpoint_segments = 16
checkpoint_timeout = 1800
commit_delay = 100000
effective_cache_size = 243750
default_statistics_target = 1000
syslog = 0
log_error_verbosity = default
log_min_error_statement = error
log_min_duration_statement = 1000
silent_mode = false
log_connections = true
log_pid = true
log_timestamp = true
stats_start_collector = true
stats_row_level = true
datestyle = 'SQL,European'
dynamic_library_path = '/usr/share/postgresql:/usr/lib/postgresql:/usr/lib/postgresql/lib'
deadlock_timeout = 2000



Responses

pgsql-fr-generale by date

Next:From: Servais NabilDate: 2006-06-06 14:09:41
Subject: Re: problème de configurat
Previous:From: Sébastien LardièreDate: 2006-06-06 11:28:46
Subject: Re: problème de configurat

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