Re: Lenteurs inexpliquées

From: julien WICQUART <j(dot)wicquart(at)newtech(dot)fr>
To: Stéphane <stephane(at)stratum-ip(dot)net>, pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Lenteurs inexpliquées
Date: 2006-06-20 14:42:35
Message-ID: 4498095B.3070502@newtech.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bonjour,

merci pour cette réponse, excusez-moi de ne pas vous avoir répondu plus tôt.

Nous n'utilisons pas d'index en cluster.

- --
Julien WICQUART NEWTECH MULTIMEDIA
Responsable Exploitation 3 ch du Pigeonnier de la Cépière
Tel: +33 5 61 43 14 80 31081 TOULOUSE
Gsm: +33 6 88 17 16 30 http://www.newtech.fr/
Fax: +33 5 61 43 20 11
j(dot)wicquart(at)newtech(dot)fr

Stéphane wrote:
> julien WICQUART a écrit :
>> 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.
>>
>
> Considérons cela comme axiomatique !
>
>>
>> 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
>>
>>
>
> La tennue des statistiques est essentielle pour les opérantions de
> maintenance. Vos tables ont-elles des index en CLUSTER ? Si oui sachez
> qu'avec votre version de PG, un VACUUM n'implique pas un CLUSTER. Qui
> lui même doit être suivi de préférence d'un ANALYSE pour que
> l'optimiseur fasse les meilleurs choix.
>
> (...)
>
> Stéphane.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEmAlbyavHQ2fnGwsRAjHMAJ9ilbC/PuzZwMM5Vhyx5dU/ugq0kQCgjHLB
d1DU/dKnmGQQVPgVmFmkLRQ=
=/FuV
-----END PGP SIGNATURE-----

In response to

Browse pgsql-fr-generale by date

  From Date Subject
Next Message julien WICQUART 2006-06-20 14:55:33 Re: Lenteurs inexpliquées
Previous Message Stephane Bortzmeyer 2006-06-19 07:24:49 Re: references et index