We have a series of SPs, poorly written, but that's not the issue here.
Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
(Dev), dual P3, 2gig ram. Pretty much just DB servers.
But we've even tried the local Dasd on the Prod (Std) box.
The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
even everything on a single RAID drive. Prod at least has db and log
separate, more at times.
We've checked everything, and can't find any differences. Running on Prod
Off hours when it's not even breaking a sweat.
The proc does nothing special, except a cursor for Update (Ooouugghh).
Any ideas what to look at ? We compared everything we can think of, no
differences SQL, Win2000... No errors in the event log ..., Query plans
match even cost estimates.
Could Developer (which is Enterprise, right) provide that much boost vs.
Std, even with nothing, that I know of that would be using EE features.
Note to date everything I've wrritten, even some larger procs (10 to 20
million row processes) seem to run as expected. Slightly faster on Prod.
KlK, MCSE
Hi
As a good benchmark, run the SQL IO stress tools on your Dev and Production
server. It will indicate if your SAN is considerably slower than the local
drives.
Look at the links off http://msmvps.com/epprecht/archive/2.../24/10591.aspx
EE does have some performance enhancements over standard (pre-fetch) but the
Disk might be your issue.
Regards
Mike
"KevinK" wrote:
> We have a series of SPs, poorly written, but that's not the issue here.
> Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
> (Dev), dual P3, 2gig ram. Pretty much just DB servers.
> But we've even tried the local Dasd on the Prod (Std) box.
> The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
> even everything on a single RAID drive. Prod at least has db and log
> separate, more at times.
> We've checked everything, and can't find any differences. Running on Prod
> Off hours when it's not even breaking a sweat.
> The proc does nothing special, except a cursor for Update (Ooouugghh).
> Any ideas what to look at ? We compared everything we can think of, no
> differences SQL, Win2000... No errors in the event log ..., Query plans
> match even cost estimates.
> Could Developer (which is Enterprise, right) provide that much boost vs.
> Std, even with nothing, that I know of that would be using EE features.
> Note to date everything I've wrritten, even some larger procs (10 to 20
> million row processes) seem to run as expected. Slightly faster on Prod.
>
> --
> KlK, MCSE
|||Thanks Mike, unfortunately we have tested it using only the local drive on
Prod.
We have a 70gig local raid drive that is normally used for Backups etc.
It didn't help.
We do know the SAN drives are slower than locals, but it isn't that
significant, maybe 20% (I think 12 to 15 was the official number.
But when we run it on the SAN we are using multiple drives, log and data.
I am trying to get them to do a DBHammer
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> As a good benchmark, run the SQL IO stress tools on your Dev and Production
> server. It will indicate if your SAN is considerably slower than the local
> drives.
> Look at the links off http://msmvps.com/epprecht/archive/2.../24/10591.aspx
> EE does have some performance enhancements over standard (pre-fetch) but the
> Disk might be your issue.
> Regards
> Mike
> "KevinK" wrote:
Showing posts with label san. Show all posts
Showing posts with label san. Show all posts
Monday, March 26, 2012
Performance Developer vs. Std
We have a series of SPs, poorly written, but that's not the issue here.
Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
(Dev), dual P3, 2gig ram. Pretty much just DB servers.
But we've even tried the local Dasd on the Prod (Std) box.
The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
even everything on a single RAID drive. Prod at least has db and log
separate, more at times.
We've checked everything, and can't find any differences. Running on Prod
Off hours when it's not even breaking a sweat.
The proc does nothing special, except a cursor for Update (Ooouugghh).
Any ideas what to look at ' We compared everything we can think of, no
differences SQL, Win2000... No errors in the event log ..., Query plans
match even cost estimates.
Could Developer (which is Enterprise, right) provide that much boost vs.
Std, even with nothing, that I know of that would be using EE features.
Note to date everything I've wrritten, even some larger procs (10 to 20
million row processes) seem to run as expected. Slightly faster on Prod.
--
KlK, MCSEHi
As a good benchmark, run the SQL IO stress tools on your Dev and Production
server. It will indicate if your SAN is considerably slower than the local
drives.
Look at the links off http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx
EE does have some performance enhancements over standard (pre-fetch) but the
Disk might be your issue.
Regards
Mike
"KevinK" wrote:
> We have a series of SPs, poorly written, but that's not the issue here.
> Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
> (Dev), dual P3, 2gig ram. Pretty much just DB servers.
> But we've even tried the local Dasd on the Prod (Std) box.
> The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
> even everything on a single RAID drive. Prod at least has db and log
> separate, more at times.
> We've checked everything, and can't find any differences. Running on Prod
> Off hours when it's not even breaking a sweat.
> The proc does nothing special, except a cursor for Update (Ooouugghh).
> Any ideas what to look at ' We compared everything we can think of, no
> differences SQL, Win2000... No errors in the event log ..., Query plans
> match even cost estimates.
> Could Developer (which is Enterprise, right) provide that much boost vs.
> Std, even with nothing, that I know of that would be using EE features.
> Note to date everything I've wrritten, even some larger procs (10 to 20
> million row processes) seem to run as expected. Slightly faster on Prod.
>
> --
> KlK, MCSE|||Thanks Mike, unfortunately we have tested it using only the local drive on
Prod.
We have a 70gig local raid drive that is normally used for Backups etc.
It didn't help.
We do know the SAN drives are slower than locals, but it isn't that
significant, maybe 20% (I think 12 to 15 was the official number.
But when we run it on the SAN we are using multiple drives, log and data.
I am trying to get them to do a DBHammer
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> As a good benchmark, run the SQL IO stress tools on your Dev and Production
> server. It will indicate if your SAN is considerably slower than the local
> drives.
> Look at the links off http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx
> EE does have some performance enhancements over standard (pre-fetch) but the
> Disk might be your issue.
> Regards
> Mike
> "KevinK" wrote:
> > We have a series of SPs, poorly written, but that's not the issue here.
> >
> > Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
> > (Dev), dual P3, 2gig ram. Pretty much just DB servers.
> >
> > But we've even tried the local Dasd on the Prod (Std) box.
> >
> > The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
> > even everything on a single RAID drive. Prod at least has db and log
> > separate, more at times.
> >
> > We've checked everything, and can't find any differences. Running on Prod
> > Off hours when it's not even breaking a sweat.
> >
> > The proc does nothing special, except a cursor for Update (Ooouugghh).
> >
> > Any ideas what to look at ' We compared everything we can think of, no
> > differences SQL, Win2000... No errors in the event log ..., Query plans
> > match even cost estimates.
> >
> > Could Developer (which is Enterprise, right) provide that much boost vs.
> > Std, even with nothing, that I know of that would be using EE features.
> >
> > Note to date everything I've wrritten, even some larger procs (10 to 20
> > million row processes) seem to run as expected. Slightly faster on Prod.
> >
> >
> >
> > --
> > KlK, MCSEsql
Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
(Dev), dual P3, 2gig ram. Pretty much just DB servers.
But we've even tried the local Dasd on the Prod (Std) box.
The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
even everything on a single RAID drive. Prod at least has db and log
separate, more at times.
We've checked everything, and can't find any differences. Running on Prod
Off hours when it's not even breaking a sweat.
The proc does nothing special, except a cursor for Update (Ooouugghh).
Any ideas what to look at ' We compared everything we can think of, no
differences SQL, Win2000... No errors in the event log ..., Query plans
match even cost estimates.
Could Developer (which is Enterprise, right) provide that much boost vs.
Std, even with nothing, that I know of that would be using EE features.
Note to date everything I've wrritten, even some larger procs (10 to 20
million row processes) seem to run as expected. Slightly faster on Prod.
--
KlK, MCSEHi
As a good benchmark, run the SQL IO stress tools on your Dev and Production
server. It will indicate if your SAN is considerably slower than the local
drives.
Look at the links off http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx
EE does have some performance enhancements over standard (pre-fetch) but the
Disk might be your issue.
Regards
Mike
"KevinK" wrote:
> We have a series of SPs, poorly written, but that's not the issue here.
> Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
> (Dev), dual P3, 2gig ram. Pretty much just DB servers.
> But we've even tried the local Dasd on the Prod (Std) box.
> The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
> even everything on a single RAID drive. Prod at least has db and log
> separate, more at times.
> We've checked everything, and can't find any differences. Running on Prod
> Off hours when it's not even breaking a sweat.
> The proc does nothing special, except a cursor for Update (Ooouugghh).
> Any ideas what to look at ' We compared everything we can think of, no
> differences SQL, Win2000... No errors in the event log ..., Query plans
> match even cost estimates.
> Could Developer (which is Enterprise, right) provide that much boost vs.
> Std, even with nothing, that I know of that would be using EE features.
> Note to date everything I've wrritten, even some larger procs (10 to 20
> million row processes) seem to run as expected. Slightly faster on Prod.
>
> --
> KlK, MCSE|||Thanks Mike, unfortunately we have tested it using only the local drive on
Prod.
We have a 70gig local raid drive that is normally used for Backups etc.
It didn't help.
We do know the SAN drives are slower than locals, but it isn't that
significant, maybe 20% (I think 12 to 15 was the official number.
But when we run it on the SAN we are using multiple drives, log and data.
I am trying to get them to do a DBHammer
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> As a good benchmark, run the SQL IO stress tools on your Dev and Production
> server. It will indicate if your SAN is considerably slower than the local
> drives.
> Look at the links off http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx
> EE does have some performance enhancements over standard (pre-fetch) but the
> Disk might be your issue.
> Regards
> Mike
> "KevinK" wrote:
> > We have a series of SPs, poorly written, but that's not the issue here.
> >
> > Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
> > (Dev), dual P3, 2gig ram. Pretty much just DB servers.
> >
> > But we've even tried the local Dasd on the Prod (Std) box.
> >
> > The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
> > even everything on a single RAID drive. Prod at least has db and log
> > separate, more at times.
> >
> > We've checked everything, and can't find any differences. Running on Prod
> > Off hours when it's not even breaking a sweat.
> >
> > The proc does nothing special, except a cursor for Update (Ooouugghh).
> >
> > Any ideas what to look at ' We compared everything we can think of, no
> > differences SQL, Win2000... No errors in the event log ..., Query plans
> > match even cost estimates.
> >
> > Could Developer (which is Enterprise, right) provide that much boost vs.
> > Std, even with nothing, that I know of that would be using EE features.
> >
> > Note to date everything I've wrritten, even some larger procs (10 to 20
> > million row processes) seem to run as expected. Slightly faster on Prod.
> >
> >
> >
> > --
> > KlK, MCSEsql
Performance Developer vs. Std
We have a series of SPs, poorly written, but that's not the issue here.
Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
(Dev), dual P3, 2gig ram. Pretty much just DB servers.
But we've even tried the local Dasd on the Prod (Std) box.
The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
even everything on a single RAID drive. Prod at least has db and log
separate, more at times.
We've checked everything, and can't find any differences. Running on Prod
Off hours when it's not even breaking a sweat.
The proc does nothing special, except a cursor for Update (Ooouugghh).
Any ideas what to look at ' We compared everything we can think of, no
differences SQL, Win2000... No errors in the event log ..., Query plans
match even cost estimates.
Could Developer (which is Enterprise, right) provide that much boost vs.
Std, even with nothing, that I know of that would be using EE features.
Note to date everything I've wrritten, even some larger procs (10 to 20
million row processes) seem to run as expected. Slightly faster on Prod.
KlK, MCSEHi
As a good benchmark, run the SQL IO stress tools on your Dev and Production
server. It will indicate if your SAN is considerably slower than the local
drives.
Look at the links off [url]http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx[/ur
l]
EE does have some performance enhancements over standard (pre-fetch) but the
Disk might be your issue.
Regards
Mike
"KevinK" wrote:
> We have a series of SPs, poorly written, but that's not the issue here.
> Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
> (Dev), dual P3, 2gig ram. Pretty much just DB servers.
> But we've even tried the local Dasd on the Prod (Std) box.
> The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
> even everything on a single RAID drive. Prod at least has db and log
> separate, more at times.
> We've checked everything, and can't find any differences. Running on Prod
> Off hours when it's not even breaking a sweat.
> The proc does nothing special, except a cursor for Update (Ooouugghh).
> Any ideas what to look at ' We compared everything we can think of, no
> differences SQL, Win2000... No errors in the event log ..., Query plans
> match even cost estimates.
> Could Developer (which is Enterprise, right) provide that much boost vs.
> Std, even with nothing, that I know of that would be using EE features.
> Note to date everything I've wrritten, even some larger procs (10 to 20
> million row processes) seem to run as expected. Slightly faster on Prod.
>
> --
> KlK, MCSE|||Thanks Mike, unfortunately we have tested it using only the local drive on
Prod.
We have a 70gig local raid drive that is normally used for Backups etc.
It didn't help.
We do know the SAN drives are slower than locals, but it isn't that
significant, maybe 20% (I think 12 to 15 was the official number.
But when we run it on the SAN we are using multiple drives, log and data.
I am trying to get them to do a DBHammer
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> As a good benchmark, run the SQL IO stress tools on your Dev and Productio
n
> server. It will indicate if your SAN is considerably slower than the local
> drives.
> Look at the links off [url]http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx[/
url]
> EE does have some performance enhancements over standard (pre-fetch) but t
he
> Disk might be your issue.
> Regards
> Mike
> "KevinK" wrote:
>
Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
(Dev), dual P3, 2gig ram. Pretty much just DB servers.
But we've even tried the local Dasd on the Prod (Std) box.
The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
even everything on a single RAID drive. Prod at least has db and log
separate, more at times.
We've checked everything, and can't find any differences. Running on Prod
Off hours when it's not even breaking a sweat.
The proc does nothing special, except a cursor for Update (Ooouugghh).
Any ideas what to look at ' We compared everything we can think of, no
differences SQL, Win2000... No errors in the event log ..., Query plans
match even cost estimates.
Could Developer (which is Enterprise, right) provide that much boost vs.
Std, even with nothing, that I know of that would be using EE features.
Note to date everything I've wrritten, even some larger procs (10 to 20
million row processes) seem to run as expected. Slightly faster on Prod.
KlK, MCSEHi
As a good benchmark, run the SQL IO stress tools on your Dev and Production
server. It will indicate if your SAN is considerably slower than the local
drives.
Look at the links off [url]http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx[/ur
l]
EE does have some performance enhancements over standard (pre-fetch) but the
Disk might be your issue.
Regards
Mike
"KevinK" wrote:
> We have a series of SPs, poorly written, but that's not the issue here.
> Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
> (Dev), dual P3, 2gig ram. Pretty much just DB servers.
> But we've even tried the local Dasd on the Prod (Std) box.
> The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
> even everything on a single RAID drive. Prod at least has db and log
> separate, more at times.
> We've checked everything, and can't find any differences. Running on Prod
> Off hours when it's not even breaking a sweat.
> The proc does nothing special, except a cursor for Update (Ooouugghh).
> Any ideas what to look at ' We compared everything we can think of, no
> differences SQL, Win2000... No errors in the event log ..., Query plans
> match even cost estimates.
> Could Developer (which is Enterprise, right) provide that much boost vs.
> Std, even with nothing, that I know of that would be using EE features.
> Note to date everything I've wrritten, even some larger procs (10 to 20
> million row processes) seem to run as expected. Slightly faster on Prod.
>
> --
> KlK, MCSE|||Thanks Mike, unfortunately we have tested it using only the local drive on
Prod.
We have a 70gig local raid drive that is normally used for Backups etc.
It didn't help.
We do know the SAN drives are slower than locals, but it isn't that
significant, maybe 20% (I think 12 to 15 was the official number.
But when we run it on the SAN we are using multiple drives, log and data.
I am trying to get them to do a DBHammer
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> As a good benchmark, run the SQL IO stress tools on your Dev and Productio
n
> server. It will indicate if your SAN is considerably slower than the local
> drives.
> Look at the links off [url]http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx[/
url]
> EE does have some performance enhancements over standard (pre-fetch) but t
he
> Disk might be your issue.
> Regards
> Mike
> "KevinK" wrote:
>
Performance degradation writing to a SAN / building a cube
Is anyone aware of performance degradation writing to a SAN over fibre optic network? We r using SQL Server 2000 (Enterprise version) with Compaq Proliant DL580 G2, writing to Compaq SAN. Is any network tuning needed? A gigabit ethernet card pushes the data over to the SAN.
Also, we r taking about 37 hours building a cube for a database barely 15GB. Database is shipped by Microsoft and is used by their product Microsoft Proect Server. So, database level tuning is out of question.
Any help would greatly be appreciated.
Thanx in advance,
BhushanYou should try the basic performance tuning practices to find out where your bottle neck is. Here are a few we use to help us troubleshoot our san...
*check CPU utilization on the sql node -- this could be caused by a lot of things
*Check disk idle time -- if your disk is below 20% idle, then you are spindle bound.
*check disk queue length. -- if the disk queue is higher than twice the number of disks in your raid array, then you have a problem. High disk queue could also be a problem with the NIC. it is possible it cant send data as fast as the cable and disks can handle it.
*check memory usage. -- if you are trying to cache everything and the pc starts paging, this will kill performance
*check your query plans (not sure if that is possible, but if it is running poorly it can make a huge difference.)
*check your network traffic between the pc and the san. are you seeing any collisions?
basically it comes down to finding the bottleneck and then fixing it.|||Originally posted by Pigeon
You should try the basic performance tuning practices to find out where your bottle neck is. Here are a few we use to help us troubleshoot our san...
*check CPU utilization on the sql node -- this could be caused by a lot of things
*Check disk idle time -- if your disk is below 20% idle, then you are spindle bound.
*check disk queue length. -- if the disk queue is higher than twice the number of disks in your raid array, then you have a problem. High disk queue could also be a problem with the NIC. it is possible it cant send data as fast as the cable and disks can handle it.
*check memory usage. -- if you are trying to cache everything and the pc starts paging, this will kill performance
*check your query plans (not sure if that is possible, but if it is running poorly it can make a huge difference.)
*check your network traffic between the pc and the san. are you seeing any collisions?
basically it comes down to finding the bottleneck and then fixing it.
Thanx a lot, Pigeon. I did check the Queue length originally; but was told by Compaq that the Queue length reported by Windows 2000 (for Compaq hardware) is not reliable for various reasons.
Anway! I personally think NIC card is slow and thats why I am seeing NETWORKIOWAIT within SQL Server. Just wanted to confirm, if I am not missing anything...
Thanx again.
- Bhushan|||The NIC can be a big bottleneck. WHat protocol does it use to send the data across the network? UDP, TCP, is it using a SCSI miniport driver (Encapsulating scsi calls into a udp or tcp packet) Many times, if this driver or protocol is not working, it will cause an increase in processor utilization, or the disk queue will be high. No matter what compaq tells you, if your queue is high, something is stopping the traffic from getting to the disk. Good Luck with it. I know these types of problems can sometimes be a real pain to find.
Also, we r taking about 37 hours building a cube for a database barely 15GB. Database is shipped by Microsoft and is used by their product Microsoft Proect Server. So, database level tuning is out of question.
Any help would greatly be appreciated.
Thanx in advance,
BhushanYou should try the basic performance tuning practices to find out where your bottle neck is. Here are a few we use to help us troubleshoot our san...
*check CPU utilization on the sql node -- this could be caused by a lot of things
*Check disk idle time -- if your disk is below 20% idle, then you are spindle bound.
*check disk queue length. -- if the disk queue is higher than twice the number of disks in your raid array, then you have a problem. High disk queue could also be a problem with the NIC. it is possible it cant send data as fast as the cable and disks can handle it.
*check memory usage. -- if you are trying to cache everything and the pc starts paging, this will kill performance
*check your query plans (not sure if that is possible, but if it is running poorly it can make a huge difference.)
*check your network traffic between the pc and the san. are you seeing any collisions?
basically it comes down to finding the bottleneck and then fixing it.|||Originally posted by Pigeon
You should try the basic performance tuning practices to find out where your bottle neck is. Here are a few we use to help us troubleshoot our san...
*check CPU utilization on the sql node -- this could be caused by a lot of things
*Check disk idle time -- if your disk is below 20% idle, then you are spindle bound.
*check disk queue length. -- if the disk queue is higher than twice the number of disks in your raid array, then you have a problem. High disk queue could also be a problem with the NIC. it is possible it cant send data as fast as the cable and disks can handle it.
*check memory usage. -- if you are trying to cache everything and the pc starts paging, this will kill performance
*check your query plans (not sure if that is possible, but if it is running poorly it can make a huge difference.)
*check your network traffic between the pc and the san. are you seeing any collisions?
basically it comes down to finding the bottleneck and then fixing it.
Thanx a lot, Pigeon. I did check the Queue length originally; but was told by Compaq that the Queue length reported by Windows 2000 (for Compaq hardware) is not reliable for various reasons.
Anway! I personally think NIC card is slow and thats why I am seeing NETWORKIOWAIT within SQL Server. Just wanted to confirm, if I am not missing anything...
Thanx again.
- Bhushan|||The NIC can be a big bottleneck. WHat protocol does it use to send the data across the network? UDP, TCP, is it using a SCSI miniport driver (Encapsulating scsi calls into a udp or tcp packet) Many times, if this driver or protocol is not working, it will cause an increase in processor utilization, or the disk queue will be high. No matter what compaq tells you, if your queue is high, something is stopping the traffic from getting to the disk. Good Luck with it. I know these types of problems can sometimes be a real pain to find.
Friday, March 23, 2012
performance counters on a SAN
Hello,
Recently we moved our database servers onto a emc cx600 san. Since
the move I ran perfmon against the server for a week to try to get a
baseline of the server's performance. I am getting some curious
metrics from perfmon on the avg. disk queue lenth and %disk time for
the data drive for the sql server database. We have the same
dedicated spindle config as we did on our former system with the
difference being the greatly increased throughput of the new system.
Avg. disk queue lenth is reporting an avg. of over 30 for lengthy
periods of time(> 10 minutes) and %disk time is reporting an avg of
over 300 around the same time . The former system was not reporting
any performance bottlenecks. I wonder if the counters are skewed
somehow. Has anyone experienced any oddities with disk related
performance counter metrics on a san or am I suddenly looking at a
disk bottleneck? Is it possible that the increased throughput to the
san is now causing a disk bottleneck?
Let me know if more details are needed.
Thanks,
GregThanks for the reply. The logical drive is a 10 spindle raid 5, so
the avg. disk queue length would be 3. If I'm not mistaken an avg.
disk queue length of 2 or more for any extended period of time would
be considered a bottleneck. Also, a % disk time of 300 seems rather
high to me as well. I am just curious if these disk counters report
accurately on a san as there weren't any bottlenecks reported on the
former system which was much slower than this system all the way
around. To my knowledge there hasn't been a substantial change in
workload to suddenly cause this.
Greg
On Tue, 12 Aug 2003 05:26:31 -0400, "Wayne Snyder"
<wsnyder@.computeredservices.com> wrote:
>Remember that disk queue lengths are for the logical drive... and to get
>*real* number you care about divide 30 by the number of physical drives
> which are likely to be a larger number in the SAN)...
>"Greg" <gjackson@.thq.com> wrote in message
>news:gjagjvgsp8ogelufmret27pdddi7vi4sh4@.4ax.com...
>> Hello,
>> Recently we moved our database servers onto a emc cx600 san. Since
>> the move I ran perfmon against the server for a week to try to get a
>> baseline of the server's performance. I am getting some curious
>> metrics from perfmon on the avg. disk queue lenth and %disk time for
>> the data drive for the sql server database. We have the same
>> dedicated spindle config as we did on our former system with the
>> difference being the greatly increased throughput of the new system.
>> Avg. disk queue lenth is reporting an avg. of over 30 for lengthy
>> periods of time(> 10 minutes) and %disk time is reporting an avg of
>> over 300 around the same time . The former system was not reporting
>> any performance bottlenecks. I wonder if the counters are skewed
>> somehow. Has anyone experienced any oddities with disk related
>> performance counter metrics on a san or am I suddenly looking at a
>> disk bottleneck? Is it possible that the increased throughput to the
>> san is now causing a disk bottleneck?
>> Let me know if more details are needed.
>> Thanks,
>> Greg
>sql
Recently we moved our database servers onto a emc cx600 san. Since
the move I ran perfmon against the server for a week to try to get a
baseline of the server's performance. I am getting some curious
metrics from perfmon on the avg. disk queue lenth and %disk time for
the data drive for the sql server database. We have the same
dedicated spindle config as we did on our former system with the
difference being the greatly increased throughput of the new system.
Avg. disk queue lenth is reporting an avg. of over 30 for lengthy
periods of time(> 10 minutes) and %disk time is reporting an avg of
over 300 around the same time . The former system was not reporting
any performance bottlenecks. I wonder if the counters are skewed
somehow. Has anyone experienced any oddities with disk related
performance counter metrics on a san or am I suddenly looking at a
disk bottleneck? Is it possible that the increased throughput to the
san is now causing a disk bottleneck?
Let me know if more details are needed.
Thanks,
GregThanks for the reply. The logical drive is a 10 spindle raid 5, so
the avg. disk queue length would be 3. If I'm not mistaken an avg.
disk queue length of 2 or more for any extended period of time would
be considered a bottleneck. Also, a % disk time of 300 seems rather
high to me as well. I am just curious if these disk counters report
accurately on a san as there weren't any bottlenecks reported on the
former system which was much slower than this system all the way
around. To my knowledge there hasn't been a substantial change in
workload to suddenly cause this.
Greg
On Tue, 12 Aug 2003 05:26:31 -0400, "Wayne Snyder"
<wsnyder@.computeredservices.com> wrote:
>Remember that disk queue lengths are for the logical drive... and to get
>*real* number you care about divide 30 by the number of physical drives
> which are likely to be a larger number in the SAN)...
>"Greg" <gjackson@.thq.com> wrote in message
>news:gjagjvgsp8ogelufmret27pdddi7vi4sh4@.4ax.com...
>> Hello,
>> Recently we moved our database servers onto a emc cx600 san. Since
>> the move I ran perfmon against the server for a week to try to get a
>> baseline of the server's performance. I am getting some curious
>> metrics from perfmon on the avg. disk queue lenth and %disk time for
>> the data drive for the sql server database. We have the same
>> dedicated spindle config as we did on our former system with the
>> difference being the greatly increased throughput of the new system.
>> Avg. disk queue lenth is reporting an avg. of over 30 for lengthy
>> periods of time(> 10 minutes) and %disk time is reporting an avg of
>> over 300 around the same time . The former system was not reporting
>> any performance bottlenecks. I wonder if the counters are skewed
>> somehow. Has anyone experienced any oddities with disk related
>> performance counter metrics on a san or am I suddenly looking at a
>> disk bottleneck? Is it possible that the increased throughput to the
>> san is now causing a disk bottleneck?
>> Let me know if more details are needed.
>> Thanks,
>> Greg
>sql
Subscribe to:
Posts (Atom)