Discussion :

[msomso]

Bonjour
Nous avons des problèmes de performance sur notre serveur de developpement.
Ce serveur héberge 3 bases de développement (4Go de data + 2Go de log chacune).
On dispose de 4Go de mémoire au total.
Le default data cache est de 500 Mo.

J'ai remarqué dans mes tables "mon" que l'indice stalls n'est pas bon.

Or d'après mda

La colonne "stalls" correspond au "Buffers grabbed dirty" de sp_sysmon. Si cette valeur n'est pas 0 elle représente un problème de perf réel puisque l'engine doit attendre que l'opération d'IO soit terminée sur le buffer "sale" avant de pouvoir le réutiliser.

Comme indiqué dans cette page, j'ai créé la procédure sp__cache
De même que mes tables MDA, elle indique que :
stalls vaut 7211 pour le pool 2Ko de default data cache sur notre serveur

Comment optimiser ce point ?

1. Faudrait-il simplement augmenter la taille de 'default data cache' pour améliorer les performances ?
2. Ne faudrait-il pas prévoir un data cache nommé et séparé pour chaque base ?
3. Préconisez-vous un data cache nommé pour la tempdb ?
4. Préconisez-vous un cache nommé pour le log ?
   Et si oui, en faut-il créer un par serveur ou par base ?
   Est-il automatiquement reconnu/pris en compte ?
5. Utilisez-vous des mises en cache explicites de tables/indexes (binding)?
6. Les liens de base ou d'objets avec le cache, doivent-ils être redéfinis à chaque démarrage serveur ?

D'avance merci
msomso

[dbaffaleuf]

Hello,

Déjà augmenter le DDC serait une bonne chose, mais ça dépend de ce qui tourne d'autre sur la machine. Créer des caches nommés, c'est plutôt dans un second temps. C'est une bonne habitude de le faire pour tempdb avec un gros pool de 16K mais encore une fois ça dépend de l'utilisation de tempdb. Créer un cache nommé pour le journal est un peu plus secondaire encore. On le fait par exemple avec Replication Server pour accélérer le travail du rep agent.

Le bind de caches nommés avec des bases ou des objets est persistant. Pas besoin de le redéclarer au redémarrage.

A+

[kagemaru]

bonjour

Sur la deuxième image, je vois que le nb de lectures physiques est égal aux logiques. Est-ce un hasard, ce qui signifierait qu'il y a des traitements vraiment lourds qui viennent de tourner ou bien est-ce que le serveur vient d'être redémarré ? Ou j'ai manaué qqch...

Je pense qu'il faudrait identifier les requêtes qui provoquent tant de rotation de pages sûrement des mises à jour massives. Dans l'absolu il faudrait augmenter le cache par défaut dans un premier temps, la zone de nettoyage (wash buffer) sera automatiquement augmentée.

Utiliser des caches nommés pour tables et/ou index peut s'avérer nécessaire lorsqu'il y a bcp de spinlock contention par exemple, car qq objets sont énormément accédés, et de manière concurrente.

[lparodi]

Hello,

Tes questions appellent des réponses assez générales : les caches nommés, les pools de large IO, et les bindings sont effet des pratiques courantes, plus habituellement répandues en production.
N'aurais-tu pas le résultat de 2-3 exécutions représentatives de sp_sysmon ? Ca nous permettrait peut-être d'identifier un problème flagrant.

a+

[msomso]

Bonjour

Je commence par :
- doubler la taille de DDC : 1Go au lieu de 500 Mo actuelles.
- créer un DC de 500 Mo dédié à tempdb (pool de 16 Ko)

Sans être en prod., nous constatons des problèmes de requêtes avec des tris et 'group by', notamment quand il s'agit de critères étant les colonnes concaténées ou fonctions:

R1:

Code :

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

1
2
3
4
5
6
Select colonneA + '-' + colonneB as "MonCritere1",
MaFonction(colonneC) as "MonCritere2",
colonneC as "MaValeurDeGroupe"
from <xxx>  where <yyy>
group by colonneA + '-' + colonneB, MaFonction(colonneC)
order by 1,2

Ces mêmes requêtes (mêmes jointure, where clause) s'exécutent bien quand on les remplace par
R2

Code :

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

1
2
3
4
Select colonneA, colonneB ,colonneC 
from <xxx>  where <yyy>
group by colonneA , colonneB
order by 1,2

Malheureusement quand il s'agit de fonctions autres que simple concaténation on n'a pas de solution de contournement.

Dans le meilleur de cas, avec les requête de type "R1" on constate un grand rallongement de temps d'exécution.
Parfois, ce genre de requête génère un Msg. 701 alors qu'il ne s'agit pas de procédures stockées, parfois on arrive à l'arrêt inopiné de serveur ....
J'ai lu dans la doc que la zone procédure cache est utilisée aussi pour les tris et group by. Nous avons pourtant 70Mo de 'procedure cache'. Nous n'utilisons pas de procédures stockées mais des fonctions SQL utilisées souvent dans les listes select de requêtes.
Devons nous agrandir aussi la zone 'procedure cache'?

Parfois on a le message suivant:

Caused by: com.sybase.jdbc3.jdbc.SybSQLException:
Impossible d'allouer de l'espace pour 'temp worktable' dans la base 'tempdb' car le segment 'system' est plein ou n'a pas d'extents disponibles.
S'il n'y a plus de place dans syslogs, videz le journal des transactions. Ou utilisez ALTER DATABASE pour agrandir le segment.

Pour répondre à kagemaru: oui, le serveur venait d'être redémarré.

A la prochaine crise je vais générer la trace sysmon, même si je la trouve peu parlant.
A ce propos, les tables MDA ne suffisent-elles pas ?

merci
msomso
P.S.
Doit-on adapter les caches si l'utilisation de 2 CPU (2 engines) ?

[mpeppler]

Euh - pour R1, ce serait pas un "bête" problème de produit cartésien?

Ce qui expliquerait pourquoi le cache se fait complètement flusher.

Il me semble que

Code :

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

1
2
3
4
5
6
7
 
SELECT colonneA + '-' + colonneB AS "MonCritere1",
MaFonction(colonneC) AS "MonCritere2",
colonneC AS "MaValeurDeGroupe"
FROM <xxx>  WHERE <yyy>
GROUP BY colonneA + '-' + colonneB, MaFonction(colonneC)
ORDER BY 1,2

devrait être ecrit

Code :

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

1
2
3
4
5
6
7
 
SELECT colonneA + '-' + colonneB AS "MonCritere1",
MaFonction(colonneC) AS "MonCritere2",
colonneC AS "MaValeurDeGroupe"
FROM <xxx>  WHERE <yyy>
GROUP BY colonneA + '-' + colonneB, MaFonction(colonneC), colonneC
ORDER BY 1,2

sauf si MaFonction est vraiment un aggregat, dans quel cas MaFonction(colonneC) ne doit pas être dans le group by...

Un "bad group by" expliquerait aussi que la worktable générée consomme tout l'espace dispo dans tempdb...


Michael