J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques
temps (il y a environ 30 millions d'informations dans l'une des tables)
malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le serveur
atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête qui
provoque le problème ?
Ton journal des transactions, il fait quelle taille ?
"Mikado" a écrit :
Salut à tous,
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques temps (il y a environ 30 millions d'informations dans l'une des tables) malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le serveur atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête qui provoque le problème ?
Merci pour vos conseils.
Mikado
Ton journal des transactions, il fait quelle taille ?
"Mikado" a écrit :
Salut à tous,
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques
temps (il y a environ 30 millions d'informations dans l'une des tables)
malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le serveur
atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête qui
provoque le problème ?
Ton journal des transactions, il fait quelle taille ?
"Mikado" a écrit :
Salut à tous,
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques temps (il y a environ 30 millions d'informations dans l'une des tables) malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le serveur atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête qui provoque le problème ?
Merci pour vos conseils.
Mikado
Fred BROUARD
Mikado a écrit:
Salut à tous,
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques temps (il y a environ 30 millions d'informations dans l'une des tables) malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le serveur atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête qui provoque le problème ?
Mais il n'y a aucun problème. C'est le fonctionnement normal de SQL Server que de tirer partie du maximum des ressources disponible pour servir au plus vite les données ?
En quoi es-ce un problème ?
Merci pour vos conseils.
Mikado
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Mikado a écrit:
Salut à tous,
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques
temps (il y a environ 30 millions d'informations dans l'une des tables)
malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le serveur
atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête qui
provoque le problème ?
Mais il n'y a aucun problème. C'est le fonctionnement normal de SQL Server que
de tirer partie du maximum des ressources disponible pour servir au plus vite
les données ?
En quoi es-ce un problème ?
Merci pour vos conseils.
Mikado
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques temps (il y a environ 30 millions d'informations dans l'une des tables) malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le serveur atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête qui provoque le problème ?
Mais il n'y a aucun problème. C'est le fonctionnement normal de SQL Server que de tirer partie du maximum des ressources disponible pour servir au plus vite les données ?
En quoi es-ce un problème ?
Merci pour vos conseils.
Mikado
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Mikado
En fait il est constamment à 100%, c'est pas une fluctuation et l'application en front en devient lente.
En fait il est constamment à 100%, c'est pas une fluctuation et
l'application en front en devient lente.
En fait il est constamment à 100%, c'est pas une fluctuation et l'application en front en devient lente.
Bouarroudj Mohamed
SQLProfiler, colonne CPU
la cause peut etre 1. Procedure stcockée ou requete trop recompilées (l'evenement SQLProfilerSP:Recompile peut etre utile) 2. Utilisation extensive des jointures de type Hash/Merge (l'evenement SQLProfilerPerormance:ShowPlan peut etre utile)
Cet article peut vous aider http://support.microsoft.com/default.aspx?scid=kb;en-us;224587
"Mikado" wrote in message news:%
Salut à tous,
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques temps (il y a environ 30 millions d'informations dans l'une des tables) malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le serveur atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête qui provoque le problème ?
Merci pour vos conseils.
Mikado
SQLProfiler, colonne CPU
la cause peut etre
1. Procedure stcockée ou requete trop recompilées (l'evenement
SQLProfilerSP:Recompile peut etre utile)
2. Utilisation extensive des jointures de type Hash/Merge (l'evenement
SQLProfilerPerormance:ShowPlan peut etre utile)
Cet article peut vous aider
http://support.microsoft.com/default.aspx?scid=kb;en-us;224587
"Mikado" <mikado@mikado.com> wrote in message
news:%235sqMJTEGHA.1424@TK2MSFTNGP12.phx.gbl...
Salut à tous,
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques
temps (il y a environ 30 millions d'informations dans l'une des tables)
malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le
serveur atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête
qui provoque le problème ?
la cause peut etre 1. Procedure stcockée ou requete trop recompilées (l'evenement SQLProfilerSP:Recompile peut etre utile) 2. Utilisation extensive des jointures de type Hash/Merge (l'evenement SQLProfilerPerormance:ShowPlan peut etre utile)
Cet article peut vous aider http://support.microsoft.com/default.aspx?scid=kb;en-us;224587
"Mikado" wrote in message news:%
Salut à tous,
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques temps (il y a environ 30 millions d'informations dans l'une des tables) malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le serveur atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête qui provoque le problème ?
Merci pour vos conseils.
Mikado
Bouarroudj Mohamed
Un autre point a regarder, avez vous un anti-virus installé sur votre serveur ?
"Bouarroudj Mohamed" wrote in message news:
SQLProfiler, colonne CPU
la cause peut etre 1. Procedure stcockée ou requete trop recompilées (l'evenement SQLProfilerSP:Recompile peut etre utile) 2. Utilisation extensive des jointures de type Hash/Merge (l'evenement SQLProfilerPerormance:ShowPlan peut etre utile)
Cet article peut vous aider http://support.microsoft.com/default.aspx?scid=kb;en-us;224587
"Mikado" wrote in message news:%
Salut à tous,
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques temps (il y a environ 30 millions d'informations dans l'une des tables) malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le serveur atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête qui provoque le problème ?
Merci pour vos conseils.
Mikado
Un autre point a regarder, avez vous un anti-virus installé sur votre
serveur ?
"Bouarroudj Mohamed" <mbouarroudj@yahoo.com> wrote in message
news:uWMyqxUEGHA.1312@TK2MSFTNGP09.phx.gbl...
SQLProfiler, colonne CPU
la cause peut etre
1. Procedure stcockée ou requete trop recompilées (l'evenement
SQLProfilerSP:Recompile peut etre utile)
2. Utilisation extensive des jointures de type Hash/Merge (l'evenement
SQLProfilerPerormance:ShowPlan peut etre utile)
Cet article peut vous aider
http://support.microsoft.com/default.aspx?scid=kb;en-us;224587
"Mikado" <mikado@mikado.com> wrote in message
news:%235sqMJTEGHA.1424@TK2MSFTNGP12.phx.gbl...
Salut à tous,
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis
quelques temps (il y a environ 30 millions d'informations dans l'une des
tables) malgré le faible nombre d'accès (environ 30 utilisateurs maximum)
le serveur atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête
qui provoque le problème ?
Un autre point a regarder, avez vous un anti-virus installé sur votre serveur ?
"Bouarroudj Mohamed" wrote in message news:
SQLProfiler, colonne CPU
la cause peut etre 1. Procedure stcockée ou requete trop recompilées (l'evenement SQLProfilerSP:Recompile peut etre utile) 2. Utilisation extensive des jointures de type Hash/Merge (l'evenement SQLProfilerPerormance:ShowPlan peut etre utile)
Cet article peut vous aider http://support.microsoft.com/default.aspx?scid=kb;en-us;224587
"Mikado" wrote in message news:%
Salut à tous,
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques temps (il y a environ 30 millions d'informations dans l'une des tables) malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le serveur atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête qui provoque le problème ?
En fait il est constamment à 100%, c'est pas une fluctuation et l'application en front en devient lente.
je suppose que cette application est sur le même serveur ?
Si c'est le cas, c'est normal. Un serveur de base de données doit normalement être installé sur un serveur indépendant et aucun autre programme ne doit s'y trouver. SQL Server est programmé pour prendre toutes les ressources qu'il juge nécessaires au détriment de toutes autres applications. La seule exception à cette règle est l'OS lui même qui peut demander à SQL Server de lui restituer de la mémoire, mais uniquement en cas de stress.
Soit vous déportez vos applications, soit il vous faudra limiter la mémoire utilisée par SQL Server. Si votre serveur (machine) est équipé en multi processeur, vous pouvez même limiter le nombre de processeurs utilisés par SQL Server.
Encore faudrait-il que vous nous donniez votre configuration : description technique complète de la machine (RAM, disque, proc...) version des OS appli installées Volume des bases de données, des disque et taux d'occupation etc.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Mikado a écrit:
En fait il est constamment à 100%, c'est pas une fluctuation et
l'application en front en devient lente.
je suppose que cette application est sur le même serveur ?
Si c'est le cas, c'est normal. Un serveur de base de données doit normalement
être installé sur un serveur indépendant et aucun autre programme ne doit s'y
trouver.
SQL Server est programmé pour prendre toutes les ressources qu'il juge
nécessaires au détriment de toutes autres applications. La seule exception à
cette règle est l'OS lui même qui peut demander à SQL Server de lui restituer de
la mémoire, mais uniquement en cas de stress.
Soit vous déportez vos applications, soit il vous faudra limiter la mémoire
utilisée par SQL Server. Si votre serveur (machine) est équipé en multi
processeur, vous pouvez même limiter le nombre de processeurs utilisés par SQL
Server.
Encore faudrait-il que vous nous donniez votre configuration :
description technique complète de la machine (RAM, disque, proc...)
version des OS
appli installées
Volume des bases de données, des disque et taux d'occupation
etc.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
En fait il est constamment à 100%, c'est pas une fluctuation et l'application en front en devient lente.
je suppose que cette application est sur le même serveur ?
Si c'est le cas, c'est normal. Un serveur de base de données doit normalement être installé sur un serveur indépendant et aucun autre programme ne doit s'y trouver. SQL Server est programmé pour prendre toutes les ressources qu'il juge nécessaires au détriment de toutes autres applications. La seule exception à cette règle est l'OS lui même qui peut demander à SQL Server de lui restituer de la mémoire, mais uniquement en cas de stress.
Soit vous déportez vos applications, soit il vous faudra limiter la mémoire utilisée par SQL Server. Si votre serveur (machine) est équipé en multi processeur, vous pouvez même limiter le nombre de processeurs utilisés par SQL Server.
Encore faudrait-il que vous nous donniez votre configuration : description technique complète de la machine (RAM, disque, proc...) version des OS appli installées Volume des bases de données, des disque et taux d'occupation etc.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
bruno reiter [MVP]
utilises le profiler pour voir ce qui utilises beaucoup de cpu, souvent ce sont des UDF
br
"Mikado" wrote in message news:#
Salut à tous,
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques temps (il y a environ 30 millions d'informations dans l'une des tables) malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le
serveur
atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête
qui
provoque le problème ?
Merci pour vos conseils.
Mikado
utilises le profiler pour voir ce qui utilises beaucoup de cpu, souvent ce
sont des UDF
br
"Mikado" <mikado@mikado.com> wrote in message
news:#5sqMJTEGHA.1424@TK2MSFTNGP12.phx.gbl...
Salut à tous,
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques
temps (il y a environ 30 millions d'informations dans l'une des tables)
malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le
serveur
atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête
utilises le profiler pour voir ce qui utilises beaucoup de cpu, souvent ce sont des UDF
br
"Mikado" wrote in message news:#
Salut à tous,
J'ai un serveur SQLServer avec une seule base utilisateur. Depuis quelques temps (il y a environ 30 millions d'informations dans l'une des tables) malgré le faible nombre d'accès (environ 30 utilisateurs maximum) le
serveur
atteind les 100% de ressources CPUs.
Comment je peux déterminer la table, la procédure stockée ou la requête
qui
provoque le problème ?
Merci pour vos conseils.
Mikado
Mikado
En fait c'est bel est bien l'une de mes PS qui utilise massivement le CPU. Il va falloir que je la modifie.
Merci pour vos conseils
En fait c'est bel est bien l'une de mes PS qui utilise massivement le CPU.
Il va falloir que je la modifie.
En fait c'est bel est bien l'une de mes PS qui utilise massivement le CPU. Il va falloir que je la modifie.
Merci pour vos conseils
Mikado
Bonjour,
je suppose que cette application est sur le même serveur ?
Bien sûr que non.
SQL Server est programmé pour prendre toutes les ressources qu'il juge nécessaires au détriment de toutes autres applications. La seule exception à cette règle est l'OS lui même qui peut demander à SQL Server de lui restituer de la mémoire, mais uniquement en cas de stress.
Oui tout à fait. Sauf que dans mon cas SQL Server utilise 100% des CPU injustement en rapport l'activité en cours. En fait après avec regardé avec SQL Profiler j'ai trouvé une PS dont le poids est excessif et qui visiblement n'est pas très optimisée. Je vais déjà modifier la procédure et voir ensuite ce qui ce passe.
Soit vous déportez vos applications, soit il vous faudra limiter la mémoire utilisée par SQL Server. Si votre serveur (machine) est équipé en multi processeur, vous pouvez même limiter le nombre de processeurs utilisés par SQL Server.
Tiens d'ailleurs petite question. La machine possède deux procs + hyperthreading. D'après ce que j'ai pu voir sur un site le hyperthreading est assez déconseillé avec SQL Server. Est-ce votre constat ?
Encore faudrait-il que vous nous donniez votre configuration : description technique complète de la machine (RAM, disque, proc...) version des OS appli installées Volume des bases de données, des disque et taux d'occupation etc.
A +
Machine : BiProc Xeon 3.2Ghz 2Go de RAM 70Go de disque dur en SCSI Raid 5 (utilisé à 21%)
Base de données : Données : 11323Mo (dont 5452,69Mo disponible) Journal des transactions : 51,18Mo (dont 44Mo disponible)
Les tables les plus conséquentes font respectivement : 5512, 5469, 31617, 2293254 et 24219374 lignes. Il y a 14 tables. Rien d'extraordinaire.
Quelques statistiques sur 10 minutes :
% Temps processeur 91.6% Connexions utilisateur 26 Nombre de requêtes de lots/s 15 Transactions/seconde 7 pour tempdb, 0 pour les autres Requêtes de verrous/seconde 97000 Recherche de pages/seconde 197010
Je suis étonné par la recherche de pages/seconde, est-ce normal ? Peut-être que d'autres infos serait intéressantes ?
Jérôme
Bonjour,
je suppose que cette application est sur le même serveur ?
Bien sûr que non.
SQL Server est programmé pour prendre toutes les ressources qu'il juge
nécessaires au détriment de toutes autres applications. La seule exception
à cette règle est l'OS lui même qui peut demander à SQL Server de lui
restituer de la mémoire, mais uniquement en cas de stress.
Oui tout à fait. Sauf que dans mon cas SQL Server utilise 100% des CPU
injustement en rapport l'activité en cours. En fait après avec regardé avec
SQL Profiler j'ai trouvé une PS dont le poids est excessif et qui
visiblement n'est pas très optimisée. Je vais déjà modifier la procédure et
voir ensuite ce qui ce passe.
Soit vous déportez vos applications, soit il vous faudra limiter la
mémoire utilisée par SQL Server. Si votre serveur (machine) est équipé en
multi processeur, vous pouvez même limiter le nombre de processeurs
utilisés par SQL Server.
Tiens d'ailleurs petite question. La machine possède deux procs +
hyperthreading. D'après ce que j'ai pu voir sur un site le hyperthreading
est assez déconseillé avec SQL Server. Est-ce votre constat ?
Encore faudrait-il que vous nous donniez votre configuration :
description technique complète de la machine (RAM, disque, proc...)
version des OS
appli installées
Volume des bases de données, des disque et taux d'occupation
etc.
A +
Machine :
BiProc Xeon 3.2Ghz
2Go de RAM
70Go de disque dur en SCSI Raid 5 (utilisé à 21%)
Base de données :
Données : 11323Mo (dont 5452,69Mo disponible)
Journal des transactions : 51,18Mo (dont 44Mo disponible)
Les tables les plus conséquentes font respectivement : 5512, 5469,
31617, 2293254 et 24219374 lignes.
Il y a 14 tables.
Rien d'extraordinaire.
Quelques statistiques sur 10 minutes :
% Temps processeur 91.6%
Connexions utilisateur 26
Nombre de requêtes de lots/s 15
Transactions/seconde 7 pour tempdb, 0 pour les autres
Requêtes de verrous/seconde 97000
Recherche de pages/seconde 197010
Je suis étonné par la recherche de pages/seconde, est-ce normal ? Peut-être
que d'autres infos serait intéressantes ?
je suppose que cette application est sur le même serveur ?
Bien sûr que non.
SQL Server est programmé pour prendre toutes les ressources qu'il juge nécessaires au détriment de toutes autres applications. La seule exception à cette règle est l'OS lui même qui peut demander à SQL Server de lui restituer de la mémoire, mais uniquement en cas de stress.
Oui tout à fait. Sauf que dans mon cas SQL Server utilise 100% des CPU injustement en rapport l'activité en cours. En fait après avec regardé avec SQL Profiler j'ai trouvé une PS dont le poids est excessif et qui visiblement n'est pas très optimisée. Je vais déjà modifier la procédure et voir ensuite ce qui ce passe.
Soit vous déportez vos applications, soit il vous faudra limiter la mémoire utilisée par SQL Server. Si votre serveur (machine) est équipé en multi processeur, vous pouvez même limiter le nombre de processeurs utilisés par SQL Server.
Tiens d'ailleurs petite question. La machine possède deux procs + hyperthreading. D'après ce que j'ai pu voir sur un site le hyperthreading est assez déconseillé avec SQL Server. Est-ce votre constat ?
Encore faudrait-il que vous nous donniez votre configuration : description technique complète de la machine (RAM, disque, proc...) version des OS appli installées Volume des bases de données, des disque et taux d'occupation etc.
A +
Machine : BiProc Xeon 3.2Ghz 2Go de RAM 70Go de disque dur en SCSI Raid 5 (utilisé à 21%)
Base de données : Données : 11323Mo (dont 5452,69Mo disponible) Journal des transactions : 51,18Mo (dont 44Mo disponible)
Les tables les plus conséquentes font respectivement : 5512, 5469, 31617, 2293254 et 24219374 lignes. Il y a 14 tables. Rien d'extraordinaire.
Quelques statistiques sur 10 minutes :
% Temps processeur 91.6% Connexions utilisateur 26 Nombre de requêtes de lots/s 15 Transactions/seconde 7 pour tempdb, 0 pour les autres Requêtes de verrous/seconde 97000 Recherche de pages/seconde 197010
Je suis étonné par la recherche de pages/seconde, est-ce normal ? Peut-être que d'autres infos serait intéressantes ?
