Discussion :

[epsilon68]

Bonjour,

J'ai une appli en prod, 250 utilisateurs concurrents.
le server a 8 processeurs, 4 GB RAM et un sqlserver 2005 standard edition (qui utilise donc 4 processors )

quand personne n'utilise le server, un report met 4 secondes,
quand le monde est dessus, le meme report met 1min 30 secondes.

Comment prouver que le server est à la ramasse?

et que faut-il préconiser?
1. passage au 64bits et 16GB de RAM
2. une version entreprise?
3. ?

les reports utilisent beaucoup de tables temporaires et manipule des larges tables de données. (c'est des reports sur une database pour un systeme de tickets)

Merci d'avance pour votre aide.

[elsuket]

Bonjour,

Un bon indicateur est le compteur de performance Page Life Expectancy, que vous pouvez visualiser à l'aide du moniteur de performance de Windows, ou bien à l'aide de la requête suivante :

Code :

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

1
2
3
4
SELECT	cntr_value AS PLE
FROM	sys.dm_os_performance_counters
WHERE	object_name = 'SQLServer:Buffer Manager'
AND	counter_name = 'Page life expectancy'

Il indique le temps moyen, en secondes, que les pages de données restent dans le cache de données. Plus c'est long, plus c'est bon
Si sa valeur est en dessous de 300, c'est que vous avez de la pression mémoire, et à mon avis ce doit être le cas, spécifiquement quand vous exécutez le rapport.

Vous pouvez donc penser à étudier les requêtes (SET STATISTICS IO, plan de requête, ...) de votre rapport et les modifier / ajouter des indexes / ...

Comme vous dites que vous utilisez des tables temporaires, il se peut également que vous deviez simplement réécrire vos requêtes.
Dès la version 2005 de SQL Server, vous pouvez vous en remettre aux expressions de table commune (CTE dans la littérature) pour éviter leur usage.

Vous dites également utiliser des tables volumineuses : c'est-à-dire ?
Quel est leur taille, leur nombre de ligne, leur définition ?
Quels sont les index sur cette table ? Sont-ils correctement utilisés par les requêtes de votre rapport ?

Si après avoir répondu à toutes ces questions et correctement adressé les performances de vos requêtes la base de données est toujours "lente", vous pourrez considérer augmenter la quantité de RAM.
En effet, SQL Server travaille exclusivement en RAM, puisque les temps d'accès sont au moins 1000 fois plus rapide que sur disque

Le fait de passer en 64 bits ne vous apportera rien sauf si vous comptez mettre plus de 64Go de RAM sur la machine hébergeant l'instance SQL Server.
En effet vous pouvez utiliser les options d'AWE (flag /PAE dans le fichier boot.ini, voyez l'article de Mikedavem à ce sujet) pour adresser au plus 64Go de RAM.

L'édition Enterprise ne comporte aucune différence avec l'édition Standard à ce niveau là.
Elle est simplement plus riche en fonctionnalités que l'édition Standard.

@++

[SQLpro]

Quelle est la taille de la base ?

Faite sp_spaceused sur la base.

Comment avez vous mesuré les 250 utilisateurs concurrents ?


Pour voir le nombre d'utilisateurs connectés, faire :

Code :

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

1
2
3
SELECT session_id, connect_time, text, COUNT(*) OVER() AS NOMBRE
FROM   sys.dm_exec_connections
       CROSS APPLY sys.dm_exec_sql_text(most_recent_sql_handle)

Nombre vous donnera le nombre total de connexions utilisateur.

Pour voir le nombre de requêtes simultanées en cours d'exécution :

Code :

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

1
2
3
4
5
SELECT * 
FROM   sys.dm_exec_requests  AS r
       INNER JOIN sys.dm_exec_connections AS c
             ON r.session_id = c.session_id
WHERE  status = 'running'

Est une appli Web ou client lourd ?

A +

[Philippe Robert]

Il indique le temps moyen, en secondes, que les pages de données restent dans le cache de données. Plus c'est long, plus c'est bon
Si sa valeur est en dessous de 300, c'est que vous avez de la pression mémoire, et à mon avis ce doit être le cas, spécifiquement quand vous exécutez le rapport.

Existe-t'il une bonne litérature à ce sujet. En effet, je quitte malgré moi le domaine de la programmation SQL pour faire de l'administration SQL Server pure, domaine qsue je maîtrise mal.

[elsuket]

Malheureusement pas grand chose sur le sujet.
On trouve au mieux un paragraphe consacré à ce compteur, et un autre au Buffer Cache Hit Ratio (qui doit être le plus proche de 100% possible), dans les livres qui traitent de la performance, comme Pro SQL Server 2008 Query Performance Tuning Distilled, écrit par Grant Fritchey et Sajal Dam, ...

@++

[Philippe Robert]

çà promet

[epsilon68]

Merci beaucoup pour votre aide,

j'ai executé la commande pour "page life expectancy",
J'ai eu 172, puis j'ai lancé un report, et la j'ai eu 12.

c'est une catastrophe, j'ai remonté l'info, je vous tiendrais au courant.