SQL Server gèle pendant quelques secondes

Bonjour à tous,

J'ai un soucis avec ma machine de dev que je n'arrive pas à résoudre.

Parfois, SQL Server semble complètement gelé pendant plusieurs dizaine de seconde, voire minutes. Un simple SELECT * sur une table contenant une énumération de 5 valeurs, sans clause WHERE peut se terminer en timeout dans mon appli (timeout fixé à 30s, Vous conviendrez donc que pour récupérer 5 enregistrements, c'est un peu long !).

Durant le gèle, j'ai essayé de voir ce qui pouvait bloquer. Malheureusement, toutes les requêtes que j'exécute sont gelées aussi. Ce qui fait que je n'ai pas plus d'information à communiquer.

J'ai regardé un peu ce qui se passe avec l'analyseur de performance, et je n'ai rien détecté d'anormal. Activité disque proche de 0. Processeurs à quelques %, 1 à 3 Go de mémoire encore disponible.

Cela fait quelques temps que j'ai ce soucis. Au début, c'était très sporadique et donc quasiment pas gênant. Mais là, cela se répète de plus en plus souvent (plusieurs fois par semaine).

Est-ce que quelqu'un aurait une idée à me suggérer pour diagnostiquer le problème ?

Des informations supplémentaires sur ma config :

• Windows 10
• SQL Server 2016 developper
• Disque C: SSD (contient quasiment toutes les bases)
• Disque D: disque dur classique (contient une seule base)
• 8Go de RAM

Merci !

Bonjour,

Avez vous fixé la mémoire alloué à SQL Server concernant votre instance ?

Avez vous un antivirus ?

Quel est votre configuration réseau ?

Citation:

---

Envoyé par julien94320

Avez vous fixé la mémoire alloué à SQL Server concernant votre instance ?

---

Je viens de me rendre compte que oui (j'étais persuadé du contraire), mais je doute que cela soit ça. Je devrais avoir une activité disque importante si c'était uniquement la mémoire pour l'instance qui manquait.

Par acquis de conscience, je lève cette contrainte.

Citation:

---

Envoyé par julien94320

Avez vous un antivirus ?

---

Juste celui de Windows : Windows Defender

Citation:

---

Envoyé par julien94320

Quel est votre configuration réseau ?

---

Rien de particulier. PC connecté en Wifi au réseau (une box opérateur classique, pas de réseau d'entreprise). La base est en local (machine de dev).

Citation:

---

Envoyé par François DORIN

Par acquis de conscience, je lève cette contrainte.

---

Surtout pas c'est une bonne stratégie que de fixer l'allocation de la mémoire.

Par contre il ne faut pas top en allouer et en allouer assez pour que l'os ne gèle pas ... généralement la loi des 80 / 20

Pour les autres point je ne vois pas de problèmes particulier.

L'espace disque sur votre machine est il suffisant ?

Citation:

---

Envoyé par julien94320

Surtout pas c'est une bonne stratégie que de fixer l'allocation de la mémoire.

---

En production, c'est le cas, et depuis longtemps. C'est juste sur ma machine de dev pour les tests. Je remettrais ensuite dans une proportion de 50/50 (Visual Studio + Chrome, ça bouffe pas mal de RAM)

Citation:

---

Envoyé par julien94320

L'espace disque sur votre machine est il suffisant ?

---

Oui. Il reste plus de 30Go de dispo. La base en elle-même fait 5Go (certaines tables sont très grosses), mais le soucis se produit même sur des tables très petites :/

Est-ce qu'il y a un antivirus qui checkent les datafiles ?
8 Go de Ram, c'est pas énorme mais le minimum requis est 1 Go, pour du dev, ça devrait pas être un problème.
Est-ce que tu as de l'applicatif ou d'autres choses qui tournent sur ce poste ?

Citation:

---

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Est-ce qu'il y a un antivirus qui checkent les datafiles ?

---

J'y avais pensé, mais non :/

Citation:

---

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Est-ce que tu as de l'applicatif ou d'autres choses qui tournent sur ce poste ?

---

Oui, c'est mon poste de travail, donc j'ai au minimum un Visual Studio et un navigateur Web d'ouvert. Outlook aussi. Après, je peux avoir Word, Excel, Notepad++, etc...

C'est quelle édition? Developer, Express?

C'est indiqué dans mon premier message : 2016 developper ;)

Citation:

---

Envoyé par François DORIN

Malheureusement, toutes les requêtes que j'exécute sont gelées aussi.

---

Qu'est ce que vous entendez par gelées ?

Quel est le statut des requêtes en question lorsque cela se produit ?
Car le cas classique, surtout sur une machine de dev, c'est une transaction bloquante restée ouverte...

Citation:

---

Envoyé par aieeeuuuuu

Qu'est ce que vous entendez par gelées ?

---

J'entend par gelé que plus rien ne semble se passer pendant plusieurs dizaines de secondes, voire minute. Pas d'activité disque, ni CPU.

Citation:

---

Envoyé par aieeeuuuuu

Quel est le statut des requêtes en question lorsque cela se produit ?

---

Justement, je n'arrive pas à le savoir. Lorsque je tente d'exécuter une requête pour voir la liste des requêtes en cours et leur statut, par exemple, celle-ci

Code:

---

1 2 3 4 5 6

SELECT session_id ,status ,blocking_session_id ,wait_type ,wait_time ,wait_resource ,transaction_id FROM sys.dm_exec_requests; GO

---

La requête bloque pendant plusieurs secondes. Elle se débloque en même temps que ma précédente requête (le SELECT sur ma table toute simple) et ne m'affiche même pas mon SELECT (qui a du être traité avant je suppose). C'est pour ça que j'ai l'impression que mon instance est gelée, et pas seulement une requête particulière.

Citation:

---

Envoyé par aieeeuuuuu

Car le cas classique, surtout sur une machine de dev, c'est une transaction bloquante restée ouverte...

---

Oui, mais dans ce cas, j'arrive à voir le statut de la requête, ce qui n'est pas le cas ici :/

Hello

Il faudrait

1/lancer le plan d’exécution pendant le SELECT, pour voir si le plan d’exécution n'est pas pourri a la fin de ta requete.

Si c'est le cas pourquoi ne pas avec l'option RECOMPILE a la fin du Select

2/Voir aussi si vous n’êtes pas lockés pendant le SELECT ?

3/il faudrait lancer une trace SQL en meme temps que le temps que le SELECT et cocher la case :

Sp_starting et sp_completed, et user error message

4/Lancer un perfmon sur votre machine :
- Avec le compteur CPU,
- Le compteur memoire (memoire disponible, memoire du cache SQL (si les perf chutent il est possible qu'il y ait une pression memoire)
- Le compteur disque physique avec les compteurs ecriture disque/s, Lecture disque/s, longueur moyenne de file d'attente ( de tete je crois que si la valeur reste tout le temps a 1 c'est qu'il y a un goulot d'etranglement disque)

Et c'est deja pas mal :)

bon courage

Bonjour,

Merci pour l'aide, mais de grâce, lisez déjà les informations que j'ai données ! Les points 1, 2 et 4 j'y ai déjà répondu...

Donc je reprend :
1) un simple SELET * FROM matable peut bloquer pendant 2min. Pour une table avec 3 enregistrements, on voit bien qu'il y a un soucis. Et là, ce n'est pas un problème de plan de requête ;
2) le problème n'est pas un problème de LOCK au niveau d'une table. Quand mon instance gèle, toutes les requêtes sur cette instance semble gelées (impossible d'avoir la liste des requêtes en cours et leur statut par exemple) ;
4) comme mentionné, rien d'anormal. Pas d'usage disque (1% !), mémoire disponible (plus de 2Go), CPU peut utilisé (< 7% tout applicatif compris)

Le point 3 est en cours depuis quelques jours. J'attends que le problème se reproduise pour pouvoir exploiter cela et espérer avoir des informations supplémentaires.

Lorsque le serveur bloque, vous devez utiliser SQLcmd en mode DAC pour lancer vos requêtes. Ceci donne une priorité absolue et des ressources minimale pour exécuter immédiatement les requêtes en urgence et diagnostiquer là ou ça pêche

Autre possibilité, utiliser SSMS et relevler avant/après les attentes (sys.dm_os_wait_stats)

A +

Citation:

---

Envoyé par SQLpro

Lorsque le serveur bloque, vous devez utiliser SQLcmd en mode DAC pour lancer vos requêtes. Ceci donne une priorité absolue et des ressources minimale pour exécuter immédiatement les requêtes en urgence et diagnostiquer là ou ça pêche

---

Bonne idée, je vais me préparer un petit script qui va me lancer les différentes commandes dont j'ai besoin. Je n'avais pas pensé à utiliser le mode DAC, n'ayant pas de soucis de connexion à ma bd.

Citation:

---

Envoyé par SQLpro

Autre possibilité, utiliser SSMS et relevler avant/après les attentes (sys.dm_os_wait_stats)

---

En théorie oui, mais difficile en pratique du fait du manque de reproductabilité. J'ai déjà deux pistes en cours, donc je vais les étudier. Si le problème persiste, je ferais un service qui ira voir et qui loguera tout ce qui se passe à intervalle régulier.

Merci en tout cas. J'essai de revenir avec des informations complémentaires, ou mieux, avec un problème résolu !

desole j'avais ecris le message en speed sans trop regarder l'historique ;)

J'ai eu deux fois le même souci :

- La requête partait en sucette du a un mauvais plan d’exécution, cela figé complètement le SQL (je l'ai vu qu'une fois, mais ca fait un bail)

- c’était hébergé sur une VM ou l'ESX qui l'hebergeait etait comment dire peu robuste :mrgreen:

bon courage :)

Si c'est une VM regarde si le balooning est activé....

A +

Pas de VM non. C'est directement sur ma machine de dev.

Bon, le problème ne s'est pas reproduit depuis maintenant 2 semaines. C'est très bizarre...

La seule modification faite concernait la limitation de mémoire de l'instance de SQL Server. Modification que j'ai annulée (juste au cas où) et le problème n'est pas réapparu pour autant.

Bref, la, pour moi, cela reste un mystère...

Je positionne en résolu comme le problème n'est plus. Je rouvrirai la discussion si jamais il se reproduit à nouveau.

Merci pour votre aide :)