How it is with hypertrading with sql 2000, better performance when its turn on, or turn of.From what I have heard SQL Server benefits from hyperthreading in the same
way as it benefits from multiple processors... but I do not know to what
expent you might expect to see any improvement..
--
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Audrius" <reiktu@.hotmail.com> wrote in message
news:927B3DC0-A098-4701-BF8E-A64AD43D0421@.microsoft.com...
> How it is with hypertrading with sql 2000, better performance when its
turn on, or turn of.|||There's an interesting article on parallel queries at
http://www.sql-server-performance.com/jc_parallel_execution_plans.asp that
includes a section (at the bottom of the article) looking at HT performance
that might be of interest. Also if you search the forum on that site you'll
see a fair bit of discussion on HT performance
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Audrius" <reiktu@.hotmail.com> wrote in message
news:927B3DC0-A098-4701-BF8E-A64AD43D0421@.microsoft.com...
> How it is with hypertrading with sql 2000, better performance when its
turn on, or turn of.
Showing posts with label performance. Show all posts
Showing posts with label performance. Show all posts
Wednesday, March 7, 2012
Hypertrading and SQL server 2000
Labels:
database,
hypertrading,
microsoft,
mysql,
oracle,
performance,
server,
sql,
turn
Hypertrading and SQL server 2000
How it is with hypertrading with sql 2000, better performance when its turn
on, or turn of.From what I have heard SQL Server benefits from hyperthreading in the same
way as it benefits from multiple processors... but I do not know to what
expent you might expect to see any improvement..
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Audrius" <reiktu@.hotmail.com> wrote in message
news:927B3DC0-A098-4701-BF8E-A64AD43D0421@.microsoft.com...
turn on, or turn of.|||There's an interesting article on parallel queries at
http://www.sql-server-performance.c...ution_plans.asp that
includes a section (at the bottom of the article) looking at HT performance
that might be of interest. Also if you search the forum on that site you'll
see a fair bit of discussion on HT performance
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Audrius" <reiktu@.hotmail.com> wrote in message
news:927B3DC0-A098-4701-BF8E-A64AD43D0421@.microsoft.com...
turn on, or turn of.
on, or turn of.From what I have heard SQL Server benefits from hyperthreading in the same
way as it benefits from multiple processors... but I do not know to what
expent you might expect to see any improvement..
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Audrius" <reiktu@.hotmail.com> wrote in message
news:927B3DC0-A098-4701-BF8E-A64AD43D0421@.microsoft.com...
quote:
> How it is with hypertrading with sql 2000, better performance when its
turn on, or turn of.|||There's an interesting article on parallel queries at
http://www.sql-server-performance.c...ution_plans.asp that
includes a section (at the bottom of the article) looking at HT performance
that might be of interest. Also if you search the forum on that site you'll
see a fair bit of discussion on HT performance
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Audrius" <reiktu@.hotmail.com> wrote in message
news:927B3DC0-A098-4701-BF8E-A64AD43D0421@.microsoft.com...
quote:
> How it is with hypertrading with sql 2000, better performance when its
turn on, or turn of.
Labels:
database,
hypertrading,
microsoft,
mysql,
oracle,
performance,
server,
sql,
turn
Hyperthreading: Negative impact on performance?
A former colleague recently notified me about some some 'benchmark'
testing he'd conducted with SQL Server and Hyperthreading - with some
interesting results. Basically the conclusion he reached was "HT gives
performance increases some of the time but most of the time it really
screws performance and you are better off disabling it.". The results
of his test queries were as follows:
HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
HT turned off, SQL Server using all 2 CPUs = 21 secs
This pretty much goes against everything i've read about the perfomance
benefits of Hyperthreading, and I was wondering, before I start testing
on our own servers - Has anyone else had similar results (or opposite
for that matter)?
I've encountered issues with parallelism slowing queries down significantly.
If you can, ask your friend to try the same test, with HT turned on, but add
OPTION (MAXDOP 1) to the end of the queries. He should be able to compare
the query plans to determine if parallelism is at fault.
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegro ups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>
|||On 12 May 2005 07:08:55 -0700, lovemyalpacas@.gmail.com wrote:
>A former colleague recently notified me about some some 'benchmark'
>testing he'd conducted with SQL Server and Hyperthreading - with some
>interesting results. Basically the conclusion he reached was "HT gives
>performance increases some of the time but most of the time it really
>screws performance and you are better off disabling it.". The results
>of his test queries were as follows:
>HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
>HT turned off, SQL Server using all 2 CPUs = 21 secs
>This pretty much goes against everything i've read about the perfomance
>benefits of Hyperthreading, and I was wondering, before I start testing
>on our own servers - Has anyone else had similar results (or opposite
>for that matter)?
Well, first of all, if you run benchmarks on SQLServer and publish the
results, Bill Gates will come to your house in the middle of the night
and, um, personally serve you papers for an injunction for violating
your EULA.
Second, Intel wants to sell you hyperthreading because it's new and
kewl, and you can't believe everything you read.
The problem is that running two logical threads may overload the
processor cache. So for some simple but CPU bound jobs hyperthreading
might be a big win, but for complex jobs that are already memory hogs,
hyperthreading might lose big - you only have to have a few percent
more cache misses to screw up both the threads by big factors.
So what's a boy to do?
Well, I'm going to guess that for SQLServer apps, hyperthreading is
going to hurt at least as often as it helps. Until and unless Intel
is putting humongous cache on these newer chips.
Your mileage may vary.
Josh
|||Whether you get a performance boost from HT or not depends mainly on what
you are doing. The boosts come when two threads use different parts of the
processor at the same time. If the two threads try to do the same type of
action (I/O, calculations etc) then you will most likely get a decrease.
You should almost never set the MAXDOP to greater than the # of physical
procs in the machine. In some cases you may even want to restrict
processing to only the physical processors. But it really depends on the
workload. You can not run one set or series of tests and say this is how it
is. Everyone needs to test under their specific hardware config and
application usage.
Andrew J. Kelly SQL MVP
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegro ups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>
|||Hi
Yesterday at SQL PASS conference in Munich, Gert Drapers (MS Architect)
explained the issues.
The problem with a HT CPU that the 2 simultaneous threads running on the CPU
both contend for the *same* L1, L2 and L3 processor cache. During heavy
processing, you may actually have the 2 clearing each other's cache. This
results in each having to go to main system RAM to work.
So, if you have 2 physical HT processors (looks like 4 to SQL Server and the
OS), set SQL Server to use only 2 processors for parallel query execution.
Server Properties Screen, change the Parallelism setting.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegro ups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>
testing he'd conducted with SQL Server and Hyperthreading - with some
interesting results. Basically the conclusion he reached was "HT gives
performance increases some of the time but most of the time it really
screws performance and you are better off disabling it.". The results
of his test queries were as follows:
HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
HT turned off, SQL Server using all 2 CPUs = 21 secs
This pretty much goes against everything i've read about the perfomance
benefits of Hyperthreading, and I was wondering, before I start testing
on our own servers - Has anyone else had similar results (or opposite
for that matter)?
I've encountered issues with parallelism slowing queries down significantly.
If you can, ask your friend to try the same test, with HT turned on, but add
OPTION (MAXDOP 1) to the end of the queries. He should be able to compare
the query plans to determine if parallelism is at fault.
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegro ups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>
|||On 12 May 2005 07:08:55 -0700, lovemyalpacas@.gmail.com wrote:
>A former colleague recently notified me about some some 'benchmark'
>testing he'd conducted with SQL Server and Hyperthreading - with some
>interesting results. Basically the conclusion he reached was "HT gives
>performance increases some of the time but most of the time it really
>screws performance and you are better off disabling it.". The results
>of his test queries were as follows:
>HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
>HT turned off, SQL Server using all 2 CPUs = 21 secs
>This pretty much goes against everything i've read about the perfomance
>benefits of Hyperthreading, and I was wondering, before I start testing
>on our own servers - Has anyone else had similar results (or opposite
>for that matter)?
Well, first of all, if you run benchmarks on SQLServer and publish the
results, Bill Gates will come to your house in the middle of the night
and, um, personally serve you papers for an injunction for violating
your EULA.
Second, Intel wants to sell you hyperthreading because it's new and
kewl, and you can't believe everything you read.
The problem is that running two logical threads may overload the
processor cache. So for some simple but CPU bound jobs hyperthreading
might be a big win, but for complex jobs that are already memory hogs,
hyperthreading might lose big - you only have to have a few percent
more cache misses to screw up both the threads by big factors.
So what's a boy to do?
Well, I'm going to guess that for SQLServer apps, hyperthreading is
going to hurt at least as often as it helps. Until and unless Intel
is putting humongous cache on these newer chips.
Your mileage may vary.
Josh
|||Whether you get a performance boost from HT or not depends mainly on what
you are doing. The boosts come when two threads use different parts of the
processor at the same time. If the two threads try to do the same type of
action (I/O, calculations etc) then you will most likely get a decrease.
You should almost never set the MAXDOP to greater than the # of physical
procs in the machine. In some cases you may even want to restrict
processing to only the physical processors. But it really depends on the
workload. You can not run one set or series of tests and say this is how it
is. Everyone needs to test under their specific hardware config and
application usage.
Andrew J. Kelly SQL MVP
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegro ups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>
|||Hi
Yesterday at SQL PASS conference in Munich, Gert Drapers (MS Architect)
explained the issues.
The problem with a HT CPU that the 2 simultaneous threads running on the CPU
both contend for the *same* L1, L2 and L3 processor cache. During heavy
processing, you may actually have the 2 clearing each other's cache. This
results in each having to go to main system RAM to work.
So, if you have 2 physical HT processors (looks like 4 to SQL Server and the
OS), set SQL Server to use only 2 processors for parallel query execution.
Server Properties Screen, change the Parallelism setting.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegro ups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>
Hyperthreading: Negative impact on performance?
A former colleague recently notified me about some some 'benchmark'
testing he'd conducted with SQL Server and Hyperthreading - with some
interesting results. Basically the conclusion he reached was "HT gives
performance increases some of the time but most of the time it really
screws performance and you are better off disabling it.". The results
of his test queries were as follows:
HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
HT turned off, SQL Server using all 2 CPUs = 21 secs
This pretty much goes against everything i've read about the perfomance
benefits of Hyperthreading, and I was wondering, before I start testing
on our own servers - Has anyone else had similar results (or opposite
for that matter)?I've encountered issues with parallelism slowing queries down significantly.
If you can, ask your friend to try the same test, with HT turned on, but add
OPTION (MAXDOP 1) to the end of the queries. He should be able to compare
the query plans to determine if parallelism is at fault.
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegroups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>|||On 12 May 2005 07:08:55 -0700, lovemyalpacas@.gmail.com wrote:
>A former colleague recently notified me about some some 'benchmark'
>testing he'd conducted with SQL Server and Hyperthreading - with some
>interesting results. Basically the conclusion he reached was "HT gives
>performance increases some of the time but most of the time it really
>screws performance and you are better off disabling it.". The results
>of his test queries were as follows:
>HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
>HT turned off, SQL Server using all 2 CPUs = 21 secs
>This pretty much goes against everything i've read about the perfomance
>benefits of Hyperthreading, and I was wondering, before I start testing
>on our own servers - Has anyone else had similar results (or opposite
>for that matter)?
Well, first of all, if you run benchmarks on SQLServer and publish the
results, Bill Gates will come to your house in the middle of the night
and, um, personally serve you papers for an injunction for violating
your EULA.
Second, Intel wants to sell you hyperthreading because it's new and
kewl, and you can't believe everything you read.
The problem is that running two logical threads may overload the
processor cache. So for some simple but CPU bound jobs hyperthreading
might be a big win, but for complex jobs that are already memory hogs,
hyperthreading might lose big - you only have to have a few percent
more cache misses to screw up both the threads by big factors.
So what's a boy to do?
Well, I'm going to guess that for SQLServer apps, hyperthreading is
going to hurt at least as often as it helps. Until and unless Intel
is putting humongous cache on these newer chips.
Your mileage may vary.
Josh|||Whether you get a performance boost from HT or not depends mainly on what
you are doing. The boosts come when two threads use different parts of the
processor at the same time. If the two threads try to do the same type of
action (I/O, calculations etc) then you will most likely get a decrease.
You should almost never set the MAXDOP to greater than the # of physical
procs in the machine. In some cases you may even want to restrict
processing to only the physical processors. But it really depends on the
workload. You can not run one set or series of tests and say this is how it
is. Everyone needs to test under their specific hardware config and
application usage.
Andrew J. Kelly SQL MVP
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegroups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>|||Hi
Yesterday at SQL PASS conference in Munich, Gert Drapers (MS Architect)
explained the issues.
The problem with a HT CPU that the 2 simultaneous threads running on the CPU
both contend for the *same* L1, L2 and L3 processor cache. During heavy
processing, you may actually have the 2 clearing each other's cache. This
results in each having to go to main system RAM to work.
So, if you have 2 physical HT processors (looks like 4 to SQL Server and the
OS), set SQL Server to use only 2 processors for parallel query execution.
Server Properties Screen, change the Parallelism setting.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegroups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>
testing he'd conducted with SQL Server and Hyperthreading - with some
interesting results. Basically the conclusion he reached was "HT gives
performance increases some of the time but most of the time it really
screws performance and you are better off disabling it.". The results
of his test queries were as follows:
HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
HT turned off, SQL Server using all 2 CPUs = 21 secs
This pretty much goes against everything i've read about the perfomance
benefits of Hyperthreading, and I was wondering, before I start testing
on our own servers - Has anyone else had similar results (or opposite
for that matter)?I've encountered issues with parallelism slowing queries down significantly.
If you can, ask your friend to try the same test, with HT turned on, but add
OPTION (MAXDOP 1) to the end of the queries. He should be able to compare
the query plans to determine if parallelism is at fault.
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegroups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>|||On 12 May 2005 07:08:55 -0700, lovemyalpacas@.gmail.com wrote:
>A former colleague recently notified me about some some 'benchmark'
>testing he'd conducted with SQL Server and Hyperthreading - with some
>interesting results. Basically the conclusion he reached was "HT gives
>performance increases some of the time but most of the time it really
>screws performance and you are better off disabling it.". The results
>of his test queries were as follows:
>HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
>HT turned off, SQL Server using all 2 CPUs = 21 secs
>This pretty much goes against everything i've read about the perfomance
>benefits of Hyperthreading, and I was wondering, before I start testing
>on our own servers - Has anyone else had similar results (or opposite
>for that matter)?
Well, first of all, if you run benchmarks on SQLServer and publish the
results, Bill Gates will come to your house in the middle of the night
and, um, personally serve you papers for an injunction for violating
your EULA.
Second, Intel wants to sell you hyperthreading because it's new and
kewl, and you can't believe everything you read.
The problem is that running two logical threads may overload the
processor cache. So for some simple but CPU bound jobs hyperthreading
might be a big win, but for complex jobs that are already memory hogs,
hyperthreading might lose big - you only have to have a few percent
more cache misses to screw up both the threads by big factors.
So what's a boy to do?
Well, I'm going to guess that for SQLServer apps, hyperthreading is
going to hurt at least as often as it helps. Until and unless Intel
is putting humongous cache on these newer chips.
Your mileage may vary.
Josh|||Whether you get a performance boost from HT or not depends mainly on what
you are doing. The boosts come when two threads use different parts of the
processor at the same time. If the two threads try to do the same type of
action (I/O, calculations etc) then you will most likely get a decrease.
You should almost never set the MAXDOP to greater than the # of physical
procs in the machine. In some cases you may even want to restrict
processing to only the physical processors. But it really depends on the
workload. You can not run one set or series of tests and say this is how it
is. Everyone needs to test under their specific hardware config and
application usage.
Andrew J. Kelly SQL MVP
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegroups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>|||Hi
Yesterday at SQL PASS conference in Munich, Gert Drapers (MS Architect)
explained the issues.
The problem with a HT CPU that the 2 simultaneous threads running on the CPU
both contend for the *same* L1, L2 and L3 processor cache. During heavy
processing, you may actually have the 2 clearing each other's cache. This
results in each having to go to main system RAM to work.
So, if you have 2 physical HT processors (looks like 4 to SQL Server and the
OS), set SQL Server to use only 2 processors for parallel query execution.
Server Properties Screen, change the Parallelism setting.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegroups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>
Hyperthreading: Negative impact on performance?
A former colleague recently notified me about some some 'benchmark'
testing he'd conducted with SQL Server and Hyperthreading - with some
interesting results. Basically the conclusion he reached was "HT gives
performance increases some of the time but most of the time it really
screws performance and you are better off disabling it.". The results
of his test queries were as follows:
HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
HT turned off, SQL Server using all 2 CPUs = 21 secs
This pretty much goes against everything i've read about the perfomance
benefits of Hyperthreading, and I was wondering, before I start testing
on our own servers - Has anyone else had similar results (or opposite
for that matter)?I've encountered issues with parallelism slowing queries down significantly.
If you can, ask your friend to try the same test, with HT turned on, but add
OPTION (MAXDOP 1) to the end of the queries. He should be able to compare
the query plans to determine if parallelism is at fault.
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegroups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>|||On 12 May 2005 07:08:55 -0700, lovemyalpacas@.gmail.com wrote:
>A former colleague recently notified me about some some 'benchmark'
>testing he'd conducted with SQL Server and Hyperthreading - with some
>interesting results. Basically the conclusion he reached was "HT gives
>performance increases some of the time but most of the time it really
>screws performance and you are better off disabling it.". The results
>of his test queries were as follows:
>HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
>HT turned off, SQL Server using all 2 CPUs = 21 secs
>This pretty much goes against everything i've read about the perfomance
>benefits of Hyperthreading, and I was wondering, before I start testing
>on our own servers - Has anyone else had similar results (or opposite
>for that matter)?
Well, first of all, if you run benchmarks on SQLServer and publish the
results, Bill Gates will come to your house in the middle of the night
and, um, personally serve you papers for an injunction for violating
your EULA.
Second, Intel wants to sell you hyperthreading because it's new and
kewl, and you can't believe everything you read.
The problem is that running two logical threads may overload the
processor cache. So for some simple but CPU bound jobs hyperthreading
might be a big win, but for complex jobs that are already memory hogs,
hyperthreading might lose big - you only have to have a few percent
more cache misses to screw up both the threads by big factors.
So what's a boy to do?
Well, I'm going to guess that for SQLServer apps, hyperthreading is
going to hurt at least as often as it helps. Until and unless Intel
is putting humongous cache on these newer chips.
Your mileage may vary.
Josh|||Whether you get a performance boost from HT or not depends mainly on what
you are doing. The boosts come when two threads use different parts of the
processor at the same time. If the two threads try to do the same type of
action (I/O, calculations etc) then you will most likely get a decrease.
You should almost never set the MAXDOP to greater than the # of physical
procs in the machine. In some cases you may even want to restrict
processing to only the physical processors. But it really depends on the
workload. You can not run one set or series of tests and say this is how it
is. Everyone needs to test under their specific hardware config and
application usage.
--
Andrew J. Kelly SQL MVP
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegroups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>|||Hi
Yesterday at SQL PASS conference in Munich, Gert Drapers (MS Architect)
explained the issues.
The problem with a HT CPU that the 2 simultaneous threads running on the CPU
both contend for the *same* L1, L2 and L3 processor cache. During heavy
processing, you may actually have the 2 clearing each other's cache. This
results in each having to go to main system RAM to work.
So, if you have 2 physical HT processors (looks like 4 to SQL Server and the
OS), set SQL Server to use only 2 processors for parallel query execution.
Server Properties Screen, change the Parallelism setting.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegroups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>
testing he'd conducted with SQL Server and Hyperthreading - with some
interesting results. Basically the conclusion he reached was "HT gives
performance increases some of the time but most of the time it really
screws performance and you are better off disabling it.". The results
of his test queries were as follows:
HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
HT turned off, SQL Server using all 2 CPUs = 21 secs
This pretty much goes against everything i've read about the perfomance
benefits of Hyperthreading, and I was wondering, before I start testing
on our own servers - Has anyone else had similar results (or opposite
for that matter)?I've encountered issues with parallelism slowing queries down significantly.
If you can, ask your friend to try the same test, with HT turned on, but add
OPTION (MAXDOP 1) to the end of the queries. He should be able to compare
the query plans to determine if parallelism is at fault.
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegroups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>|||On 12 May 2005 07:08:55 -0700, lovemyalpacas@.gmail.com wrote:
>A former colleague recently notified me about some some 'benchmark'
>testing he'd conducted with SQL Server and Hyperthreading - with some
>interesting results. Basically the conclusion he reached was "HT gives
>performance increases some of the time but most of the time it really
>screws performance and you are better off disabling it.". The results
>of his test queries were as follows:
>HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
>HT turned off, SQL Server using all 2 CPUs = 21 secs
>This pretty much goes against everything i've read about the perfomance
>benefits of Hyperthreading, and I was wondering, before I start testing
>on our own servers - Has anyone else had similar results (or opposite
>for that matter)?
Well, first of all, if you run benchmarks on SQLServer and publish the
results, Bill Gates will come to your house in the middle of the night
and, um, personally serve you papers for an injunction for violating
your EULA.
Second, Intel wants to sell you hyperthreading because it's new and
kewl, and you can't believe everything you read.
The problem is that running two logical threads may overload the
processor cache. So for some simple but CPU bound jobs hyperthreading
might be a big win, but for complex jobs that are already memory hogs,
hyperthreading might lose big - you only have to have a few percent
more cache misses to screw up both the threads by big factors.
So what's a boy to do?
Well, I'm going to guess that for SQLServer apps, hyperthreading is
going to hurt at least as often as it helps. Until and unless Intel
is putting humongous cache on these newer chips.
Your mileage may vary.
Josh|||Whether you get a performance boost from HT or not depends mainly on what
you are doing. The boosts come when two threads use different parts of the
processor at the same time. If the two threads try to do the same type of
action (I/O, calculations etc) then you will most likely get a decrease.
You should almost never set the MAXDOP to greater than the # of physical
procs in the machine. In some cases you may even want to restrict
processing to only the physical processors. But it really depends on the
workload. You can not run one set or series of tests and say this is how it
is. Everyone needs to test under their specific hardware config and
application usage.
--
Andrew J. Kelly SQL MVP
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegroups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>|||Hi
Yesterday at SQL PASS conference in Munich, Gert Drapers (MS Architect)
explained the issues.
The problem with a HT CPU that the 2 simultaneous threads running on the CPU
both contend for the *same* L1, L2 and L3 processor cache. During heavy
processing, you may actually have the 2 clearing each other's cache. This
results in each having to go to main system RAM to work.
So, if you have 2 physical HT processors (looks like 4 to SQL Server and the
OS), set SQL Server to use only 2 processors for parallel query execution.
Server Properties Screen, change the Parallelism setting.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
<lovemyalpacas@.gmail.com> wrote in message
news:1115906935.420327.32460@.z14g2000cwz.googlegroups.com...
>A former colleague recently notified me about some some 'benchmark'
> testing he'd conducted with SQL Server and Hyperthreading - with some
> interesting results. Basically the conclusion he reached was "HT gives
> performance increases some of the time but most of the time it really
> screws performance and you are better off disabling it.". The results
> of his test queries were as follows:
> HT turned on, SQL Server using all 4 logical CPUs = 2 mins 41 secs
> HT turned off, SQL Server using all 2 CPUs = 21 secs
> This pretty much goes against everything i've read about the perfomance
> benefits of Hyperthreading, and I was wondering, before I start testing
> on our own servers - Has anyone else had similar results (or opposite
> for that matter)?
>
Hyperthreading killing performance of simple query?
We have a new server, 4 physical dual core processors, with hyperthreading,
so it shows up as 16 logical processors.
A simple query joining 3 tables, a distinct, an order by, with maxdop set to
0, takes over 2 seconds. With maxdop set to 1, it takes 200 milliseconds.
setting maxdop between 1 and 15, pretty linear time progression.
Does this sound sane? Is there some magic matrix where under load a higher
maxdop will result in this simple query running faster than where there is
no load (the current case)
Thanks in advance!
Derrick
Derrick,
It is true: Parallelism does not alway help. In fact, for some queries it
may make them perform abysmally.
Although I do not do this personally, several posters recommend setting an
OLTP server to a maximum degree of parallelism of 1. They indicate good
success and few discernable problems because of the setting.
I do follow the guideline to limit the server's maximum degree of
parallelism to the number of physical chips, which in your case would be 4.
Then, if a query is troubled we can specifically run it at MAXDOP 1.
FWIW,
RLF
"Derrick" <derrick1298@.excite.com> wrote in message
news:%23E%23LO250HHA.5644@.TK2MSFTNGP05.phx.gbl...
> We have a new server, 4 physical dual core processors, with
> hyperthreading, so it shows up as 16 logical processors.
> A simple query joining 3 tables, a distinct, an order by, with maxdop set
> to 0, takes over 2 seconds. With maxdop set to 1, it takes 200
> milliseconds. setting maxdop between 1 and 15, pretty linear time
> progression.
> Does this sound sane? Is there some magic matrix where under load a
> higher maxdop will result in this simple query running faster than where
> there is no load (the current case)
> Thanks in advance!
> Derrick
>
|||Russell,
Thanks for the info, one more q, so would you reccomend hyperthreading be
enabled, or disabled?
We ran tests both ways and turning hyperthreading off does not seem the way
to go based on our results, does that match up with what you have seen/read?
Thanks again,
Derrick
"Russell Fields" <russellfields@.nomail.com> wrote in message
news:eJddSQ60HHA.3788@.TK2MSFTNGP02.phx.gbl...
> Derrick,
> It is true: Parallelism does not alway help. In fact, for some queries it
> may make them perform abysmally.
> Although I do not do this personally, several posters recommend setting an
> OLTP server to a maximum degree of parallelism of 1. They indicate good
> success and few discernable problems because of the setting.
> I do follow the guideline to limit the server's maximum degree of
> parallelism to the number of physical chips, which in your case would be
> 4. Then, if a query is troubled we can specifically run it at MAXDOP 1.
> FWIW,
> RLF
> "Derrick" <derrick1298@.excite.com> wrote in message
> news:%23E%23LO250HHA.5644@.TK2MSFTNGP05.phx.gbl...
>
|||Derrick,
Lara Rubbelke made these comments:
http://blogs.digineer.com/blogs/larar/archive/2006/11/13/maximum-degree-of-parallelism-and-hyperthreading.aspx
He links to Slava Ok's
http://blogs.msdn.com/slavao/archive/2005/11/12/492119.aspx
Their bottom seems to be, do not enable hyperthreading unless you have
proved it will help you.
RLF
"Derrick" <derrick1298@.excite.com> wrote in message
news:u1F0WU60HHA.464@.TK2MSFTNGP02.phx.gbl...
> Russell,
> Thanks for the info, one more q, so would you reccomend hyperthreading be
> enabled, or disabled?
> We ran tests both ways and turning hyperthreading off does not seem the
> way to go based on our results, does that match up with what you have
> seen/read?
> Thanks again,
> Derrick
>
> "Russell Fields" <russellfields@.nomail.com> wrote in message
> news:eJddSQ60HHA.3788@.TK2MSFTNGP02.phx.gbl...
>
so it shows up as 16 logical processors.
A simple query joining 3 tables, a distinct, an order by, with maxdop set to
0, takes over 2 seconds. With maxdop set to 1, it takes 200 milliseconds.
setting maxdop between 1 and 15, pretty linear time progression.
Does this sound sane? Is there some magic matrix where under load a higher
maxdop will result in this simple query running faster than where there is
no load (the current case)
Thanks in advance!
Derrick
Derrick,
It is true: Parallelism does not alway help. In fact, for some queries it
may make them perform abysmally.
Although I do not do this personally, several posters recommend setting an
OLTP server to a maximum degree of parallelism of 1. They indicate good
success and few discernable problems because of the setting.
I do follow the guideline to limit the server's maximum degree of
parallelism to the number of physical chips, which in your case would be 4.
Then, if a query is troubled we can specifically run it at MAXDOP 1.
FWIW,
RLF
"Derrick" <derrick1298@.excite.com> wrote in message
news:%23E%23LO250HHA.5644@.TK2MSFTNGP05.phx.gbl...
> We have a new server, 4 physical dual core processors, with
> hyperthreading, so it shows up as 16 logical processors.
> A simple query joining 3 tables, a distinct, an order by, with maxdop set
> to 0, takes over 2 seconds. With maxdop set to 1, it takes 200
> milliseconds. setting maxdop between 1 and 15, pretty linear time
> progression.
> Does this sound sane? Is there some magic matrix where under load a
> higher maxdop will result in this simple query running faster than where
> there is no load (the current case)
> Thanks in advance!
> Derrick
>
|||Russell,
Thanks for the info, one more q, so would you reccomend hyperthreading be
enabled, or disabled?
We ran tests both ways and turning hyperthreading off does not seem the way
to go based on our results, does that match up with what you have seen/read?
Thanks again,
Derrick
"Russell Fields" <russellfields@.nomail.com> wrote in message
news:eJddSQ60HHA.3788@.TK2MSFTNGP02.phx.gbl...
> Derrick,
> It is true: Parallelism does not alway help. In fact, for some queries it
> may make them perform abysmally.
> Although I do not do this personally, several posters recommend setting an
> OLTP server to a maximum degree of parallelism of 1. They indicate good
> success and few discernable problems because of the setting.
> I do follow the guideline to limit the server's maximum degree of
> parallelism to the number of physical chips, which in your case would be
> 4. Then, if a query is troubled we can specifically run it at MAXDOP 1.
> FWIW,
> RLF
> "Derrick" <derrick1298@.excite.com> wrote in message
> news:%23E%23LO250HHA.5644@.TK2MSFTNGP05.phx.gbl...
>
|||Derrick,
Lara Rubbelke made these comments:
http://blogs.digineer.com/blogs/larar/archive/2006/11/13/maximum-degree-of-parallelism-and-hyperthreading.aspx
He links to Slava Ok's
http://blogs.msdn.com/slavao/archive/2005/11/12/492119.aspx
Their bottom seems to be, do not enable hyperthreading unless you have
proved it will help you.
RLF
"Derrick" <derrick1298@.excite.com> wrote in message
news:u1F0WU60HHA.464@.TK2MSFTNGP02.phx.gbl...
> Russell,
> Thanks for the info, one more q, so would you reccomend hyperthreading be
> enabled, or disabled?
> We ran tests both ways and turning hyperthreading off does not seem the
> way to go based on our results, does that match up with what you have
> seen/read?
> Thanks again,
> Derrick
>
> "Russell Fields" <russellfields@.nomail.com> wrote in message
> news:eJddSQ60HHA.3788@.TK2MSFTNGP02.phx.gbl...
>
Hyperthreading killing performance of simple query?
We have a new server, 4 physical dual core processors, with hyperthreading,
so it shows up as 16 logical processors.
A simple query joining 3 tables, a distinct, an order by, with maxdop set to
0, takes over 2 seconds. With maxdop set to 1, it takes 200 milliseconds.
setting maxdop between 1 and 15, pretty linear time progression.
Does this sound sane? Is there some magic matrix where under load a higher
maxdop will result in this simple query running faster than where there is
no load (the current case)
Thanks in advance!
DerrickDerrick,
It is true: Parallelism does not alway help. In fact, for some queries it
may make them perform abysmally.
Although I do not do this personally, several posters recommend setting an
OLTP server to a maximum degree of parallelism of 1. They indicate good
success and few discernable problems because of the setting.
I do follow the guideline to limit the server's maximum degree of
parallelism to the number of physical chips, which in your case would be 4.
Then, if a query is troubled we can specifically run it at MAXDOP 1.
FWIW,
RLF
"Derrick" <derrick1298@.excite.com> wrote in message
news:%23E%23LO250HHA.5644@.TK2MSFTNGP05.phx.gbl...
> We have a new server, 4 physical dual core processors, with
> hyperthreading, so it shows up as 16 logical processors.
> A simple query joining 3 tables, a distinct, an order by, with maxdop set
> to 0, takes over 2 seconds. With maxdop set to 1, it takes 200
> milliseconds. setting maxdop between 1 and 15, pretty linear time
> progression.
> Does this sound sane? Is there some magic matrix where under load a
> higher maxdop will result in this simple query running faster than where
> there is no load (the current case)
> Thanks in advance!
> Derrick
>|||Russell,
Thanks for the info, one more q, so would you reccomend hyperthreading be
enabled, or disabled?
We ran tests both ways and turning hyperthreading off does not seem the way
to go based on our results, does that match up with what you have seen/read?
Thanks again,
Derrick
"Russell Fields" <russellfields@.nomail.com> wrote in message
news:eJddSQ60HHA.3788@.TK2MSFTNGP02.phx.gbl...
> Derrick,
> It is true: Parallelism does not alway help. In fact, for some queries it
> may make them perform abysmally.
> Although I do not do this personally, several posters recommend setting an
> OLTP server to a maximum degree of parallelism of 1. They indicate good
> success and few discernable problems because of the setting.
> I do follow the guideline to limit the server's maximum degree of
> parallelism to the number of physical chips, which in your case would be
> 4. Then, if a query is troubled we can specifically run it at MAXDOP 1.
> FWIW,
> RLF
> "Derrick" <derrick1298@.excite.com> wrote in message
> news:%23E%23LO250HHA.5644@.TK2MSFTNGP05.phx.gbl...
>> We have a new server, 4 physical dual core processors, with
>> hyperthreading, so it shows up as 16 logical processors.
>> A simple query joining 3 tables, a distinct, an order by, with maxdop set
>> to 0, takes over 2 seconds. With maxdop set to 1, it takes 200
>> milliseconds. setting maxdop between 1 and 15, pretty linear time
>> progression.
>> Does this sound sane? Is there some magic matrix where under load a
>> higher maxdop will result in this simple query running faster than where
>> there is no load (the current case)
>> Thanks in advance!
>> Derrick
>|||Derrick,
Lara Rubbelke made these comments:
http://blogs.digineer.com/blogs/larar/archive/2006/11/13/maximum-degree-of-parallelism-and-hyperthreading.aspx
He links to Slava Ok's
http://blogs.msdn.com/slavao/archive/2005/11/12/492119.aspx
Their bottom seems to be, do not enable hyperthreading unless you have
proved it will help you.
RLF
"Derrick" <derrick1298@.excite.com> wrote in message
news:u1F0WU60HHA.464@.TK2MSFTNGP02.phx.gbl...
> Russell,
> Thanks for the info, one more q, so would you reccomend hyperthreading be
> enabled, or disabled?
> We ran tests both ways and turning hyperthreading off does not seem the
> way to go based on our results, does that match up with what you have
> seen/read?
> Thanks again,
> Derrick
>
> "Russell Fields" <russellfields@.nomail.com> wrote in message
> news:eJddSQ60HHA.3788@.TK2MSFTNGP02.phx.gbl...
>> Derrick,
>> It is true: Parallelism does not alway help. In fact, for some queries it
>> may make them perform abysmally.
>> Although I do not do this personally, several posters recommend setting
>> an OLTP server to a maximum degree of parallelism of 1. They indicate
>> good success and few discernable problems because of the setting.
>> I do follow the guideline to limit the server's maximum degree of
>> parallelism to the number of physical chips, which in your case would be
>> 4. Then, if a query is troubled we can specifically run it at MAXDOP 1.
>> FWIW,
>> RLF
>> "Derrick" <derrick1298@.excite.com> wrote in message
>> news:%23E%23LO250HHA.5644@.TK2MSFTNGP05.phx.gbl...
>> We have a new server, 4 physical dual core processors, with
>> hyperthreading, so it shows up as 16 logical processors.
>> A simple query joining 3 tables, a distinct, an order by, with maxdop
>> set to 0, takes over 2 seconds. With maxdop set to 1, it takes 200
>> milliseconds. setting maxdop between 1 and 15, pretty linear time
>> progression.
>> Does this sound sane? Is there some magic matrix where under load a
>> higher maxdop will result in this simple query running faster than where
>> there is no load (the current case)
>> Thanks in advance!
>> Derrick
>>
>
so it shows up as 16 logical processors.
A simple query joining 3 tables, a distinct, an order by, with maxdop set to
0, takes over 2 seconds. With maxdop set to 1, it takes 200 milliseconds.
setting maxdop between 1 and 15, pretty linear time progression.
Does this sound sane? Is there some magic matrix where under load a higher
maxdop will result in this simple query running faster than where there is
no load (the current case)
Thanks in advance!
DerrickDerrick,
It is true: Parallelism does not alway help. In fact, for some queries it
may make them perform abysmally.
Although I do not do this personally, several posters recommend setting an
OLTP server to a maximum degree of parallelism of 1. They indicate good
success and few discernable problems because of the setting.
I do follow the guideline to limit the server's maximum degree of
parallelism to the number of physical chips, which in your case would be 4.
Then, if a query is troubled we can specifically run it at MAXDOP 1.
FWIW,
RLF
"Derrick" <derrick1298@.excite.com> wrote in message
news:%23E%23LO250HHA.5644@.TK2MSFTNGP05.phx.gbl...
> We have a new server, 4 physical dual core processors, with
> hyperthreading, so it shows up as 16 logical processors.
> A simple query joining 3 tables, a distinct, an order by, with maxdop set
> to 0, takes over 2 seconds. With maxdop set to 1, it takes 200
> milliseconds. setting maxdop between 1 and 15, pretty linear time
> progression.
> Does this sound sane? Is there some magic matrix where under load a
> higher maxdop will result in this simple query running faster than where
> there is no load (the current case)
> Thanks in advance!
> Derrick
>|||Russell,
Thanks for the info, one more q, so would you reccomend hyperthreading be
enabled, or disabled?
We ran tests both ways and turning hyperthreading off does not seem the way
to go based on our results, does that match up with what you have seen/read?
Thanks again,
Derrick
"Russell Fields" <russellfields@.nomail.com> wrote in message
news:eJddSQ60HHA.3788@.TK2MSFTNGP02.phx.gbl...
> Derrick,
> It is true: Parallelism does not alway help. In fact, for some queries it
> may make them perform abysmally.
> Although I do not do this personally, several posters recommend setting an
> OLTP server to a maximum degree of parallelism of 1. They indicate good
> success and few discernable problems because of the setting.
> I do follow the guideline to limit the server's maximum degree of
> parallelism to the number of physical chips, which in your case would be
> 4. Then, if a query is troubled we can specifically run it at MAXDOP 1.
> FWIW,
> RLF
> "Derrick" <derrick1298@.excite.com> wrote in message
> news:%23E%23LO250HHA.5644@.TK2MSFTNGP05.phx.gbl...
>> We have a new server, 4 physical dual core processors, with
>> hyperthreading, so it shows up as 16 logical processors.
>> A simple query joining 3 tables, a distinct, an order by, with maxdop set
>> to 0, takes over 2 seconds. With maxdop set to 1, it takes 200
>> milliseconds. setting maxdop between 1 and 15, pretty linear time
>> progression.
>> Does this sound sane? Is there some magic matrix where under load a
>> higher maxdop will result in this simple query running faster than where
>> there is no load (the current case)
>> Thanks in advance!
>> Derrick
>|||Derrick,
Lara Rubbelke made these comments:
http://blogs.digineer.com/blogs/larar/archive/2006/11/13/maximum-degree-of-parallelism-and-hyperthreading.aspx
He links to Slava Ok's
http://blogs.msdn.com/slavao/archive/2005/11/12/492119.aspx
Their bottom seems to be, do not enable hyperthreading unless you have
proved it will help you.
RLF
"Derrick" <derrick1298@.excite.com> wrote in message
news:u1F0WU60HHA.464@.TK2MSFTNGP02.phx.gbl...
> Russell,
> Thanks for the info, one more q, so would you reccomend hyperthreading be
> enabled, or disabled?
> We ran tests both ways and turning hyperthreading off does not seem the
> way to go based on our results, does that match up with what you have
> seen/read?
> Thanks again,
> Derrick
>
> "Russell Fields" <russellfields@.nomail.com> wrote in message
> news:eJddSQ60HHA.3788@.TK2MSFTNGP02.phx.gbl...
>> Derrick,
>> It is true: Parallelism does not alway help. In fact, for some queries it
>> may make them perform abysmally.
>> Although I do not do this personally, several posters recommend setting
>> an OLTP server to a maximum degree of parallelism of 1. They indicate
>> good success and few discernable problems because of the setting.
>> I do follow the guideline to limit the server's maximum degree of
>> parallelism to the number of physical chips, which in your case would be
>> 4. Then, if a query is troubled we can specifically run it at MAXDOP 1.
>> FWIW,
>> RLF
>> "Derrick" <derrick1298@.excite.com> wrote in message
>> news:%23E%23LO250HHA.5644@.TK2MSFTNGP05.phx.gbl...
>> We have a new server, 4 physical dual core processors, with
>> hyperthreading, so it shows up as 16 logical processors.
>> A simple query joining 3 tables, a distinct, an order by, with maxdop
>> set to 0, takes over 2 seconds. With maxdop set to 1, it takes 200
>> milliseconds. setting maxdop between 1 and 15, pretty linear time
>> progression.
>> Does this sound sane? Is there some magic matrix where under load a
>> higher maxdop will result in this simple query running faster than where
>> there is no load (the current case)
>> Thanks in advance!
>> Derrick
>>
>
Hyperthreading killing performance of simple query?
We have a new server, 4 physical dual core processors, with hyperthreading,
so it shows up as 16 logical processors.
A simple query joining 3 tables, a distinct, an order by, with maxdop set to
0, takes over 2 seconds. With maxdop set to 1, it takes 200 milliseconds.
setting maxdop between 1 and 15, pretty linear time progression.
Does this sound sane? Is there some magic matrix where under load a higher
maxdop will result in this simple query running faster than where there is
no load (the current case)
Thanks in advance!
DerrickDerrick,
It is true: Parallelism does not alway help. In fact, for some queries it
may make them perform abysmally.
Although I do not do this personally, several posters recommend setting an
OLTP server to a maximum degree of parallelism of 1. They indicate good
success and few discernable problems because of the setting.
I do follow the guideline to limit the server's maximum degree of
parallelism to the number of physical chips, which in your case would be 4.
Then, if a query is troubled we can specifically run it at MAXDOP 1.
FWIW,
RLF
"Derrick" <derrick1298@.excite.com> wrote in message
news:%23E%23LO250HHA.5644@.TK2MSFTNGP05.phx.gbl...
> We have a new server, 4 physical dual core processors, with
> hyperthreading, so it shows up as 16 logical processors.
> A simple query joining 3 tables, a distinct, an order by, with maxdop set
> to 0, takes over 2 seconds. With maxdop set to 1, it takes 200
> milliseconds. setting maxdop between 1 and 15, pretty linear time
> progression.
> Does this sound sane? Is there some magic matrix where under load a
> higher maxdop will result in this simple query running faster than where
> there is no load (the current case)
> Thanks in advance!
> Derrick
>|||Russell,
Thanks for the info, one more q, so would you reccomend hyperthreading be
enabled, or disabled?
We ran tests both ways and turning hyperthreading off does not seem the way
to go based on our results, does that match up with what you have seen/read?
Thanks again,
Derrick
"Russell Fields" <russellfields@.nomail.com> wrote in message
news:eJddSQ60HHA.3788@.TK2MSFTNGP02.phx.gbl...
> Derrick,
> It is true: Parallelism does not alway help. In fact, for some queries it
> may make them perform abysmally.
> Although I do not do this personally, several posters recommend setting an
> OLTP server to a maximum degree of parallelism of 1. They indicate good
> success and few discernable problems because of the setting.
> I do follow the guideline to limit the server's maximum degree of
> parallelism to the number of physical chips, which in your case would be
> 4. Then, if a query is troubled we can specifically run it at MAXDOP 1.
> FWIW,
> RLF
> "Derrick" <derrick1298@.excite.com> wrote in message
> news:%23E%23LO250HHA.5644@.TK2MSFTNGP05.phx.gbl...
>|||Derrick,
Lara Rubbelke made these comments:
http://blogs.digineer.com/blogs/lar...rthreading.aspx
He links to Slava Ok's
http://blogs.msdn.com/slavao/archiv.../12/492119.aspx
Their bottom seems to be, do not enable hyperthreading unless you have
proved it will help you.
RLF
"Derrick" <derrick1298@.excite.com> wrote in message
news:u1F0WU60HHA.464@.TK2MSFTNGP02.phx.gbl...
> Russell,
> Thanks for the info, one more q, so would you reccomend hyperthreading be
> enabled, or disabled?
> We ran tests both ways and turning hyperthreading off does not seem the
> way to go based on our results, does that match up with what you have
> seen/read?
> Thanks again,
> Derrick
>
> "Russell Fields" <russellfields@.nomail.com> wrote in message
> news:eJddSQ60HHA.3788@.TK2MSFTNGP02.phx.gbl...
>
so it shows up as 16 logical processors.
A simple query joining 3 tables, a distinct, an order by, with maxdop set to
0, takes over 2 seconds. With maxdop set to 1, it takes 200 milliseconds.
setting maxdop between 1 and 15, pretty linear time progression.
Does this sound sane? Is there some magic matrix where under load a higher
maxdop will result in this simple query running faster than where there is
no load (the current case)
Thanks in advance!
DerrickDerrick,
It is true: Parallelism does not alway help. In fact, for some queries it
may make them perform abysmally.
Although I do not do this personally, several posters recommend setting an
OLTP server to a maximum degree of parallelism of 1. They indicate good
success and few discernable problems because of the setting.
I do follow the guideline to limit the server's maximum degree of
parallelism to the number of physical chips, which in your case would be 4.
Then, if a query is troubled we can specifically run it at MAXDOP 1.
FWIW,
RLF
"Derrick" <derrick1298@.excite.com> wrote in message
news:%23E%23LO250HHA.5644@.TK2MSFTNGP05.phx.gbl...
> We have a new server, 4 physical dual core processors, with
> hyperthreading, so it shows up as 16 logical processors.
> A simple query joining 3 tables, a distinct, an order by, with maxdop set
> to 0, takes over 2 seconds. With maxdop set to 1, it takes 200
> milliseconds. setting maxdop between 1 and 15, pretty linear time
> progression.
> Does this sound sane? Is there some magic matrix where under load a
> higher maxdop will result in this simple query running faster than where
> there is no load (the current case)
> Thanks in advance!
> Derrick
>|||Russell,
Thanks for the info, one more q, so would you reccomend hyperthreading be
enabled, or disabled?
We ran tests both ways and turning hyperthreading off does not seem the way
to go based on our results, does that match up with what you have seen/read?
Thanks again,
Derrick
"Russell Fields" <russellfields@.nomail.com> wrote in message
news:eJddSQ60HHA.3788@.TK2MSFTNGP02.phx.gbl...
> Derrick,
> It is true: Parallelism does not alway help. In fact, for some queries it
> may make them perform abysmally.
> Although I do not do this personally, several posters recommend setting an
> OLTP server to a maximum degree of parallelism of 1. They indicate good
> success and few discernable problems because of the setting.
> I do follow the guideline to limit the server's maximum degree of
> parallelism to the number of physical chips, which in your case would be
> 4. Then, if a query is troubled we can specifically run it at MAXDOP 1.
> FWIW,
> RLF
> "Derrick" <derrick1298@.excite.com> wrote in message
> news:%23E%23LO250HHA.5644@.TK2MSFTNGP05.phx.gbl...
>|||Derrick,
Lara Rubbelke made these comments:
http://blogs.digineer.com/blogs/lar...rthreading.aspx
He links to Slava Ok's
http://blogs.msdn.com/slavao/archiv.../12/492119.aspx
Their bottom seems to be, do not enable hyperthreading unless you have
proved it will help you.
RLF
"Derrick" <derrick1298@.excite.com> wrote in message
news:u1F0WU60HHA.464@.TK2MSFTNGP02.phx.gbl...
> Russell,
> Thanks for the info, one more q, so would you reccomend hyperthreading be
> enabled, or disabled?
> We ran tests both ways and turning hyperthreading off does not seem the
> way to go based on our results, does that match up with what you have
> seen/read?
> Thanks again,
> Derrick
>
> "Russell Fields" <russellfields@.nomail.com> wrote in message
> news:eJddSQ60HHA.3788@.TK2MSFTNGP02.phx.gbl...
>
Subscribe to:
Posts (Atom)