Extent lock time out

Bonjour,

D'après ce que je comprend les évènements lock timeout provienne d'une trace
profiler.
Ce qui se passe visiblement :
à partir d'un certain volume d'insertion/suppression il n'y a plus de place
libre dans les pages pour insérer de nouvelles lignes, on en alloue des
nouvelles, l'allocation de nouvelles page se fait par extent, tout le monde
veut s'allouer de nouveau extent, il y a potentiellement un risque de
saturation/contention.
Pourquoi on alloue de nouvelles pages plutôt que de réutiliser celles où il
y a de la place puisqu'on fait des suppressions:
un DELETE ne déclenche pas la suppression physique de la ligne
immédiatement, mais marque la ligne comme "ghostée", c'est le process
(interne à SQL Server) de ghost cleanup qui se chargera en différé de
supprimer physiquement la ligne et de mettre à jour les pages PFS (page free
space) qui tiennent à jour le taux d'utilisation. Ce process peut être mis
en attente parce que des pages sont lockées (du fait des insert et delete).
A partir d'un seuil de charge le ghost cleaup risque d'avoir du travail en
retard (backlog) et donc toute nouvelle insertion necessite un nouvel extent
et donc contention à ce niveau.

Un select * from sysprocesses au moment du problème, et un coup d'oeil aux
colonnes waittype et lastwaittype
(c.f.http://support.microsoft.com/default.aspx?scid=kb;en-us;822101 pour
info) peuvent aider à déterminer où est la contention. S'il y a du
lastwaittype/waittype WRITELOG ou PAGEIOLATCH c'est de la contention
physique, sinon (LATCH ou PAGELATCH) il y a des chances que l'on soit
simplement aux limites du système.

Un select * from ::fn_virtualfilestats(db_id, -1) peut mettre rapidement en
évidence une contention sur un fichier particulier, voir IOStallMS.

Si la machine est plus rapide alors on repousse cette limite, mais on risque
d'en rencontrer une nouvelle, celle des disques.

Une question plus générale : quel est la justification d'INSERT/DELETE en
boucle, les DELETE se font soit de manière ponctuelle (correction
d'utilisateurs), soit de manière massive (batch de purge typiquement).


Cordialement,
LionelP



"HERVY Bruno" <anonymous@discussions.microsoft.com> wrote in message
news:89c701c3e995$27d427c0$a501280a@phx.gbl...
Bonjour,
A l'occasion d'une prestation pour un client, nous
réussissons à faire fonctionner le bench avec une charge
de 2500 utilisateurs de façon satisfaisante (1500
transactions par seconde). Lorsque que nous poursuivons
la montée en charge (la cible est de 5000) les temps de
réponse s'écroule et l'application devient inaccessible
en l'espace de quelques secondes. En auditant la base
nous avons constaté une avalanche subite de lock_timeout
de type Extend sur une table où nous réalisons uniquement
des Insert et des Delete (200 insert et 200 delete par
seconde) et à chaque insert correspond un delete. Pour
quelles raisons SQL utilise t-il des locks Extend et non
des locks Row, qui nous sembleraient plus approprié pour
ce type d'opérations ? Les locks sur les autres tables ne
sont pas excessifs.
Nous avons de même constater qu'entre le moment où nous
insérions une ligne dans cette table et celui où nous
souhaitions la supprimer, il fallait un certain délai.
Ainsi l'utilisation d'un compteur de 1 à 32000 et
bouclant nous générait des violations de clés au bout de
quelques minutes. Il a fallut utiliser un compteur sur un
million, pour ne plus rencontrer le problème.

Nous rencontrons aussi occasionnellement des messages
d'erreur 1229 en rafale lors du blocage de SQL.

Par avance merci pour vos réponses

En réponse à votre sur la raison du bien fondé des
delete, nous effectuons ces tests avec une application
fournie par le client, nous ne sommes donc pas maitre de
la situation. Ces Insert et Delete permettent de
contrôler le bon déroulement d'une transaction plus
importante.
Nous avons regardé les tables que vous m'aviez indiqué.
Nous avons du Writelog puis de façon assez rapide, à
partir du moment ou nous arrivons à 1000 utilsateurs, des
Pagelatch. Ces derniers arrivent trés rapidement en même
temps que les ExtendTIme out.

Quels seraient d'aprés vous les moyens au niveau SQL ou
de l'application qui permettrait de retarder ce
changement de situation? SQL est sur une machine Octopro
IA64 avec 16 Go de RAM et nous sommes trés étonné du peu
de performances que nous pouvons en tirer.

Que représentent réélement les IOStallMS ? Nous avons
deux fichiers sur lesquels nous avons uniquement des
accés en lecture alors que nous réalisons aussi des
updates dans les tables qu'ils contiennent. Le changement
de raid influe sur les résultats retournés, nous en avons
donc déduit qu'il subsiste un rapport avec les IO
physiques mais bon ??? D'autre part, la base de données
que nous avons fait 3 Go environ et le serveur en dispose
de 16, alors pourquoi des IO disques en nombre et en
lecture ?
Merci.

-----Message d'origine-----
Bonjour,

D'après ce que je comprend les évènements lock timeout

provienne d'une trace

profiler.
Ce qui se passe visiblement :
à partir d'un certain volume d'insertion/suppression il

n'y a plus de place

libre dans les pages pour insérer de nouvelles lignes,

on en alloue des

nouvelles, l'allocation de nouvelles page se fait par

extent, tout le monde

veut s'allouer de nouveau extent, il y a potentiellement

un risque de

saturation/contention.
Pourquoi on alloue de nouvelles pages plutôt que de

réutiliser celles où il

y a de la place puisqu'on fait des suppressions:
un DELETE ne déclenche pas la suppression physique de la

ligne

immédiatement, mais marque la ligne comme "ghostée",

c'est le process

(interne à SQL Server) de ghost cleanup qui se chargera

en différé de

supprimer physiquement la ligne et de mettre à jour les

pages PFS (page free

space) qui tiennent à jour le taux d'utilisation. Ce

process peut être mis

en attente parce que des pages sont lockées (du fait des

insert et delete).

A partir d'un seuil de charge le ghost cleaup risque

d'avoir du travail en

retard (backlog) et donc toute nouvelle insertion

necessite un nouvel extent

et donc contention à ce niveau.

Un select * from sysprocesses au moment du problème, et

un coup d'oeil aux

colonnes waittype et lastwaittype
(c.f.http://support.microsoft.com/default.aspx?

scid=kb;en-us;822101 pour

info) peuvent aider à déterminer où est la contention.

S'il y a du

lastwaittype/waittype WRITELOG ou PAGEIOLATCH c'est de

la contention

physique, sinon (LATCH ou PAGELATCH) il y a des chances

que l'on soit

simplement aux limites du système.

Un select * from ::fn_virtualfilestats(db_id, -1) peut

mettre rapidement en

évidence une contention sur un fichier particulier, voir

IOStallMS.

Si la machine est plus rapide alors on repousse cette

limite, mais on risque

d'en rencontrer une nouvelle, celle des disques.

Une question plus générale : quel est la justification

d'INSERT/DELETE en

boucle, les DELETE se font soit de manière ponctuelle

(correction

d'utilisateurs), soit de manière massive (batch de purge

typiquement).

Cordialement,
LionelP



"HERVY Bruno" <anonymous@discussions.microsoft.com>

wrote in message

news:89c701c3e995$27d427c0$a501280a@phx.gbl...
Bonjour,
A l'occasion d'une prestation pour un client, nous
réussissons à faire fonctionner le bench avec une charge
de 2500 utilisateurs de façon satisfaisante (1500
transactions par seconde). Lorsque que nous poursuivons
la montée en charge (la cible est de 5000) les temps de
réponse s'écroule et l'application devient inaccessible
en l'espace de quelques secondes. En auditant la base
nous avons constaté une avalanche subite de lock_timeout
de type Extend sur une table où nous réalisons uniquement
des Insert et des Delete (200 insert et 200 delete par
seconde) et à chaque insert correspond un delete. Pour
quelles raisons SQL utilise t-il des locks Extend et non
des locks Row, qui nous sembleraient plus approprié pour
ce type d'opérations ? Les locks sur les autres tables ne
sont pas excessifs.
Nous avons de même constater qu'entre le moment où nous
insérions une ligne dans cette table et celui où nous
souhaitions la supprimer, il fallait un certain délai.
Ainsi l'utilisation d'un compteur de 1 à 32000 et
bouclant nous générait des violations de clés au bout de
quelques minutes. Il a fallut utiliser un compteur sur un
million, pour ne plus rencontrer le problème.

Nous rencontrons aussi occasionnellement des messages
d'erreur 1229 en rafale lors du blocage de SQL.

Par avance merci pour vos réponses


.

Bonsoir,

Les Writelog indiquent qu'on écrit les transactions sur disque, quand c'est
fini, la prochaine lecture de ces données se fera via le disque d'ou le
pagelatch.
IOStallMS : c'est dans les books on line, c'est le temps pour qu'un IO soit
fait, par data file ==> permet de voir lequel est le plus lent.

Si on fait des INSERT/DELETE on fait travailler le sous-système disque et
peu la mémoire et donc peu (ou mal) le cache SQL Server, à ce niveau on peut
avoir des surprises quant aux performance en fonction de la taille des IO.
Sur certains tests type insert en boucle on peut avoir de meilleures
performances sur une machine de bureau avec des disques IDE qu'avec un gros
multipro avec des gigas de RAM et une baie SAN.

Il faut utiliser les compteurs perfmon (log bytes flushed/sec et log bytes
read read/sec entre autre, les compteurs physical disks, current disk queue
length), utiliser iometer en faisant des test d'IO (petits blocs genre 512o,
puis 1Ko, 8Ko et 64Ko tout en 100% écriture) afin de calibrer la baie.


Cordialement,
LionelP


"bruno.hervy@bull.net" <anonymous@discussions.microsoft.com> wrote in
message news:8cc501c3ea58$9a9762e0$a301280a@phx.gbl...
En réponse à votre sur la raison du bien fondé des
delete, nous effectuons ces tests avec une application
fournie par le client, nous ne sommes donc pas maitre de
la situation. Ces Insert et Delete permettent de
contrôler le bon déroulement d'une transaction plus
importante.
Nous avons regardé les tables que vous m'aviez indiqué.
Nous avons du Writelog puis de façon assez rapide, à
partir du moment ou nous arrivons à 1000 utilsateurs, des
Pagelatch. Ces derniers arrivent trés rapidement en même
temps que les ExtendTIme out.

Quels seraient d'aprés vous les moyens au niveau SQL ou
de l'application qui permettrait de retarder ce
changement de situation? SQL est sur une machine Octopro
IA64 avec 16 Go de RAM et nous sommes trés étonné du peu
de performances que nous pouvons en tirer.

Que représentent réélement les IOStallMS ? Nous avons
deux fichiers sur lesquels nous avons uniquement des
accés en lecture alors que nous réalisons aussi des
updates dans les tables qu'ils contiennent. Le changement
de raid influe sur les résultats retournés, nous en avons
donc déduit qu'il subsiste un rapport avec les IO
physiques mais bon ??? D'autre part, la base de données
que nous avons fait 3 Go environ et le serveur en dispose
de 16, alors pourquoi des IO disques en nombre et en
lecture ?
Merci.

-----Message d'origine-----
Bonjour,

D'après ce que je comprend les évènements lock timeout

provienne d'une trace

profiler.
Ce qui se passe visiblement :
à partir d'un certain volume d'insertion/suppression il

n'y a plus de place

libre dans les pages pour insérer de nouvelles lignes,

on en alloue des

nouvelles, l'allocation de nouvelles page se fait par

extent, tout le monde

veut s'allouer de nouveau extent, il y a potentiellement

un risque de

saturation/contention.
Pourquoi on alloue de nouvelles pages plutôt que de

réutiliser celles où il

y a de la place puisqu'on fait des suppressions:
un DELETE ne déclenche pas la suppression physique de la

ligne

immédiatement, mais marque la ligne comme "ghostée",

c'est le process

(interne à SQL Server) de ghost cleanup qui se chargera

en différé de

supprimer physiquement la ligne et de mettre à jour les

pages PFS (page free

space) qui tiennent à jour le taux d'utilisation. Ce

process peut être mis

en attente parce que des pages sont lockées (du fait des

insert et delete).

A partir d'un seuil de charge le ghost cleaup risque

d'avoir du travail en

retard (backlog) et donc toute nouvelle insertion

necessite un nouvel extent

et donc contention à ce niveau.

Un select * from sysprocesses au moment du problème, et

un coup d'oeil aux

colonnes waittype et lastwaittype
(c.f.http://support.microsoft.com/default.aspx?

scid=kb;en-us;822101 pour

info) peuvent aider à déterminer où est la contention.

S'il y a du

lastwaittype/waittype WRITELOG ou PAGEIOLATCH c'est de

la contention

physique, sinon (LATCH ou PAGELATCH) il y a des chances

que l'on soit

simplement aux limites du système.

Un select * from ::fn_virtualfilestats(db_id, -1) peut

mettre rapidement en

évidence une contention sur un fichier particulier, voir

IOStallMS.

Si la machine est plus rapide alors on repousse cette

limite, mais on risque

d'en rencontrer une nouvelle, celle des disques.

Une question plus générale : quel est la justification

d'INSERT/DELETE en

boucle, les DELETE se font soit de manière ponctuelle

(correction

d'utilisateurs), soit de manière massive (batch de purge

typiquement).

Cordialement,
LionelP



"HERVY Bruno" <anonymous@discussions.microsoft.com>

wrote in message

news:89c701c3e995$27d427c0$a501280a@phx.gbl...
Bonjour,
A l'occasion d'une prestation pour un client, nous
réussissons à faire fonctionner le bench avec une charge
de 2500 utilisateurs de façon satisfaisante (1500
transactions par seconde). Lorsque que nous poursuivons
la montée en charge (la cible est de 5000) les temps de
réponse s'écroule et l'application devient inaccessible
en l'espace de quelques secondes. En auditant la base
nous avons constaté une avalanche subite de lock_timeout
de type Extend sur une table où nous réalisons uniquement
des Insert et des Delete (200 insert et 200 delete par
seconde) et à chaque insert correspond un delete. Pour
quelles raisons SQL utilise t-il des locks Extend et non
des locks Row, qui nous sembleraient plus approprié pour
ce type d'opérations ? Les locks sur les autres tables ne
sont pas excessifs.
Nous avons de même constater qu'entre le moment où nous
insérions une ligne dans cette table et celui où nous
souhaitions la supprimer, il fallait un certain délai.
Ainsi l'utilisation d'un compteur de 1 à 32000 et
bouclant nous générait des violations de clés au bout de
quelques minutes. Il a fallut utiliser un compteur sur un
million, pour ne plus rencontrer le problème.

Nous rencontrons aussi occasionnellement des messages
d'erreur 1229 en rafale lors du blocage de SQL.

Par avance merci pour vos réponses


.

Merci beaucoup pour votre reponse. Nous avions deja
regarde les disques mais comme leur sollicitation ne
depassait pas 30% et que les files d'attentes en L/E
etaient largement inferieur a 1, nous n'avions pas
investigue plus loin. Nous avons d'ailleurs constate auen
augmemtant le nombre de fichiers sur un memes axes, les
performances etaient tout de meme accrues sensiblement. La
multiplication des axes etant plus judicieuse.
Le fait de "pintable" les tables sollicitees aurait-il un
impact positif sur les perfs des IO? Quels en seraient les
inconvenients ?
Merci et bonne journee.

-----Message d'origine-----
Bonsoir,

Les Writelog indiquent qu'on écrit les transactions sur

disque, quand c'est

fini, la prochaine lecture de ces données se fera via le

disque d'ou le

pagelatch.
IOStallMS : c'est dans les books on line, c'est le temps

pour qu'un IO soit

fait, par data file ==> permet de voir lequel est le plus

lent.

Si on fait des INSERT/DELETE on fait travailler le sous-

système disque et

peu la mémoire et donc peu (ou mal) le cache SQL Server,

à ce niveau on peut

avoir des surprises quant aux performance en fonction de

la taille des IO.

Sur certains tests type insert en boucle on peut avoir de

meilleures

performances sur une machine de bureau avec des disques

IDE qu'avec un gros

multipro avec des gigas de RAM et une baie SAN.

Il faut utiliser les compteurs perfmon (log bytes

flushed/sec et log bytes

read read/sec entre autre, les compteurs physical disks,

current disk queue

length), utiliser iometer en faisant des test d'IO

(petits blocs genre 512o,

puis 1Ko, 8Ko et 64Ko tout en 100% écriture) afin de

calibrer la baie.

Cordialement,
LionelP


"bruno.hervy@bull.net"

<anonymous@discussions.microsoft.com> wrote in

message news:8cc501c3ea58$9a9762e0$a301280a@phx.gbl...
En réponse à votre sur la raison du bien fondé des
delete, nous effectuons ces tests avec une application
fournie par le client, nous ne sommes donc pas maitre de
la situation. Ces Insert et Delete permettent de
contrôler le bon déroulement d'une transaction plus
importante.
Nous avons regardé les tables que vous m'aviez indiqué.
Nous avons du Writelog puis de façon assez rapide, à
partir du moment ou nous arrivons à 1000 utilsateurs, des
Pagelatch. Ces derniers arrivent trés rapidement en même
temps que les ExtendTIme out.

Quels seraient d'aprés vous les moyens au niveau SQL ou
de l'application qui permettrait de retarder ce
changement de situation? SQL est sur une machine Octopro
IA64 avec 16 Go de RAM et nous sommes trés étonné du peu
de performances que nous pouvons en tirer.

Que représentent réélement les IOStallMS ? Nous avons
deux fichiers sur lesquels nous avons uniquement des
accés en lecture alors que nous réalisons aussi des
updates dans les tables qu'ils contiennent. Le changement
de raid influe sur les résultats retournés, nous en avons
donc déduit qu'il subsiste un rapport avec les IO
physiques mais bon ??? D'autre part, la base de données
que nous avons fait 3 Go environ et le serveur en dispose
de 16, alors pourquoi des IO disques en nombre et en
lecture ?
Merci.

-----Message d'origine-----
Bonjour,

D'après ce que je comprend les évènements lock timeout

provienne d'une trace

profiler.
Ce qui se passe visiblement :
à partir d'un certain volume d'insertion/suppression il

n'y a plus de place

libre dans les pages pour insérer de nouvelles lignes,

on en alloue des

nouvelles, l'allocation de nouvelles page se fait par

extent, tout le monde

veut s'allouer de nouveau extent, il y a potentiellement

un risque de

saturation/contention.
Pourquoi on alloue de nouvelles pages plutôt que de

réutiliser celles où il

y a de la place puisqu'on fait des suppressions:
un DELETE ne déclenche pas la suppression physique de la

ligne

immédiatement, mais marque la ligne comme "ghostée",

c'est le process

(interne à SQL Server) de ghost cleanup qui se chargera

en différé de

supprimer physiquement la ligne et de mettre à jour les

pages PFS (page free

space) qui tiennent à jour le taux d'utilisation. Ce

process peut être mis

en attente parce que des pages sont lockées (du fait des

insert et delete).

A partir d'un seuil de charge le ghost cleaup risque

d'avoir du travail en

retard (backlog) et donc toute nouvelle insertion

necessite un nouvel extent

et donc contention à ce niveau.

Un select * from sysprocesses au moment du problème, et

un coup d'oeil aux

colonnes waittype et lastwaittype
(c.f.http://support.microsoft.com/default.aspx?

scid=kb;en-us;822101 pour

info) peuvent aider à déterminer où est la contention.

S'il y a du

lastwaittype/waittype WRITELOG ou PAGEIOLATCH c'est de

la contention

physique, sinon (LATCH ou PAGELATCH) il y a des chances

que l'on soit

simplement aux limites du système.

Un select * from ::fn_virtualfilestats(db_id, -1) peut

mettre rapidement en

évidence une contention sur un fichier particulier, voir

IOStallMS.

Si la machine est plus rapide alors on repousse cette

limite, mais on risque

d'en rencontrer une nouvelle, celle des disques.

Une question plus générale : quel est la justification

d'INSERT/DELETE en

boucle, les DELETE se font soit de manière ponctuelle

(correction

d'utilisateurs), soit de manière massive (batch de purge

typiquement).

Cordialement,
LionelP



"HERVY Bruno" <anonymous@discussions.microsoft.com>

wrote in message

news:89c701c3e995$27d427c0$a501280a@phx.gbl...
Bonjour,
A l'occasion d'une prestation pour un client, nous
réussissons à faire fonctionner le bench avec une charge
de 2500 utilisateurs de façon satisfaisante (1500
transactions par seconde). Lorsque que nous poursuivons
la montée en charge (la cible est de 5000) les temps de
réponse s'écroule et l'application devient inaccessible
en l'espace de quelques secondes. En auditant la base
nous avons constaté une avalanche subite de lock_timeout
de type Extend sur une table où nous réalisons uniquement
des Insert et des Delete (200 insert et 200 delete par
seconde) et à chaque insert correspond un delete. Pour
quelles raisons SQL utilise t-il des locks Extend et non
des locks Row, qui nous sembleraient plus approprié pour
ce type d'opérations ? Les locks sur les autres tables ne
sont pas excessifs.
Nous avons de même constater qu'entre le moment où nous
insérions une ligne dans cette table et celui où nous
souhaitions la supprimer, il fallait un certain délai.
Ainsi l'utilisation d'un compteur de 1 à 32000 et
bouclant nous générait des violations de clés au bout de
quelques minutes. Il a fallut utiliser un compteur sur un
million, pour ne plus rencontrer le problème.

Nous rencontrons aussi occasionnellement des messages
d'erreur 1229 en rafale lors du blocage de SQL.

Par avance merci pour vos réponses


.

.

Bonjour,


a priori l'option pintable n'est pas intéressante parce qu'elle verrouille
des pages de données en cache inutilement : des pages que plus personne
n'accède, car tant qu'une page est sollicitée elle reste en cache, bien sûr,
la modification de celle-ci implique qu'elle est vidée sur disque d'où un
nouvel accès disque que pintable n'évitera pas. C'est une option piège, on
l'oublie, la table grossit, on a des pb de mémoire et avant de se rappeler
qu'on a pintable sur une table de quelques M d'enregistrement...
ceci étant dit ça ne coute rien de faire le test.

Ce qui peut être testé également c'est le ou les log de la base les mettre
sur une unité/axe paramétrée pour favoriser les petits IO, une écriture dans
le journal c'est de taille variable de 50o (au minimum de mémoire) jusqu'à
quelques Ko.

Vérifier de temps à autres (après chaque modif) via fn_virtualfilestats sur
quels fichiers on a du gain, on perd, les perfs ne changes pas.

S'assurer qu'il n'y a pas d'autogrow ou autoshrink qui rallentit ou bloque.

Si on simule 1000 clients, avec ou sans "connection pooling" ça change
quelque chose.


Cordialement,
LionelP


"bruno.hervy" <anonymous@discussions.microsoft.com> wrote in message
news:9e0601c3eaf1$bacad9e0$a401280a@phx.gbl...
Merci beaucoup pour votre reponse. Nous avions deja
regarde les disques mais comme leur sollicitation ne
depassait pas 30% et que les files d'attentes en L/E
etaient largement inferieur a 1, nous n'avions pas
investigue plus loin. Nous avons d'ailleurs constate auen
augmemtant le nombre de fichiers sur un memes axes, les
performances etaient tout de meme accrues sensiblement. La
multiplication des axes etant plus judicieuse.
Le fait de "pintable" les tables sollicitees aurait-il un
impact positif sur les perfs des IO? Quels en seraient les
inconvenients ?
Merci et bonne journee.

-----Message d'origine-----
Bonsoir,

Les Writelog indiquent qu'on écrit les transactions sur

disque, quand c'est

fini, la prochaine lecture de ces données se fera via le

disque d'ou le

pagelatch.
IOStallMS : c'est dans les books on line, c'est le temps

pour qu'un IO soit

fait, par data file ==> permet de voir lequel est le plus

lent.

Si on fait des INSERT/DELETE on fait travailler le sous-

système disque et

peu la mémoire et donc peu (ou mal) le cache SQL Server,

à ce niveau on peut

avoir des surprises quant aux performance en fonction de

la taille des IO.

Sur certains tests type insert en boucle on peut avoir de

meilleures

performances sur une machine de bureau avec des disques

IDE qu'avec un gros

multipro avec des gigas de RAM et une baie SAN.

Il faut utiliser les compteurs perfmon (log bytes

flushed/sec et log bytes

read read/sec entre autre, les compteurs physical disks,

current disk queue

length), utiliser iometer en faisant des test d'IO

(petits blocs genre 512o,

puis 1Ko, 8Ko et 64Ko tout en 100% écriture) afin de

calibrer la baie.

Cordialement,
LionelP


"bruno.hervy@bull.net"

<anonymous@discussions.microsoft.com> wrote in

message news:8cc501c3ea58$9a9762e0$a301280a@phx.gbl...
En réponse à votre sur la raison du bien fondé des
delete, nous effectuons ces tests avec une application
fournie par le client, nous ne sommes donc pas maitre de
la situation. Ces Insert et Delete permettent de
contrôler le bon déroulement d'une transaction plus
importante.
Nous avons regardé les tables que vous m'aviez indiqué.
Nous avons du Writelog puis de façon assez rapide, à
partir du moment ou nous arrivons à 1000 utilsateurs, des
Pagelatch. Ces derniers arrivent trés rapidement en même
temps que les ExtendTIme out.

Quels seraient d'aprés vous les moyens au niveau SQL ou
de l'application qui permettrait de retarder ce
changement de situation? SQL est sur une machine Octopro
IA64 avec 16 Go de RAM et nous sommes trés étonné du peu
de performances que nous pouvons en tirer.

Que représentent réélement les IOStallMS ? Nous avons
deux fichiers sur lesquels nous avons uniquement des
accés en lecture alors que nous réalisons aussi des
updates dans les tables qu'ils contiennent. Le changement
de raid influe sur les résultats retournés, nous en avons
donc déduit qu'il subsiste un rapport avec les IO
physiques mais bon ??? D'autre part, la base de données
que nous avons fait 3 Go environ et le serveur en dispose
de 16, alors pourquoi des IO disques en nombre et en
lecture ?
Merci.

-----Message d'origine-----
Bonjour,

D'après ce que je comprend les évènements lock timeout

provienne d'une trace

profiler.
Ce qui se passe visiblement :
à partir d'un certain volume d'insertion/suppression il

n'y a plus de place

libre dans les pages pour insérer de nouvelles lignes,

on en alloue des

nouvelles, l'allocation de nouvelles page se fait par

extent, tout le monde

veut s'allouer de nouveau extent, il y a potentiellement

un risque de

saturation/contention.
Pourquoi on alloue de nouvelles pages plutôt que de

réutiliser celles où il

y a de la place puisqu'on fait des suppressions:
un DELETE ne déclenche pas la suppression physique de la

ligne

immédiatement, mais marque la ligne comme "ghostée",

c'est le process

(interne à SQL Server) de ghost cleanup qui se chargera

en différé de

supprimer physiquement la ligne et de mettre à jour les

pages PFS (page free

space) qui tiennent à jour le taux d'utilisation. Ce

process peut être mis

en attente parce que des pages sont lockées (du fait des

insert et delete).

A partir d'un seuil de charge le ghost cleaup risque

d'avoir du travail en

retard (backlog) et donc toute nouvelle insertion

necessite un nouvel extent

et donc contention à ce niveau.

Un select * from sysprocesses au moment du problème, et

un coup d'oeil aux

colonnes waittype et lastwaittype
(c.f.http://support.microsoft.com/default.aspx?

scid=kb;en-us;822101 pour

info) peuvent aider à déterminer où est la contention.

S'il y a du

lastwaittype/waittype WRITELOG ou PAGEIOLATCH c'est de

la contention

physique, sinon (LATCH ou PAGELATCH) il y a des chances

que l'on soit

simplement aux limites du système.

Un select * from ::fn_virtualfilestats(db_id, -1) peut

mettre rapidement en

évidence une contention sur un fichier particulier, voir

IOStallMS.

Si la machine est plus rapide alors on repousse cette

limite, mais on risque

d'en rencontrer une nouvelle, celle des disques.

Une question plus générale : quel est la justification

d'INSERT/DELETE en

boucle, les DELETE se font soit de manière ponctuelle

(correction

d'utilisateurs), soit de manière massive (batch de purge

typiquement).

Cordialement,
LionelP



"HERVY Bruno" <anonymous@discussions.microsoft.com>

wrote in message

news:89c701c3e995$27d427c0$a501280a@phx.gbl...
Bonjour,
A l'occasion d'une prestation pour un client, nous
réussissons à faire fonctionner le bench avec une charge
de 2500 utilisateurs de façon satisfaisante (1500
transactions par seconde). Lorsque que nous poursuivons
la montée en charge (la cible est de 5000) les temps de
réponse s'écroule et l'application devient inaccessible
en l'espace de quelques secondes. En auditant la base
nous avons constaté une avalanche subite de lock_timeout
de type Extend sur une table où nous réalisons uniquement
des Insert et des Delete (200 insert et 200 delete par
seconde) et à chaque insert correspond un delete. Pour
quelles raisons SQL utilise t-il des locks Extend et non
des locks Row, qui nous sembleraient plus approprié pour
ce type d'opérations ? Les locks sur les autres tables ne
sont pas excessifs.
Nous avons de même constater qu'entre le moment où nous
insérions une ligne dans cette table et celui où nous
souhaitions la supprimer, il fallait un certain délai.
Ainsi l'utilisation d'un compteur de 1 à 32000 et
bouclant nous générait des violations de clés au bout de
quelques minutes. Il a fallut utiliser un compteur sur un
million, pour ne plus rencontrer le problème.

Nous rencontrons aussi occasionnellement des messages
d'erreur 1229 en rafale lors du blocage de SQL.

Par avance merci pour vos réponses


.

.