Discussion :

[Pierre_45]

Bonjour,
Voici ma config:

• Serveur Intel Xeon 2 x 3.06GHz 4GB RAM (dont 3GB pour SQL)
• Serveur Windows 2003 Standard Edition SP2
• SQL 2005 SP3 - Plusieurs bases dont la plus grosse = 40GB avec env 1100 connexions ouvertes
• McAfee VirusScan Entreprise V8.7i

En cherchant à améliorer les temps de réponses aux requêtes SQL qui s'étaient dégradés ces derniers mois, je me suis aperçu que le process sqlserver.exe utilisait en permanence env 60% de la CPU.
En désactivant l'antivirus, sqlserver.exe est retombé à 25% et les temps de réponses se sont largement améliorés.
Le pb est que les repertoires des bases étaient déjà exclus du scan et que je constate toujours la même chose si j'exclus tout les disques du serveur

Le support MacAfee a annoncé que le pb ne venait pas d'eux et je n'ai pas encore contacté Mircosoft
Une idée, des pistes de recherches, des tests à réaliser ? Merci

Pierre

[mikedavem]

Bonjour,

Avez vous regardé si la vérification à l'accès n'était pas activé sur l'antivirus pour les fichiers de bases de données (extension MDF etc ...) ?

++

[Pierre_45]

Oui les fichiers .bak, .mdf, .ldf, .ndf, .trn sont exclus sur les évenements Onread et On write

Merci tout de même.

Pierre

[SQLpro]

De toutes façon l'utilisation de tout antivirus sur un serveur de bases de données est catastrophique pour les performances. En aucun cas vous ne devriez avoir un tel service sur un serveur de SGBDR C/S.
Prévoyez ceci en amont, par exemple avec un DMZ. Si votre serveur de BD est attaqué par un serveur web ou d'objet, alors il n'y a pas lieu de mettre quoi que ce soit. Il suffit de sécuriser la connexion entre les serveurs et interdire toute autre connexion.

A +

[dbaffaleuf]

Hello,

Pour appuyer un peu plus encore contre la présence d'un AV sur un serveur qui fait des entrées/sorties comme SQL Server, il faut savoir qu'un agent résidant passe le plus clair de son temps à lire des pages en mémoire et vérifier leur contenu pour voir si elles ne contiennent pas une signature de virus connu, et donc génère énormément de défauts de page.

Lorsque windows translate l'adresse d'une page en adresse physique, mais que la page ne se trouve pas à l'adresse indiquée, le morceau de code qui trappe les interruptions dans windows (Dispatcher) est invoqué pour résoudre le problème, ce qui est très néfaste pour le déroulement de l'exécution d'un thread de SQL Server, car il sera interrompu dans son travail. Et comme l'agent résidant génère beaucoup de défauts de page, il génère du même coup beaucoup de changements de contexte au niveau Windows.

Je suis d'accord avec Frédéric, sus aux antivirus sur les SGBDR.

A+ David B.

[mikedavem]

Plutôt d'accord avec vous également. Cependant pour bcp d'entreprises ne pas avoir danti virus sur un serveur n'est pas pensable. Comme tu l'expliques le problème de l'agent se pose bcp lors de l'analyse a l'accès. Chez le client actuel nous avons négocier sur le serveur de production la désactivation a l'accès de cet agent et décider de planification "légère" d'un scan aux heures creuses en excluant les fichiers de bases de données.

++