Vous n'êtes pas identifié(e).

#1 Re : Migration » Migration Oracle 10 vers PostgreSQL 9 : Lenteur procédures stockées » 22/11/2013 17:42:00

Merci gleu pour tes réponses qui nous on permis de creuser le sujet.


Nous avons finalement fait plusieurs tests avec les éléments suivants :
- Utilisation de table temporaire (en mémoire car work_mem et temp_mem supérieur à la volumétrie de la table)
- utilisation de l'option UNLOGGED lors du create de la table 2
- utilisation de LOCK explicite au début du traitement
- utilisation d'isolation de transaction de type serializable (d'autres forums semblaient y croire...)

toutes ces pistes n'ont rien données.


Finalement nous avons retourné le problème et avons décidé de changer le comportement de notre procedureA. Ainsi le curseur dos_encours prend maintenant en compte un offset et un limit afin de découper en sous ensemble les données à traiter.
De cette façon la procédure est appelée plusieurs fois à la suite au lieu d'une seule. Ceci a l'avantage de fermer et reouvrir une transaction à chaque fois et ainsi laisser le temps au autovaccum de passer entre les deux appels (wait forcé de 50ms entre chaque appel) afin de supprimer les lignes mortes dans la table.


Après plusieurs tests il s'avère que le traitement de 1000 dossiers à la fois reste le plus performant. Nous avons ainsi pu réduire le temps et passer à 2 min de traitement.

#2 Re : Migration » Migration Oracle 10 vers PostgreSQL 9 : Lenteur procédures stockées » 20/11/2013 11:45:34

C'est en effet ma crainte...

Je vais faire quelques tests en posant dans la session des LOCK sur la table 2 et en changeant le niveau d'isolation de la transaction (READ UNCOMMITED). On verra bien.

#3 Re : Migration » Migration Oracle 10 vers PostgreSQL 9 : Lenteur procédures stockées » 19/11/2013 23:56:12

Oui c'est bien cela, la procédure G prend 65/70 du temps de traitement.


Niveau configuration matériel je suis sur un windows server 2003, avec 8Go de RAM, et un quad-core 2.4Ghz. La base de données utilise 500Mo sur disque et les index 200Mo (car le modèle utilise beaucoup de colonne de type character)
Pour les performance, le processeur est utilisé à 25% durant le traitement et côté RAM pas de monté flagrante (500Mo / 1Go consommé).


Pour les paramètres Postgres j'ai aussi essayé de jouer avec le vaccum et la synchronisation des commit, sans trouver de valeurs intéressante.

#4 Migration » Migration Oracle 10 vers PostgreSQL 9 : Lenteur procédures stockées » 19/11/2013 16:49:18

rezus
Réponses : 8

Bonjour,


Suite à la migration d'une base de données Oracle 10g vers PostgreSQL 9.2.2.1, je rencontre quelques problèmes de performances sur un enchainement de procédures stockées.


Suite à différents tests est à l'activation des statistiques (pg_stat) j'ai pu identifier que le problème viens des updates. Ces updates sont relativement simples mais "très" nombreux. Chose étonnante, le nombre d'updates executés par seconde diminue au fur et à mesure du traitement...


J'ai tout d'abord accusé un problème de buffer et j'ai donc boosté les paramètres suivants (volontairement excessif) :

shared_buffers = 1GB
work_mem = 512MB
effective_cache_size = 2GB
temp_buffers = 512MB

sans succès...



Pour rentrer dans le détail voici le hiérarchie d'appel des procédures concernées :

-- point d'entrée, executé en 70 min
procedureA
    dos_encours CURSOR FOR
        SELECT *
        FROM table1
        WHERE colA <= date AND TRIM(colB) IS NOT NULL AND (colB) <> '        ' ORDER BY colA;
    
    FOR l_dos IN dos_encours LOOP
        PERFORM procedureB('E',l_dos.colA,l_dos.colB,...);
    END LOOP;

-- appelé 28 000 fois
procedureB
    ...
    IF ancien > 0 THEN
        PERFORM procedureC(...);
        PERFORM procedureD(...);
        PERFORM procedureE(...);
        PERFORM procedureD(...);
        PERFORM procedureE(...);
    END IF;
    
-- appelé 28 000 fois
procedureC
    WHILE
        ...
        IF
            ...
            FOR
            ...
                procedureF(...);
        ELSE IF
        ...
    ...
    procedureD(...);
    procedureE(...);    

-- appelé entre 28 000 et 84 000
procedureD et procedureE
    IF 
        PERFORM procedureF(...);
    ELSE
        PERFORM procedureF(...);


-- appelé 335000 fois
procedureF
  IF quel = 1 THEN
    PERFORM procedureG(...);
  ELSIF quel = 2 THEN
    ...

-- appelé au total 112 000 fois, self_time : 65 min
procedureG
  IF moy>0 THEN
    UPDATE table2
    SET colA=to_char(to_number_arob(rtrim(colA),'9999990.99')+moy,'9999990.99')
    WHERE colB=param1 AND colC=param2;
  END IF;
  
  UPDATE wingescph.f_suivi
  SET colA=to_char(moy,'9999990.99')
  WHERE colB=param1 AND colC=param2 AND to_number_arob(TRIM(colA),'9999990.99')<moy;

La table 2 est une table de 60 lignes disposant de 42 colonnes de type « character » avec un index composite de type btree sur les colonnes colB, colC.


Quelqu'un aurait-il une explication sur ce comportement qui reste étonnant pour de simples update, surtout quand oracle s'en sort très bien (moins de 3 minutes de traitement) ?

Pied de page des forums

Propulsé par FluxBB