Discussion :

[FranckRav]

Bonjour,

Je suis confronté à des différences de performances entre notre environnement de test et notre environnement de production. La production est en moyenne, sur tous les tests que nous avons fait, 50% plus lente!

Pourtant :

- Les benchs hardware (CPU, disques, réseau) sont largement meilleurs en production
- Les machines de productions sont loins d'etre surchargées

La configuration est la meme (défaut), l'édition de SQL server aussi (Standard).

Le protocole utilisé est TCP/IP; l'authentitfication SQL dans les deux cas.

Quels sont les pistes possibles d'investigation?

Merci

[jabbounet]

difficile de t'orienter avec si peu de détails.

je pense que vous devriez essayer de monitorer un peu votre application pour voir ou elle perd du temps (si ce n'est pas déjà fait).

En général les volumétrie sont différentes entres des environnement de test et de productions. par exemple tu peux avoir une table avec 500 utilisateurs en test et 50000 en prod, ça peux changer pas mal la donne quand tu tente d'accéder à ces données.

Parfois il y'a aussi des petits détails qui font que ton SGBD peu être ralenti, Je me souviens que lors d'une mise en production un index sur une table oracle n'avait pas été crée et cela avait bien ralentit le processus.

[FranckRav]

J'ai oublié de préciser que les bench étaient faits sur l'environnement de test avec un backup de production restauré. Les données et le modéle sont exactement donc les memes.

Est ce que un problème de résolution DNS peut influer à ce point? Les différences sont plutot sur une succession de nombreuses requetes moyenne plutot que sur les grosses requetes.

[SQLpro]

Avez vous pensé à préfixez tous vos objets (tables, vues, procédures...) par leur schéma (à défaut par dbo ?) dans toutes vos requêtes et vos routines (proc, trigger, foctions..) ?

A +

[FranckRav]

1) version et édition de l'OS et de SQL Server

TEST : Windows serveur 2003 32 bit & SQL server 2005 Standard
PROD: Windows serveur 2008 64 bit & SQL server 2005 Standard

2) config machine : RAM, CPU, Disque (physique et logique (RAID))

TEST : Serveur Physique, RAM 2Go, Quad Core, RAID 0
PROD : VM Ware, RAM 6Go, Quad Core, RAID 5

3) services autres que SQL Server tournant dessus

TEST : IIS
PROD : Aucun

4) contenu de sp_configure

TEST

Ad Hoc Distributed Queries 0 1 1 1
affinity I/O mask -2147483648 2147483647 0 0
affinity mask -2147483648 2147483647 0 0
Agent XPs 0 1 1 1
allow updates 0 1 0 0
awe enabled 0 1 0 0
blocked process threshold 0 86400 0 0
c2 audit mode 0 1 0 0
clr enabled 0 1 1 1
cost threshold for parallelism 0 32767 5 5
cross db ownership chaining 0 1 0 0
cursor threshold -1 2147483647 -1 -1
Database Mail XPs 0 1 0 0
default full-text language 0 2147483647 1036 1036
default language 0 9999 2 2
default trace enabled 0 1 1 1
disallow results from triggers 0 1 0 0
fill factor (%) 0 100 0 0
ft crawl bandwidth (max) 0 32767 100 100
ft crawl bandwidth (min) 0 32767 0 0
ft notify bandwidth (max) 0 32767 100 100
ft notify bandwidth (min) 0 32767 0 0
index create memory (KB) 704 2147483647 0 0
in-doubt xact resolution 0 2 0 0
lightweight pooling 0 1 0 0
locks 5000 2147483647 0 0
max degree of parallelism 0 64 0 0
max full-text crawl range 0 256 4 4
max server memory (MB) 16 2147483647 2147483647 2147483647
max text repl size (B) 0 2147483647 65536 65536
max worker threads 128 32767 0 0
media retention 0 365 0 0
min memory per query (KB) 512 2147483647 1024 1024
min server memory (MB) 0 2147483647 0 8
nested triggers 0 1 1 1
network packet size (B) 512 32767 4096 4096
Ole Automation Procedures 0 1 0 0
open objects 0 2147483647 0 0
PH timeout (s) 1 3600 60 60
precompute rank 0 1 0 0
priority boost 0 1 0 0
query governor cost limit 0 2147483647 0 0
query wait (s) -1 2147483647 -1 -1
recovery interval (min) 0 32767 0 0
remote access 0 1 1 1
remote admin connections 0 1 0 0
remote login timeout (s) 0 2147483647 20 20
remote proc trans 0 1 0 0
remote query timeout (s) 0 2147483647 600 600
Replication XPs 0 1 0 0
scan for startup procs 0 1 1 1
server trigger recursion 0 1 1 1
set working set size 0 1 0 0
show advanced options 0 1 1 1
SMO and DMO XPs 0 1 1 1
SQL Mail XPs 0 1 0 0
transform noise words 0 1 0 0
two digit year cutoff 1753 9999 2049 2049
user connections 0 32767 0 0
user options 0 32767 0 0
Web Assistant Procedures 0 1 0 0
xp_cmdshell 0 1 1 1

PROD

allow updates 0 1 0 0
clr enabled 0 1 0 0
cross db ownership chaining 0 1 0 0
default language 0 9999 2 2
max text repl size (B) 0 2147483647 65536 65536
nested triggers 0 1 1 1
remote access 0 1 1 1
remote admin connections 0 1 0 0
remote login timeout (s) 0 2147483647 20 20
remote proc trans 0 1 0 0
remote query timeout (s) 0 2147483647 600 600
server trigger recursion 0 1 1 1
show advanced options 0 1 0 0
user options 0 32767 0 0

5) quelle type de connexion ? ASP.net ? Client lourd PHP ???

Nos applications sont habituellement des applications Web ou Console.

Les benchs ont été faits avec des exe console

6) combien d'utilisateur en // ? (SELECT COUNt(*) FROM sys.dm_exec_sessions)

TEST : 51
PROD : 80

7) taille de la base (data/index), emplacement des fichiers et taille (pour toutes les BD de prod
LOG : 18MB
DATA : 360 MB

PROD: Fichiers Data et Log sur des partitions séparées, différentes du système
TEST : Fichier Data et Log sur la meme partition, différente du système


8) emplacement de tempdb

TEST : Partition système
PROD : Même partition que les données

[FranckRav]

Le fait de mal préfixer les objets peut-il entrainer des différences entre deux environnements avec la meme base?

[SQLpro]

Donnez nous les éléments suivants :
1) version et édition de l'OS et de SQL Server
2) config machine : bits (32, 64), RAM, CPU, Disque (physique et logique (RAID))
3) services autres que SQL Server tournant dessus
4) contenu de sp_configure
5) quelle type de connexion ? ASP.net ? Client lourd PHP ???
6) combien d'utilisateur en // ? (SELECT COUNt(*) FROM sys.dm_exec_sessions)
7) taille de la base (data/index), emplacement des fichiers et taille (pour toutes les BD de prod
8) emplacement de tempdb
...
C'est un minimum !

A +

[FranckRav]

Bonjour,

J'ai utilisé SQLIO et vos soupcons se confirment. Il doit s'agir d'un soucis de comptabilité entre la virtualisation et l'OS de SQL server, les résultats de bench classiques des disques en RAID5 étant tout à fait excellents.

Existe-t-il des config SQL server permettant de minimiser l'impact de la virtualisation?

Merci pour vos conseils

Plateforme de TEST :

sqlio v1.5.SG
1 thread reading for 30 secs from file testfile.dat
using 2KB IOs over 128KB stripes with 64 IOs per run
initialization done
CUMULATIVE DATA:
throughput metrics:
IOs/sec: 11814.53
MBs/sec: 23.07

Plateforme de production :

sqlio v1.5.SG
1 thread reading for 30 secs from file testfile.dat
using 2KB IOs over 128KB stripes with 64 IOs per run
size of file testfile.dat needs to be: 8388608 bytes
current file size: 0 bytes
need to expand by: 8388608 bytes
expanding testfile.dat ... done.
initialization done
CUMULATIVE DATA:
throughput metrics:
IOs/sec: 5026.60
MBs/sec: 9.81

[mikedavem]

Avec VMWARE regardez les points suivants :

- Activation Pass through sur l'esx hôte (attention car l'activation du pass through sur l'esx hôte sera valable pour l'ensemble des machines virtuelles).

--> /etc/vmware/esx.conf avec /device/000:11.0/owner = "passthru" par exemple

- Alignement des fichiers vmdk sur votre serveur. (Si les fichiers ont été créés depuis l'interface graphique en principe ces fichiers sont alignés automatiquement). Vous pouvez le vérifiez avec la commande suivante (sous linux) :

--> fdisk -lu

++