Re: Reponse lente de postgres

Bonjour,

Hajatiana RAHOLIARIJAONA Administrateur réseaux et systèmes du centre de
traitement SAISIE.MG administrateur(at)saisie(dot)mg
----- Original Message -----
From: "Guillaume Lelarge" <guillaume(at)lelarge(dot)info>
To: "Alain Lucari" <eurlix(dot)alain(at)free(dot)fr>
Cc: <pgsql-fr-generale(at)postgresql(dot)org>
Sent: Thursday, August 02, 2007 11:30 PM
Subject: Re: [pgsql-fr-generale] Reponse lente de postgres

> Bonsoir,
>
> Alain Lucari a écrit :
>>>> Nous avons constaté que : BEGIN TRANSACTION pose un verouillage
>>>> exclusif de la table. Est ce normal.
>>>>
>>> Un BEGIN ne pose aucun verrou. Par contre, vous avez une ligne
>>> supplémentaire dans pg_locks indiquant l'ID de transaction.
>>
>> et si on ne termine pas par un COMMIT, l'ensemble de la transaction
>> depuis le begin n'est pas pris en compte, NON ?
>
> Une transaction n'est validée que par l'ordre SQL COMMIT (ou END). Une
> transaction est annulée dans les autres cas : une requête qui échoue, un
> ordre ROLLBACK, une fin de session.
>
>> a priori, la seule façon de locker une table est d'écrire
>> explicitement "LOCK nom de table"
>
> Si on veut verrouiller la table, oui, c'est le seul moyen. Un mauvais
> moyen, mais le seul moyen.
>
>>> Au prochain SELECT, INSERT, UPDATE ou DELETE, un verrou sera posé
>>> sur une table, mais ce verrou n'est pas forcément exclusif.
>>
>> sauf si on a écrit "SELECT FOR UPDATE", NON ?
>
> Ce n'est pas un verrou exclusif. Le verrou posé est un RowShareLock.
> Vous pouvez donc lire la table, la ligne. Vous pouvez aussi insérer des
> lignes dans cette table. Seule action impossible : une mise à jour de la
> même ligne (ou des mêmes lignes). Sinon, vous aurez ce résultat :
>
> guillaume(at)laptop:~$ ps -ef | grep postgres
> 1000 16183 22198 0 22:22 ? 00:00:00 postgres: guillaume pgfr
> [local] idle in transaction
> 1000 16187 22198 0 22:22 ? 00:00:00 postgres: guillaume pgfr
> [local] UPDATE waiting

C'est bien le phenomene qui se produisit. Des listes de waiting comme :
UPDATE waiting; LOCK table waiting.

Je m'explique un peu :
Un ou plusieurs utilsateurs inserent des données dans trois tables
differentes (ce sont les préparateurs), une operation compte environ 2000 à
2500 lignes(environ 50 à 60.000 lignes /jour) . Ces données seront ensuite
utilisé et updatés par l'ensemble de production.
Le pb se maifeste quand les préparateurs inserent ses données et en même
temps la production met à jour dans les tables d'insertion.
Les insertions debutent par un BEGIN TRANSACTION et se termine par COMMIT ou
ROLLBACK s'il y a erreur.

C'est pourquoi je me demande si les tables entieres sont verouillés ou il y
a un nombre limite de UPDATE quand on fait des insertions.
Le verouillage au niveau de la production est "SELECT for update".

>
> Un processus en transaction (là il ne fait rien mais il pourrait
> travailler, ça ne changerait rien au processus suivant) et un processus
> en attente (UPDATE waiting).
>
> En fait, vous avez simplement avancé le verrou de l'UPDATE au moment du
> SELECT.
>
>> si NON, cela pourrait expliquer quelques problèmes que j'ai eu, en 7.
>>
>>>> En lancant la transaction, nous ne pouvons plus faire des UPDATE
>>>> sur la table et tous les requettes sont mis en attente.
>>>>
>>> On pourrait voir le contenu de la transaction ?
>>
>> Ben OUI, ce serait plus simple.
>>>> Avez vous une idée ou me donnér une commande qui ne verouille pas
>>>> la table entier?
>>>>
>>> Il n'existe pas de verrou de lignes sur PostgreSQL (en dehors du
>>> module contrib userlock et des advisory locks en 8.2).
>>>
>> select for UPDATE pas en 8 ?
>>
>
> Si si, j'ai d'ailleurs déjà renvoyé un message pour expliquer mon erreur.
>
>
> --
> Guillaume.
> <!-- http://abs.traduc.org/
> http://lfs.traduc.org/
> http://docs.postgresqlfr.org/ -->
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>