[10G] Shared Server et optimisation

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 ?

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 ? ...

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:

---

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.

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

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:mouarf:.

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 :mouarf:

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...

vu sur le sp_65_70 :
- évite de calculer les stats (sur perfstat dans le cas présent) pendant tes phases de run
- fais un explain plan de la requête :
SELECT DISTINCT ID_TELEPAIEMENT, a.ID_DECLARATION,
a.ID_ETABLISSEMENT_DECLARANT, a.ANNEE_DECLARATION, a.SIRET, MNT
_CONTRIB_APRES_DEDUCTIONS, BANQUE1, GUICHET1, COMP
TE1, CLE1, TITULAIRE1, MONTANT1, BANQUE2, GUICHET2, COMPTE2, CLE
2, TITULAIRE2, MONTANT2, BANQUE3, GUICHET3, COMPTE...

Elle est en top 1 des conso cpu et est lancée 341 fois en 25'.
Elle ne fait que très peu d'accès disque par contre mais quelques accès mémoire : 75 blocs mémoire par exécution.
Fait-elle des calculs sur les données lignes ramenées ?

J'ai vu la requête en effet. Les développeurs ont réussi à faire un produit cartésien sur cette requête avec une table qui n'est pas du tout utilisée dans celle ci en plus...

Ca a l'air de mieux fonctionner, je vais enlever les stats sur Perfstat et refaire un tir de charge pour vérifier cela :yaisse2:

Citation:

---

Envoyé par Cactus

Les développeurs ont réussi à faire un produit cartésien sur cette requête avec une table qui n'est pas du tout utilisée dans celle ci en plus...

---

Pour les développeurs : :fessee::fessee::fessee:

Ce serait mieux si un dba jetait un oeil aux requêtes avant mise en prod ou si un manuel de best practices était fourni aux dév.

On est pas en prod, heureusement, mais on construit la prod justement avec les tests de charge qui vont avec ;)

Comme c'est un prestataire qui nous livre le tout, c'est pas évident d'aller voir ce qu'ils font, ou d'aller fouiller leur code au final :mouarf:

En tout cas, après tests de charge ca marche pas mal, j'ai la CPU qui monte jusqu'à 15% en pic pour l'instant, rien à voir avec ce que j'avais avant ;)