counters

Question

counters

saby

SSCommitted

Points: 1681
More actions
October 25, 2008 at 6:26 am

#127200

hi all m having an issue ...
we are having a server contains 28 gb ram ... 20 gb given to sqlserver ,x64 enterprise ,windows 2003
database size 5 GB
we are having an application which goes 100 stages ....
all the stages are same which runs a proc ...
for every 1 stage took 5 mins after 35 stages the time increased and after 70 stages it is taking 35 mins wen i 1st checked the counters
total target memory and Target server Memory wer same and
then after stage 35 total target memory was less then Target server Memory
disk IO is not increasing as it was increasing cpu utilization is normal 14 %
buffer cache hit ratio is 99.20 and cache hit ratio is avg 55 % for 35 the stages after 35 it increased to more than 70 %.
wen using who2 active it shows cpu 463781disk IO 406
Please provide me the solution i m not getin what exactly the reason is...

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply

Steve Jones - SSC Editor SSC Guru Points: 734418 More actions · Answer 1

It's hard to get you something to do because there isn't enough information here. The low cahce hit ratio makes me wonder if your data is significantly diverse that you can't cache enough. If you watch the execution plans for the states, are they all the same? What is the difference in the stages?

Jeff Moden SSC Guru Points: 1003853 More actions · Answer 2

It sounds like you're passing each stage as a parameter and that you're looping through each stage. It sounds like each stage may be different enough where you are actually experiencing a phenomenon known as "parameter sniffing" whereby the previous set of parameters setup a particular execution plan that is no good for the current parameter.

It's too long to list here... search for "parameter sniff" on the web for more info.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

saby SSCommitted Points: 1681 More actions · Answer 3

the only difference in the stages is stage 1 wil calulate for stage 1 and after the 1st stage gets fully completed it will go to the next stage and soo on .....

but i dnt no y disk IO is not increasing so much after 35 stages and cache hit ratio is dam low ...

may i know wat can be the reason for cache hit ratio

saby SSCommitted Points: 1681 More actions · Answer 4

saby

SSCommitted

Points: 1681

October 27, 2008 at 5:45 am

#889912

waiting for the reply.

Jeff Moden SSC Guru Points: 1003853 More actions · Answer 5

Heh... me too... as previously stated, there's just not enough info to help here.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Jeff Moden SSC Guru Points: 1003853 More actions · Answer 6

Have you looked in "parameter sniffing" like I suggested above?

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

saby SSCommitted Points: 1681 More actions · Answer 7

jeff the prob is even if i m running on 1 stage at a time my IO is slowly increasing and cache hit ratio is below 60 % there where some query which wer using doing table scan that has been sorted on...