Hi all,
I hope someone will be kind enough to have a look over this for me and
let me know if I'm correct.
We bought an application to do timetabling a couple of years ago. Last
year we had terrible problems with system performance, during the busy
period in August/September the system became basically unusable. We
tracked that down to disk performance, and after toying with using the
SAN, eventually went for Solid State Disk (RamSan 300) after some
careful analysis of the SAN. We also moved the application up to a new
4x3GHz Xeon machine with 4GB RAM.
We've just run a simulated load test to see if we think the system will
be able to stand up to the load this year and are very concerned about
the results. The load test had 20 users in it.
All IO/Memory/Paging/Compilation counters etc seemed to show the server
wasn't stretched, however the CPU load went to 100% and stayed there for
the duration. The number of Page locks got to 70,000 (last year it was
230,000 + so we've improved something!) and we saw several blocking
chains with the lead blocker in a 'sleeping' state. The wait times for
the blocked processes got to in excess of 500 seconds.
The suppliers say we need a bigger server, my concern, since we're on a
far bigger server is that the app is just highly inefficient and any
size server will get swamped by it...
Following the load test I've been looking at the Profiler tool. The
output seems to show the app uses server side cursors (we've noticed
some very heavy IO on tempdb that seems to support this). I dimly
remember reading something in the past that high CPU can be a symptom of
high lock counts rather than a cause of it - is this right?
Any help or advice will be much appreciated :-)
cheers
daveDave
Try run SQL Server Profiler to identify a long running queries/stored
procedures (look at DURATION ) , so once you have identified them , take a
look at how you casn improve it , may be adding indexes to the table or
somethinmg else
Looking at what you gave provided it seems that the APP is using cursors
(blocking/cursors) which is really bad in terms of performance
Speek to the vendor to improve the app
"Dave Thornley" <cisdht@.yahoo.com> wrote in message
news:uWzgAdxrGHA.2256@.TK2MSFTNGP03.phx.gbl...
> Hi all,
> I hope someone will be kind enough to have a look over this for me and let
> me know if I'm correct.
> We bought an application to do timetabling a couple of years ago. Last
> year we had terrible problems with system performance, during the busy
> period in August/September the system became basically unusable. We
> tracked that down to disk performance, and after toying with using the
> SAN, eventually went for Solid State Disk (RamSan 300) after some careful
> analysis of the SAN. We also moved the application up to a new 4x3GHz Xeon
> machine with 4GB RAM.
> We've just run a simulated load test to see if we think the system will be
> able to stand up to the load this year and are very concerned about the
> results. The load test had 20 users in it.
> All IO/Memory/Paging/Compilation counters etc seemed to show the server
> wasn't stretched, however the CPU load went to 100% and stayed there for
> the duration. The number of Page locks got to 70,000 (last year it was
> 230,000 + so we've improved something!) and we saw several blocking chains
> with the lead blocker in a 'sleeping' state. The wait times for the
> blocked processes got to in excess of 500 seconds.
> The suppliers say we need a bigger server, my concern, since we're on a
> far bigger server is that the app is just highly inefficient and any size
> server will get swamped by it...
> Following the load test I've been looking at the Profiler tool. The output
> seems to show the app uses server side cursors (we've noticed some very
> heavy IO on tempdb that seems to support this). I dimly remember reading
> something in the past that high CPU can be a symptom of high lock counts
> rather than a cause of it - is this right?
> Any help or advice will be much appreciated :-)
> cheers
> dave|||Hi Dave
High CPU can be the result of poor code and you may want to look at the lock
events such as lock escallation in SQL profiler. You can also use the
profiler to find out what the I/O intensive queries are see:
http://www.sql-server-performance.com/sql_server_performance_audit10.asp
You may then want to go back to the vendor and ask them to improve it.
Also check that if there are maintenance routines that will update your
indexes and statistics that they have successfully been run.
For blocking you may want to look at http://support.microsoft.com/kb/271509
HTH
John
"Dave Thornley" wrote:
> Hi all,
> I hope someone will be kind enough to have a look over this for me and
> let me know if I'm correct.
> We bought an application to do timetabling a couple of years ago. Last
> year we had terrible problems with system performance, during the busy
> period in August/September the system became basically unusable. We
> tracked that down to disk performance, and after toying with using the
> SAN, eventually went for Solid State Disk (RamSan 300) after some
> careful analysis of the SAN. We also moved the application up to a new
> 4x3GHz Xeon machine with 4GB RAM.
> We've just run a simulated load test to see if we think the system will
> be able to stand up to the load this year and are very concerned about
> the results. The load test had 20 users in it.
> All IO/Memory/Paging/Compilation counters etc seemed to show the server
> wasn't stretched, however the CPU load went to 100% and stayed there for
> the duration. The number of Page locks got to 70,000 (last year it was
> 230,000 + so we've improved something!) and we saw several blocking
> chains with the lead blocker in a 'sleeping' state. The wait times for
> the blocked processes got to in excess of 500 seconds.
> The suppliers say we need a bigger server, my concern, since we're on a
> far bigger server is that the app is just highly inefficient and any
> size server will get swamped by it...
> Following the load test I've been looking at the Profiler tool. The
> output seems to show the app uses server side cursors (we've noticed
> some very heavy IO on tempdb that seems to support this). I dimly
> remember reading something in the past that high CPU can be a symptom of
> high lock counts rather than a cause of it - is this right?
> Any help or advice will be much appreciated :-)
> cheers
> dave
>|||Hi Dave,
Since the application suffers from heavy locking/blocking you should
considder upgrading to SS2005 and use snapshot isolation.
ALTER DATABASE [S] SET read_committed_snapshot ON
Be sure that tempdb is big enough :-)
The application you are talking about sounds a lot like Axapta :-)
Do you reindex your clustered indexes from time to time - be sure there is a
clustered index on the tables?
You should look at the wait statistics for the different sessions - have you
heard about the YAPP method?
Good luck :-)
"Dave Thornley" wrote:
> Hi all,
> I hope someone will be kind enough to have a look over this for me and
> let me know if I'm correct.
> We bought an application to do timetabling a couple of years ago. Last
> year we had terrible problems with system performance, during the busy
> period in August/September the system became basically unusable. We
> tracked that down to disk performance, and after toying with using the
> SAN, eventually went for Solid State Disk (RamSan 300) after some
> careful analysis of the SAN. We also moved the application up to a new
> 4x3GHz Xeon machine with 4GB RAM.
> We've just run a simulated load test to see if we think the system will
> be able to stand up to the load this year and are very concerned about
> the results. The load test had 20 users in it.
> All IO/Memory/Paging/Compilation counters etc seemed to show the server
> wasn't stretched, however the CPU load went to 100% and stayed there for
> the duration. The number of Page locks got to 70,000 (last year it was
> 230,000 + so we've improved something!) and we saw several blocking
> chains with the lead blocker in a 'sleeping' state. The wait times for
> the blocked processes got to in excess of 500 seconds.
> The suppliers say we need a bigger server, my concern, since we're on a
> far bigger server is that the app is just highly inefficient and any
> size server will get swamped by it...
> Following the load test I've been looking at the Profiler tool. The
> output seems to show the app uses server side cursors (we've noticed
> some very heavy IO on tempdb that seems to support this). I dimly
> remember reading something in the past that high CPU can be a symptom of
> high lock counts rather than a cause of it - is this right?
> Any help or advice will be much appreciated :-)
> cheers
> dave
>|||Thanks for the help and suggestions guys.
davesql
Showing posts with label bought. Show all posts
Showing posts with label bought. Show all posts
Wednesday, March 28, 2012
Performance sanity check
Hi all,
I hope someone will be kind enough to have a look over this for me and
let me know if I'm correct.
We bought an application to do timetabling a couple of years ago. Last
year we had terrible problems with system performance, during the busy
period in August/September the system became basically unusable. We
tracked that down to disk performance, and after toying with using the
SAN, eventually went for Solid State Disk (RamSan 300) after some
careful analysis of the SAN. We also moved the application up to a new
4x3GHz Xeon machine with 4GB RAM.
We've just run a simulated load test to see if we think the system will
be able to stand up to the load this year and are very concerned about
the results. The load test had 20 users in it.
All IO/Memory/Paging/Compilation counters etc seemed to show the server
wasn't stretched, however the CPU load went to 100% and stayed there for
the duration. The number of Page locks got to 70,000 (last year it was
230,000 + so we've improved something!) and we saw several blocking
chains with the lead blocker in a 'sleeping' state. The wait times for
the blocked processes got to in excess of 500 seconds.
The suppliers say we need a bigger server, my concern, since we're on a
far bigger server is that the app is just highly inefficient and any
size server will get swamped by it...
Following the load test I've been looking at the Profiler tool. The
output seems to show the app uses server side cursors (we've noticed
some very heavy IO on tempdb that seems to support this). I dimly
remember reading something in the past that high CPU can be a symptom of
high lock counts rather than a cause of it - is this right?
Any help or advice will be much appreciated :-)
cheers
daveDave
Try run SQL Server Profiler to identify a long running queries/stored
procedures (look at DURATION ) , so once you have identified them , take a
look at how you casn improve it , may be adding indexes to the table or
somethinmg else
Looking at what you gave provided it seems that the APP is using cursors
(blocking/cursors) which is really bad in terms of performance
Speek to the vendor to improve the app
"Dave Thornley" <cisdht@.yahoo.com> wrote in message
news:uWzgAdxrGHA.2256@.TK2MSFTNGP03.phx.gbl...
> Hi all,
> I hope someone will be kind enough to have a look over this for me and let
> me know if I'm correct.
> We bought an application to do timetabling a couple of years ago. Last
> year we had terrible problems with system performance, during the busy
> period in August/September the system became basically unusable. We
> tracked that down to disk performance, and after toying with using the
> SAN, eventually went for Solid State Disk (RamSan 300) after some careful
> analysis of the SAN. We also moved the application up to a new 4x3GHz Xeon
> machine with 4GB RAM.
> We've just run a simulated load test to see if we think the system will be
> able to stand up to the load this year and are very concerned about the
> results. The load test had 20 users in it.
> All IO/Memory/Paging/Compilation counters etc seemed to show the server
> wasn't stretched, however the CPU load went to 100% and stayed there for
> the duration. The number of Page locks got to 70,000 (last year it was
> 230,000 + so we've improved something!) and we saw several blocking chains
> with the lead blocker in a 'sleeping' state. The wait times for the
> blocked processes got to in excess of 500 seconds.
> The suppliers say we need a bigger server, my concern, since we're on a
> far bigger server is that the app is just highly inefficient and any size
> server will get swamped by it...
> Following the load test I've been looking at the Profiler tool. The output
> seems to show the app uses server side cursors (we've noticed some very
> heavy IO on tempdb that seems to support this). I dimly remember reading
> something in the past that high CPU can be a symptom of high lock counts
> rather than a cause of it - is this right?
> Any help or advice will be much appreciated :-)
> cheers
> dave|||Hi Dave
High CPU can be the result of poor code and you may want to look at the lock
events such as lock escallation in SQL profiler. You can also use the
profiler to find out what the I/O intensive queries are see:
http://www.sql-server-performance.c...nce_audit10.asp
You may then want to go back to the vendor and ask them to improve it.
Also check that if there are maintenance routines that will update your
indexes and statistics that they have successfully been run.
For blocking you may want to look at http://support.microsoft.com/kb/271509
HTH
John
"Dave Thornley" wrote:
> Hi all,
> I hope someone will be kind enough to have a look over this for me and
> let me know if I'm correct.
> We bought an application to do timetabling a couple of years ago. Last
> year we had terrible problems with system performance, during the busy
> period in August/September the system became basically unusable. We
> tracked that down to disk performance, and after toying with using the
> SAN, eventually went for Solid State Disk (RamSan 300) after some
> careful analysis of the SAN. We also moved the application up to a new
> 4x3GHz Xeon machine with 4GB RAM.
> We've just run a simulated load test to see if we think the system will
> be able to stand up to the load this year and are very concerned about
> the results. The load test had 20 users in it.
> All IO/Memory/Paging/Compilation counters etc seemed to show the server
> wasn't stretched, however the CPU load went to 100% and stayed there for
> the duration. The number of Page locks got to 70,000 (last year it was
> 230,000 + so we've improved something!) and we saw several blocking
> chains with the lead blocker in a 'sleeping' state. The wait times for
> the blocked processes got to in excess of 500 seconds.
> The suppliers say we need a bigger server, my concern, since we're on a
> far bigger server is that the app is just highly inefficient and any
> size server will get swamped by it...
> Following the load test I've been looking at the Profiler tool. The
> output seems to show the app uses server side cursors (we've noticed
> some very heavy IO on tempdb that seems to support this). I dimly
> remember reading something in the past that high CPU can be a symptom of
> high lock counts rather than a cause of it - is this right?
> Any help or advice will be much appreciated :-)
> cheers
> dave
>|||Hi Dave,
Since the application suffers from heavy locking/blocking you should
considder upgrading to SS2005 and use snapshot isolation.
ALTER DATABASE [S] SET read_committed_snapshot ON
Be sure that tempdb is big enough :-)
The application you are talking about sounds a lot like Axapta :-)
Do you reindex your clustered indexes from time to time - be sure there is a
clustered index on the tables?
You should look at the wait statistics for the different sessions - have you
heard about the YAPP method?
Good luck :-)
"Dave Thornley" wrote:
> Hi all,
> I hope someone will be kind enough to have a look over this for me and
> let me know if I'm correct.
> We bought an application to do timetabling a couple of years ago. Last
> year we had terrible problems with system performance, during the busy
> period in August/September the system became basically unusable. We
> tracked that down to disk performance, and after toying with using the
> SAN, eventually went for Solid State Disk (RamSan 300) after some
> careful analysis of the SAN. We also moved the application up to a new
> 4x3GHz Xeon machine with 4GB RAM.
> We've just run a simulated load test to see if we think the system will
> be able to stand up to the load this year and are very concerned about
> the results. The load test had 20 users in it.
> All IO/Memory/Paging/Compilation counters etc seemed to show the server
> wasn't stretched, however the CPU load went to 100% and stayed there for
> the duration. The number of Page locks got to 70,000 (last year it was
> 230,000 + so we've improved something!) and we saw several blocking
> chains with the lead blocker in a 'sleeping' state. The wait times for
> the blocked processes got to in excess of 500 seconds.
> The suppliers say we need a bigger server, my concern, since we're on a
> far bigger server is that the app is just highly inefficient and any
> size server will get swamped by it...
> Following the load test I've been looking at the Profiler tool. The
> output seems to show the app uses server side cursors (we've noticed
> some very heavy IO on tempdb that seems to support this). I dimly
> remember reading something in the past that high CPU can be a symptom of
> high lock counts rather than a cause of it - is this right?
> Any help or advice will be much appreciated :-)
> cheers
> dave
>|||Thanks for the help and suggestions guys.
dave
I hope someone will be kind enough to have a look over this for me and
let me know if I'm correct.
We bought an application to do timetabling a couple of years ago. Last
year we had terrible problems with system performance, during the busy
period in August/September the system became basically unusable. We
tracked that down to disk performance, and after toying with using the
SAN, eventually went for Solid State Disk (RamSan 300) after some
careful analysis of the SAN. We also moved the application up to a new
4x3GHz Xeon machine with 4GB RAM.
We've just run a simulated load test to see if we think the system will
be able to stand up to the load this year and are very concerned about
the results. The load test had 20 users in it.
All IO/Memory/Paging/Compilation counters etc seemed to show the server
wasn't stretched, however the CPU load went to 100% and stayed there for
the duration. The number of Page locks got to 70,000 (last year it was
230,000 + so we've improved something!) and we saw several blocking
chains with the lead blocker in a 'sleeping' state. The wait times for
the blocked processes got to in excess of 500 seconds.
The suppliers say we need a bigger server, my concern, since we're on a
far bigger server is that the app is just highly inefficient and any
size server will get swamped by it...
Following the load test I've been looking at the Profiler tool. The
output seems to show the app uses server side cursors (we've noticed
some very heavy IO on tempdb that seems to support this). I dimly
remember reading something in the past that high CPU can be a symptom of
high lock counts rather than a cause of it - is this right?
Any help or advice will be much appreciated :-)
cheers
daveDave
Try run SQL Server Profiler to identify a long running queries/stored
procedures (look at DURATION ) , so once you have identified them , take a
look at how you casn improve it , may be adding indexes to the table or
somethinmg else
Looking at what you gave provided it seems that the APP is using cursors
(blocking/cursors) which is really bad in terms of performance
Speek to the vendor to improve the app
"Dave Thornley" <cisdht@.yahoo.com> wrote in message
news:uWzgAdxrGHA.2256@.TK2MSFTNGP03.phx.gbl...
> Hi all,
> I hope someone will be kind enough to have a look over this for me and let
> me know if I'm correct.
> We bought an application to do timetabling a couple of years ago. Last
> year we had terrible problems with system performance, during the busy
> period in August/September the system became basically unusable. We
> tracked that down to disk performance, and after toying with using the
> SAN, eventually went for Solid State Disk (RamSan 300) after some careful
> analysis of the SAN. We also moved the application up to a new 4x3GHz Xeon
> machine with 4GB RAM.
> We've just run a simulated load test to see if we think the system will be
> able to stand up to the load this year and are very concerned about the
> results. The load test had 20 users in it.
> All IO/Memory/Paging/Compilation counters etc seemed to show the server
> wasn't stretched, however the CPU load went to 100% and stayed there for
> the duration. The number of Page locks got to 70,000 (last year it was
> 230,000 + so we've improved something!) and we saw several blocking chains
> with the lead blocker in a 'sleeping' state. The wait times for the
> blocked processes got to in excess of 500 seconds.
> The suppliers say we need a bigger server, my concern, since we're on a
> far bigger server is that the app is just highly inefficient and any size
> server will get swamped by it...
> Following the load test I've been looking at the Profiler tool. The output
> seems to show the app uses server side cursors (we've noticed some very
> heavy IO on tempdb that seems to support this). I dimly remember reading
> something in the past that high CPU can be a symptom of high lock counts
> rather than a cause of it - is this right?
> Any help or advice will be much appreciated :-)
> cheers
> dave|||Hi Dave
High CPU can be the result of poor code and you may want to look at the lock
events such as lock escallation in SQL profiler. You can also use the
profiler to find out what the I/O intensive queries are see:
http://www.sql-server-performance.c...nce_audit10.asp
You may then want to go back to the vendor and ask them to improve it.
Also check that if there are maintenance routines that will update your
indexes and statistics that they have successfully been run.
For blocking you may want to look at http://support.microsoft.com/kb/271509
HTH
John
"Dave Thornley" wrote:
> Hi all,
> I hope someone will be kind enough to have a look over this for me and
> let me know if I'm correct.
> We bought an application to do timetabling a couple of years ago. Last
> year we had terrible problems with system performance, during the busy
> period in August/September the system became basically unusable. We
> tracked that down to disk performance, and after toying with using the
> SAN, eventually went for Solid State Disk (RamSan 300) after some
> careful analysis of the SAN. We also moved the application up to a new
> 4x3GHz Xeon machine with 4GB RAM.
> We've just run a simulated load test to see if we think the system will
> be able to stand up to the load this year and are very concerned about
> the results. The load test had 20 users in it.
> All IO/Memory/Paging/Compilation counters etc seemed to show the server
> wasn't stretched, however the CPU load went to 100% and stayed there for
> the duration. The number of Page locks got to 70,000 (last year it was
> 230,000 + so we've improved something!) and we saw several blocking
> chains with the lead blocker in a 'sleeping' state. The wait times for
> the blocked processes got to in excess of 500 seconds.
> The suppliers say we need a bigger server, my concern, since we're on a
> far bigger server is that the app is just highly inefficient and any
> size server will get swamped by it...
> Following the load test I've been looking at the Profiler tool. The
> output seems to show the app uses server side cursors (we've noticed
> some very heavy IO on tempdb that seems to support this). I dimly
> remember reading something in the past that high CPU can be a symptom of
> high lock counts rather than a cause of it - is this right?
> Any help or advice will be much appreciated :-)
> cheers
> dave
>|||Hi Dave,
Since the application suffers from heavy locking/blocking you should
considder upgrading to SS2005 and use snapshot isolation.
ALTER DATABASE [S] SET read_committed_snapshot ON
Be sure that tempdb is big enough :-)
The application you are talking about sounds a lot like Axapta :-)
Do you reindex your clustered indexes from time to time - be sure there is a
clustered index on the tables?
You should look at the wait statistics for the different sessions - have you
heard about the YAPP method?
Good luck :-)
"Dave Thornley" wrote:
> Hi all,
> I hope someone will be kind enough to have a look over this for me and
> let me know if I'm correct.
> We bought an application to do timetabling a couple of years ago. Last
> year we had terrible problems with system performance, during the busy
> period in August/September the system became basically unusable. We
> tracked that down to disk performance, and after toying with using the
> SAN, eventually went for Solid State Disk (RamSan 300) after some
> careful analysis of the SAN. We also moved the application up to a new
> 4x3GHz Xeon machine with 4GB RAM.
> We've just run a simulated load test to see if we think the system will
> be able to stand up to the load this year and are very concerned about
> the results. The load test had 20 users in it.
> All IO/Memory/Paging/Compilation counters etc seemed to show the server
> wasn't stretched, however the CPU load went to 100% and stayed there for
> the duration. The number of Page locks got to 70,000 (last year it was
> 230,000 + so we've improved something!) and we saw several blocking
> chains with the lead blocker in a 'sleeping' state. The wait times for
> the blocked processes got to in excess of 500 seconds.
> The suppliers say we need a bigger server, my concern, since we're on a
> far bigger server is that the app is just highly inefficient and any
> size server will get swamped by it...
> Following the load test I've been looking at the Profiler tool. The
> output seems to show the app uses server side cursors (we've noticed
> some very heavy IO on tempdb that seems to support this). I dimly
> remember reading something in the past that high CPU can be a symptom of
> high lock counts rather than a cause of it - is this right?
> Any help or advice will be much appreciated :-)
> cheers
> dave
>|||Thanks for the help and suggestions guys.
dave
Friday, March 23, 2012
Performance puzzle
We have a new Compaq Proliant DL760 server running
Windows 2003 that we bought to replace a Dell 8450
running Windows 2000
The new machine has 4 2.5 Ghz processors with hyper-
threading (when you open Task Mgr it looks like it
has 8 processors)
The old machine has 8 P3 700 Mhz processors.
Both machines have direct attached fiber channel
arrays configured identically except the new one uses
72 Gig hard drives and the old one has 36 Gig drives.
I am using 9 drives in Raid5 for data and 4 drives in Raid
1+0 for logs on both machines. Both arrays have 15000 RPM
drives.
Both machines have SQL Server 2000. My test database is
about 4 Gig and it is identical on both servers.
I have a stress test script with a variety of operations
such as bulk insert, create clustered index, calculations,
etc.
As you would expect, the new machine runs processor
intensive operations much faster. But the old machine runs
disk intensive operations faster than the new one. We had
expected at least comparable performance.
Overall, the test runs in 39 minutes on the old machine
and 40 minutes on the new one (pretty close, I know, but
the new one should win by a larger margin).
Is there anything special about running SQL Server 2000 on
Windows 2003 that we need to know?
Does the Compaq drive array have some limitation that the
Dell does not?
Thanks
Dave GDave,
don't know whether you have considered the following two variants:
1. seek time. it is a specification of the hard drive, and though not much,
different drives can have different seek times. With the rotation speed on
the higher end, the seek times' difference plays a larger role
2. sorting mechanism of the RAID controllers: some controllers support
elevator sorting that is clearly at advantage than without.
hth
Quentin
"DaveG" <anonymous@.discussions.microsoft.com> wrote in message
news:02c701c3dae2$a256fde0$a401280a@.phx.gbl...
> We have a new Compaq Proliant DL760 server running
> Windows 2003 that we bought to replace a Dell 8450
> running Windows 2000
> The new machine has 4 2.5 Ghz processors with hyper-
> threading (when you open Task Mgr it looks like it
> has 8 processors)
> The old machine has 8 P3 700 Mhz processors.
> Both machines have direct attached fiber channel
> arrays configured identically except the new one uses
> 72 Gig hard drives and the old one has 36 Gig drives.
> I am using 9 drives in Raid5 for data and 4 drives in Raid
> 1+0 for logs on both machines. Both arrays have 15000 RPM
> drives.
> Both machines have SQL Server 2000. My test database is
> about 4 Gig and it is identical on both servers.
> I have a stress test script with a variety of operations
> such as bulk insert, create clustered index, calculations,
> etc.
> As you would expect, the new machine runs processor
> intensive operations much faster. But the old machine runs
> disk intensive operations faster than the new one. We had
> expected at least comparable performance.
> Overall, the test runs in 39 minutes on the old machine
> and 40 minutes on the new one (pretty close, I know, but
> the new one should win by a larger margin).
> Is there anything special about running SQL Server 2000 on
> Windows 2003 that we need to know?
> Does the Compaq drive array have some limitation that the
> Dell does not?
> Thanks
> Dave G
>|||Thanks, I'll see if I can find the specs.
DG
>--Original Message--
>Dave,
>don't know whether you have considered the following two
variants:
>1. seek time. it is a specification of the hard drive,
and though not much,
>different drives can have different seek times. With the
rotation speed on
>the higher end, the seek times' difference plays a larger
role
>2. sorting mechanism of the RAID controllers: some
controllers support
>elevator sorting that is clearly at advantage than
without.
>hth
>Quentin
>
>"DaveG" <anonymous@.discussions.microsoft.com> wrote in
message
>news:02c701c3dae2$a256fde0$a401280a@.phx.gbl...
>> We have a new Compaq Proliant DL760 server running
>> Windows 2003 that we bought to replace a Dell 8450
>> running Windows 2000
>> The new machine has 4 2.5 Ghz processors with hyper-
>> threading (when you open Task Mgr it looks like it
>> has 8 processors)
>> The old machine has 8 P3 700 Mhz processors.
>> Both machines have direct attached fiber channel
>> arrays configured identically except the new one uses
>> 72 Gig hard drives and the old one has 36 Gig drives.
>> I am using 9 drives in Raid5 for data and 4 drives in
Raid
>> 1+0 for logs on both machines. Both arrays have 15000
RPM
>> drives.
>> Both machines have SQL Server 2000. My test database is
>> about 4 Gig and it is identical on both servers.
>> I have a stress test script with a variety of operations
>> such as bulk insert, create clustered index,
calculations,
>> etc.
>> As you would expect, the new machine runs processor
>> intensive operations much faster. But the old machine
runs
>> disk intensive operations faster than the new one. We
had
>> expected at least comparable performance.
>> Overall, the test runs in 39 minutes on the old machine
>> and 40 minutes on the new one (pretty close, I know, but
>> the new one should win by a larger margin).
>> Is there anything special about running SQL Server 2000
on
>> Windows 2003 that we need to know?
>> Does the Compaq drive array have some limitation that
the
>> Dell does not?
>> Thanks
>> Dave G
>>
>
>.
>|||You don't mention which drive arrays you have but from what I've seen of our
Compaq RA8000's there is more to the configuration than just the RAID level.
So it might still be something between the way the arrays are configured. If
you're familiar with IOMeter from Intel you might want to use that to test
the disk systems performance.
Also, from the tests I've seen hyperthreading isn't the same as having more
full processors, so maybe the difference in processor count plays a larger
part than expected. It may be possible that hyperthreading is actually
causing worse performance, you might want to test disabling it.
Mike Kruchten
"DaveG" <anonymous@.discussions.microsoft.com> wrote in message
news:02c701c3dae2$a256fde0$a401280a@.phx.gbl...
> We have a new Compaq Proliant DL760 server running
> Windows 2003 that we bought to replace a Dell 8450
> running Windows 2000
> The new machine has 4 2.5 Ghz processors with hyper-
> threading (when you open Task Mgr it looks like it
> has 8 processors)
> The old machine has 8 P3 700 Mhz processors.
> Both machines have direct attached fiber channel
> arrays configured identically except the new one uses
> 72 Gig hard drives and the old one has 36 Gig drives.
> I am using 9 drives in Raid5 for data and 4 drives in Raid
> 1+0 for logs on both machines. Both arrays have 15000 RPM
> drives.
> Both machines have SQL Server 2000. My test database is
> about 4 Gig and it is identical on both servers.
> I have a stress test script with a variety of operations
> such as bulk insert, create clustered index, calculations,
> etc.
> As you would expect, the new machine runs processor
> intensive operations much faster. But the old machine runs
> disk intensive operations faster than the new one. We had
> expected at least comparable performance.
> Overall, the test runs in 39 minutes on the old machine
> and 40 minutes on the new one (pretty close, I know, but
> the new one should win by a larger margin).
> Is there anything special about running SQL Server 2000 on
> Windows 2003 that we need to know?
> Does the Compaq drive array have some limitation that the
> Dell does not?
> Thanks
> Dave G
>|||> Also, from the tests I've seen hyperthreading isn't the same as having
more
> full processors, so maybe the difference in processor count plays a larger
> part than expected. It may be possible that hyperthreading is actually
> causing worse performance, you might want to test disabling it.
Absolutely right.
> "DaveG" <anonymous@.discussions.microsoft.com> wrote in message
> news:02c701c3dae2$a256fde0$a401280a@.phx.gbl...
> > We have a new Compaq Proliant DL760 server running
> > Windows 2003 that we bought to replace a Dell 8450
> > running Windows 2000
> > The new machine has 4 2.5 Ghz processors with hyper-
> > threading (when you open Task Mgr it looks like it
> > has 8 processors)
> > The old machine has 8 P3 700 Mhz processors.
> > Both machines have direct attached fiber channel
> > arrays configured identically except the new one uses
> > 72 Gig hard drives and the old one has 36 Gig drives.
> > I am using 9 drives in Raid5 for data and 4 drives in Raid
> > 1+0 for logs on both machines. Both arrays have 15000 RPM
> > drives.
> >
> > Both machines have SQL Server 2000. My test database is
> > about 4 Gig and it is identical on both servers.
> >
> > I have a stress test script with a variety of operations
> > such as bulk insert, create clustered index, calculations,
> > etc.
> >
> > As you would expect, the new machine runs processor
> > intensive operations much faster. But the old machine runs
> > disk intensive operations faster than the new one. We had
> > expected at least comparable performance.
> >
> > Overall, the test runs in 39 minutes on the old machine
> > and 40 minutes on the new one (pretty close, I know, but
> > the new one should win by a larger margin).
> >
> > Is there anything special about running SQL Server 2000 on
> > Windows 2003 that we need to know?
> > Does the Compaq drive array have some limitation that the
> > Dell does not?
> >
> > Thanks
> > Dave G
> >
> >
>sql
Windows 2003 that we bought to replace a Dell 8450
running Windows 2000
The new machine has 4 2.5 Ghz processors with hyper-
threading (when you open Task Mgr it looks like it
has 8 processors)
The old machine has 8 P3 700 Mhz processors.
Both machines have direct attached fiber channel
arrays configured identically except the new one uses
72 Gig hard drives and the old one has 36 Gig drives.
I am using 9 drives in Raid5 for data and 4 drives in Raid
1+0 for logs on both machines. Both arrays have 15000 RPM
drives.
Both machines have SQL Server 2000. My test database is
about 4 Gig and it is identical on both servers.
I have a stress test script with a variety of operations
such as bulk insert, create clustered index, calculations,
etc.
As you would expect, the new machine runs processor
intensive operations much faster. But the old machine runs
disk intensive operations faster than the new one. We had
expected at least comparable performance.
Overall, the test runs in 39 minutes on the old machine
and 40 minutes on the new one (pretty close, I know, but
the new one should win by a larger margin).
Is there anything special about running SQL Server 2000 on
Windows 2003 that we need to know?
Does the Compaq drive array have some limitation that the
Dell does not?
Thanks
Dave GDave,
don't know whether you have considered the following two variants:
1. seek time. it is a specification of the hard drive, and though not much,
different drives can have different seek times. With the rotation speed on
the higher end, the seek times' difference plays a larger role
2. sorting mechanism of the RAID controllers: some controllers support
elevator sorting that is clearly at advantage than without.
hth
Quentin
"DaveG" <anonymous@.discussions.microsoft.com> wrote in message
news:02c701c3dae2$a256fde0$a401280a@.phx.gbl...
> We have a new Compaq Proliant DL760 server running
> Windows 2003 that we bought to replace a Dell 8450
> running Windows 2000
> The new machine has 4 2.5 Ghz processors with hyper-
> threading (when you open Task Mgr it looks like it
> has 8 processors)
> The old machine has 8 P3 700 Mhz processors.
> Both machines have direct attached fiber channel
> arrays configured identically except the new one uses
> 72 Gig hard drives and the old one has 36 Gig drives.
> I am using 9 drives in Raid5 for data and 4 drives in Raid
> 1+0 for logs on both machines. Both arrays have 15000 RPM
> drives.
> Both machines have SQL Server 2000. My test database is
> about 4 Gig and it is identical on both servers.
> I have a stress test script with a variety of operations
> such as bulk insert, create clustered index, calculations,
> etc.
> As you would expect, the new machine runs processor
> intensive operations much faster. But the old machine runs
> disk intensive operations faster than the new one. We had
> expected at least comparable performance.
> Overall, the test runs in 39 minutes on the old machine
> and 40 minutes on the new one (pretty close, I know, but
> the new one should win by a larger margin).
> Is there anything special about running SQL Server 2000 on
> Windows 2003 that we need to know?
> Does the Compaq drive array have some limitation that the
> Dell does not?
> Thanks
> Dave G
>|||Thanks, I'll see if I can find the specs.
DG
>--Original Message--
>Dave,
>don't know whether you have considered the following two
variants:
>1. seek time. it is a specification of the hard drive,
and though not much,
>different drives can have different seek times. With the
rotation speed on
>the higher end, the seek times' difference plays a larger
role
>2. sorting mechanism of the RAID controllers: some
controllers support
>elevator sorting that is clearly at advantage than
without.
>hth
>Quentin
>
>"DaveG" <anonymous@.discussions.microsoft.com> wrote in
message
>news:02c701c3dae2$a256fde0$a401280a@.phx.gbl...
>> We have a new Compaq Proliant DL760 server running
>> Windows 2003 that we bought to replace a Dell 8450
>> running Windows 2000
>> The new machine has 4 2.5 Ghz processors with hyper-
>> threading (when you open Task Mgr it looks like it
>> has 8 processors)
>> The old machine has 8 P3 700 Mhz processors.
>> Both machines have direct attached fiber channel
>> arrays configured identically except the new one uses
>> 72 Gig hard drives and the old one has 36 Gig drives.
>> I am using 9 drives in Raid5 for data and 4 drives in
Raid
>> 1+0 for logs on both machines. Both arrays have 15000
RPM
>> drives.
>> Both machines have SQL Server 2000. My test database is
>> about 4 Gig and it is identical on both servers.
>> I have a stress test script with a variety of operations
>> such as bulk insert, create clustered index,
calculations,
>> etc.
>> As you would expect, the new machine runs processor
>> intensive operations much faster. But the old machine
runs
>> disk intensive operations faster than the new one. We
had
>> expected at least comparable performance.
>> Overall, the test runs in 39 minutes on the old machine
>> and 40 minutes on the new one (pretty close, I know, but
>> the new one should win by a larger margin).
>> Is there anything special about running SQL Server 2000
on
>> Windows 2003 that we need to know?
>> Does the Compaq drive array have some limitation that
the
>> Dell does not?
>> Thanks
>> Dave G
>>
>
>.
>|||You don't mention which drive arrays you have but from what I've seen of our
Compaq RA8000's there is more to the configuration than just the RAID level.
So it might still be something between the way the arrays are configured. If
you're familiar with IOMeter from Intel you might want to use that to test
the disk systems performance.
Also, from the tests I've seen hyperthreading isn't the same as having more
full processors, so maybe the difference in processor count plays a larger
part than expected. It may be possible that hyperthreading is actually
causing worse performance, you might want to test disabling it.
Mike Kruchten
"DaveG" <anonymous@.discussions.microsoft.com> wrote in message
news:02c701c3dae2$a256fde0$a401280a@.phx.gbl...
> We have a new Compaq Proliant DL760 server running
> Windows 2003 that we bought to replace a Dell 8450
> running Windows 2000
> The new machine has 4 2.5 Ghz processors with hyper-
> threading (when you open Task Mgr it looks like it
> has 8 processors)
> The old machine has 8 P3 700 Mhz processors.
> Both machines have direct attached fiber channel
> arrays configured identically except the new one uses
> 72 Gig hard drives and the old one has 36 Gig drives.
> I am using 9 drives in Raid5 for data and 4 drives in Raid
> 1+0 for logs on both machines. Both arrays have 15000 RPM
> drives.
> Both machines have SQL Server 2000. My test database is
> about 4 Gig and it is identical on both servers.
> I have a stress test script with a variety of operations
> such as bulk insert, create clustered index, calculations,
> etc.
> As you would expect, the new machine runs processor
> intensive operations much faster. But the old machine runs
> disk intensive operations faster than the new one. We had
> expected at least comparable performance.
> Overall, the test runs in 39 minutes on the old machine
> and 40 minutes on the new one (pretty close, I know, but
> the new one should win by a larger margin).
> Is there anything special about running SQL Server 2000 on
> Windows 2003 that we need to know?
> Does the Compaq drive array have some limitation that the
> Dell does not?
> Thanks
> Dave G
>|||> Also, from the tests I've seen hyperthreading isn't the same as having
more
> full processors, so maybe the difference in processor count plays a larger
> part than expected. It may be possible that hyperthreading is actually
> causing worse performance, you might want to test disabling it.
Absolutely right.
> "DaveG" <anonymous@.discussions.microsoft.com> wrote in message
> news:02c701c3dae2$a256fde0$a401280a@.phx.gbl...
> > We have a new Compaq Proliant DL760 server running
> > Windows 2003 that we bought to replace a Dell 8450
> > running Windows 2000
> > The new machine has 4 2.5 Ghz processors with hyper-
> > threading (when you open Task Mgr it looks like it
> > has 8 processors)
> > The old machine has 8 P3 700 Mhz processors.
> > Both machines have direct attached fiber channel
> > arrays configured identically except the new one uses
> > 72 Gig hard drives and the old one has 36 Gig drives.
> > I am using 9 drives in Raid5 for data and 4 drives in Raid
> > 1+0 for logs on both machines. Both arrays have 15000 RPM
> > drives.
> >
> > Both machines have SQL Server 2000. My test database is
> > about 4 Gig and it is identical on both servers.
> >
> > I have a stress test script with a variety of operations
> > such as bulk insert, create clustered index, calculations,
> > etc.
> >
> > As you would expect, the new machine runs processor
> > intensive operations much faster. But the old machine runs
> > disk intensive operations faster than the new one. We had
> > expected at least comparable performance.
> >
> > Overall, the test runs in 39 minutes on the old machine
> > and 40 minutes on the new one (pretty close, I know, but
> > the new one should win by a larger margin).
> >
> > Is there anything special about running SQL Server 2000 on
> > Windows 2003 that we need to know?
> > Does the Compaq drive array have some limitation that the
> > Dell does not?
> >
> > Thanks
> > Dave G
> >
> >
>sql
Performance puzzle
We have a new Compaq Proliant DL760 server running
Windows 2003 that we bought to replace a Dell 8450
running Windows 2000
The new machine has 4 2.5 Ghz processors with hyper-
threading (when you open Task Mgr it looks like it
has 8 processors)
The old machine has 8 P3 700 Mhz processors.
Both machines have direct attached fiber channel
arrays configured identically except the new one uses
72 Gig hard drives and the old one has 36 Gig drives.
I am using 9 drives in Raid5 for data and 4 drives in Raid
1+0 for logs on both machines. Both arrays have 15000 RPM
drives.
Both machines have SQL Server 2000. My test database is
about 4 Gig and it is identical on both servers.
I have a stress test script with a variety of operations
such as bulk insert, create clustered index, calculations,
etc.
As you would expect, the new machine runs processor
intensive operations much faster. But the old machine runs
disk intensive operations faster than the new one. We had
expected at least comparable performance.
Overall, the test runs in 39 minutes on the old machine
and 40 minutes on the new one (pretty close, I know, but
the new one should win by a larger margin).
Is there anything special about running SQL Server 2000 on
Windows 2003 that we need to know?
Does the Compaq drive array have some limitation that the
Dell does not?
Thanks
Dave GDave,
don't know whether you have considered the following two variants:
1. seek time. it is a specification of the hard drive, and though not much,
different drives can have different seek times. With the rotation speed on
the higher end, the seek times' difference plays a larger role
2. sorting mechanism of the RAID controllers: some controllers support
elevator sorting that is clearly at advantage than without.
hth
Quentin
"DaveG" <anonymous@.discussions.microsoft.com> wrote in message
news:02c701c3dae2$a256fde0$a401280a@.phx.gbl...
DG
variants:
and though not much,
rotation speed on
role
controllers support
without.
message
Compaq RA8000's there is more to the configuration than just the RAID level.
So it might still be something between the way the arrays are configured. If
you're familiar with IOMeter from Intel you might want to use that to test
the disk systems performance.
Also, from the tests I've seen hyperthreading isn't the same as having more
full processors, so maybe the difference in processor count plays a larger
part than expected. It may be possible that hyperthreading is actually
causing worse performance, you might want to test disabling it.
Mike Kruchten
"DaveG" <anonymous@.discussions.microsoft.com> wrote in message
news:02c701c3dae2$a256fde0$a401280a@.phx.gbl...
more
Absolutely right.
Windows 2003 that we bought to replace a Dell 8450
running Windows 2000
The new machine has 4 2.5 Ghz processors with hyper-
threading (when you open Task Mgr it looks like it
has 8 processors)
The old machine has 8 P3 700 Mhz processors.
Both machines have direct attached fiber channel
arrays configured identically except the new one uses
72 Gig hard drives and the old one has 36 Gig drives.
I am using 9 drives in Raid5 for data and 4 drives in Raid
1+0 for logs on both machines. Both arrays have 15000 RPM
drives.
Both machines have SQL Server 2000. My test database is
about 4 Gig and it is identical on both servers.
I have a stress test script with a variety of operations
such as bulk insert, create clustered index, calculations,
etc.
As you would expect, the new machine runs processor
intensive operations much faster. But the old machine runs
disk intensive operations faster than the new one. We had
expected at least comparable performance.
Overall, the test runs in 39 minutes on the old machine
and 40 minutes on the new one (pretty close, I know, but
the new one should win by a larger margin).
Is there anything special about running SQL Server 2000 on
Windows 2003 that we need to know?
Does the Compaq drive array have some limitation that the
Dell does not?
Thanks
Dave GDave,
don't know whether you have considered the following two variants:
1. seek time. it is a specification of the hard drive, and though not much,
different drives can have different seek times. With the rotation speed on
the higher end, the seek times' difference plays a larger role
2. sorting mechanism of the RAID controllers: some controllers support
elevator sorting that is clearly at advantage than without.
hth
Quentin
"DaveG" <anonymous@.discussions.microsoft.com> wrote in message
news:02c701c3dae2$a256fde0$a401280a@.phx.gbl...
quote:|||Thanks, I'll see if I can find the specs.
> We have a new Compaq Proliant DL760 server running
> Windows 2003 that we bought to replace a Dell 8450
> running Windows 2000
> The new machine has 4 2.5 Ghz processors with hyper-
> threading (when you open Task Mgr it looks like it
> has 8 processors)
> The old machine has 8 P3 700 Mhz processors.
> Both machines have direct attached fiber channel
> arrays configured identically except the new one uses
> 72 Gig hard drives and the old one has 36 Gig drives.
> I am using 9 drives in Raid5 for data and 4 drives in Raid
> 1+0 for logs on both machines. Both arrays have 15000 RPM
> drives.
> Both machines have SQL Server 2000. My test database is
> about 4 Gig and it is identical on both servers.
> I have a stress test script with a variety of operations
> such as bulk insert, create clustered index, calculations,
> etc.
> As you would expect, the new machine runs processor
> intensive operations much faster. But the old machine runs
> disk intensive operations faster than the new one. We had
> expected at least comparable performance.
> Overall, the test runs in 39 minutes on the old machine
> and 40 minutes on the new one (pretty close, I know, but
> the new one should win by a larger margin).
> Is there anything special about running SQL Server 2000 on
> Windows 2003 that we need to know?
> Does the Compaq drive array have some limitation that the
> Dell does not?
> Thanks
> Dave G
>
DG
quote:
>--Original Message--
>Dave,
>don't know whether you have considered the following two
variants:
quote:
>1. seek time. it is a specification of the hard drive,
and though not much,
quote:
>different drives can have different seek times. With the
rotation speed on
quote:
>the higher end, the seek times' difference plays a larger
role
quote:
>2. sorting mechanism of the RAID controllers: some
controllers support
quote:
>elevator sorting that is clearly at advantage than
without.
quote:
>hth
>Quentin
>
>"DaveG" <anonymous@.discussions.microsoft.com> wrote in
message
quote:|||You don't mention which drive arrays you have but from what I've seen of our
>news:02c701c3dae2$a256fde0$a401280a@.phx.gbl...
Raid[QUOTE]
RPM[QUOTE]
calculations,[QUOTE]
runs[QUOTE]
had[QUOTE]
on[QUOTE]
the[QUOTE]
>
>.
>
Compaq RA8000's there is more to the configuration than just the RAID level.
So it might still be something between the way the arrays are configured. If
you're familiar with IOMeter from Intel you might want to use that to test
the disk systems performance.
Also, from the tests I've seen hyperthreading isn't the same as having more
full processors, so maybe the difference in processor count plays a larger
part than expected. It may be possible that hyperthreading is actually
causing worse performance, you might want to test disabling it.
Mike Kruchten
"DaveG" <anonymous@.discussions.microsoft.com> wrote in message
news:02c701c3dae2$a256fde0$a401280a@.phx.gbl...
quote:|||> Also, from the tests I've seen hyperthreading isn't the same as having
> We have a new Compaq Proliant DL760 server running
> Windows 2003 that we bought to replace a Dell 8450
> running Windows 2000
> The new machine has 4 2.5 Ghz processors with hyper-
> threading (when you open Task Mgr it looks like it
> has 8 processors)
> The old machine has 8 P3 700 Mhz processors.
> Both machines have direct attached fiber channel
> arrays configured identically except the new one uses
> 72 Gig hard drives and the old one has 36 Gig drives.
> I am using 9 drives in Raid5 for data and 4 drives in Raid
> 1+0 for logs on both machines. Both arrays have 15000 RPM
> drives.
> Both machines have SQL Server 2000. My test database is
> about 4 Gig and it is identical on both servers.
> I have a stress test script with a variety of operations
> such as bulk insert, create clustered index, calculations,
> etc.
> As you would expect, the new machine runs processor
> intensive operations much faster. But the old machine runs
> disk intensive operations faster than the new one. We had
> expected at least comparable performance.
> Overall, the test runs in 39 minutes on the old machine
> and 40 minutes on the new one (pretty close, I know, but
> the new one should win by a larger margin).
> Is there anything special about running SQL Server 2000 on
> Windows 2003 that we need to know?
> Does the Compaq drive array have some limitation that the
> Dell does not?
> Thanks
> Dave G
>
more
quote:
> full processors, so maybe the difference in processor count plays a larger
> part than expected. It may be possible that hyperthreading is actually
> causing worse performance, you might want to test disabling it.
Absolutely right.
quote:
> "DaveG" <anonymous@.discussions.microsoft.com> wrote in message
> news:02c701c3dae2$a256fde0$a401280a@.phx.gbl...
>
Subscribe to:
Posts (Atom)