Discussion :

[SQLpro]

Les requêtes avec les TABLOCK viennent de reporting Services... et notamment à des abonnement à des états.

Reporting Services est-il installé sur le serveur ?

Quel est la RAM allouée à SQL Server ? (sp_configure 'max server memory')
Quelle est la RAM du serveur ?

De plus je mettrais le parallélisme à 1 en attendant. (sp_configure 'max degree of parallelism', 1)

La base tempdb a t-elle été correctement dimensionnée ?

A +

[funkyjul]

Je dirais que la majorité des tables sont liées au serveur SQL via des connexions ODBC. Après il reste des tables attachées vers d'autres applications qui elles sont en Access complet (interface + base). Cela dit les actions entreprises par les utilisateurs lors de ces lenteurs ne font sauf erreur pas appel aux tables liées.
J'ai fais quelques tests en utilisant plusieurs version des pilotes ODBC (SQL Native client 9, 10 et 11) mais cela n'a pas l'air de changer quoi que ce soit, peu importe la version du pilote installé.

[funkyjul]

Les requêtes avec les TABLOCK viennent de reporting Services... et notamment à des abonnement à des états.

Reporting Services est-il installé sur le serveur ?

Quel est la RAM allouée à SQL Server ? (sp_configure 'max server memory')
Quelle est la RAM du serveur ?

De plus je mettrais le parallélisme à 1 en attendant. (sp_configure 'max degree of parallelism', 1)

La base tempdb a t-elle été correctement dimensionnée ?

A +

Alors non, pas de reporting services sur le serveur.
RAM allouée à sql :

Code :

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

1
2
name	minimum	maximum	config_value	run_value
max server memory (MB)	128	2147483647	2147483647	2147483647

La VM qui héberge SQL Serveur dispose de 24 Go de RAM. Et j'y pense maintenant, nous avons monter un RAID 10 sur la VM SQL, je sais pas si cette information peut être importante ici, mais je le précise tout de même.

Je suis désolé (une fois de plus) mais le concept de parallélisme m'est ici encore quasi inconnu... Quels sont les effets de changer cette valeur à 1? Et heu vous dites : "En attendant".. mais en attendant quoi? que ça aille mieux justement?
Concernant la base tempdb... ici encore on me pose une colle. Comment puis-je contrôler tout ça?

[rudib]

RAM allouée à sql :

Code :

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

1
2
name	minimum	maximum	config_value	run_value
max server memory (MB)	128	2147483647	2147483647	2147483647

La VM qui héberge SQL Serveur dispose de 24 Go de RAM. Et j'y pense maintenant, nous avons monter un RAID 10 sur la VM SQL, je sais pas si cette information peut être importante ici, mais je le précise tout de même.

Tu n'as pas limité le max memory, en 64 bit il est important de le faire pour éviter que SQL Server confisque toute la mémoire. Quelle est l'occupation mémoire de SQL Server ? Il me semble que tu disais qu'il ne prenait pas tout. Y a-t-il un autre service important qui tourne sur cette VM, ou est-ce dédié à SQL Server ?

Ne t'inquiète pas pour la configuration matérielle, je pense qu'on peut dire que ce n'est pas le problème, en tout cas il n'y a aucune signe dans les statistiques d'attentes que ce soit le problème.

Il faudra surveiller le serveur quand les problèmes se posent.

Il y a aussi une possibilité :
- tu récupères le fichier de requêtes de Glen Berry qui correspond à ta version, plus la feuille excel qui va avec : http://sqlserverperformance.wordpres...g/dmv-queries/
- tu exécutes le tout, tu colles les résultats dans le fichier Excel ... attention, c'est un peu de boulot.
- tu compresses le tout et tu le poses ici

[funkyjul]

Non effectivement je n'ai pas mis de limite, je ne pensais pas que cela était important. De plus, comme tu le soulignes, je n'ai jamais vu la RAM utilisée à plus de 60-70 % sur le serveur, même pendant les lenteurs. Bon du coup je vais lui mettre une petite limite, dison à une vingtaine de gigas ou 18!

Cette VM n'est pas exclusivement dédiée à SQL Serveur mais c'est comme si. La seule autre chose qui tourne est notre base de données pour les timbrages d'entrées/sorties du personnel. J'ai pensé une fois désactiver ce service au complet et voir si cela changeait mais non, rien n'y a fait. Pour info il s'agit d'une petite base de données Hyperfile et en y regardant de plus près les services liés ne sont pas gourmands du tout. J'avais également une fois désactiver l'antivirus sur cette VM (Kaspersky) mais là encore pas de changement.

Je vais suivre ton conseil et utiliser le fichier de Glen Berry. Même si c'est du boulot c'est pas grave.. et ce d'autant plus si cela peut m'aider à trouver ce qui cloche!

Ausi il faut je pense que je check de plus près cette histoire de tempdb. Mais là encore je suis un peu (pour ne pas dire complètement) dans le chou.

[funkyjul]

Concernant la base tempdb : elle fait 760 Mo et il y en a plus de 650 de libre.

En plus l'augmentation automatique est activé, à coup de 10%. Puis-je donc en déduire que le problème ne vienne pas de la configuration de cette base?

[rudib]

Tu ne peux rien déduire de ça. Règle n°1 : obtenir des infos précise avant de déduire.

Donc, sérieusement : la prochaine étape est de recueillir les résultats des requêtes de diagnostic de Glen Berry. Il y aura peut-être un signe de ce qui se passe dedans.

[funkyjul]

C'est juste...

Je suis donc fin prêt pour attaquer avec ces requêtes de diagnostiques. J'attends juste la prochaine vague de lenteur. Qui à mon avis ne tarderons pas.

Merci déjà pour toutes vos précieuses informations et vos conseils avisés.

Je posterai le résultat de ces requêtes dès que ça sera OK je pense début de semaine prochaine car le vendredi à tendance à être assez calme par ici.

A+

[funkyjul]

Re bonjour à tous,

Me revoilà j'espère pour la dernière ligne droite! Je joins à ce post un fichier ZIP contenant plusieurs fichiers xls avec les résultats des requêtes de Glen Berry ainsi qu'un fichier indiquant les waits lors de mes lenteurs.

J'ai pu remarquer (me semble-t-il lors des lenteurs les plus marquantes) que les waits sur "BROKER_RECEIVE_WAITFOR" avait très fortement augmentés.... mais ce n'est pas systématique non plus!

J'ai tenté vaguement de mettre mon nez dans ces résultats mais j'avoue que la pratique et les connaissances me manquent un peu, pour ne pas dire plus. Si ces fichiers peuvent alors éventuellement vous aider, si bien sur le choeur vous en dit, à trouver ce qui cloche ici.... je vous en serais énormément reconnaissant.

D'avance merci et bonne fin de journée

[rudib]

Hello,

Ce qu'on voit clairement dans les attentes :
les attentes les plus courantes viennent d'ASYNC_NETWORK_IO, donc lenteurs de la part du client pour traiter les données qu'il récupère petit à petit du serveur SQL, DataReader dans du code .NET ou peut-être les tables attachées dans Access.
Il y a des attentes PREEMPTIVE_OS_AUTHENTICATIONOPS, des petites attentes pour joindre le contrôleur de domaine ? Ce n'est probablement pas un gros problème.

Il y a aussi des petits signes d'attentes sur le disque, et je vois que tout est sur D:, tu as des attentes moyennes de 20 ms sur l'accès aux journaux de transactions, c'est un petit ralentissement sur tes opérations dû au fait que tout est sur le même disque, ce n'est pas excellent mais ce n'est pas ce qui provoque les blocages.

Les bases triplecode, SSISDB, et d'autres qui sont en mode de récupération COMPLET alors qu'il n'y a manifestement pas de sauvegarde de journal. Il faut les mettre en mode simple sinon ton disque va se remplir petit à petit. triplecode, SSISDB sont les bases sur lesquelles le problème est le plus aigü en ce moment.

Il te manque manifestement des index sur ces tables :
[cimproductimport].[dbo].[OF]
[cimproductimport].[dbo].[Piece]
C'est en tout cas ce qui se voit le plus.

La RAM a l'air tout à fait ok, n'oublie pas de limiter le max memory comme déjà dit.

Ces procédures posent des problèmes de performance:
xsp_lbsa_getCliInfo4CC
xsp_lbsa_getArtInfo4CC
SP_BELET_VERIFY_SOLDES

On a le code dans le fichier Excel, c'est juste fastidieux à lire, en tout cas on voit des curseurs, donc il faudrait vraiment optimiser ces procédures.

Il manque VRAIMENT un ou des index sur la table
[XSBWDATASSQLBELET].[dbo].[Lignes]
C'est pour l'instant la chose la plus importante que je vois à faire, avec l'optimisation de la procédure xsp_lbsa_getCliInfo4CC


Il faut absolument défragmenter les index sur la base XSBWDATASSQLBELET

Peux-tu poster la structure des tables suivantes :
XSBWDATASSQLBELET.LibArt
XSBWDATASSQLBELET.Articles
XSBWDATASSQLBELET.Lignes
XSBWDATASSQLBELET.PrixArt