Problème constaté lors de connexions multiples à SQL-Server 2000

Version imprimable

19/04/2012, 23h02
verryvalentino

Problème constaté lors de connexions multiples à SQL-Server 2000

Bonjour à tous.

Actuellement en stage, je travail sur une application (développée en perl) utilisant SQL server 2000 (Enterprise Manager).

1°) Sur le Serveur virtuelle, il y a :
a) serveur web: Apache
b) antivirus: Mc Afee
...
2°) Taille de la base de données: 6327 MB
3°) Quantité de RAM: 1 Go
4°) Microsoft Windows Server 2003 R2 Standard Edition, service pack 2

Description du problème:

- Lorsque plusieurs utilisateurs se connectent à l'application, je constate un ralentissement assez important dans l'affichage des pages. Aussi, il arrive d'avoir l'erreur décrite à la fin de ce message.

- J'ai aussi également constaté que lorsque je lance mon application, même en exécutant une seule requête, le CPU est consommé à 100%, ce qui à mon avis n'est pas du tout normal.

La quasi totalité des clefs primaires de mes tables sont indexée (cluster) ainsi que les clefs étragères. surtout les tables les plus utilisées dans les requêtes SQL.

N'étant pas un expert en Administration de Bases de Données, je souhaiterai savoir:

1°) à quoi cela peut être dû et comment faire pour y remédier afin que les temps de réponses soit assez courts (rapide) et que je ne puisse plus avoir l'erreur de connexion décrite ci dessous ( à la fin du message).

2°) comment faire pour optimiser ma base de données
3°) Comment faire pour identifier les requêtes les plus consomatrices.

Merci par avance pour votre aide précieuse.

Message d'erreur en dessous (merci):

Erreur constatée quelque fois lorsque plusieurs utilisateurs tentent de se connecter:

Citation:

Software Error

'Financial.Project.Show': Could not load module 'LLL::Functions::Financial::Project':
DBI connect('rb_ps','rb_ps_test',...) failed: [ODBC SQL Server Driver]Timeout expired (SQL-HYT00)(DBD: db_login/SQLConnect err=-1) at d:/rb/instances/ps/cgi-bin/../Modules/LLL/Database/Generic.pm line 289
Compilation failed in require at d:/rb/instances/ps/cgi-bin/../Modules/LLL/HTMLTools/CGIext.pm line 14.
BEGIN failed--compilation aborted at d:/rb/instances/ps/cgi-bin/../Modules/LLL/HTMLTools/CGIext.pm line 14.
Compilation failed in require at d:/rb/instances/ps/cgi-bin/../Modules/LLL/UserTools.pm line 12.
BEGIN failed--compilation aborted at d:/rb/instances/ps/cgi-bin/../Modules/LLL/UserTools.pm line 12.
Compilation failed in require at d:/rb/instances/ps/cgi-bin/../Modules/LLL/Functions/Financial/Project.pm line 32.
BEGIN failed--compilation aborted at d:/rb/instances/ps/cgi-bin/../Modules/LLL/Functions/Financial/Project.pm line 32.
Compilation failed in require at d:/rb/instances/ps/cgi-bin/../Modules/LLL/Dispatcher.pm line 94.
19/04/2012, 23h56
SQLpro

C'est une situation normale. Un SGBDR doit être installé sur une machine dédié et consomme TOUTE le RAM du serveur. Comme tout bon SGBDR SQL Server fonctionne exclusivement en mémoire or avec 1 Go de RAM, vous n'irez pas loin.... Le minimum ordinaire pour ce type de SGBDR est 4 Go en serveur dédié !
Le fait que SQL Server va pomper toute la RAM, empêche les autres applications de fonctionner correctement.

En sus il faut désactiver votre antivirus. Un SGBDR n'est pas sensible aux virus et cela ralentis considérablement le service des données.

A +
20/04/2012, 00h42
verryvalentino

Merci pour les orientation. Je vais suivre votre conseil de désintaller l'anti virus.

Par contre je souhaiterai savoir également si ce problème peut être lié aux requêtes qui pourraient être mal écrites.

Lorsqu'il y a moins d'utilisateurs connectés sur l'application, les temps de réponses sont acceptables ( inférieur à 1 minute). Par contre lorsqu'ils y en a plusieurs (utilisateurs connectés), les temps de réponse sont plus important, l'application rame.
20/04/2012, 04h14
elsuket

Bonjour,

Citation:

Par contre je souhaiterai savoir également si ce problème peut être lié aux requêtes qui pourraient être mal écrites.

Lorsqu'il y a moins d'utilisateurs connectés sur l'application, les temps de réponses sont acceptables ( inférieur à 1 minute). Par contre lorsqu'ils y en a plusieurs (utilisateurs connectés), les temps de réponse sont plus important, l'application rame.

Ce peut effectivement être une autre partie du problème.
Les requêtes sont lentes principalement parce que lorsque plusieurs utilisateurs sont connectés, ils exécutent des requêtes différentes.
Comme elles sont différentes, il y a des grandes chances pour qu'elles accèdent à des données différentes et/ou dans des tables différentes.
Avec si peu de RAM, il est donc impossible de stocker toutes ces données en RAM.
Donc les performances de la base de données en souffrent puisqu'il y a un aller-retour constant entre le disque (1000 fois plus lent que la RAM) et la RAM.
D'autre part le fait de virtualiser n'aide pas.

Combien d'utilisateurs votre base de données doit-elle supporter ?
Comme il s'agit d'une machine virtuelle, voyez si vous ne pouvez pas prendre plus de RAM sur la machine hôte : plus en aurez à disposition, meilleures seront les performances ;) (mais ce n'est pas le remède absolu)

Seulement ensuite exécutez SQL Profiler côté serveur, filtrez bien votre trace sur la durée, la consommation CPU et le nombre de lectures, et vous allez trouver les mauvaises requêtes ;)

Pouvez-vous dire si les statistiques et les index sont maintenus sur cette base de données ?
Quelle est l'édition du moteur de base de données ?

@++ ;)
20/04/2012, 07h57
SiSMik

Si l'environnement est du VMWare, je vous conseil de suivre cette documentation pour comprendre et pourquoi pas revoir la configuration "hardware" de votre server SQL

VMWare SQL Server Best Practice

ça peut aussi être une piste

@+
20/04/2012, 08h27
verryvalentino

Bonjour,

Merci pour vos réponse car cela me permet de voir plus claire.

Ma base de données doit supporter environ 50 utilisateurs. Mais en ce moment, dès qu'il y a plus de 2 utilisateurs connectés, les temps de réponse de l'application sont assez lente ( plus d'une minutes, voir plus pour afficher une page).

Autres précisions: J'ai des bases de données mutualisées car j'ai:

1°) une base de données pour l'environnement de recette ( pour les tests)
2°) une base de données pour l'environnement de production
3°) une base de données pour l'environnement de développement.

Toutes les bases de données ont quasiment toutes la même taille ( les différentes applications font exactement la même chose)

J'ai différents liens ( applications) qui me permettent de me connecter à chacune d'elle.

Par contre, Pouvez-vous me dire comment je peux faire pour savoir si les statistiques et les index sont maintenus sur la base de données ?

Voici les différentes caractéristiques que j'ai relevé sur le serveur:

- Product: SQL Server Standard Edition
- OS: Microsoft Windows NT-5.2 (3790)
- Product version: NT INTEL X86
- OS memory: 1023 (MB)
- Processeur: 1
- Server Collation: Latin1_General_Cl_AS

Concernant les informations suivantes, je pourrai vous en dire plus une fois que j'aurai ces informations: la maintenance des statistiques et des index sur la base de données et l'édition du moteur de base de données.

Merci encore pour vos réponses précieuses.
20/04/2012, 11h37
elsuket

Bonjour,

Citation:

- Product: SQL Server Standard Edition

Certes, mais cela ne donne pas la version, ni le service pack (un peu moins important). Utilisez le second lien que je vous ai donné dans ma réponse précédente ;)

Citation:

Pouvez-vous me dire comment je peux faire pour savoir si les statistiques et les index sont maintenus sur la base de données ?

Ce n'est pas facile sans la version (si vous êtes en SQL Server 2000, les requêtes pour le savoir sont différentes de celles pour le savoir sur une version postérieure ;))

Citation:

- OS memory: 1023 (MB)
- Processeur: 1

Clairement sous-dimensionné à mon avis pour 50 utilisateurs.

@++ ;)
21/04/2012, 00h43
verryvalentino

1 pièce(s) jointe(s)

Bonjour,

Merci pour l'ensemble de vos réponses.

Pour apporter plus de détaille au problème posé, j'apporte en plus les informations suivantes:

- Finalement le nombre d'utilisateurs est limité entre 3 et 5 au maximum. le plus grand nombre d'utilisateurs au grand maximum ne dépassera pas plus de 10 utilisateurs.

- Les statistiques et les index ne sont pas maintenus ( à moins que SQL Server le face automatiquement)

- SQL Server 2000, Service Pack 4, Version(Product Version): 8.00.2039

- L'environnement est du VMWare

Comme spécifié dans mes messages précédents, lorsqu'il y a plus d'un utilisateur connecté, le temps de réponse de l'application est assez lent, problème qui n'est pas observé avec une seule connexion ( les temps de réponse sont assez court).

Au regard des différentes orientations reçues, j'ai également lancé "SQL Profiler" afin d'identifier dans la mesure du possible les éventuelles requêtes ou procédures qui pourraient être à l'origine du problème de connexion au serveur observé lorsqu'ils plusieurs utilisateurs qui se connectent ( à l'application).

j'ai obtenu le résultat suivant: voir pièce jointe. ayant obtenu plusieurs lignes, je n'ai mis que quelques unes dans le fichier joint.

Aussi, je souhaiterai avoir de plus amples explication concernant ces résultats, et comment puis -je faire pour identier la ou les procédures concernées dans la base de données à partir du résulatat obtenu.
J'ai mis des filtres sur: RPC:Completed, reads>100, Writes et Duration(voir fichier).

Merci par avance pour votre aisde si précieuse.
21/04/2012, 07h30
elsuket

Bonjour,

Citation:

- Les statistiques et les index ne sont pas maintenus ( à moins que SQL Server le face automatiquement)

Il se peut qu'il y a ait un plan de maintenance qui le fasse, et si c'est le cas, ce n'est pas optimal.
Si vous êtes sûr que rien n'existe, vous pouvez utiliser l'article de SQLPro sur le sujet en ce qui concerne les index.

Pour les statistiques de colonne, commencez par EXEC sp_updatestats.

Il semble que la première procédure stockée soit contre-performante ;)
Vous pouvez l'exécuter en incluant le plan d'exécution réel, et à partir de là voir ce qui ne va pas.
Il existe aussi les options SET STATISTICS IO ON (qui permet d'afficher dans la console l'activité IO générée par l'exécution d'une requête) et SET STATISTICS TIME ON (affiche dans la console l'activité CPU et la durée des requêtes).

Pour les autres requêtes, elles ne semblent pas être méchantes, mais cela dépend de la fréquence à laquelle est sont exécutées ;)
Vous pouvez les exécuter à la main, en affectant une valeur aux paramètres si cela vous est possible ...

Mais comme on vous l'a dit avant, vu que vous êtes en environnement virtualisé, voyez à augmenter au moins la quantité de RAM disponible pour cette machine virtuelle !

@++ ;)