Discussion :

[Kropernic]

Hello,

Je rencontre actuellement un problème avec un serveur.
Je peux apparemment m'y connecter car j'ai un utilisateur qui teste un nouvelle application mais avec SSMS, je m'y connecte mais le serveur reste en "expanding".

Cad qu'il ne se déroule pas dans l'interface de SSMS. Mais en faisant un clic droit dessus, je peux apparemment choisir New Query et faire une query.
C'est donc qu'il "fonctionne".

Après, en fouillant ce qu'il y a dans le menu contextuel du clic droit, j'ai découvert l'Activity Monitor. Là, dans la partie Processes, j'en ai tout un tas avec un Wait Type sur "PREEMPTIVE_OS_GETPROCADDRESS" (cfr screenshot). J'ai fait une recherche google sur ce type mais je n'obtiens rien de bien folichon...

Ce pourrait-il que ce soit cela qui "bloque" le serveur ? Puis-je killer ces processus sans risques ? Leur propriété Task State et Command sont respectivement sur RUNNING et EXECUTE.

Je ne sais pas quoi donner de plus comme info .

[darkelend]

Salut,
Si tu fais :

Code :

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

sp_who2 active

Est ce que tu obtiens des lignes avec la colonne blkby différent de "." ?

[SQLpro]

Vous êtes sur une VM ????

Si oui, laquelle ?

En principe ce genre de chose est un conflit d'accès entre des processus de la VM ert SQL Server.

Mieux vaut éviter les VM, si vous n'avez aucune compétences :
1) système
2) VM
3) SQL Server DBA

A +

[Kropernic]

Il n'y a pas de virtual machine.

Finalement, j'ai tenté de redémarrer le service principale de sql serveur (celui qui provoque un restart du service de l'agent aussi). Et quand il a tenté de restarter l'agent, il n'a pas réussi.

J'en déduis donc que c'était ce service qui était dans la panade... Reste à savoir pourquoi.

J'avais envisagé la piste de la mémoire mais d'après l'onglet performance du task manager, il n'y avait que 12 Gb des 16Gb de RAM sur le serveur qui étaient utilisés.

Quoi qu'il en soit, j'ai à présent limité la mémoire pour sql server à 14 Gb (sur 16 au total) sur nos trois nouveaux serveurs.

J'oubliais... J'ai finalement redémarrer complètement le serveur car j'avais vraiment besoin de pouvoir travailler dessus...

[aieeeuuuuu]

Bonjour

Dans les propriétés du serveur, onglet "processeurs", est-ce que la case "renforcer la priorité de SQL Server" est cochée ?

[Kropernic]

Bonjour

Dans les propriétés du serveur, onglet "processeurs", est-ce que la case "renforcer la priorité de SQL Server" est cochée ?

J'imagine qu'en anglais ça donne "Boost SQL Server Priority" ?
(normalement oui mais bon, on ne sait jamais)

Si oui, la réponse est non.

Pour info, il y a 8 processeurs repris dans la liste du dessus et toutes leurs cases (Processor Affinity et I/O Affinity) dans cette liste sont cochées.

[SQLpro]

Pour info, il y a 8 processeurs repris dans la liste du dessus et toutes leurs cases (Processor Affinity et I/O Affinity) dans cette liste sont cochées.

C'est ça qui a causé votre plongeons... en effet il ne doit JAMAIS y avoir le même core attribué à la fois à affinity mask et IO mask.
La doc a un bug.

A +

[Kropernic]

En français ???

Des bribes que j'ai compris, j'en ai déduis que les 2 colonnes ne doivent pas être cochées pour le même processeur. Correct ?

Que faut-il faire alors ? 4 pour l'une et 4 pour l'autre ou bien y a-t-il un ratio optimal à respecter ?

[SQLpro]

Le mieux est d'indiquer 75% au plus de CPU pour affinitu mask et de ne pas se préoccuper de affinity IO mask.

A +

[Kropernic]

Ok, Je coche donc deux tiers des processeurs pour affinity mask et rien pour IO.

Par contre, c'est assez inquiétant car je n'ai jamais été modifié cela et je pense pas que ce soit demandé lors de l'installation. Ce qui voudrait dire qu'il s'agit de la config par défaut et que cette dernière est erronnée.

C'est assez grave non ?

[Kropernic]

Bon en fait, pour confirmer ce que vous avez déjà dit à propos de l'ihm : c'est de la merde (je paraphrase^^).

Il y a 2 cases à cocher sous cette liste qui s'intitulent "Automatically set XXX for all processors" où XXX est "processeur affinity mask" et "I/O affinity mask".

Je les décoche donc pour pouvoir paramétrer comme je veux et je décoche tout dans la colonne I/O. Et bim ! Dès que je décoche le dernier processeur, la case "set auto" se recoche et voilà tous les processeurs de nouveaux cochés...

Du coup, comment configure-t-on cela via query ? Vu que je ne sais pas vraiment ce que je fais, je ne sais pas quoi chercher dans google :-/

[mikedavem]

Bonjour,

Je pense qu'il y a confusion : Par défaut lors des installations l'ensemble des processeurs sont utilisés pour une instance donnée (Processor Affinity) et tous les processeurs peuvent être utilisés pour gérer les I/O (I/O Affinity) et cela fonctionne très bien comme ça sauf pour certains scénarios bien précis.

Je pense que ton problème est ailleurs. Un verrou posé ou autre ..

++

[SQLpro]

oui, mais dans ce cas les cases seraient grisées....

Mais je ne sais pas si tu es ou courant du bug de la doc MS !

(au fait ton père n'a pas été sacré pape ? ;-)


A +

[mikedavem]

oui, mais dans ce cas les cases seraient grisées....

Si on parle de cela :

Je les décoche donc pour pouvoir paramétrer comme je veux et je décoche tout dans la colonne I/O. Et bim ! Dès que je décoche le dernier processeur, la case "set auto" se recoche et voilà tous les processeurs de nouveaux cochés...

je pense que le comportement est tout à fait normal. Il faut au minimum avoir un processeur alloué à la gestion des I/O.

(au fait ton père n'a pas été sacré pape ? ;-)

Pfff je leur ai bien suggéré mais ils ont préféré prendre un argentin ... la déception quoi :-)

++

[Kropernic]

Pour couper court aux malentendus, voilà un screenshot.

Les cases sont bien grisées mais néanmoins cochées.

[SQLpro]

Donc, ça va... Ca veut dire : "SQL Server, fait ce que tu veut, nous en s'en fout" ....

A +

[Kropernic]

J'avais bien compris que cela voulait dire ça (même si je sais que vaguement à quel sujet) mais j'avais cru que vous disiez que c'était pas bien de laisser sql server se démerder.

P-e ai-je mal compris.