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.

++

[SQLpro]

C'est la moindre des choses, mais absolument pas suffisant pour les perf !

A +

[mikedavem]

Il est clair que cela est au détriment des performances ... donc autant minimiser l'impact de l'antivirus .. La DSI doit en être consciente et faire un choix ...

Les serveurs de bases de données ne présentent pas un fort risque de sécurité en général. Cependant certaines fonctionnalités de SQL Server peuvent nécessiter la présence d'un antivirus dans certains cas :

- Utilisation des fonctions XML de SQL Server 2000 + IIS
- Utilisation de SQL Mail qui gèrent les messages entrants et sortants ...

++

[Pierre_45]

Bonjour et merci pour vos réponses.
En ce qui concerne mon serveur, la nécessité d'un antivirus se justifie de part le fait qu'un de ses répertoires est partagé et monté en lecteur sur les postes de production. Donc plus de 300 postes peuvent accèder à ce partage et il suffit qu'un de ces postes ne soit pas à jour au niveau de son antivirus et ... Evidemment cette architecture est liée à une application développée par des personnes peu au fait de la sécurité.

Dans la config de McAfee on peut définir des process comme étant "low risk" et on peut exclure des répertoires, fichiers mais il n'est jamais question de scan de la mémoire auquel dbaffaleuf fait allusion. A moins qu'il ne parle de la swap? Quelqu'un peut m'éclairer ?

Pierre

[SQLpro]

Ton AV peut être programmé pour scruter les process auquel cas il accède à la RAM.

Un serveur de SGBDR doit être installé sur un serveur dédié. Un SGBDR de type C/S est strictement incompatible en production avec tout autre process serveur ou application, partage, etc.
On peut tolérer cela sur un serveur de DEV (auquel cas des perf catastrophiques ne sont pas génantes), mais en aucun cas sur de la prod !

A +

[dbaffaleuf]

Dans le cas de McAffe, le scanner doit s'appeler mcshield.exe, qq chose comme ça. J'ai vu qu'ils ne le mettaient plus en realtime dans leur produit AV depuis février 2010 au profit d'un outil tiers (Artemis).

Pour vérifier s'il y a scan de la mémoire, une manière simple consiste à ajouter la colonne Page Faults (ou Erreurs de Pages) dans Task Manager -> Processes , classer tous les processus sur cette colonne et vérifier si mcshield.exe est dans le 5 de tête. (sachant de sqlservr.exe n'est en général pas mal non plus).

Par exemple, cf capture ci-joint.

David B.

[Pierre_45]

Ok je ferai la manip au retour de mes vacances... Actuellement l'AV est désactivé pour ne pas géner la prod, donc tout va bien pour moi, c'est l'admin système qui claque des dents !!

Je n'ai pas l'impression de pouvoir désactiver le scan des process, seulement de définir des process "Low risk" ou "High"? Je me renseigne.

C'est sur qu'on ne devrait pas avoir autre chose qu'une base de données sur un serveur, hélas entre la théorie et la pratique...

Merci à vous

Pierre