Discussion :

[jeeps64]

Bonjour

J'ai actuellement un problème sur un batch qui dure très longtemps.
Ce batch lance plusieurs processus en parallèle (géré côté applicatif)
Chaque processus lance plusieurs la même procédure
Cette procédure fait environ 1 millions d'IO (99% d'IO logique/ pas ou peu d'IO physiques)

Au final le traitement global dure plus de 5 heures et lance plus de 3 000 fois cette procédure.

Je simplifie un peu mais la procédure lance ce genre de traitement :

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
44
45
46
47
48
49
50
51
52
53
54
55
56
 
CREATE TABLE #TMP_Flux
		( [col1] varchar(50)
		, col2varchar(50)
		, [col3] varchar(50)
		, [col4] varchar(50)
		, [col5] varchar(50)
		, [col6] varchar(50)
		, [col7] int)
 
	-- TMP Insertion
	INSERT INTO #TMP_Flux (col1,col2,col3,col4, col5, col6, col7)
	SELECT col1,col2,col3,col4, col5, col6, col7
	FROM   OPENXML (@idoc, '/root/row', 2)
	WITH 
	(
		col1 varchar(50) '@val1',
		col2 varchar(50) '@val2',
		col3 varchar(50) '@val3',
		col4 varchar(50) '@val4' ,
		col5 varchar(50) '@val5', 
		col6 varchar(50) '@val6', 
		col7 int '@val7'
	) as inputTable
 
	-- TMP Index Creation
	CREATE NONCLUSTERED INDEX IX_TMP_Flux_2
		ON #TMP_Flux   ([col5],col4)
 
 
	-- Selection of cashflow
	SELECT DISTINCT 
	C.c1
	, C.c2
	, C.c3
	, EC.c1
	, C.c4
	, C.c5
	, C.c6
 	, inputTable.col1
	, inputTable.col2
	, ET.c1
	FROM #TMP_Flux  as inputTable
	LEFT JOIN t1 CW WITH(NOLOCK) ON CW.c5 = inputTable.c5 AND CW.c4 = inputTable.c4 AND CW.c6 = inputTable.c6
	LEFT JOIN t2 T ON T.c3 = CW.c3
	LEFT JOIN t3 ET WITH (NOLOCK) ON ET.TradeId = T.Id
	LEFT JOIN t4 C WITH (NOLOCK)ON C.TradeId = T.Id
 	LEFT JOIN t5 EC WITH (NOLOCK) ON EC.CId = C.Id
	LEFT JOIN t6 B WITH(NOLOCK) ON B.CId = C.Id AND B.SId = inputTable.c4
	where inputTable.c2 = '' AND CW.CType = 'Portfolio'
	AND ET.RunId = @CId 
	AND ET.Gop = inputTable.c5
	AND EC.RunId = @CId
	AND C.c3 IN ('BAU','STATIC')
	AND C.CType NOT LIKE '%winding' AND C.CCode = inputTable.CCurr 
	AND B.Id is not null

Les IO se font essentiellement sur la partie select distinct

L'instance SQLServer a 48 Go de RAM et 12 engines répartis sur 2 engine NUMA.

Durant le batch, la CPU dépasse les 80% d'utilisation.
Les principales 'wait tasks' sont CXPACKET majoritairement et LATCH_EX et sont uniforme durant tout le batch :
CXPACKET : 5 000 000 wait_time_ms (collecte faite toutes les minutes)
LATCH_EX : 900 000 wait_time_ms (collecte faite toutes les minutes)

Le débit d'IO semble se détériorer

J'avoue que je seche un peu
J'aurais voulu comprendre comment identifier la contention LATCH_EX et si elle peut être peinalisante pour mon batch

En fait, toute idée est la bien venue

Heeeeeeeeeeeeelp !!!!

Merci
Jeeps64

[SQLpro]

Insérez tout vos documents XML dans une table dotée d'une colonne XML, indexez cette colonne (inndex XML), puis faites quelques requêtes ensemblistes.

Je pense que vous serez surpris par la différence fondamentale de temps de traitements.

Je ne serait pas surpris que vous diviser au moins par 10 le temps d'exec.

En sus, désactivez la parallélisme pour ces requêtes e n utilisant la clause OPTION (MAXOP 1) en effet, les requêtes XML ne sont par parallélisables, d’où vos CXPACKET.

A +

[jeeps64]

Merci de ce retour
Nous allons tester votre proposition

En parallèle, comme puis-je identifier à quoi correspond les attentes LATCH_EX dans mon cas de figure ?
En fait, j'ai du mal à comprendre ou est la contention

Je comprend la "contention" CXPACKET sur laquelle nous avons pu agir en travaillant sur le MAXDOP sur certaines procedure stockée

Jeeps64