SQL Server 2008 R2 + problème de perf

**davy.g** · 02/03/2011, 09h07

Bonjour,

Pour info ce matin l'update a tourné toute la nuit et voila le résultat des attentes en ce moment :

PAGEIOLATCH_EX 51616.795000 51608.206000 8.589000 5152901 78.985193916636188
PAGEIOLATCH_SH 6552.465000 6539.317000 13.148000 837744 10.026731002127728
CXPACKET 6277.006000 4455.446000 1821.560000 2265795 9.605217374032790

**Waldar** · 02/03/2011, 11h28

N'oubliez pas de répondre à mes petites questions, je suis (quasiment) certain que le principal problème, c'est votre requête.

**iberserk** · 02/03/2011, 15h21

Je crois en effet que la requete peut être grandement ameliorée

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
 
UPDATE P1 
	SET MPA_NB_AGE_BALANCE = P3.D
	FROM SBI_DWH.dbo.TM_PARC P1
	INNER JOIN
	(
		SELECT P.MPA_FK_JOUR, P.[MPA_FK_CLIENT] C,datediff(d,convert(datetime,cast(Max(P2.MPA_FK_JOUR AS varchar(8)),112),convert(datetime,cast(P.MPA_FK_JOUR AS varchar(8)),112)) ) D
		FROM 
		SBI_DWh.dbo.TM_PARC P
		INNER JOIN SBI_DWH.dbo.TM_PARC P2
			ON P.MPA_FK_CLIENT = P2.MPA_FK_CLIENT 
			AND P2.MPA_FK_JOUR <= P.MPA_FK_JOUR
		WHERE ISNULL([MPA_MT_BALANCE_AGEE],0) = 0 AND P.MPA_FK_JOUR>@max_dt
		GROUP BY
		P.[MPA_FK_JOUR]
		,P.[MPA_FK_CLIENT]
		,P.[MPA_FK_CLIENT_HISTO]
		,P.[MPA_FK_BU]
		,P.[MPA_FK_CONTRAT]
		,P.[MPA_FK_CONTRAT_HISTO]
		,P.[MPA_FK_ANCIENNETE]
		,P.[MPA_FK_ENGAGEMENT_RESTANT]
		,P.[MPA_FK_TERMINAL]
		,P.[MPA_FK_OPERATEUR_DONNEUR]
		,P.[MPA_FK_STATUT_PORTAGE_IN]
		,P.[MPA_FK_OPERATEUR_RECEVEUR]
		,P.[MPA_FK_STATUT_PORTAGE_OUT]
		,P.[MPA_FK_CONTRAT_ACTIF]
		,P.[MPA_FK_CONTRAT_ACTIF_ARCEP]
		,P.[MPA_FK_OFFRE]
		,P.[MPA_FK_CANAL_VENTE]
		,P.MPA_FK_JOUR_RELANCE
		,p.[MPA_MT_BALANCE_AGEE]
		,P.[MPA_NB_PLAN_RELANCE]
	) P3
	ON P1.[MPA_FK_CLIENT]=  P3.C
	AND P1.MPA_FK_JOUR = P3.MPA_FK_JOUR
	--MODIF POUR OPTIM
	AND P1.MPA_FK_JOUR > @max_dt

Si vous êtes en 2008 vous pouvez modifier celà:

Code :

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

datediff(d,convert(datetime,cast(Max(P2.MPA_FK_JOUR AS varchar(8)),112),convert(datetime,cast(P.MPA_FK_JOUR AS varchar(8)),112)) )

en

Code :

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

1
2
3
 
 
datediff(d,convert(date,Max(P2.MPA_FK_JOUR)),convert(date,P.MPA_FK_JOUR) )

Si MPA_FK_JOUR est un datetime.

Me trompes-je?

**iberserk** · 06/03/2011, 09h35

Des avancées?

**davy.g** · 09/03/2011, 17h19

Bonjour,

Après avoir découpé ma tempdb, et sorti ma table tm_parc sur un filegroup différent composé de 6 fichiers (3 data et 3 indexs) sur des vdisks différents, voici les résultats (sur du windows 2008 R2):

03H15 avec tous les procs (4) et 01H16 avec 1 proc (affinity mask).

**mikedavem** · 09/03/2011, 17h24

Pourriez vous préciser un peu votre découpage ?

Nb de fichiers pour tempdb ... etc ...

Concernant vos vdisks sont ils dans un meme vgroup ou des vgroup distincts ?

Merci pour vos réponses

++

**davy.g** · 09/03/2011, 17h32

j'ai 3 fichiers data de tempdb de 16 Go chacun et 1 fichier log de tempdb.
Chacun de ces fichiers est sur des vdisks différents.
Tous ces fichiers, y compris ceux de ma BD, sont dans le même diskgroup.

**SQLpro** · 09/03/2011, 17h53

Envoyé par davy.g

Bonjour,

Après avoir découpé ma tempdb, et sorti ma table tm_parc sur un filegroup différent composé de 6 fichiers (3 data et 3 indexs) sur des vdisks différents, voici les résultats (sur du windows 2008 R2):

03H15 avec tous les procs (4) et 01H16 avec 1 proc (affinity mask).

Que de temps perdu... Regardez ce que je vous disait dans le post suivant :
http://www.developpez.net/forums/d10...f/#post5802158

Malheureusement la plupart de gens ne savent pas que pour une bonne parallélisation il faut que TOUTES LES RESSOURCES DU SERVEUR soit parallélisable, ce qui veut dire les CPU, la RAM et les fichiers et cela implique au minimum :
1) autant d'axe physique différents (disques mécaniquement indépendants)
2) RAM accessible sans verrouillage pour chaque CPU (NUMA).
Bref, pendre un cours d'admin ou d'optimisation, c'est pas du temps perdu !!!

A +

**iberserk** · 09/03/2011, 18h02

Une fois votre architecture "physique" rationalisée pensez à refaire votre requête malgré tout...

**davy.g** · 09/03/2011, 18h18

Envoyé par SQLpro

Que de temps perdu... Regardez ce que je vous disait dans le post suivant :
http://www.developpez.net/forums/d10...f/#post5802158

Malheureusement la plupart de gens ne savent pas que pour une bonne parallélisation il faut que TOUTES LES RESSOURCES DU SERVEUR soit parallélisable, ce qui veut dire les CPU, la RAM et les fichiers et cela implique au minimum :
1) autant d'axe physique différents (disques mécaniquement indépendants)
2) RAM accessible sans verrouillage pour chaque CPU (NUMA).
Bref, pendre un cours d'admin ou d'optimisation, c'est pas du temps perdu !!!

A +

Mes fichiers sont bien sur des Lun différents. Je peux pas créer 32 fichiers pour ma base de données utilisateur.
Numa est activé : mais je ne peux pas configurer mon serveur pour qu'il n'utilise qu'un CPU.
En Prod 2005, ce traitement tourne en 01H15.
Avec 3 procs sur 4, il met 03H00. et avec 1 proc, il met 01H16.

Que faire d'autres ? Vous essayez de me faire comprendre qu'il me faut des diskgroups différents ?

**mikedavem** · 09/03/2011, 18h26

Avec la configuration de davy.g il n'y aura pas de problèmes de parallélisation à mon avis.

En effet, l'OS verra un disque distinct pour chaque vdisk mis à disposition.
Chaque vdisk répartira la charge IO sur tous les spindles qui le compsent en fonction de la configuration VRAID implémentée.

Un des soucis que je vois ici est que tous les vdisks sont sur le même diskgroup . Pour augmenter les performances il faudrait peut être au moins en avoir 2 (un qui isolera les datas et un qui isolera les logs) car les types d'opérations ne sont pas les mêmes par mature

Moi je verrais bien ceci :

1 diskgroup avec un Vdisk en VRAID5. Si votre stockage le permet il faut préférer une solution en VRAID10.

1 diskgroup avec un Vdisk en VRAID1 pour vos journaux.

Je pense que ca vaut le coup de tester mais pour cela il faudra également que vous établissiez une baseline des performances de vos systèmes disques pour chaque configuration ... histoire de pouvoir comparer

03H15 avec tous les procs (4) et 01H16 avec 1 proc (affinity mask).

Soyons positif vous êtes sur la bonne voie

++

**davy.g** · 09/03/2011, 18h37

Merci pour vos réponses.
Je vais voir si je peux jouer au niveau SAN.
Par contre, il est hallucinant qu'en découpant tout, je ne puisse pas utiliser plus de procs que 1 et avoir des temps similaires à la Prod 2005.

**SQLpro** · 09/03/2011, 21h24

Vous aurez sans doute de meilleurs temps en faisant ce que vous dite Mikedavem, et en évitant autant que faire se peut le RAID 5 qui est une abomination pour les SGBDR.
Essayez ensuite avec 2 CPU.
Si vous arrivez à avoir 4 diskgroups dont 1 en RAID 10 pour les journaux et 3 en RAID 1 pour les data et index (2 pour data et 1 pour index) tentez progressivement de passer de 2 CPU à 3 CPU ou 4 et notez les gains obtenus.

A +

**davy.g** · 17/03/2011, 18h59

Bonjour à tous,

Nous venons de constater un problème de controleur sur notre baie EVA.
Je constate également que sur l'update en question, sur le serveur hébergeant SQL 2008R2, celui-ci génèrent beaucoup plus d'I/O sur ma tempdb jusqu'à la saturer, chose qui ne se produit pas sur le SQL 2005.
Sur le serveur SQL 2005, ma tempdb fait 300Go et sur le serveur SQL 2008 elle fait 375Go.

**SQLpro** · 17/03/2011, 19h28

Avez vous des transactions en mode d'isolation SNAPSHOT ???

A +

**davy.g** · 17/03/2011, 21h32

Non. Je n'ai pas ce type de transaction.

**slefevre01** · 18/03/2011, 10h34

Bonjour,
Avez-vous appliqué des "cumulatives update" à votre version sQL2008 R2.
Il s'agit "peut-être" tout simplement d'un bug avec la RTM.

Pour info, le dernier CU est le 6.

Cdlt,

Sébastien.