Bonjour,

A certains moments de la journée, j'observe que le nombre de sessions ouvertes retournées par cette requête :

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
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
GO
 
SELECT		SM.host_name
		, SM.login_name
		, SM.program_name
		, UPPER(SM.status) AS status
		, COUNT(*) AS session_count
		, MIN(SM.login_time) AS min_login_time
		, MAX(SM.login_time) AS max_login_time
		, MIN(SM.last_request_end_time) AS min_last_request_end_time
		, EC.client_net_address
FROM		sys.dm_exec_sessions AS SM
INNER JOIN	sys.dm_exec_connections AS EC 
			ON SM.session_id = EC.session_id
GROUP BY	SM.host_name
		, SM.program_name
		, SM.status
		, SM.login_name
		, EC.client_net_address
HAVING		COUNT(*) > 5
ORDER		BY status, COUNT(*) DESC
Oscille entre 150 et 180 par serveur (host_name) et ont le statut RUNNING, et environ le même nombre SLEEPING.
A d'autres j'ai seulement des sessions dont le statut est SLEEPING.
Dans les deux cas je n'observe jamais de RUNNABLE.

D'autre part j'ai remarqué que la DMV sys.dm_os_wait_stats montre un nombre important de PAGELATCH_UP.
J'ai donc cherché où ça bloque avec :

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
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
GO
 
SELECT		D.name AS database_name		
		, WT.session_id
		, WT.wait_type
		, WT.wait_duration_ms
		, WT.blocking_session_id
		, WT.resource_description
		, BD.page_id
		, BD.page_level
		, BD.page_type
		, BD.row_count
		, BD.free_space_in_bytes
		, BD.is_modified AS is_dirty
		, MF.physical_name AS file_physical_name
		, MF.name AS file_logical_name
FROM		sys.dm_os_waiting_tasks AS WT
INNER JOIN	sys.dm_os_buffer_descriptors AS BD
			ON LEFT(WT.resource_description, CHARINDEX(':', WT.resource_description, 0) - 1) = BD.database_id
			AND SUBSTRING(WT.resource_description, CHARINDEX(':', WT.resource_description) + 1, CHARINDEX(':', WT.resource_description, CHARINDEX(':', resource_description) + 1) - (CHARINDEX(':', resource_description) + 1)) = BD.[file_id]
			AND RIGHT(WT.resource_description, LEN(WT.resource_description) - CHARINDEX(':', WT.resource_description, 3)) = BD.[page_id]
INNER JOIN	sys.databases AS D
			ON D.database_id = BD.database_id
INNER JOIN	sys.master_files AS MF
			ON D.database_id = MF.database_id
			AND BD.file_id = MF.file_id
WHERE		WT.wait_type LIKE 'PAGE%LATCH_%'
AND		D.name = 'TempDB'
Ce qui m'a permis de trouver que la page PFS de TempDB (2:1:1 dans WT.resource_description) subit pas mal de contention (entre 30 et 40 sessions tentent d'y accéder en même temps).
Ceci est bien sûr du à l'utilisation de variables de type table, et je ne peux globalement rien y faire

La base de données TempDB a pour l'instant deux fichiers de données (qui sont loin d'être plein, chacun fait exactement 3GB), mais je n'ai observé de contention que sur un des deux fichiers, pas l'autre, et les deux fichiers sont sur deux volumes différents.

D'autre part j'ai remarqué qu'il y a des variables de type table qui sont sur le serveur depuis le 22 Décembre 2011.
Aucune d'entre elles n'occupe de l'espace (2 octets, zéro lignes).

Qu'en pensez-vous à part que je devrait peut-être ajouter des fichiers à TempDB ?
Je ne pense pas que le trace flag 1118 soit utile dans mon cas car les tables sont de petite taille ...

@++