Discussion :

[Karma57]

Bonjour,

Je viens vers vous aujourd'hui car je commence à ne plus avoir d'idée.
Dans mon entreprise, nous avons une DB sur un serveur (Oracle 12).
Nous avons des problèmes de performance dans nos batch et nous sommes en train d'investiguer pourquoi.
Nous avons éliminé tout ceci:
- Problème performance d'écriture dans fichiers plats
- Problème performance réseau pour accéder à la base de données (car la base est sur un autre serveur)
- Problème d'accès disques
Nous sommes arrivés à ce test qui est très étrange :
Si j'execute un script PL/SQL qui va lire une table de 2M500k records, cela prends 28secondes. (par un select-fetch)
Si j'exécute simultanément deux fois ce même script, les deux vont prendre 50secondes.
...
Si j'execute simultanément cinq fois ce même script, les 5 vont prendre deux minutes à s'executer.
Tout ceci plus ou moins: l'un va prendra 2minutes03, l'autre va prendre 1min59, etc...


Si nous faisons le test sur un environnement de notre R&D (qui plus est n'est pas une bete de course), avec les même records, cela va prendre 11secondes.
Peu importe le nombre de lancement simultannée.
=> On constate aussi que 11sec c'est beaucoup mieux que 28sec...

Il y'a dont un genre de pool (limite mémoire, limite cpu, dispatcher, listener,...?) qui fait que le temps est très long et séquentiellement augmenté, selon la charge sur la DB.
Nos batch prennent 5fois plus de temps qu'à la R&D et d'après nos investigations, tout le temps est perdu dans des appel DB.

A noter que les temps de toutes les requêtes de nos batch sont très bons, puisque dans le rapport AWR il n'y a aucun souci.

Quelqu'un aurait-il une idée d'ou cela peut venir, et quoi checker?

Merci beaucoup de vos aides,
Karma.

[13thFloor]

Hello,
problème intéressant.
Dans un premier temps je vérifierai si le plan d'exécution ne varie pas entre 2 exécutions.
Dans un 2nd temps, je vérifierai quelles sont les attentes pendant l'exécution de la requête
a/ en single exécution
b/ en simultané (5 exécutions en //)
Il serait intéressant de savoir comment les données sont renvoyées : index scan, direct read...
Que donne le plan d'exécution d'un simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 select /*+ full(t) nocache(t) */ count(*) from ta_table t;

N'y aurait-il pas un souci avec le cache file-system (si linux/unix) ?
Mais au fait, quel est l'os ?

[Karma57]

Salut,

Merci de ta réponse.
Le script exécuté est le suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SET serveroutput ON;
declare
   nb NUMBER(8) := 0;
   cursor curs is
      select * from MATABLE
      order by 1, 2, 3;
   begin
      for CUR in curs loop
         nb := nb + 1;
      end loop;
      dbms_output.put_line ('Nombre enreg. dans MATABLE = '||to_char(nb));
   end;
/
exit;

Donc aucun problème d'index,le temps passé ne dépend pas de mon select mais plutôt du curseur.
Le rapport AWR correspondant est bon (gets ok, IO ok, cpu ok...)

Tu vérifierais comment ton point 2? (Les attentes)

Pour le cache-file system, tu vérifierais quoi?
Je préfère demander tout, pour éventuellement si on oublie quelque chose. Nous ne sommes ni expert linux, ni expert database.

Pour la version:
cat /proc/version
Linux version 2.6.32-573.22.1.el6.x86_64 (mockbuild@x86-029.build.eng.bos.redhat.com) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) ) #1 SMP Thu Mar 17 03:23:39 EDT 2016

Merci à toi,
Karma.

[mnitu]

Je suis désolé mais ce script est en concurrence pour les scripts les plus stupides jamais vu! Et il est bien placé pour occuper la première place!

Justification:
- la clause order by qui existe juste pour augmenter le temps de traitement.
- le comptage des enregistrements via une boucle PL/SQL au lieu de compter les enregistrements directement en SQL via Count

Si cela ne vous saute pas aux yeux quelle chances avez vous pour optimiser votre traitement ?

[13thFloor]

Remarque 1 : si la finalité est de compter les lignes d'une table, il y a mieux que faire un curseur qui parcours toutes les lignes pour les traiter une par une => select count(*).
Remarque 2 : l'order by ne sert à rien puisque les lignes sont comptées 1 par 1.
Pour les attentes :
tu identifies le sid qui exécute la requête (avec toad ou sqldeveloper) et tu lances :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
SELECT NVL(s.username, '(oracle)') AS username,
       s.sid,
       s.serial#,
       sw.event,
       sw.wait_class,
       sw.wait_time,
       sw.seconds_in_wait,
       sw.state
FROM   v$session_wait sw,
       v$session s
WHERE  s.sid = sw.sid
and STATUS='ACTIVE'
ORDER BY 2;

Coté cache file-system : on va mettre de coté sauf si un admin système peut nous donner les bonnes commandes (que je n'ai pas).
Il s'agissait de vérifier si Oracle utilise le cache FS ou va lire/écriture directement sur disque.
Mais cela va impliquer trop de questions (asm ou pas...).
Info toutefois intéressantes sur les hugepages :
https://oracle-base.com/articles/lin...le-on-linux-64

Les 2 environnements (prod et R&D) sont-ils les mêmes, notamment au niveau paramétrage oracle ?
je pense notamment aux paramètres suivants :
filesystemio_options
memory_target
memory_max_target
pga_aggregate_target
sga_max_size
sga_target
db_file_multiblock_read_count
db_cache_size

[13thFloor]

Je suis désolé mais ce script est en concurrence pour les scripts les plus stupides jamais vu! Et il est bien placé pour occuper la première place!

C'est vrai que celui qui l'a écrit :

[Karma57]

@13thfloor

Merci je vais regarder ca.

Pour info le script est juste la pour le test, il n'est en aucun cas dans un traitement.
C'est juste pour comparaison des temps de réponse en le lançant plusieurs fois simultannéement.

Bien à vous,
Karma.