Discussion :

[Cactus]

Bonjour,

Toujours dans mon installation d'un serveur web + oracle sous win2003 et Oracle 10gR2 10.2.0.3

Suite à des tests de charge, j'ai ma base qui a lachée. Chouette, ca tombe bien, c'était le but, voir ce qui allait lacher en premier. Le serveur sur lequel la base est hébergée est grimpé à 100% de CPU sur le scénario, base indisponible...

Pour contourner cela, je suis passé en mode shared server. On a relancé le test de charge, cette fois ci la base tient, mais le process oracle reprend 100% de CPU sur la montée en charge, et les temps de réponses de la base sont affreusement longs.

Ma question est la suivante :

Quelles sont les pistes d'optimisation de la base à explorer lorsque l'on met en place un MTS sous 10G ? Suis-je parti trop vite dans la ligne MTS ?

[LeoAnderson]

vous êtes parti, à mon avis, trop tôt sur du MTS

Après, quelque soit la solution et les réglages, si vous demandez à un 386 de faire des millions d'opérations, il va forcément partir à 100% de CPU.
Il est donc possible que la machine ne puisse pas accepter la charge de votre scénario.

Combien de clients ? quelle type d'activité ? comment sont réglées les PGA et SGA ? tout en automatique ? ...

[Cactus]

Serveur :
Bi Pro intel 3ghz
4Go Ram + 2 Go swap
OS : Win2003 Server SE

Dessus il y a un IIS 6 avec du php, et une base Oracle 10g SE 10.2.0.3.

J'ai un autre serveur pour équilibrer la charge IIS avec juste un serveur IIS (et la base standby décrite dans mon autre post)

L'activité, c'est du télépaiement. Il n'y aura pas de charge sur le serveur sauf durant la période de déclaration, où au grand maximum (ui ne sera pas atteint, c'est juste la limite théorique si l'ensemble du public concerné passe sur le serveur) 60000 personnes peuvent se connecter durant la période de déclaration (1 mois).

Un déclaration pouvant prendre 2 minutes sur 4 pages, voire plus si les personnes connectées doivent aller récupérer les informations dans divers sources papiers/electroniques pour remplir le formulaire, le nombre de sessions actives simultanées devraient être très loin des 60000 connexions possibles.

Voilà ce que cela donne au niveau des paramètres de la base :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
processes                                150
sessions                                 170
 
sga_max_size                             1610612736
sga_target                               1610612736
 
pga_aggregate_target                     524288000
 
pre_page_sga                             FALSE
shared_memory_address                    0
hi_shared_memory_address                 0
use_indirect_data_buffers                FALSE
lock_sga                                 FALSE
shared_pool_size                         0
large_pool_size                          0
java_pool_size                           0
streams_pool_size                        0
shared_pool_reserved_size                17616076
java_soft_sessionspace_limit             0
java_max_sessionspace_size               0
db_block_buffers                         0
db_block_checksum                        TRUE
db_block_size                            8192
db_cache_size                            0
db_2k_cache_size                         0
db_4k_cache_size                         0
db_8k_cache_size                         0
db_16k_cache_size                        0
db_32k_cache_size                        0
db_keep_cache_size                       0
db_recycle_cache_size                    0
db_writer_processes                      1
buffer_pool_keep
buffer_pool_recycle
db_cache_advice                          ON
create_bitmap_area_size                  8388608
bitmap_merge_area_size                   1048576
hash_area_size                           131072
sort_area_size                           65536
sort_area_retained_size                  0
 
dispatchers                              (PROTOCOL=TCP)(DISP=3)
shared_servers                           5

Quand on a fait le test de charge, il y avait un pool de 60 connexions simultanées qui lancaient en boucle le scénario, ce qui a fait monter le nombre de sessions à 140 et la CPU utilisée par Oracle à 100% lors des pics durant le test. La durée des scénarios étaient alors de 1 à 2 minutes au lieu des 30 secondes en moyenne.

Par contre, en période non-stressante, la réponse des scénarios est tombée à 7 seconde depuis le passage en MTS, au lieu des 30 secondes observées la première fois.

[LeoAnderson]

faut a minima passer un statspack pendant la période de charge...

[13thFloor]

Quelques pistes/règles à envisager :
- limiter les full table scan (indexation, paramétrage, pas de partitionnement car tu es en SE)
- mettre en cache oracle les données les plus fréquemment accédées (modification db_keep_cache_size, clause cache des tables...)
- ajuster la taille des blocs de dats (db_16k_cache_size ou 32)
- déterminer ou se situent les attentes (statspack aidera pour cela)
- identifier les requêtes les plus gloutonnes (statspack ou explain plan si tu a accès au code sql des scénarios)

Ton cas me fait un peu penser à ce que j'ai rencontré il n'y a pas longtemps chez un client : 1 requête lancée unitairement prenait environ 5-7'. Mais lorsque plus d'un dizaine étaient lancées => + d'1 heure. C'était normal, toutes les requêtes tapaient en fts dans la même table -> tout le monde attendait de lire les mêmes blocs disque, sga trop petite donc grosse activité disque-sga, io wait important coté serveur (unix) avec cpu à 99%. Au final : mise en cache de la table sollicitée, premier accès en 5-7', les suivants de l'ordre de la dizaine de secondes.

[Cactus]

Pour commencer, je suis revenu en mode dedicated, sinon je ne peut pas faire de trace sql des opérations quand il y a besoin

Voilà donc les deux premiers rapports statspack en pièce jointe (les snapshots sont pris à 5 minutes d'intervale)

En période creuse ca donne le rapport sp_30_44.txt

et en période de charge le rapport sp_65_70.txt

Sinon, en effet, il y a de fortes chances que les tables soient encombrées, il y a peu de tables qui sont toutes en insert sur la première phase de la déclaration...