Hi,
Licensing wise, if a server has 2 physical CPU's that hyperthreaded, how
many licenses need to be configured in SQL interface.
I know we need to buy 2, but does SQL 2000 recognize that the 4 CPU's
showing are really 2 physical CPU's...
Thanks !!!
SQL Licensing is per physical CPU 'Socket'.
Dual core, hyperthreaded processors can be seen as four (4) processors by
the OS (and SQL Server) -BUT only require a single license.
There is a Computer GOD!
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
You can't help someone get up a hill without getting a little closer to the
top yourself.
- H. Norman Schwarzkopf
"Thinkpad21" <thinkpad21@.yahoo.com> wrote in message
news:ukXwjFuHHHA.1264@.TK2MSFTNGP03.phx.gbl...
> Hi,
> Licensing wise, if a server has 2 physical CPU's that hyperthreaded, how
> many licenses need to be configured in SQL interface.
> I know we need to buy 2, but does SQL 2000 recognize that the 4 CPU's
> showing are really 2 physical CPU's...
> Thanks !!!
>
|||Thinkpad21 wrote:
> Hi,
> Licensing wise, if a server has 2 physical CPU's that hyperthreaded, how
> many licenses need to be configured in SQL interface.
> I know we need to buy 2, but does SQL 2000 recognize that the 4 CPU's
> showing are really 2 physical CPU's...
Regardless of how you license it SQL Server can use all processors. It
is your repsonsibility to license them correctly (i.e. per physical
processor).
For optimum performance with HT it is important that you mask 2 of the
logical processors so that SQL Server will not attempt to use more than
that number. 2 x HT CPUs is NOT the same as 4 cores.
See: http://support.microsoft.com/kb/322385
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
Showing posts with label cpus. Show all posts
Showing posts with label cpus. Show all posts
Wednesday, March 7, 2012
Hyperthreading
Hi,
We are using a quad Xeon with hyperthreading. Windows 2000 and SQL Server "see" 8 processors. We have scheduled SQL to only use CPUs 0,1,2,3. The server is a dedicated database server. Has anyone done much work with hyperthreading? Is our approach sensible?
Ken"Ken Ng" <anonymous@.discussions.microsoft.com> wrote in message
news:72043C98-B317-4CA2-A97D-36AC17A5ABA0@.microsoft.com...
> Hi,
> We are using a quad Xeon with hyperthreading. Windows 2000 and SQL Server
"see" 8 processors. We have scheduled SQL to only use CPUs 0,1,2,3. The
server is a dedicated database server. Has anyone done much work with
hyperthreading? Is our approach sensible?
>
This will essentially disable hyperthreading for SQL server since CPUs
0,1,2,3 are the first logical processesors on each chip. So the system will
run basically like a non-hyperthreading 4-way server.
But you should get better performance if you let SQL Server schedule threads
on all 8 logical processors. The point of HT is that scheduling 2 threads
on each physical processor allows a higher utilization of internal CPU
resources, and results in a higher throughput than switching between the 2
threads.
David|||i have not found anything in SQL Server that benefits from
HT in a useful manner.
however, HT and parallel execution plans may in certain
circumstances have potentially crippling effect.
i suggest that HT be disabled unless you have conducted a
reasonably comphrensive test on whether there are any ill
effects
>--Original Message--
>Hi,
>We are using a quad Xeon with hyperthreading. Windows
2000 and SQL Server "see" 8 processors. We have scheduled
SQL to only use CPUs 0,1,2,3. The server is a dedicated
database server. Has anyone done much work with
hyperthreading? Is our approach sensible?
>Ken
>.
>|||In my tests performance with HT switched ON was about 15%
WORSE than with HT switched OFF. Physical processor is a
physical processor and when SQL Server creates parallel
execution plan and is trying to run simultaneously two
subqueries on the same physical processor, it creates a
bottleneck.
Cheers,
Alex|||I have no evidence for this, but if parallellism is not used (for
example just OLTP), then I expect a HT system to perform 15% better than
the same system with HT disabled. If parallellism is used (sometimes),
then I guess it is better to turn off HT.
Gert-Jan
joe chang wrote:
> i have not found anything in SQL Server that benefits from
> HT in a useful manner.
> however, HT and parallel execution plans may in certain
> circumstances have potentially crippling effect.
> i suggest that HT be disabled unless you have conducted a
> reasonably comphrensive test on whether there are any ill
> effects
> >--Original Message--
> >Hi,
> >
> >We are using a quad Xeon with hyperthreading. Windows
> 2000 and SQL Server "see" 8 processors. We have scheduled
> SQL to only use CPUs 0,1,2,3. The server is a dedicated
> database server. Has anyone done much work with
> hyperthreading? Is our approach sensible?
> >
> >Ken
> >.
> >|||> This will essentially disable hyperthreading for SQL server since CPUs
> 0,1,2,3 are the first logical processesors on each chip. So the system will
> run basically like a non-hyperthreading 4-way server.
However, the OS can still use the other 4 logical processors.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in message
news:e1d$qQPuDHA.2448@.TK2MSFTNGP09.phx.gbl...
> "Ken Ng" <anonymous@.discussions.microsoft.com> wrote in message
> news:72043C98-B317-4CA2-A97D-36AC17A5ABA0@.microsoft.com...
> > Hi,
> >
> > We are using a quad Xeon with hyperthreading. Windows 2000 and SQL Server
> "see" 8 processors. We have scheduled SQL to only use CPUs 0,1,2,3. The
> server is a dedicated database server. Has anyone done much work with
> hyperthreading? Is our approach sensible?
> >
> This will essentially disable hyperthreading for SQL server since CPUs
> 0,1,2,3 are the first logical processesors on each chip. So the system will
> run basically like a non-hyperthreading 4-way server.
> But you should get better performance if you let SQL Server schedule threads
> on all 8 logical processors. The point of HT is that scheduling 2 threads
> on each physical processor allows a higher utilization of internal CPU
> resources, and results in a higher throughput than switching between the 2
> threads.
> David
>|||Thanks for the replies folks. From the discussion I deduce that HT may not be that beneficial for SQL per se. In our case, by limiting SQL to CPU 0,1,2,3 we seem to be disabling HT for SQL but enabling the extra 4 (logical) processors i.e. CPU 4,5,6,7 to be used by the o/s. This seems to be a reasonable approach
Many Thank
Ken Ng
We are using a quad Xeon with hyperthreading. Windows 2000 and SQL Server "see" 8 processors. We have scheduled SQL to only use CPUs 0,1,2,3. The server is a dedicated database server. Has anyone done much work with hyperthreading? Is our approach sensible?
Ken"Ken Ng" <anonymous@.discussions.microsoft.com> wrote in message
news:72043C98-B317-4CA2-A97D-36AC17A5ABA0@.microsoft.com...
> Hi,
> We are using a quad Xeon with hyperthreading. Windows 2000 and SQL Server
"see" 8 processors. We have scheduled SQL to only use CPUs 0,1,2,3. The
server is a dedicated database server. Has anyone done much work with
hyperthreading? Is our approach sensible?
>
This will essentially disable hyperthreading for SQL server since CPUs
0,1,2,3 are the first logical processesors on each chip. So the system will
run basically like a non-hyperthreading 4-way server.
But you should get better performance if you let SQL Server schedule threads
on all 8 logical processors. The point of HT is that scheduling 2 threads
on each physical processor allows a higher utilization of internal CPU
resources, and results in a higher throughput than switching between the 2
threads.
David|||i have not found anything in SQL Server that benefits from
HT in a useful manner.
however, HT and parallel execution plans may in certain
circumstances have potentially crippling effect.
i suggest that HT be disabled unless you have conducted a
reasonably comphrensive test on whether there are any ill
effects
>--Original Message--
>Hi,
>We are using a quad Xeon with hyperthreading. Windows
2000 and SQL Server "see" 8 processors. We have scheduled
SQL to only use CPUs 0,1,2,3. The server is a dedicated
database server. Has anyone done much work with
hyperthreading? Is our approach sensible?
>Ken
>.
>|||In my tests performance with HT switched ON was about 15%
WORSE than with HT switched OFF. Physical processor is a
physical processor and when SQL Server creates parallel
execution plan and is trying to run simultaneously two
subqueries on the same physical processor, it creates a
bottleneck.
Cheers,
Alex|||I have no evidence for this, but if parallellism is not used (for
example just OLTP), then I expect a HT system to perform 15% better than
the same system with HT disabled. If parallellism is used (sometimes),
then I guess it is better to turn off HT.
Gert-Jan
joe chang wrote:
> i have not found anything in SQL Server that benefits from
> HT in a useful manner.
> however, HT and parallel execution plans may in certain
> circumstances have potentially crippling effect.
> i suggest that HT be disabled unless you have conducted a
> reasonably comphrensive test on whether there are any ill
> effects
> >--Original Message--
> >Hi,
> >
> >We are using a quad Xeon with hyperthreading. Windows
> 2000 and SQL Server "see" 8 processors. We have scheduled
> SQL to only use CPUs 0,1,2,3. The server is a dedicated
> database server. Has anyone done much work with
> hyperthreading? Is our approach sensible?
> >
> >Ken
> >.
> >|||> This will essentially disable hyperthreading for SQL server since CPUs
> 0,1,2,3 are the first logical processesors on each chip. So the system will
> run basically like a non-hyperthreading 4-way server.
However, the OS can still use the other 4 logical processors.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in message
news:e1d$qQPuDHA.2448@.TK2MSFTNGP09.phx.gbl...
> "Ken Ng" <anonymous@.discussions.microsoft.com> wrote in message
> news:72043C98-B317-4CA2-A97D-36AC17A5ABA0@.microsoft.com...
> > Hi,
> >
> > We are using a quad Xeon with hyperthreading. Windows 2000 and SQL Server
> "see" 8 processors. We have scheduled SQL to only use CPUs 0,1,2,3. The
> server is a dedicated database server. Has anyone done much work with
> hyperthreading? Is our approach sensible?
> >
> This will essentially disable hyperthreading for SQL server since CPUs
> 0,1,2,3 are the first logical processesors on each chip. So the system will
> run basically like a non-hyperthreading 4-way server.
> But you should get better performance if you let SQL Server schedule threads
> on all 8 logical processors. The point of HT is that scheduling 2 threads
> on each physical processor allows a higher utilization of internal CPU
> resources, and results in a higher throughput than switching between the 2
> threads.
> David
>|||Thanks for the replies folks. From the discussion I deduce that HT may not be that beneficial for SQL per se. In our case, by limiting SQL to CPU 0,1,2,3 we seem to be disabling HT for SQL but enabling the extra 4 (logical) processors i.e. CPU 4,5,6,7 to be used by the o/s. This seems to be a reasonable approach
Many Thank
Ken Ng
Hyperthreaded CPU's
Hi,
This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a
server with 3 hyperthreaded CPUs that will show as 6 CPU's to SQL2000 SP3A.
I am lead to believe that logical CPU's 0, 2 and 4 are the physical CPU's.
If I uncheck CPU's 1, 3 and 5 but keep the Use All Available Processors
checked I am restricting SQL to only using the 3 physical processors and
reducing the horsepower available to SQL to half. Is this statement true?
Thanks
Chris
> I am lead to believe that logical CPU's 0, 2 and 4 are the physical CPU's.
This isn't really how HT is working. A physical processor (lets call it "core" from now on, to avoid
confusion if we have multi-core sockets) exposes two logical processors. You can't say that one of
those logical processors is more physical than the other.
Also, Intel's recommendation for the BIOS/HW manufacturer is as below. Say we have 4 core:
Processor 0, as seen by OS: Core 0, logical processor 0
Processor 1, as seen by OS: Core 1, logical processor 0
Processor 2, as seen by OS: Core 2, logical processor 0
Processor 3, as seen by OS: Core 3, logical processor 0
Processor 4, as seen by OS: Core 0, logical processor 1
Processor 5, as seen by OS: Core 1, logical processor 1
Processor 6, as seen by OS: Core 2, logical processor 1
Processor 7, as seen by OS: Core 3, logical processor 1
So, if you want to specify that only one logical processor per core should be used by SQL Server,
you should tell SQL Server to use processors 0-3. However, disabling HT at the BIOS level might be a
better option.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
> Hi,
> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a server with 3
> hyperthreaded CPUs that will show as 6 CPU's to SQL2000 SP3A. I am lead to believe that logical
> CPU's 0, 2 and 4 are the physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use All
> Available Processors checked I am restricting SQL to only using the 3 physical processors and
> reducing the horsepower available to SQL to half. Is this statement true?
> Thanks
> Chris
>
|||Tibor,
We have reason to believe that we are following Processor mapping table 2 as
described in: - http://support.microsoft.com/default.aspx/kb/322385
In the thread I mentioned earlier Andrew J Kelly gave a very good
description of what could be happening.
My question was more that we cannot have our cake and eat it too! If we
either change the affinity mask by using the GUI or sp_configure then we are
reducing the number of logical processors available to SQL by half even
though Windows will still see all logical processors. Disabling in the BIOS
would also reduce the logical processors available to Windows in half. I am
having a hard time convincing developers that hyperthreading may be causing
more performance problems than it could be improving by having more logical
processors.
Thanks for your speedy reply.
Chris
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
> This isn't really how HT is working. A physical processor (lets call it
> "core" from now on, to avoid confusion if we have multi-core sockets)
> exposes two logical processors. You can't say that one of those logical
> processors is more physical than the other.
> Also, Intel's recommendation for the BIOS/HW manufacturer is as below. Say
> we have 4 core:
> Processor 0, as seen by OS: Core 0, logical processor 0
> Processor 1, as seen by OS: Core 1, logical processor 0
> Processor 2, as seen by OS: Core 2, logical processor 0
> Processor 3, as seen by OS: Core 3, logical processor 0
> Processor 4, as seen by OS: Core 0, logical processor 1
> Processor 5, as seen by OS: Core 1, logical processor 1
> Processor 6, as seen by OS: Core 2, logical processor 1
> Processor 7, as seen by OS: Core 3, logical processor 1
> So, if you want to specify that only one logical processor per core should
> be used by SQL Server, you should tell SQL Server to use processors 0-3.
> However, disabling HT at the BIOS level might be a better option.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>
|||Chris,
Some systems follow the rules that Tibor mentioned and some don't in regards
to how they number their physical and logical processors. There are some
utilities out there on the net that can interrogate your system to see which
is which. But once you determine for sure which ones are the physical ones
and which are only logical you have several options. You can disable the
logical ones via the affinity mask and that will prevent SQL Server from
using them but not the OS or any other apps. If you are only running SQL
Server you are probably OK just disabling them with the affinity mask. But
if you really want to see for sure if HT is helping or hurting I really
suggest you turn it off at the BIOS level so there is no mistaking the
effects. Personally I wish they never invented HT processors and everything
was dual core
. While I have seen some cases where HT made a positive
difference I have seen far too many where its behavior was misunderstood and
it ended up hurting more than helping. I wouldn't recommend anyone buy HT
enable processors for SQL Server going forward.
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
> Tibor,
> We have reason to believe that we are following Processor mapping table 2
> as described in: - http://support.microsoft.com/default.aspx/kb/322385
> In the thread I mentioned earlier Andrew J Kelly gave a very good
> description of what could be happening.
> My question was more that we cannot have our cake and eat it too! If we
> either change the affinity mask by using the GUI or sp_configure then we
> are reducing the number of logical processors available to SQL by half
> even though Windows will still see all logical processors. Disabling in
> the BIOS would also reduce the logical processors available to Windows in
> half. I am having a hard time convincing developers that hyperthreading
> may be causing more performance problems than it could be improving by
> having more logical processors.
> Thanks for your speedy reply.
> Chris
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>
|||> We have reason to believe that we are following Processor mapping table 2 as described in: -
> http://support.microsoft.com/default.aspx/kb/322385
Ahh, thanks for updating my knowledge on this, I was only aware of table 1, as the recommendation
from Intel.
I fully concur with Andrew to verify how the layout, using a utility before experimenting with
affinity mask, and also do a load test to see whether disabling HT at the BIOS level won't be the
best after all.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
> Tibor,
> We have reason to believe that we are following Processor mapping table 2 as described in: -
> http://support.microsoft.com/default.aspx/kb/322385
> In the thread I mentioned earlier Andrew J Kelly gave a very good description of what could be
> happening.
> My question was more that we cannot have our cake and eat it too! If we either change the affinity
> mask by using the GUI or sp_configure then we are reducing the number of logical processors
> available to SQL by half even though Windows will still see all logical processors. Disabling in
> the BIOS would also reduce the logical processors available to Windows in half. I am having a hard
> time convincing developers that hyperthreading may be causing more performance problems than it
> could be improving by having more logical processors.
> Thanks for your speedy reply.
> Chris
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message
> news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>
|||Andrew,
Some weeks ago we moved a highly I/O intense SQL application off of an SQL
clustered server to its own SQL cluster because it could not live with
another SQL application. After some significant tuning of the code, both
apps, and dropping of old data we are about to put them back together again.
The clustered SQL server has 3 hyperthreaded CPU's with hyperthreading
switched on and available to SQL2000 SP3A build 818. I had read that
hyperthreading was not the best for SQL2000 and wanted to see if notable SQL
experts would comment. We did see some CXPACKET waits before and from what
you are saying if we see them again disabling hyperthreading could be the
best action rather than using the affinity mask.
Thanks so much for your valued opinion.
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
> Chris,
> Some systems follow the rules that Tibor mentioned and some don't in
> regards to how they number their physical and logical processors. There
> are some utilities out there on the net that can interrogate your system
> to see which is which. But once you determine for sure which ones are the
> physical ones and which are only logical you have several options. You can
> disable the logical ones via the affinity mask and that will prevent SQL
> Server from using them but not the OS or any other apps. If you are only
> running SQL Server you are probably OK just disabling them with the
> affinity mask. But if you really want to see for sure if HT is helping or
> hurting I really suggest you turn it off at the BIOS level so there is no
> mistaking the effects. Personally I wish they never invented HT
> processors and everything was dual core. While I have seen some cases
> where HT made a positive difference I have seen far too many where its
> behavior was misunderstood and it ended up hurting more than helping. I
> wouldn't recommend anyone buy HT enable processors for SQL Server going
> forward.
> --
> Andrew J. Kelly SQL MVP
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
>
|||Chris,
I have to say I have never seen a system with 3 processors. CXPackets can be
from several other things as well. Just poor parallel processing in general
can cause these waits. I don't remember too much of the original thread
but setting your MAXDOP to 1 can get rid of any simply due to parallelism
but will not fully alleviate the issues of HT. Are you planning on
upgrading to2005 or even SP4 any time soon? What OS are you using? If it is
Win2000 then you are even further behind when it come to HT. Just buy a new
server, its only money
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23l28mErgHHA.4156@.TK2MSFTNGP02.phx.gbl...
> Andrew,
> Some weeks ago we moved a highly I/O intense SQL application off of an SQL
> clustered server to its own SQL cluster because it could not live with
> another SQL application. After some significant tuning of the code, both
> apps, and dropping of old data we are about to put them back together
> again. The clustered SQL server has 3 hyperthreaded CPU's with
> hyperthreading switched on and available to SQL2000 SP3A build 818. I had
> read that hyperthreading was not the best for SQL2000 and wanted to see if
> notable SQL experts would comment. We did see some CXPACKET waits before
> and from what you are saying if we see them again disabling hyperthreading
> could be the best action rather than using the affinity mask.
> Thanks so much for your valued opinion.
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
>
|||Andrew,
We have held off from SP4 because of the move to a new server (the one the
I/O app went to) and SQL2005 SP2. One app is starting converting to SQL2005
and the other will follow when we have enough staff. Both servers are W2K3
with SP1 but the old server has less than 4Gb memory while the new one has
6Gb memory with 4Gb for SQL. Once they are back together again we will be
shoehorning 2 apps into less SQL cache so while I expect faster response
than what is was before the separation I do not expect it to be anywhere as
fast as when they were on their own.
We may have to water down HT to make things work better.
Thanks again.
Hope to see you in Denver at PASS. I am sure I heard you talk in Orlando in
2004 PASS.
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:u7DtGnsgHHA.4260@.TK2MSFTNGP03.phx.gbl...
> Chris,
> I have to say I have never seen a system with 3 processors. CXPackets can
> be from several other things as well. Just poor parallel processing in
> general can cause these waits. I don't remember too much of the original
> thread but setting your MAXDOP to 1 can get rid of any simply due to
> parallelism but will not fully alleviate the issues of HT. Are you
> planning on upgrading to2005 or even SP4 any time soon? What OS are you
> using? If it is Win2000 then you are even further behind when it come to
> HT. Just buy a new server, its only money
> --
> Andrew J. Kelly SQL MVP
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:%23l28mErgHHA.4156@.TK2MSFTNGP02.phx.gbl...
>
|||Chris,
I will be speaking at PASS in Denver this year along with TechEd in Orlando
and probably Dev Connections in Vegas as well. So if you are at any one of
them please look me up.
See you then.
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23I1RD9sgHHA.4872@.TK2MSFTNGP03.phx.gbl...
> Andrew,
> We have held off from SP4 because of the move to a new server (the one the
> I/O app went to) and SQL2005 SP2. One app is starting converting to
> SQL2005 and the other will follow when we have enough staff. Both servers
> are W2K3 with SP1 but the old server has less than 4Gb memory while the
> new one has 6Gb memory with 4Gb for SQL. Once they are back together again
> we will be shoehorning 2 apps into less SQL cache so while I expect faster
> response than what is was before the separation I do not expect it to be
> anywhere as fast as when they were on their own.
> We may have to water down HT to make things work better.
> Thanks again.
> Hope to see you in Denver at PASS. I am sure I heard you talk in Orlando
> in 2004 PASS.
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:u7DtGnsgHHA.4260@.TK2MSFTNGP03.phx.gbl...
>
This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a
server with 3 hyperthreaded CPUs that will show as 6 CPU's to SQL2000 SP3A.
I am lead to believe that logical CPU's 0, 2 and 4 are the physical CPU's.
If I uncheck CPU's 1, 3 and 5 but keep the Use All Available Processors
checked I am restricting SQL to only using the 3 physical processors and
reducing the horsepower available to SQL to half. Is this statement true?
Thanks
Chris
> I am lead to believe that logical CPU's 0, 2 and 4 are the physical CPU's.
This isn't really how HT is working. A physical processor (lets call it "core" from now on, to avoid
confusion if we have multi-core sockets) exposes two logical processors. You can't say that one of
those logical processors is more physical than the other.
Also, Intel's recommendation for the BIOS/HW manufacturer is as below. Say we have 4 core:
Processor 0, as seen by OS: Core 0, logical processor 0
Processor 1, as seen by OS: Core 1, logical processor 0
Processor 2, as seen by OS: Core 2, logical processor 0
Processor 3, as seen by OS: Core 3, logical processor 0
Processor 4, as seen by OS: Core 0, logical processor 1
Processor 5, as seen by OS: Core 1, logical processor 1
Processor 6, as seen by OS: Core 2, logical processor 1
Processor 7, as seen by OS: Core 3, logical processor 1
So, if you want to specify that only one logical processor per core should be used by SQL Server,
you should tell SQL Server to use processors 0-3. However, disabling HT at the BIOS level might be a
better option.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
> Hi,
> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a server with 3
> hyperthreaded CPUs that will show as 6 CPU's to SQL2000 SP3A. I am lead to believe that logical
> CPU's 0, 2 and 4 are the physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use All
> Available Processors checked I am restricting SQL to only using the 3 physical processors and
> reducing the horsepower available to SQL to half. Is this statement true?
> Thanks
> Chris
>
|||Tibor,
We have reason to believe that we are following Processor mapping table 2 as
described in: - http://support.microsoft.com/default.aspx/kb/322385
In the thread I mentioned earlier Andrew J Kelly gave a very good
description of what could be happening.
My question was more that we cannot have our cake and eat it too! If we
either change the affinity mask by using the GUI or sp_configure then we are
reducing the number of logical processors available to SQL by half even
though Windows will still see all logical processors. Disabling in the BIOS
would also reduce the logical processors available to Windows in half. I am
having a hard time convincing developers that hyperthreading may be causing
more performance problems than it could be improving by having more logical
processors.
Thanks for your speedy reply.
Chris
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
> This isn't really how HT is working. A physical processor (lets call it
> "core" from now on, to avoid confusion if we have multi-core sockets)
> exposes two logical processors. You can't say that one of those logical
> processors is more physical than the other.
> Also, Intel's recommendation for the BIOS/HW manufacturer is as below. Say
> we have 4 core:
> Processor 0, as seen by OS: Core 0, logical processor 0
> Processor 1, as seen by OS: Core 1, logical processor 0
> Processor 2, as seen by OS: Core 2, logical processor 0
> Processor 3, as seen by OS: Core 3, logical processor 0
> Processor 4, as seen by OS: Core 0, logical processor 1
> Processor 5, as seen by OS: Core 1, logical processor 1
> Processor 6, as seen by OS: Core 2, logical processor 1
> Processor 7, as seen by OS: Core 3, logical processor 1
> So, if you want to specify that only one logical processor per core should
> be used by SQL Server, you should tell SQL Server to use processors 0-3.
> However, disabling HT at the BIOS level might be a better option.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>
|||Chris,
Some systems follow the rules that Tibor mentioned and some don't in regards
to how they number their physical and logical processors. There are some
utilities out there on the net that can interrogate your system to see which
is which. But once you determine for sure which ones are the physical ones
and which are only logical you have several options. You can disable the
logical ones via the affinity mask and that will prevent SQL Server from
using them but not the OS or any other apps. If you are only running SQL
Server you are probably OK just disabling them with the affinity mask. But
if you really want to see for sure if HT is helping or hurting I really
suggest you turn it off at the BIOS level so there is no mistaking the
effects. Personally I wish they never invented HT processors and everything
was dual core
. While I have seen some cases where HT made a positivedifference I have seen far too many where its behavior was misunderstood and
it ended up hurting more than helping. I wouldn't recommend anyone buy HT
enable processors for SQL Server going forward.
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
> Tibor,
> We have reason to believe that we are following Processor mapping table 2
> as described in: - http://support.microsoft.com/default.aspx/kb/322385
> In the thread I mentioned earlier Andrew J Kelly gave a very good
> description of what could be happening.
> My question was more that we cannot have our cake and eat it too! If we
> either change the affinity mask by using the GUI or sp_configure then we
> are reducing the number of logical processors available to SQL by half
> even though Windows will still see all logical processors. Disabling in
> the BIOS would also reduce the logical processors available to Windows in
> half. I am having a hard time convincing developers that hyperthreading
> may be causing more performance problems than it could be improving by
> having more logical processors.
> Thanks for your speedy reply.
> Chris
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>
|||> We have reason to believe that we are following Processor mapping table 2 as described in: -
> http://support.microsoft.com/default.aspx/kb/322385
Ahh, thanks for updating my knowledge on this, I was only aware of table 1, as the recommendation
from Intel.
I fully concur with Andrew to verify how the layout, using a utility before experimenting with
affinity mask, and also do a load test to see whether disabling HT at the BIOS level won't be the
best after all.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
> Tibor,
> We have reason to believe that we are following Processor mapping table 2 as described in: -
> http://support.microsoft.com/default.aspx/kb/322385
> In the thread I mentioned earlier Andrew J Kelly gave a very good description of what could be
> happening.
> My question was more that we cannot have our cake and eat it too! If we either change the affinity
> mask by using the GUI or sp_configure then we are reducing the number of logical processors
> available to SQL by half even though Windows will still see all logical processors. Disabling in
> the BIOS would also reduce the logical processors available to Windows in half. I am having a hard
> time convincing developers that hyperthreading may be causing more performance problems than it
> could be improving by having more logical processors.
> Thanks for your speedy reply.
> Chris
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message
> news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>
|||Andrew,
Some weeks ago we moved a highly I/O intense SQL application off of an SQL
clustered server to its own SQL cluster because it could not live with
another SQL application. After some significant tuning of the code, both
apps, and dropping of old data we are about to put them back together again.
The clustered SQL server has 3 hyperthreaded CPU's with hyperthreading
switched on and available to SQL2000 SP3A build 818. I had read that
hyperthreading was not the best for SQL2000 and wanted to see if notable SQL
experts would comment. We did see some CXPACKET waits before and from what
you are saying if we see them again disabling hyperthreading could be the
best action rather than using the affinity mask.
Thanks so much for your valued opinion.
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
> Chris,
> Some systems follow the rules that Tibor mentioned and some don't in
> regards to how they number their physical and logical processors. There
> are some utilities out there on the net that can interrogate your system
> to see which is which. But once you determine for sure which ones are the
> physical ones and which are only logical you have several options. You can
> disable the logical ones via the affinity mask and that will prevent SQL
> Server from using them but not the OS or any other apps. If you are only
> running SQL Server you are probably OK just disabling them with the
> affinity mask. But if you really want to see for sure if HT is helping or
> hurting I really suggest you turn it off at the BIOS level so there is no
> mistaking the effects. Personally I wish they never invented HT
> processors and everything was dual core
. While I have seen some cases> where HT made a positive difference I have seen far too many where its
> behavior was misunderstood and it ended up hurting more than helping. I
> wouldn't recommend anyone buy HT enable processors for SQL Server going
> forward.
> --
> Andrew J. Kelly SQL MVP
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
>
|||Chris,
I have to say I have never seen a system with 3 processors. CXPackets can be
from several other things as well. Just poor parallel processing in general
can cause these waits. I don't remember too much of the original thread
but setting your MAXDOP to 1 can get rid of any simply due to parallelism
but will not fully alleviate the issues of HT. Are you planning on
upgrading to2005 or even SP4 any time soon? What OS are you using? If it is
Win2000 then you are even further behind when it come to HT. Just buy a new
server, its only money
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23l28mErgHHA.4156@.TK2MSFTNGP02.phx.gbl...
> Andrew,
> Some weeks ago we moved a highly I/O intense SQL application off of an SQL
> clustered server to its own SQL cluster because it could not live with
> another SQL application. After some significant tuning of the code, both
> apps, and dropping of old data we are about to put them back together
> again. The clustered SQL server has 3 hyperthreaded CPU's with
> hyperthreading switched on and available to SQL2000 SP3A build 818. I had
> read that hyperthreading was not the best for SQL2000 and wanted to see if
> notable SQL experts would comment. We did see some CXPACKET waits before
> and from what you are saying if we see them again disabling hyperthreading
> could be the best action rather than using the affinity mask.
> Thanks so much for your valued opinion.
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
>
|||Andrew,
We have held off from SP4 because of the move to a new server (the one the
I/O app went to) and SQL2005 SP2. One app is starting converting to SQL2005
and the other will follow when we have enough staff. Both servers are W2K3
with SP1 but the old server has less than 4Gb memory while the new one has
6Gb memory with 4Gb for SQL. Once they are back together again we will be
shoehorning 2 apps into less SQL cache so while I expect faster response
than what is was before the separation I do not expect it to be anywhere as
fast as when they were on their own.
We may have to water down HT to make things work better.
Thanks again.
Hope to see you in Denver at PASS. I am sure I heard you talk in Orlando in
2004 PASS.
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:u7DtGnsgHHA.4260@.TK2MSFTNGP03.phx.gbl...
> Chris,
> I have to say I have never seen a system with 3 processors. CXPackets can
> be from several other things as well. Just poor parallel processing in
> general can cause these waits. I don't remember too much of the original
> thread
but setting your MAXDOP to 1 can get rid of any simply due to> parallelism but will not fully alleviate the issues of HT. Are you
> planning on upgrading to2005 or even SP4 any time soon? What OS are you
> using? If it is Win2000 then you are even further behind when it come to
> HT. Just buy a new server, its only money
> --
> Andrew J. Kelly SQL MVP
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:%23l28mErgHHA.4156@.TK2MSFTNGP02.phx.gbl...
>
|||Chris,
I will be speaking at PASS in Denver this year along with TechEd in Orlando
and probably Dev Connections in Vegas as well. So if you are at any one of
them please look me up.
See you then.
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23I1RD9sgHHA.4872@.TK2MSFTNGP03.phx.gbl...
> Andrew,
> We have held off from SP4 because of the move to a new server (the one the
> I/O app went to) and SQL2005 SP2. One app is starting converting to
> SQL2005 and the other will follow when we have enough staff. Both servers
> are W2K3 with SP1 but the old server has less than 4Gb memory while the
> new one has 6Gb memory with 4Gb for SQL. Once they are back together again
> we will be shoehorning 2 apps into less SQL cache so while I expect faster
> response than what is was before the separation I do not expect it to be
> anywhere as fast as when they were on their own.
> We may have to water down HT to make things work better.
> Thanks again.
> Hope to see you in Denver at PASS. I am sure I heard you talk in Orlando
> in 2004 PASS.
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:u7DtGnsgHHA.4260@.TK2MSFTNGP03.phx.gbl...
>
Hyperthreaded CPU's
Hi,
This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a
server with 3 hyperthreaded CPUs that will show as 6 CPU's to SQL2000 SP3A.
I am lead to believe that logical CPU's 0, 2 and 4 are the physical CPU's.
If I uncheck CPU's 1, 3 and 5 but keep the Use All Available Processors
checked I am restricting SQL to only using the 3 physical processors and
reducing the horsepower available to SQL to half. Is this statement true?
Thanks
Chris> I am lead to believe that logical CPU's 0, 2 and 4 are the physical CPU's.
This isn't really how HT is working. A physical processor (lets call it "cor
e" from now on, to avoid
confusion if we have multi-core sockets) exposes two logical processors. You
can't say that one of
those logical processors is more physical than the other.
Also, Intel's recommendation for the BIOS/HW manufacturer is as below. Say w
e have 4 core:
Processor 0, as seen by OS: Core 0, logical processor 0
Processor 1, as seen by OS: Core 1, logical processor 0
Processor 2, as seen by OS: Core 2, logical processor 0
Processor 3, as seen by OS: Core 3, logical processor 0
Processor 4, as seen by OS: Core 0, logical processor 1
Processor 5, as seen by OS: Core 1, logical processor 1
Processor 6, as seen by OS: Core 2, logical processor 1
Processor 7, as seen by OS: Core 3, logical processor 1
So, if you want to specify that only one logical processor per core should b
e used by SQL Server,
you should tell SQL Server to use processors 0-3. However, disabling HT at t
he BIOS level might be a
better option.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
> Hi,
> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a s
erver with 3
> hyperthreaded CPUs that will show as 6 CPU's to SQL2000 SP3A. I am lead to
believe that logical
> CPU's 0, 2 and 4 are the physical CPU's. If I uncheck CPU's 1, 3 and 5 but
keep the Use All
> Available Processors checked I am restricting SQL to only using the 3 phys
ical processors and
> reducing the horsepower available to SQL to half. Is this statement true?
> Thanks
> Chris
>|||Tibor,
We have reason to believe that we are following Processor mapping table 2 as
described in: - http://support.microsoft.com/default.aspx/kb/322385
In the thread I mentioned earlier Andrew J Kelly gave a very good
description of what could be happening.
My question was more that we cannot have our cake and eat it too! If we
either change the affinity mask by using the GUI or sp_configure then we are
reducing the number of logical processors available to SQL by half even
though Windows will still see all logical processors. Disabling in the BIOS
would also reduce the logical processors available to Windows in half. I am
having a hard time convincing developers that hyperthreading may be causing
more performance problems than it could be improving by having more logical
processors.
Thanks for your speedy reply.
Chris
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
> This isn't really how HT is working. A physical processor (lets call it
> "core" from now on, to avoid confusion if we have multi-core sockets)
> exposes two logical processors. You can't say that one of those logical
> processors is more physical than the other.
> Also, Intel's recommendation for the BIOS/HW manufacturer is as below. Say
> we have 4 core:
> Processor 0, as seen by OS: Core 0, logical processor 0
> Processor 1, as seen by OS: Core 1, logical processor 0
> Processor 2, as seen by OS: Core 2, logical processor 0
> Processor 3, as seen by OS: Core 3, logical processor 0
> Processor 4, as seen by OS: Core 0, logical processor 1
> Processor 5, as seen by OS: Core 1, logical processor 1
> Processor 6, as seen by OS: Core 2, logical processor 1
> Processor 7, as seen by OS: Core 3, logical processor 1
> So, if you want to specify that only one logical processor per core should
> be used by SQL Server, you should tell SQL Server to use processors 0-3.
> However, disabling HT at the BIOS level might be a better option.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>|||Chris,
Some systems follow the rules that Tibor mentioned and some don't in regards
to how they number their physical and logical processors. There are some
utilities out there on the net that can interrogate your system to see which
is which. But once you determine for sure which ones are the physical ones
and which are only logical you have several options. You can disable the
logical ones via the affinity mask and that will prevent SQL Server from
using them but not the OS or any other apps. If you are only running SQL
Server you are probably OK just disabling them with the affinity mask. But
if you really want to see for sure if HT is helping or hurting I really
suggest you turn it off at the BIOS level so there is no mistaking the
effects. Personally I wish they never invented HT processors and everything
was dual core. While I have seen some cases where HT made a positive
difference I have seen far too many where its behavior was misunderstood and
it ended up hurting more than helping. I wouldn't recommend anyone buy HT
enable processors for SQL Server going forward.
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
> Tibor,
> We have reason to believe that we are following Processor mapping table 2
> as described in: - http://support.microsoft.com/default.aspx/kb/322385
> In the thread I mentioned earlier Andrew J Kelly gave a very good
> description of what could be happening.
> My question was more that we cannot have our cake and eat it too! If we
> either change the affinity mask by using the GUI or sp_configure then we
> are reducing the number of logical processors available to SQL by half
> even though Windows will still see all logical processors. Disabling in
> the BIOS would also reduce the logical processors available to Windows in
> half. I am having a hard time convincing developers that hyperthreading
> may be causing more performance problems than it could be improving by
> having more logical processors.
> Thanks for your speedy reply.
> Chris
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>|||> We have reason to believe that we are following Processor mapping table 2 as described in:
-
> http://support.microsoft.com/default.aspx/kb/322385
Ahh, thanks for updating my knowledge on this, I was only aware of table 1,
as the recommendation
from Intel.
I fully concur with Andrew to verify how the layout, using a utility before
experimenting with
affinity mask, and also do a load test to see whether disabling HT at the BI
OS level won't be the
best after all.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
> Tibor,
> We have reason to believe that we are following Processor mapping table 2
as described in: -
> http://support.microsoft.com/default.aspx/kb/322385
> In the thread I mentioned earlier Andrew J Kelly gave a very good descript
ion of what could be
> happening.
> My question was more that we cannot have our cake and eat it too! If we ei
ther change the affinity
> mask by using the GUI or sp_configure then we are reducing the number of l
ogical processors
> available to SQL by half even though Windows will still see all logical pr
ocessors. Disabling in
> the BIOS would also reduce the logical processors available to Windows in
half. I am having a hard
> time convincing developers that hyperthreading may be causing more perform
ance problems than it
> could be improving by having more logical processors.
> Thanks for your speedy reply.
> Chris
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote i
n message
> news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>|||Andrew,
Some weeks ago we moved a highly I/O intense SQL application off of an SQL
clustered server to its own SQL cluster because it could not live with
another SQL application. After some significant tuning of the code, both
apps, and dropping of old data we are about to put them back together again.
The clustered SQL server has 3 hyperthreaded CPU's with hyperthreading
switched on and available to SQL2000 SP3A build 818. I had read that
hyperthreading was not the best for SQL2000 and wanted to see if notable SQL
experts would comment. We did see some CXPACKET waits before and from what
you are saying if we see them again disabling hyperthreading could be the
best action rather than using the affinity mask.
Thanks so much for your valued opinion.
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
> Chris,
> Some systems follow the rules that Tibor mentioned and some don't in
> regards to how they number their physical and logical processors. There
> are some utilities out there on the net that can interrogate your system
> to see which is which. But once you determine for sure which ones are the
> physical ones and which are only logical you have several options. You can
> disable the logical ones via the affinity mask and that will prevent SQL
> Server from using them but not the OS or any other apps. If you are only
> running SQL Server you are probably OK just disabling them with the
> affinity mask. But if you really want to see for sure if HT is helping or
> hurting I really suggest you turn it off at the BIOS level so there is no
> mistaking the effects. Personally I wish they never invented HT
> processors and everything was dual core. While I have seen some cases
> where HT made a positive difference I have seen far too many where its
> behavior was misunderstood and it ended up hurting more than helping. I
> wouldn't recommend anyone buy HT enable processors for SQL Server going
> forward.
> --
> Andrew J. Kelly SQL MVP
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
>|||Chris,
I have to say I have never seen a system with 3 processors. CXPackets can be
from several other things as well. Just poor parallel processing in general
can cause these waits. I don't remember too much of the original thread
but setting your MAXDOP to 1 can get rid of any simply due to parallelism
but will not fully alleviate the issues of HT. Are you planning on
upgrading to2005 or even SP4 any time soon? What OS are you using? If it is
Win2000 then you are even further behind when it come to HT. Just buy a new
server, its only money
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23l28mErgHHA.4156@.TK2MSFTNGP02.phx.gbl...
> Andrew,
> Some weeks ago we moved a highly I/O intense SQL application off of an SQL
> clustered server to its own SQL cluster because it could not live with
> another SQL application. After some significant tuning of the code, both
> apps, and dropping of old data we are about to put them back together
> again. The clustered SQL server has 3 hyperthreaded CPU's with
> hyperthreading switched on and available to SQL2000 SP3A build 818. I had
> read that hyperthreading was not the best for SQL2000 and wanted to see if
> notable SQL experts would comment. We did see some CXPACKET waits before
> and from what you are saying if we see them again disabling hyperthreading
> could be the best action rather than using the affinity mask.
> Thanks so much for your valued opinion.
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
>|||Andrew,
We have held off from SP4 because of the move to a new server (the one the
I/O app went to) and SQL2005 SP2. One app is starting converting to SQL2005
and the other will follow when we have enough staff. Both servers are W2K3
with SP1 but the old server has less than 4Gb memory while the new one has
6Gb memory with 4Gb for SQL. Once they are back together again we will be
shoehorning 2 apps into less SQL cache so while I expect faster response
than what is was before the separation I do not expect it to be anywhere as
fast as when they were on their own.
We may have to water down HT to make things work better.
Thanks again.
Hope to see you in Denver at PASS. I am sure I heard you talk in Orlando in
2004 PASS.
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:u7DtGnsgHHA.4260@.TK2MSFTNGP03.phx.gbl...
> Chris,
> I have to say I have never seen a system with 3 processors. CXPackets can
> be from several other things as well. Just poor parallel processing in
> general can cause these waits. I don't remember too much of the original
> thread but setting your MAXDOP to 1 can get rid of any simply due to
> parallelism but will not fully alleviate the issues of HT. Are you
> planning on upgrading to2005 or even SP4 any time soon? What OS are you
> using? If it is Win2000 then you are even further behind when it come to
> HT. Just buy a new server, its only money
> --
> Andrew J. Kelly SQL MVP
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:%23l28mErgHHA.4156@.TK2MSFTNGP02.phx.gbl...
>|||Chris,
I will be speaking at PASS in Denver this year along with TechEd in Orlando
and probably Dev Connections in Vegas as well. So if you are at any one of
them please look me up.
See you then.
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23I1RD9sgHHA.4872@.TK2MSFTNGP03.phx.gbl...
> Andrew,
> We have held off from SP4 because of the move to a new server (the one the
> I/O app went to) and SQL2005 SP2. One app is starting converting to
> SQL2005 and the other will follow when we have enough staff. Both servers
> are W2K3 with SP1 but the old server has less than 4Gb memory while the
> new one has 6Gb memory with 4Gb for SQL. Once they are back together again
> we will be shoehorning 2 apps into less SQL cache so while I expect faster
> response than what is was before the separation I do not expect it to be
> anywhere as fast as when they were on their own.
> We may have to water down HT to make things work better.
> Thanks again.
> Hope to see you in Denver at PASS. I am sure I heard you talk in Orlando
> in 2004 PASS.
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:u7DtGnsgHHA.4260@.TK2MSFTNGP03.phx.gbl...
>
This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a
server with 3 hyperthreaded CPUs that will show as 6 CPU's to SQL2000 SP3A.
I am lead to believe that logical CPU's 0, 2 and 4 are the physical CPU's.
If I uncheck CPU's 1, 3 and 5 but keep the Use All Available Processors
checked I am restricting SQL to only using the 3 physical processors and
reducing the horsepower available to SQL to half. Is this statement true?
Thanks
Chris> I am lead to believe that logical CPU's 0, 2 and 4 are the physical CPU's.
This isn't really how HT is working. A physical processor (lets call it "cor
e" from now on, to avoid
confusion if we have multi-core sockets) exposes two logical processors. You
can't say that one of
those logical processors is more physical than the other.
Also, Intel's recommendation for the BIOS/HW manufacturer is as below. Say w
e have 4 core:
Processor 0, as seen by OS: Core 0, logical processor 0
Processor 1, as seen by OS: Core 1, logical processor 0
Processor 2, as seen by OS: Core 2, logical processor 0
Processor 3, as seen by OS: Core 3, logical processor 0
Processor 4, as seen by OS: Core 0, logical processor 1
Processor 5, as seen by OS: Core 1, logical processor 1
Processor 6, as seen by OS: Core 2, logical processor 1
Processor 7, as seen by OS: Core 3, logical processor 1
So, if you want to specify that only one logical processor per core should b
e used by SQL Server,
you should tell SQL Server to use processors 0-3. However, disabling HT at t
he BIOS level might be a
better option.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
> Hi,
> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a s
erver with 3
> hyperthreaded CPUs that will show as 6 CPU's to SQL2000 SP3A. I am lead to
believe that logical
> CPU's 0, 2 and 4 are the physical CPU's. If I uncheck CPU's 1, 3 and 5 but
keep the Use All
> Available Processors checked I am restricting SQL to only using the 3 phys
ical processors and
> reducing the horsepower available to SQL to half. Is this statement true?
> Thanks
> Chris
>|||Tibor,
We have reason to believe that we are following Processor mapping table 2 as
described in: - http://support.microsoft.com/default.aspx/kb/322385
In the thread I mentioned earlier Andrew J Kelly gave a very good
description of what could be happening.
My question was more that we cannot have our cake and eat it too! If we
either change the affinity mask by using the GUI or sp_configure then we are
reducing the number of logical processors available to SQL by half even
though Windows will still see all logical processors. Disabling in the BIOS
would also reduce the logical processors available to Windows in half. I am
having a hard time convincing developers that hyperthreading may be causing
more performance problems than it could be improving by having more logical
processors.
Thanks for your speedy reply.
Chris
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
> This isn't really how HT is working. A physical processor (lets call it
> "core" from now on, to avoid confusion if we have multi-core sockets)
> exposes two logical processors. You can't say that one of those logical
> processors is more physical than the other.
> Also, Intel's recommendation for the BIOS/HW manufacturer is as below. Say
> we have 4 core:
> Processor 0, as seen by OS: Core 0, logical processor 0
> Processor 1, as seen by OS: Core 1, logical processor 0
> Processor 2, as seen by OS: Core 2, logical processor 0
> Processor 3, as seen by OS: Core 3, logical processor 0
> Processor 4, as seen by OS: Core 0, logical processor 1
> Processor 5, as seen by OS: Core 1, logical processor 1
> Processor 6, as seen by OS: Core 2, logical processor 1
> Processor 7, as seen by OS: Core 3, logical processor 1
> So, if you want to specify that only one logical processor per core should
> be used by SQL Server, you should tell SQL Server to use processors 0-3.
> However, disabling HT at the BIOS level might be a better option.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>|||Chris,
Some systems follow the rules that Tibor mentioned and some don't in regards
to how they number their physical and logical processors. There are some
utilities out there on the net that can interrogate your system to see which
is which. But once you determine for sure which ones are the physical ones
and which are only logical you have several options. You can disable the
logical ones via the affinity mask and that will prevent SQL Server from
using them but not the OS or any other apps. If you are only running SQL
Server you are probably OK just disabling them with the affinity mask. But
if you really want to see for sure if HT is helping or hurting I really
suggest you turn it off at the BIOS level so there is no mistaking the
effects. Personally I wish they never invented HT processors and everything
was dual core
. While I have seen some cases where HT made a positivedifference I have seen far too many where its behavior was misunderstood and
it ended up hurting more than helping. I wouldn't recommend anyone buy HT
enable processors for SQL Server going forward.
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
> Tibor,
> We have reason to believe that we are following Processor mapping table 2
> as described in: - http://support.microsoft.com/default.aspx/kb/322385
> In the thread I mentioned earlier Andrew J Kelly gave a very good
> description of what could be happening.
> My question was more that we cannot have our cake and eat it too! If we
> either change the affinity mask by using the GUI or sp_configure then we
> are reducing the number of logical processors available to SQL by half
> even though Windows will still see all logical processors. Disabling in
> the BIOS would also reduce the logical processors available to Windows in
> half. I am having a hard time convincing developers that hyperthreading
> may be causing more performance problems than it could be improving by
> having more logical processors.
> Thanks for your speedy reply.
> Chris
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>|||> We have reason to believe that we are following Processor mapping table 2 as described in:
-
> http://support.microsoft.com/default.aspx/kb/322385
Ahh, thanks for updating my knowledge on this, I was only aware of table 1,
as the recommendation
from Intel.
I fully concur with Andrew to verify how the layout, using a utility before
experimenting with
affinity mask, and also do a load test to see whether disabling HT at the BI
OS level won't be the
best after all.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
> Tibor,
> We have reason to believe that we are following Processor mapping table 2
as described in: -
> http://support.microsoft.com/default.aspx/kb/322385
> In the thread I mentioned earlier Andrew J Kelly gave a very good descript
ion of what could be
> happening.
> My question was more that we cannot have our cake and eat it too! If we ei
ther change the affinity
> mask by using the GUI or sp_configure then we are reducing the number of l
ogical processors
> available to SQL by half even though Windows will still see all logical pr
ocessors. Disabling in
> the BIOS would also reduce the logical processors available to Windows in
half. I am having a hard
> time convincing developers that hyperthreading may be causing more perform
ance problems than it
> could be improving by having more logical processors.
> Thanks for your speedy reply.
> Chris
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote i
n message
> news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>|||Andrew,
Some weeks ago we moved a highly I/O intense SQL application off of an SQL
clustered server to its own SQL cluster because it could not live with
another SQL application. After some significant tuning of the code, both
apps, and dropping of old data we are about to put them back together again.
The clustered SQL server has 3 hyperthreaded CPU's with hyperthreading
switched on and available to SQL2000 SP3A build 818. I had read that
hyperthreading was not the best for SQL2000 and wanted to see if notable SQL
experts would comment. We did see some CXPACKET waits before and from what
you are saying if we see them again disabling hyperthreading could be the
best action rather than using the affinity mask.
Thanks so much for your valued opinion.
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
> Chris,
> Some systems follow the rules that Tibor mentioned and some don't in
> regards to how they number their physical and logical processors. There
> are some utilities out there on the net that can interrogate your system
> to see which is which. But once you determine for sure which ones are the
> physical ones and which are only logical you have several options. You can
> disable the logical ones via the affinity mask and that will prevent SQL
> Server from using them but not the OS or any other apps. If you are only
> running SQL Server you are probably OK just disabling them with the
> affinity mask. But if you really want to see for sure if HT is helping or
> hurting I really suggest you turn it off at the BIOS level so there is no
> mistaking the effects. Personally I wish they never invented HT
> processors and everything was dual core
. While I have seen some cases> where HT made a positive difference I have seen far too many where its
> behavior was misunderstood and it ended up hurting more than helping. I
> wouldn't recommend anyone buy HT enable processors for SQL Server going
> forward.
> --
> Andrew J. Kelly SQL MVP
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
>|||Chris,
I have to say I have never seen a system with 3 processors. CXPackets can be
from several other things as well. Just poor parallel processing in general
can cause these waits. I don't remember too much of the original thread
but setting your MAXDOP to 1 can get rid of any simply due to parallelism
but will not fully alleviate the issues of HT. Are you planning on
upgrading to2005 or even SP4 any time soon? What OS are you using? If it is
Win2000 then you are even further behind when it come to HT. Just buy a new
server, its only money
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23l28mErgHHA.4156@.TK2MSFTNGP02.phx.gbl...
> Andrew,
> Some weeks ago we moved a highly I/O intense SQL application off of an SQL
> clustered server to its own SQL cluster because it could not live with
> another SQL application. After some significant tuning of the code, both
> apps, and dropping of old data we are about to put them back together
> again. The clustered SQL server has 3 hyperthreaded CPU's with
> hyperthreading switched on and available to SQL2000 SP3A build 818. I had
> read that hyperthreading was not the best for SQL2000 and wanted to see if
> notable SQL experts would comment. We did see some CXPACKET waits before
> and from what you are saying if we see them again disabling hyperthreading
> could be the best action rather than using the affinity mask.
> Thanks so much for your valued opinion.
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
>|||Andrew,
We have held off from SP4 because of the move to a new server (the one the
I/O app went to) and SQL2005 SP2. One app is starting converting to SQL2005
and the other will follow when we have enough staff. Both servers are W2K3
with SP1 but the old server has less than 4Gb memory while the new one has
6Gb memory with 4Gb for SQL. Once they are back together again we will be
shoehorning 2 apps into less SQL cache so while I expect faster response
than what is was before the separation I do not expect it to be anywhere as
fast as when they were on their own.
We may have to water down HT to make things work better.
Thanks again.
Hope to see you in Denver at PASS. I am sure I heard you talk in Orlando in
2004 PASS.
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:u7DtGnsgHHA.4260@.TK2MSFTNGP03.phx.gbl...
> Chris,
> I have to say I have never seen a system with 3 processors. CXPackets can
> be from several other things as well. Just poor parallel processing in
> general can cause these waits. I don't remember too much of the original
> thread
but setting your MAXDOP to 1 can get rid of any simply due to> parallelism but will not fully alleviate the issues of HT. Are you
> planning on upgrading to2005 or even SP4 any time soon? What OS are you
> using? If it is Win2000 then you are even further behind when it come to
> HT. Just buy a new server, its only money
> --
> Andrew J. Kelly SQL MVP
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:%23l28mErgHHA.4156@.TK2MSFTNGP02.phx.gbl...
>|||Chris,
I will be speaking at PASS in Denver this year along with TechEd in Orlando
and probably Dev Connections in Vegas as well. So if you are at any one of
them please look me up.
See you then.
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23I1RD9sgHHA.4872@.TK2MSFTNGP03.phx.gbl...
> Andrew,
> We have held off from SP4 because of the move to a new server (the one the
> I/O app went to) and SQL2005 SP2. One app is starting converting to
> SQL2005 and the other will follow when we have enough staff. Both servers
> are W2K3 with SP1 but the old server has less than 4Gb memory while the
> new one has 6Gb memory with 4Gb for SQL. Once they are back together again
> we will be shoehorning 2 apps into less SQL cache so while I expect faster
> response than what is was before the separation I do not expect it to be
> anywhere as fast as when they were on their own.
> We may have to water down HT to make things work better.
> Thanks again.
> Hope to see you in Denver at PASS. I am sure I heard you talk in Orlando
> in 2004 PASS.
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:u7DtGnsgHHA.4260@.TK2MSFTNGP03.phx.gbl...
>
Hyperthreaded CPU's
Hi,
This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a
server with 3 hyperthreaded CPUs that will show as 6 CPU's to SQL2000 SP3A.
I am lead to believe that logical CPU's 0, 2 and 4 are the physical CPU's.
If I uncheck CPU's 1, 3 and 5 but keep the Use All Available Processors
checked I am restricting SQL to only using the 3 physical processors and
reducing the horsepower available to SQL to half. Is this statement true?
Thanks
Chris> I am lead to believe that logical CPU's 0, 2 and 4 are the physical CPU's.
This isn't really how HT is working. A physical processor (lets call it "core" from now on, to avoid
confusion if we have multi-core sockets) exposes two logical processors. You can't say that one of
those logical processors is more physical than the other.
Also, Intel's recommendation for the BIOS/HW manufacturer is as below. Say we have 4 core:
Processor 0, as seen by OS: Core 0, logical processor 0
Processor 1, as seen by OS: Core 1, logical processor 0
Processor 2, as seen by OS: Core 2, logical processor 0
Processor 3, as seen by OS: Core 3, logical processor 0
Processor 4, as seen by OS: Core 0, logical processor 1
Processor 5, as seen by OS: Core 1, logical processor 1
Processor 6, as seen by OS: Core 2, logical processor 1
Processor 7, as seen by OS: Core 3, logical processor 1
So, if you want to specify that only one logical processor per core should be used by SQL Server,
you should tell SQL Server to use processors 0-3. However, disabling HT at the BIOS level might be a
better option.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
> Hi,
> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a server with 3
> hyperthreaded CPUs that will show as 6 CPU's to SQL2000 SP3A. I am lead to believe that logical
> CPU's 0, 2 and 4 are the physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use All
> Available Processors checked I am restricting SQL to only using the 3 physical processors and
> reducing the horsepower available to SQL to half. Is this statement true?
> Thanks
> Chris
>|||Tibor,
We have reason to believe that we are following Processor mapping table 2 as
described in: - http://support.microsoft.com/default.aspx/kb/322385
In the thread I mentioned earlier Andrew J Kelly gave a very good
description of what could be happening.
My question was more that we cannot have our cake and eat it too! If we
either change the affinity mask by using the GUI or sp_configure then we are
reducing the number of logical processors available to SQL by half even
though Windows will still see all logical processors. Disabling in the BIOS
would also reduce the logical processors available to Windows in half. I am
having a hard time convincing developers that hyperthreading may be causing
more performance problems than it could be improving by having more logical
processors.
Thanks for your speedy reply.
Chris
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>> I am lead to believe that logical CPU's 0, 2 and 4 are the physical
>> CPU's.
> This isn't really how HT is working. A physical processor (lets call it
> "core" from now on, to avoid confusion if we have multi-core sockets)
> exposes two logical processors. You can't say that one of those logical
> processors is more physical than the other.
> Also, Intel's recommendation for the BIOS/HW manufacturer is as below. Say
> we have 4 core:
> Processor 0, as seen by OS: Core 0, logical processor 0
> Processor 1, as seen by OS: Core 1, logical processor 0
> Processor 2, as seen by OS: Core 2, logical processor 0
> Processor 3, as seen by OS: Core 3, logical processor 0
> Processor 4, as seen by OS: Core 0, logical processor 1
> Processor 5, as seen by OS: Core 1, logical processor 1
> Processor 6, as seen by OS: Core 2, logical processor 1
> Processor 7, as seen by OS: Core 3, logical processor 1
> So, if you want to specify that only one logical processor per core should
> be used by SQL Server, you should tell SQL Server to use processors 0-3.
> However, disabling HT at the BIOS level might be a better option.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a
>> server with 3 hyperthreaded CPUs that will show as 6 CPU's to SQL2000
>> SP3A. I am lead to believe that logical CPU's 0, 2 and 4 are the physical
>> CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use All Available
>> Processors checked I am restricting SQL to only using the 3 physical
>> processors and reducing the horsepower available to SQL to half. Is this
>> statement true?
>> Thanks
>> Chris
>|||Chris,
Some systems follow the rules that Tibor mentioned and some don't in regards
to how they number their physical and logical processors. There are some
utilities out there on the net that can interrogate your system to see which
is which. But once you determine for sure which ones are the physical ones
and which are only logical you have several options. You can disable the
logical ones via the affinity mask and that will prevent SQL Server from
using them but not the OS or any other apps. If you are only running SQL
Server you are probably OK just disabling them with the affinity mask. But
if you really want to see for sure if HT is helping or hurting I really
suggest you turn it off at the BIOS level so there is no mistaking the
effects. Personally I wish they never invented HT processors and everything
was dual core:). While I have seen some cases where HT made a positive
difference I have seen far too many where its behavior was misunderstood and
it ended up hurting more than helping. I wouldn't recommend anyone buy HT
enable processors for SQL Server going forward.
--
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
> Tibor,
> We have reason to believe that we are following Processor mapping table 2
> as described in: - http://support.microsoft.com/default.aspx/kb/322385
> In the thread I mentioned earlier Andrew J Kelly gave a very good
> description of what could be happening.
> My question was more that we cannot have our cake and eat it too! If we
> either change the affinity mask by using the GUI or sp_configure then we
> are reducing the number of logical processors available to SQL by half
> even though Windows will still see all logical processors. Disabling in
> the BIOS would also reduce the logical processors available to Windows in
> half. I am having a hard time convincing developers that hyperthreading
> may be causing more performance problems than it could be improving by
> having more logical processors.
> Thanks for your speedy reply.
> Chris
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>> I am lead to believe that logical CPU's 0, 2 and 4 are the physical
>> CPU's.
>> This isn't really how HT is working. A physical processor (lets call it
>> "core" from now on, to avoid confusion if we have multi-core sockets)
>> exposes two logical processors. You can't say that one of those logical
>> processors is more physical than the other.
>> Also, Intel's recommendation for the BIOS/HW manufacturer is as below.
>> Say we have 4 core:
>> Processor 0, as seen by OS: Core 0, logical processor 0
>> Processor 1, as seen by OS: Core 1, logical processor 0
>> Processor 2, as seen by OS: Core 2, logical processor 0
>> Processor 3, as seen by OS: Core 3, logical processor 0
>> Processor 4, as seen by OS: Core 0, logical processor 1
>> Processor 5, as seen by OS: Core 1, logical processor 1
>> Processor 6, as seen by OS: Core 2, logical processor 1
>> Processor 7, as seen by OS: Core 3, logical processor 1
>> So, if you want to specify that only one logical processor per core
>> should be used by SQL Server, you should tell SQL Server to use
>> processors 0-3. However, disabling HT at the BIOS level might be a better
>> option.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a
>> server with 3 hyperthreaded CPUs that will show as 6 CPU's to SQL2000
>> SP3A. I am lead to believe that logical CPU's 0, 2 and 4 are the
>> physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use All
>> Available Processors checked I am restricting SQL to only using the 3
>> physical processors and reducing the horsepower available to SQL to
>> half. Is this statement true?
>> Thanks
>> Chris
>>
>|||> We have reason to believe that we are following Processor mapping table 2 as described in: -
> http://support.microsoft.com/default.aspx/kb/322385
Ahh, thanks for updating my knowledge on this, I was only aware of table 1, as the recommendation
from Intel.
I fully concur with Andrew to verify how the layout, using a utility before experimenting with
affinity mask, and also do a load test to see whether disabling HT at the BIOS level won't be the
best after all.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
> Tibor,
> We have reason to believe that we are following Processor mapping table 2 as described in: -
> http://support.microsoft.com/default.aspx/kb/322385
> In the thread I mentioned earlier Andrew J Kelly gave a very good description of what could be
> happening.
> My question was more that we cannot have our cake and eat it too! If we either change the affinity
> mask by using the GUI or sp_configure then we are reducing the number of logical processors
> available to SQL by half even though Windows will still see all logical processors. Disabling in
> the BIOS would also reduce the logical processors available to Windows in half. I am having a hard
> time convincing developers that hyperthreading may be causing more performance problems than it
> could be improving by having more logical processors.
> Thanks for your speedy reply.
> Chris
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message
> news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>> I am lead to believe that logical CPU's 0, 2 and 4 are the physical CPU's.
>> This isn't really how HT is working. A physical processor (lets call it "core" from now on, to
>> avoid confusion if we have multi-core sockets) exposes two logical processors. You can't say that
>> one of those logical processors is more physical than the other.
>> Also, Intel's recommendation for the BIOS/HW manufacturer is as below. Say we have 4 core:
>> Processor 0, as seen by OS: Core 0, logical processor 0
>> Processor 1, as seen by OS: Core 1, logical processor 0
>> Processor 2, as seen by OS: Core 2, logical processor 0
>> Processor 3, as seen by OS: Core 3, logical processor 0
>> Processor 4, as seen by OS: Core 0, logical processor 1
>> Processor 5, as seen by OS: Core 1, logical processor 1
>> Processor 6, as seen by OS: Core 2, logical processor 1
>> Processor 7, as seen by OS: Core 3, logical processor 1
>> So, if you want to specify that only one logical processor per core should be used by SQL Server,
>> you should tell SQL Server to use processors 0-3. However, disabling HT at the BIOS level might
>> be a better option.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a server with 3
>> hyperthreaded CPUs that will show as 6 CPU's to SQL2000 SP3A. I am lead to believe that logical
>> CPU's 0, 2 and 4 are the physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use All
>> Available Processors checked I am restricting SQL to only using the 3 physical processors and
>> reducing the horsepower available to SQL to half. Is this statement true?
>> Thanks
>> Chris
>>
>|||Andrew,
Some weeks ago we moved a highly I/O intense SQL application off of an SQL
clustered server to its own SQL cluster because it could not live with
another SQL application. After some significant tuning of the code, both
apps, and dropping of old data we are about to put them back together again.
The clustered SQL server has 3 hyperthreaded CPU's with hyperthreading
switched on and available to SQL2000 SP3A build 818. I had read that
hyperthreading was not the best for SQL2000 and wanted to see if notable SQL
experts would comment. We did see some CXPACKET waits before and from what
you are saying if we see them again disabling hyperthreading could be the
best action rather than using the affinity mask.
Thanks so much for your valued opinion.
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
> Chris,
> Some systems follow the rules that Tibor mentioned and some don't in
> regards to how they number their physical and logical processors. There
> are some utilities out there on the net that can interrogate your system
> to see which is which. But once you determine for sure which ones are the
> physical ones and which are only logical you have several options. You can
> disable the logical ones via the affinity mask and that will prevent SQL
> Server from using them but not the OS or any other apps. If you are only
> running SQL Server you are probably OK just disabling them with the
> affinity mask. But if you really want to see for sure if HT is helping or
> hurting I really suggest you turn it off at the BIOS level so there is no
> mistaking the effects. Personally I wish they never invented HT
> processors and everything was dual core:). While I have seen some cases
> where HT made a positive difference I have seen far too many where its
> behavior was misunderstood and it ended up hurting more than helping. I
> wouldn't recommend anyone buy HT enable processors for SQL Server going
> forward.
> --
> Andrew J. Kelly SQL MVP
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
>> Tibor,
>> We have reason to believe that we are following Processor mapping table 2
>> as described in: - http://support.microsoft.com/default.aspx/kb/322385
>> In the thread I mentioned earlier Andrew J Kelly gave a very good
>> description of what could be happening.
>> My question was more that we cannot have our cake and eat it too! If we
>> either change the affinity mask by using the GUI or sp_configure then we
>> are reducing the number of logical processors available to SQL by half
>> even though Windows will still see all logical processors. Disabling in
>> the BIOS would also reduce the logical processors available to Windows in
>> half. I am having a hard time convincing developers that hyperthreading
>> may be causing more performance problems than it could be improving by
>> having more logical processors.
>> Thanks for your speedy reply.
>> Chris
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
>> in message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>> I am lead to believe that logical CPU's 0, 2 and 4 are the physical
>> CPU's.
>> This isn't really how HT is working. A physical processor (lets call it
>> "core" from now on, to avoid confusion if we have multi-core sockets)
>> exposes two logical processors. You can't say that one of those logical
>> processors is more physical than the other.
>> Also, Intel's recommendation for the BIOS/HW manufacturer is as below.
>> Say we have 4 core:
>> Processor 0, as seen by OS: Core 0, logical processor 0
>> Processor 1, as seen by OS: Core 1, logical processor 0
>> Processor 2, as seen by OS: Core 2, logical processor 0
>> Processor 3, as seen by OS: Core 3, logical processor 0
>> Processor 4, as seen by OS: Core 0, logical processor 1
>> Processor 5, as seen by OS: Core 1, logical processor 1
>> Processor 6, as seen by OS: Core 2, logical processor 1
>> Processor 7, as seen by OS: Core 3, logical processor 1
>> So, if you want to specify that only one logical processor per core
>> should be used by SQL Server, you should tell SQL Server to use
>> processors 0-3. However, disabling HT at the BIOS level might be a
>> better option.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have
>> a server with 3 hyperthreaded CPUs that will show as 6 CPU's to SQL2000
>> SP3A. I am lead to believe that logical CPU's 0, 2 and 4 are the
>> physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use All
>> Available Processors checked I am restricting SQL to only using the 3
>> physical processors and reducing the horsepower available to SQL to
>> half. Is this statement true?
>> Thanks
>> Chris
>>
>>
>|||Chris,
I have to say I have never seen a system with 3 processors. CXPackets can be
from several other things as well. Just poor parallel processing in general
can cause these waits. I don't remember too much of the original thread :(
but setting your MAXDOP to 1 can get rid of any simply due to parallelism
but will not fully alleviate the issues of HT. Are you planning on
upgrading to2005 or even SP4 any time soon? What OS are you using? If it is
Win2000 then you are even further behind when it come to HT. Just buy a new
server, its only money:)
--
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23l28mErgHHA.4156@.TK2MSFTNGP02.phx.gbl...
> Andrew,
> Some weeks ago we moved a highly I/O intense SQL application off of an SQL
> clustered server to its own SQL cluster because it could not live with
> another SQL application. After some significant tuning of the code, both
> apps, and dropping of old data we are about to put them back together
> again. The clustered SQL server has 3 hyperthreaded CPU's with
> hyperthreading switched on and available to SQL2000 SP3A build 818. I had
> read that hyperthreading was not the best for SQL2000 and wanted to see if
> notable SQL experts would comment. We did see some CXPACKET waits before
> and from what you are saying if we see them again disabling hyperthreading
> could be the best action rather than using the affinity mask.
> Thanks so much for your valued opinion.
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
>> Chris,
>> Some systems follow the rules that Tibor mentioned and some don't in
>> regards to how they number their physical and logical processors. There
>> are some utilities out there on the net that can interrogate your system
>> to see which is which. But once you determine for sure which ones are
>> the physical ones and which are only logical you have several options.
>> You can disable the logical ones via the affinity mask and that will
>> prevent SQL Server from using them but not the OS or any other apps. If
>> you are only running SQL Server you are probably OK just disabling them
>> with the affinity mask. But if you really want to see for sure if HT is
>> helping or hurting I really suggest you turn it off at the BIOS level so
>> there is no mistaking the effects. Personally I wish they never invented
>> HT processors and everything was dual core:). While I have seen some
>> cases where HT made a positive difference I have seen far too many where
>> its behavior was misunderstood and it ended up hurting more than helping.
>> I wouldn't recommend anyone buy HT enable processors for SQL Server going
>> forward.
>> --
>> Andrew J. Kelly SQL MVP
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
>> Tibor,
>> We have reason to believe that we are following Processor mapping table
>> 2 as described in: - http://support.microsoft.com/default.aspx/kb/322385
>> In the thread I mentioned earlier Andrew J Kelly gave a very good
>> description of what could be happening.
>> My question was more that we cannot have our cake and eat it too! If we
>> either change the affinity mask by using the GUI or sp_configure then we
>> are reducing the number of logical processors available to SQL by half
>> even though Windows will still see all logical processors. Disabling in
>> the BIOS would also reduce the logical processors available to Windows
>> in half. I am having a hard time convincing developers that
>> hyperthreading may be causing more performance problems than it could be
>> improving by having more logical processors.
>> Thanks for your speedy reply.
>> Chris
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
>> in message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>> I am lead to believe that logical CPU's 0, 2 and 4 are the physical
>> CPU's.
>> This isn't really how HT is working. A physical processor (lets call it
>> "core" from now on, to avoid confusion if we have multi-core sockets)
>> exposes two logical processors. You can't say that one of those logical
>> processors is more physical than the other.
>> Also, Intel's recommendation for the BIOS/HW manufacturer is as below.
>> Say we have 4 core:
>> Processor 0, as seen by OS: Core 0, logical processor 0
>> Processor 1, as seen by OS: Core 1, logical processor 0
>> Processor 2, as seen by OS: Core 2, logical processor 0
>> Processor 3, as seen by OS: Core 3, logical processor 0
>> Processor 4, as seen by OS: Core 0, logical processor 1
>> Processor 5, as seen by OS: Core 1, logical processor 1
>> Processor 6, as seen by OS: Core 2, logical processor 1
>> Processor 7, as seen by OS: Core 3, logical processor 1
>> So, if you want to specify that only one logical processor per core
>> should be used by SQL Server, you should tell SQL Server to use
>> processors 0-3. However, disabling HT at the BIOS level might be a
>> better option.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have
>> a server with 3 hyperthreaded CPUs that will show as 6 CPU's to
>> SQL2000 SP3A. I am lead to believe that logical CPU's 0, 2 and 4 are
>> the physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use All
>> Available Processors checked I am restricting SQL to only using the 3
>> physical processors and reducing the horsepower available to SQL to
>> half. Is this statement true?
>> Thanks
>> Chris
>>
>>
>>
>|||Andrew,
We have held off from SP4 because of the move to a new server (the one the
I/O app went to) and SQL2005 SP2. One app is starting converting to SQL2005
and the other will follow when we have enough staff. Both servers are W2K3
with SP1 but the old server has less than 4Gb memory while the new one has
6Gb memory with 4Gb for SQL. Once they are back together again we will be
shoehorning 2 apps into less SQL cache so while I expect faster response
than what is was before the separation I do not expect it to be anywhere as
fast as when they were on their own.
We may have to water down HT to make things work better.
Thanks again.
Hope to see you in Denver at PASS. I am sure I heard you talk in Orlando in
2004 PASS.
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:u7DtGnsgHHA.4260@.TK2MSFTNGP03.phx.gbl...
> Chris,
> I have to say I have never seen a system with 3 processors. CXPackets can
> be from several other things as well. Just poor parallel processing in
> general can cause these waits. I don't remember too much of the original
> thread :( but setting your MAXDOP to 1 can get rid of any simply due to
> parallelism but will not fully alleviate the issues of HT. Are you
> planning on upgrading to2005 or even SP4 any time soon? What OS are you
> using? If it is Win2000 then you are even further behind when it come to
> HT. Just buy a new server, its only money:)
> --
> Andrew J. Kelly SQL MVP
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:%23l28mErgHHA.4156@.TK2MSFTNGP02.phx.gbl...
>> Andrew,
>> Some weeks ago we moved a highly I/O intense SQL application off of an
>> SQL clustered server to its own SQL cluster because it could not live
>> with another SQL application. After some significant tuning of the code,
>> both apps, and dropping of old data we are about to put them back
>> together again. The clustered SQL server has 3 hyperthreaded CPU's with
>> hyperthreading switched on and available to SQL2000 SP3A build 818. I had
>> read that hyperthreading was not the best for SQL2000 and wanted to see
>> if notable SQL experts would comment. We did see some CXPACKET waits
>> before and from what you are saying if we see them again disabling
>> hyperthreading could be the best action rather than using the affinity
>> mask.
>> Thanks so much for your valued opinion.
>> Chris
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
>> Chris,
>> Some systems follow the rules that Tibor mentioned and some don't in
>> regards to how they number their physical and logical processors. There
>> are some utilities out there on the net that can interrogate your system
>> to see which is which. But once you determine for sure which ones are
>> the physical ones and which are only logical you have several options.
>> You can disable the logical ones via the affinity mask and that will
>> prevent SQL Server from using them but not the OS or any other apps. If
>> you are only running SQL Server you are probably OK just disabling them
>> with the affinity mask. But if you really want to see for sure if HT is
>> helping or hurting I really suggest you turn it off at the BIOS level so
>> there is no mistaking the effects. Personally I wish they never
>> invented HT processors and everything was dual core:). While I have
>> seen some cases where HT made a positive difference I have seen far too
>> many where its behavior was misunderstood and it ended up hurting more
>> than helping. I wouldn't recommend anyone buy HT enable processors for
>> SQL Server going forward.
>> --
>> Andrew J. Kelly SQL MVP
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
>> Tibor,
>> We have reason to believe that we are following Processor mapping table
>> 2 as described in: -
>> http://support.microsoft.com/default.aspx/kb/322385
>> In the thread I mentioned earlier Andrew J Kelly gave a very good
>> description of what could be happening.
>> My question was more that we cannot have our cake and eat it too! If we
>> either change the affinity mask by using the GUI or sp_configure then
>> we are reducing the number of logical processors available to SQL by
>> half even though Windows will still see all logical processors.
>> Disabling in the BIOS would also reduce the logical processors
>> available to Windows in half. I am having a hard time convincing
>> developers that hyperthreading may be causing more performance problems
>> than it could be improving by having more logical processors.
>> Thanks for your speedy reply.
>> Chris
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com>
>> wrote in message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>> I am lead to believe that logical CPU's 0, 2 and 4 are the physical
>> CPU's.
>> This isn't really how HT is working. A physical processor (lets call
>> it "core" from now on, to avoid confusion if we have multi-core
>> sockets) exposes two logical processors. You can't say that one of
>> those logical processors is more physical than the other.
>> Also, Intel's recommendation for the BIOS/HW manufacturer is as below.
>> Say we have 4 core:
>> Processor 0, as seen by OS: Core 0, logical processor 0
>> Processor 1, as seen by OS: Core 1, logical processor 0
>> Processor 2, as seen by OS: Core 2, logical processor 0
>> Processor 3, as seen by OS: Core 3, logical processor 0
>> Processor 4, as seen by OS: Core 0, logical processor 1
>> Processor 5, as seen by OS: Core 1, logical processor 1
>> Processor 6, as seen by OS: Core 2, logical processor 1
>> Processor 7, as seen by OS: Core 3, logical processor 1
>> So, if you want to specify that only one logical processor per core
>> should be used by SQL Server, you should tell SQL Server to use
>> processors 0-3. However, disabling HT at the BIOS level might be a
>> better option.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We
>> have a server with 3 hyperthreaded CPUs that will show as 6 CPU's to
>> SQL2000 SP3A. I am lead to believe that logical CPU's 0, 2 and 4 are
>> the physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use
>> All Available Processors checked I am restricting SQL to only using
>> the 3 physical processors and reducing the horsepower available to
>> SQL to half. Is this statement true?
>> Thanks
>> Chris
>>
>>
>>
>>
>|||Chris,
I will be speaking at PASS in Denver this year along with TechEd in Orlando
and probably Dev Connections in Vegas as well. So if you are at any one of
them please look me up.
See you then.
--
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23I1RD9sgHHA.4872@.TK2MSFTNGP03.phx.gbl...
> Andrew,
> We have held off from SP4 because of the move to a new server (the one the
> I/O app went to) and SQL2005 SP2. One app is starting converting to
> SQL2005 and the other will follow when we have enough staff. Both servers
> are W2K3 with SP1 but the old server has less than 4Gb memory while the
> new one has 6Gb memory with 4Gb for SQL. Once they are back together again
> we will be shoehorning 2 apps into less SQL cache so while I expect faster
> response than what is was before the separation I do not expect it to be
> anywhere as fast as when they were on their own.
> We may have to water down HT to make things work better.
> Thanks again.
> Hope to see you in Denver at PASS. I am sure I heard you talk in Orlando
> in 2004 PASS.
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:u7DtGnsgHHA.4260@.TK2MSFTNGP03.phx.gbl...
>> Chris,
>> I have to say I have never seen a system with 3 processors. CXPackets can
>> be from several other things as well. Just poor parallel processing in
>> general can cause these waits. I don't remember too much of the original
>> thread :( but setting your MAXDOP to 1 can get rid of any simply due to
>> parallelism but will not fully alleviate the issues of HT. Are you
>> planning on upgrading to2005 or even SP4 any time soon? What OS are you
>> using? If it is Win2000 then you are even further behind when it come to
>> HT. Just buy a new server, its only money:)
>> --
>> Andrew J. Kelly SQL MVP
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:%23l28mErgHHA.4156@.TK2MSFTNGP02.phx.gbl...
>> Andrew,
>> Some weeks ago we moved a highly I/O intense SQL application off of an
>> SQL clustered server to its own SQL cluster because it could not live
>> with another SQL application. After some significant tuning of the code,
>> both apps, and dropping of old data we are about to put them back
>> together again. The clustered SQL server has 3 hyperthreaded CPU's with
>> hyperthreading switched on and available to SQL2000 SP3A build 818. I
>> had read that hyperthreading was not the best for SQL2000 and wanted to
>> see if notable SQL experts would comment. We did see some CXPACKET waits
>> before and from what you are saying if we see them again disabling
>> hyperthreading could be the best action rather than using the affinity
>> mask.
>> Thanks so much for your valued opinion.
>> Chris
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
>> Chris,
>> Some systems follow the rules that Tibor mentioned and some don't in
>> regards to how they number their physical and logical processors. There
>> are some utilities out there on the net that can interrogate your
>> system to see which is which. But once you determine for sure which
>> ones are the physical ones and which are only logical you have several
>> options. You can disable the logical ones via the affinity mask and
>> that will prevent SQL Server from using them but not the OS or any
>> other apps. If you are only running SQL Server you are probably OK just
>> disabling them with the affinity mask. But if you really want to see
>> for sure if HT is helping or hurting I really suggest you turn it off
>> at the BIOS level so there is no mistaking the effects. Personally I
>> wish they never invented HT processors and everything was dual core:).
>> While I have seen some cases where HT made a positive difference I have
>> seen far too many where its behavior was misunderstood and it ended up
>> hurting more than helping. I wouldn't recommend anyone buy HT enable
>> processors for SQL Server going forward.
>> --
>> Andrew J. Kelly SQL MVP
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
>> Tibor,
>> We have reason to believe that we are following Processor mapping
>> table 2 as described in: -
>> http://support.microsoft.com/default.aspx/kb/322385
>> In the thread I mentioned earlier Andrew J Kelly gave a very good
>> description of what could be happening.
>> My question was more that we cannot have our cake and eat it too! If
>> we either change the affinity mask by using the GUI or sp_configure
>> then we are reducing the number of logical processors available to SQL
>> by half even though Windows will still see all logical processors.
>> Disabling in the BIOS would also reduce the logical processors
>> available to Windows in half. I am having a hard time convincing
>> developers that hyperthreading may be causing more performance
>> problems than it could be improving by having more logical processors.
>> Thanks for your speedy reply.
>> Chris
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com>
>> wrote in message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>>> I am lead to believe that logical CPU's 0, 2 and 4 are the physical
>>> CPU's.
>> This isn't really how HT is working. A physical processor (lets call
>> it "core" from now on, to avoid confusion if we have multi-core
>> sockets) exposes two logical processors. You can't say that one of
>> those logical processors is more physical than the other.
>> Also, Intel's recommendation for the BIOS/HW manufacturer is as
>> below. Say we have 4 core:
>> Processor 0, as seen by OS: Core 0, logical processor 0
>> Processor 1, as seen by OS: Core 1, logical processor 0
>> Processor 2, as seen by OS: Core 2, logical processor 0
>> Processor 3, as seen by OS: Core 3, logical processor 0
>> Processor 4, as seen by OS: Core 0, logical processor 1
>> Processor 5, as seen by OS: Core 1, logical processor 1
>> Processor 6, as seen by OS: Core 2, logical processor 1
>> Processor 7, as seen by OS: Core 3, logical processor 1
>> So, if you want to specify that only one logical processor per core
>> should be used by SQL Server, you should tell SQL Server to use
>> processors 0-3. However, disabling HT at the BIOS level might be a
>> better option.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>>> Hi,
>>>
>>> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We
>>> have a server with 3 hyperthreaded CPUs that will show as 6 CPU's to
>>> SQL2000 SP3A. I am lead to believe that logical CPU's 0, 2 and 4 are
>>> the physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use
>>> All Available Processors checked I am restricting SQL to only using
>>> the 3 physical processors and reducing the horsepower available to
>>> SQL to half. Is this statement true?
>>>
>>> Thanks
>>>
>>> Chris
>>>
>>
>>
>>
>>
>
This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a
server with 3 hyperthreaded CPUs that will show as 6 CPU's to SQL2000 SP3A.
I am lead to believe that logical CPU's 0, 2 and 4 are the physical CPU's.
If I uncheck CPU's 1, 3 and 5 but keep the Use All Available Processors
checked I am restricting SQL to only using the 3 physical processors and
reducing the horsepower available to SQL to half. Is this statement true?
Thanks
Chris> I am lead to believe that logical CPU's 0, 2 and 4 are the physical CPU's.
This isn't really how HT is working. A physical processor (lets call it "core" from now on, to avoid
confusion if we have multi-core sockets) exposes two logical processors. You can't say that one of
those logical processors is more physical than the other.
Also, Intel's recommendation for the BIOS/HW manufacturer is as below. Say we have 4 core:
Processor 0, as seen by OS: Core 0, logical processor 0
Processor 1, as seen by OS: Core 1, logical processor 0
Processor 2, as seen by OS: Core 2, logical processor 0
Processor 3, as seen by OS: Core 3, logical processor 0
Processor 4, as seen by OS: Core 0, logical processor 1
Processor 5, as seen by OS: Core 1, logical processor 1
Processor 6, as seen by OS: Core 2, logical processor 1
Processor 7, as seen by OS: Core 3, logical processor 1
So, if you want to specify that only one logical processor per core should be used by SQL Server,
you should tell SQL Server to use processors 0-3. However, disabling HT at the BIOS level might be a
better option.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
> Hi,
> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a server with 3
> hyperthreaded CPUs that will show as 6 CPU's to SQL2000 SP3A. I am lead to believe that logical
> CPU's 0, 2 and 4 are the physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use All
> Available Processors checked I am restricting SQL to only using the 3 physical processors and
> reducing the horsepower available to SQL to half. Is this statement true?
> Thanks
> Chris
>|||Tibor,
We have reason to believe that we are following Processor mapping table 2 as
described in: - http://support.microsoft.com/default.aspx/kb/322385
In the thread I mentioned earlier Andrew J Kelly gave a very good
description of what could be happening.
My question was more that we cannot have our cake and eat it too! If we
either change the affinity mask by using the GUI or sp_configure then we are
reducing the number of logical processors available to SQL by half even
though Windows will still see all logical processors. Disabling in the BIOS
would also reduce the logical processors available to Windows in half. I am
having a hard time convincing developers that hyperthreading may be causing
more performance problems than it could be improving by having more logical
processors.
Thanks for your speedy reply.
Chris
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>> I am lead to believe that logical CPU's 0, 2 and 4 are the physical
>> CPU's.
> This isn't really how HT is working. A physical processor (lets call it
> "core" from now on, to avoid confusion if we have multi-core sockets)
> exposes two logical processors. You can't say that one of those logical
> processors is more physical than the other.
> Also, Intel's recommendation for the BIOS/HW manufacturer is as below. Say
> we have 4 core:
> Processor 0, as seen by OS: Core 0, logical processor 0
> Processor 1, as seen by OS: Core 1, logical processor 0
> Processor 2, as seen by OS: Core 2, logical processor 0
> Processor 3, as seen by OS: Core 3, logical processor 0
> Processor 4, as seen by OS: Core 0, logical processor 1
> Processor 5, as seen by OS: Core 1, logical processor 1
> Processor 6, as seen by OS: Core 2, logical processor 1
> Processor 7, as seen by OS: Core 3, logical processor 1
> So, if you want to specify that only one logical processor per core should
> be used by SQL Server, you should tell SQL Server to use processors 0-3.
> However, disabling HT at the BIOS level might be a better option.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a
>> server with 3 hyperthreaded CPUs that will show as 6 CPU's to SQL2000
>> SP3A. I am lead to believe that logical CPU's 0, 2 and 4 are the physical
>> CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use All Available
>> Processors checked I am restricting SQL to only using the 3 physical
>> processors and reducing the horsepower available to SQL to half. Is this
>> statement true?
>> Thanks
>> Chris
>|||Chris,
Some systems follow the rules that Tibor mentioned and some don't in regards
to how they number their physical and logical processors. There are some
utilities out there on the net that can interrogate your system to see which
is which. But once you determine for sure which ones are the physical ones
and which are only logical you have several options. You can disable the
logical ones via the affinity mask and that will prevent SQL Server from
using them but not the OS or any other apps. If you are only running SQL
Server you are probably OK just disabling them with the affinity mask. But
if you really want to see for sure if HT is helping or hurting I really
suggest you turn it off at the BIOS level so there is no mistaking the
effects. Personally I wish they never invented HT processors and everything
was dual core:). While I have seen some cases where HT made a positive
difference I have seen far too many where its behavior was misunderstood and
it ended up hurting more than helping. I wouldn't recommend anyone buy HT
enable processors for SQL Server going forward.
--
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
> Tibor,
> We have reason to believe that we are following Processor mapping table 2
> as described in: - http://support.microsoft.com/default.aspx/kb/322385
> In the thread I mentioned earlier Andrew J Kelly gave a very good
> description of what could be happening.
> My question was more that we cannot have our cake and eat it too! If we
> either change the affinity mask by using the GUI or sp_configure then we
> are reducing the number of logical processors available to SQL by half
> even though Windows will still see all logical processors. Disabling in
> the BIOS would also reduce the logical processors available to Windows in
> half. I am having a hard time convincing developers that hyperthreading
> may be causing more performance problems than it could be improving by
> having more logical processors.
> Thanks for your speedy reply.
> Chris
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>> I am lead to believe that logical CPU's 0, 2 and 4 are the physical
>> CPU's.
>> This isn't really how HT is working. A physical processor (lets call it
>> "core" from now on, to avoid confusion if we have multi-core sockets)
>> exposes two logical processors. You can't say that one of those logical
>> processors is more physical than the other.
>> Also, Intel's recommendation for the BIOS/HW manufacturer is as below.
>> Say we have 4 core:
>> Processor 0, as seen by OS: Core 0, logical processor 0
>> Processor 1, as seen by OS: Core 1, logical processor 0
>> Processor 2, as seen by OS: Core 2, logical processor 0
>> Processor 3, as seen by OS: Core 3, logical processor 0
>> Processor 4, as seen by OS: Core 0, logical processor 1
>> Processor 5, as seen by OS: Core 1, logical processor 1
>> Processor 6, as seen by OS: Core 2, logical processor 1
>> Processor 7, as seen by OS: Core 3, logical processor 1
>> So, if you want to specify that only one logical processor per core
>> should be used by SQL Server, you should tell SQL Server to use
>> processors 0-3. However, disabling HT at the BIOS level might be a better
>> option.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a
>> server with 3 hyperthreaded CPUs that will show as 6 CPU's to SQL2000
>> SP3A. I am lead to believe that logical CPU's 0, 2 and 4 are the
>> physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use All
>> Available Processors checked I am restricting SQL to only using the 3
>> physical processors and reducing the horsepower available to SQL to
>> half. Is this statement true?
>> Thanks
>> Chris
>>
>|||> We have reason to believe that we are following Processor mapping table 2 as described in: -
> http://support.microsoft.com/default.aspx/kb/322385
Ahh, thanks for updating my knowledge on this, I was only aware of table 1, as the recommendation
from Intel.
I fully concur with Andrew to verify how the layout, using a utility before experimenting with
affinity mask, and also do a load test to see whether disabling HT at the BIOS level won't be the
best after all.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
> Tibor,
> We have reason to believe that we are following Processor mapping table 2 as described in: -
> http://support.microsoft.com/default.aspx/kb/322385
> In the thread I mentioned earlier Andrew J Kelly gave a very good description of what could be
> happening.
> My question was more that we cannot have our cake and eat it too! If we either change the affinity
> mask by using the GUI or sp_configure then we are reducing the number of logical processors
> available to SQL by half even though Windows will still see all logical processors. Disabling in
> the BIOS would also reduce the logical processors available to Windows in half. I am having a hard
> time convincing developers that hyperthreading may be causing more performance problems than it
> could be improving by having more logical processors.
> Thanks for your speedy reply.
> Chris
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message
> news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>> I am lead to believe that logical CPU's 0, 2 and 4 are the physical CPU's.
>> This isn't really how HT is working. A physical processor (lets call it "core" from now on, to
>> avoid confusion if we have multi-core sockets) exposes two logical processors. You can't say that
>> one of those logical processors is more physical than the other.
>> Also, Intel's recommendation for the BIOS/HW manufacturer is as below. Say we have 4 core:
>> Processor 0, as seen by OS: Core 0, logical processor 0
>> Processor 1, as seen by OS: Core 1, logical processor 0
>> Processor 2, as seen by OS: Core 2, logical processor 0
>> Processor 3, as seen by OS: Core 3, logical processor 0
>> Processor 4, as seen by OS: Core 0, logical processor 1
>> Processor 5, as seen by OS: Core 1, logical processor 1
>> Processor 6, as seen by OS: Core 2, logical processor 1
>> Processor 7, as seen by OS: Core 3, logical processor 1
>> So, if you want to specify that only one logical processor per core should be used by SQL Server,
>> you should tell SQL Server to use processors 0-3. However, disabling HT at the BIOS level might
>> be a better option.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have a server with 3
>> hyperthreaded CPUs that will show as 6 CPU's to SQL2000 SP3A. I am lead to believe that logical
>> CPU's 0, 2 and 4 are the physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use All
>> Available Processors checked I am restricting SQL to only using the 3 physical processors and
>> reducing the horsepower available to SQL to half. Is this statement true?
>> Thanks
>> Chris
>>
>|||Andrew,
Some weeks ago we moved a highly I/O intense SQL application off of an SQL
clustered server to its own SQL cluster because it could not live with
another SQL application. After some significant tuning of the code, both
apps, and dropping of old data we are about to put them back together again.
The clustered SQL server has 3 hyperthreaded CPU's with hyperthreading
switched on and available to SQL2000 SP3A build 818. I had read that
hyperthreading was not the best for SQL2000 and wanted to see if notable SQL
experts would comment. We did see some CXPACKET waits before and from what
you are saying if we see them again disabling hyperthreading could be the
best action rather than using the affinity mask.
Thanks so much for your valued opinion.
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
> Chris,
> Some systems follow the rules that Tibor mentioned and some don't in
> regards to how they number their physical and logical processors. There
> are some utilities out there on the net that can interrogate your system
> to see which is which. But once you determine for sure which ones are the
> physical ones and which are only logical you have several options. You can
> disable the logical ones via the affinity mask and that will prevent SQL
> Server from using them but not the OS or any other apps. If you are only
> running SQL Server you are probably OK just disabling them with the
> affinity mask. But if you really want to see for sure if HT is helping or
> hurting I really suggest you turn it off at the BIOS level so there is no
> mistaking the effects. Personally I wish they never invented HT
> processors and everything was dual core:). While I have seen some cases
> where HT made a positive difference I have seen far too many where its
> behavior was misunderstood and it ended up hurting more than helping. I
> wouldn't recommend anyone buy HT enable processors for SQL Server going
> forward.
> --
> Andrew J. Kelly SQL MVP
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
>> Tibor,
>> We have reason to believe that we are following Processor mapping table 2
>> as described in: - http://support.microsoft.com/default.aspx/kb/322385
>> In the thread I mentioned earlier Andrew J Kelly gave a very good
>> description of what could be happening.
>> My question was more that we cannot have our cake and eat it too! If we
>> either change the affinity mask by using the GUI or sp_configure then we
>> are reducing the number of logical processors available to SQL by half
>> even though Windows will still see all logical processors. Disabling in
>> the BIOS would also reduce the logical processors available to Windows in
>> half. I am having a hard time convincing developers that hyperthreading
>> may be causing more performance problems than it could be improving by
>> having more logical processors.
>> Thanks for your speedy reply.
>> Chris
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
>> in message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>> I am lead to believe that logical CPU's 0, 2 and 4 are the physical
>> CPU's.
>> This isn't really how HT is working. A physical processor (lets call it
>> "core" from now on, to avoid confusion if we have multi-core sockets)
>> exposes two logical processors. You can't say that one of those logical
>> processors is more physical than the other.
>> Also, Intel's recommendation for the BIOS/HW manufacturer is as below.
>> Say we have 4 core:
>> Processor 0, as seen by OS: Core 0, logical processor 0
>> Processor 1, as seen by OS: Core 1, logical processor 0
>> Processor 2, as seen by OS: Core 2, logical processor 0
>> Processor 3, as seen by OS: Core 3, logical processor 0
>> Processor 4, as seen by OS: Core 0, logical processor 1
>> Processor 5, as seen by OS: Core 1, logical processor 1
>> Processor 6, as seen by OS: Core 2, logical processor 1
>> Processor 7, as seen by OS: Core 3, logical processor 1
>> So, if you want to specify that only one logical processor per core
>> should be used by SQL Server, you should tell SQL Server to use
>> processors 0-3. However, disabling HT at the BIOS level might be a
>> better option.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have
>> a server with 3 hyperthreaded CPUs that will show as 6 CPU's to SQL2000
>> SP3A. I am lead to believe that logical CPU's 0, 2 and 4 are the
>> physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use All
>> Available Processors checked I am restricting SQL to only using the 3
>> physical processors and reducing the horsepower available to SQL to
>> half. Is this statement true?
>> Thanks
>> Chris
>>
>>
>|||Chris,
I have to say I have never seen a system with 3 processors. CXPackets can be
from several other things as well. Just poor parallel processing in general
can cause these waits. I don't remember too much of the original thread :(
but setting your MAXDOP to 1 can get rid of any simply due to parallelism
but will not fully alleviate the issues of HT. Are you planning on
upgrading to2005 or even SP4 any time soon? What OS are you using? If it is
Win2000 then you are even further behind when it come to HT. Just buy a new
server, its only money:)
--
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23l28mErgHHA.4156@.TK2MSFTNGP02.phx.gbl...
> Andrew,
> Some weeks ago we moved a highly I/O intense SQL application off of an SQL
> clustered server to its own SQL cluster because it could not live with
> another SQL application. After some significant tuning of the code, both
> apps, and dropping of old data we are about to put them back together
> again. The clustered SQL server has 3 hyperthreaded CPU's with
> hyperthreading switched on and available to SQL2000 SP3A build 818. I had
> read that hyperthreading was not the best for SQL2000 and wanted to see if
> notable SQL experts would comment. We did see some CXPACKET waits before
> and from what you are saying if we see them again disabling hyperthreading
> could be the best action rather than using the affinity mask.
> Thanks so much for your valued opinion.
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
>> Chris,
>> Some systems follow the rules that Tibor mentioned and some don't in
>> regards to how they number their physical and logical processors. There
>> are some utilities out there on the net that can interrogate your system
>> to see which is which. But once you determine for sure which ones are
>> the physical ones and which are only logical you have several options.
>> You can disable the logical ones via the affinity mask and that will
>> prevent SQL Server from using them but not the OS or any other apps. If
>> you are only running SQL Server you are probably OK just disabling them
>> with the affinity mask. But if you really want to see for sure if HT is
>> helping or hurting I really suggest you turn it off at the BIOS level so
>> there is no mistaking the effects. Personally I wish they never invented
>> HT processors and everything was dual core:). While I have seen some
>> cases where HT made a positive difference I have seen far too many where
>> its behavior was misunderstood and it ended up hurting more than helping.
>> I wouldn't recommend anyone buy HT enable processors for SQL Server going
>> forward.
>> --
>> Andrew J. Kelly SQL MVP
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
>> Tibor,
>> We have reason to believe that we are following Processor mapping table
>> 2 as described in: - http://support.microsoft.com/default.aspx/kb/322385
>> In the thread I mentioned earlier Andrew J Kelly gave a very good
>> description of what could be happening.
>> My question was more that we cannot have our cake and eat it too! If we
>> either change the affinity mask by using the GUI or sp_configure then we
>> are reducing the number of logical processors available to SQL by half
>> even though Windows will still see all logical processors. Disabling in
>> the BIOS would also reduce the logical processors available to Windows
>> in half. I am having a hard time convincing developers that
>> hyperthreading may be causing more performance problems than it could be
>> improving by having more logical processors.
>> Thanks for your speedy reply.
>> Chris
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
>> in message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>> I am lead to believe that logical CPU's 0, 2 and 4 are the physical
>> CPU's.
>> This isn't really how HT is working. A physical processor (lets call it
>> "core" from now on, to avoid confusion if we have multi-core sockets)
>> exposes two logical processors. You can't say that one of those logical
>> processors is more physical than the other.
>> Also, Intel's recommendation for the BIOS/HW manufacturer is as below.
>> Say we have 4 core:
>> Processor 0, as seen by OS: Core 0, logical processor 0
>> Processor 1, as seen by OS: Core 1, logical processor 0
>> Processor 2, as seen by OS: Core 2, logical processor 0
>> Processor 3, as seen by OS: Core 3, logical processor 0
>> Processor 4, as seen by OS: Core 0, logical processor 1
>> Processor 5, as seen by OS: Core 1, logical processor 1
>> Processor 6, as seen by OS: Core 2, logical processor 1
>> Processor 7, as seen by OS: Core 3, logical processor 1
>> So, if you want to specify that only one logical processor per core
>> should be used by SQL Server, you should tell SQL Server to use
>> processors 0-3. However, disabling HT at the BIOS level might be a
>> better option.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We have
>> a server with 3 hyperthreaded CPUs that will show as 6 CPU's to
>> SQL2000 SP3A. I am lead to believe that logical CPU's 0, 2 and 4 are
>> the physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use All
>> Available Processors checked I am restricting SQL to only using the 3
>> physical processors and reducing the horsepower available to SQL to
>> half. Is this statement true?
>> Thanks
>> Chris
>>
>>
>>
>|||Andrew,
We have held off from SP4 because of the move to a new server (the one the
I/O app went to) and SQL2005 SP2. One app is starting converting to SQL2005
and the other will follow when we have enough staff. Both servers are W2K3
with SP1 but the old server has less than 4Gb memory while the new one has
6Gb memory with 4Gb for SQL. Once they are back together again we will be
shoehorning 2 apps into less SQL cache so while I expect faster response
than what is was before the separation I do not expect it to be anywhere as
fast as when they were on their own.
We may have to water down HT to make things work better.
Thanks again.
Hope to see you in Denver at PASS. I am sure I heard you talk in Orlando in
2004 PASS.
Chris
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:u7DtGnsgHHA.4260@.TK2MSFTNGP03.phx.gbl...
> Chris,
> I have to say I have never seen a system with 3 processors. CXPackets can
> be from several other things as well. Just poor parallel processing in
> general can cause these waits. I don't remember too much of the original
> thread :( but setting your MAXDOP to 1 can get rid of any simply due to
> parallelism but will not fully alleviate the issues of HT. Are you
> planning on upgrading to2005 or even SP4 any time soon? What OS are you
> using? If it is Win2000 then you are even further behind when it come to
> HT. Just buy a new server, its only money:)
> --
> Andrew J. Kelly SQL MVP
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:%23l28mErgHHA.4156@.TK2MSFTNGP02.phx.gbl...
>> Andrew,
>> Some weeks ago we moved a highly I/O intense SQL application off of an
>> SQL clustered server to its own SQL cluster because it could not live
>> with another SQL application. After some significant tuning of the code,
>> both apps, and dropping of old data we are about to put them back
>> together again. The clustered SQL server has 3 hyperthreaded CPU's with
>> hyperthreading switched on and available to SQL2000 SP3A build 818. I had
>> read that hyperthreading was not the best for SQL2000 and wanted to see
>> if notable SQL experts would comment. We did see some CXPACKET waits
>> before and from what you are saying if we see them again disabling
>> hyperthreading could be the best action rather than using the affinity
>> mask.
>> Thanks so much for your valued opinion.
>> Chris
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
>> Chris,
>> Some systems follow the rules that Tibor mentioned and some don't in
>> regards to how they number their physical and logical processors. There
>> are some utilities out there on the net that can interrogate your system
>> to see which is which. But once you determine for sure which ones are
>> the physical ones and which are only logical you have several options.
>> You can disable the logical ones via the affinity mask and that will
>> prevent SQL Server from using them but not the OS or any other apps. If
>> you are only running SQL Server you are probably OK just disabling them
>> with the affinity mask. But if you really want to see for sure if HT is
>> helping or hurting I really suggest you turn it off at the BIOS level so
>> there is no mistaking the effects. Personally I wish they never
>> invented HT processors and everything was dual core:). While I have
>> seen some cases where HT made a positive difference I have seen far too
>> many where its behavior was misunderstood and it ended up hurting more
>> than helping. I wouldn't recommend anyone buy HT enable processors for
>> SQL Server going forward.
>> --
>> Andrew J. Kelly SQL MVP
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
>> Tibor,
>> We have reason to believe that we are following Processor mapping table
>> 2 as described in: -
>> http://support.microsoft.com/default.aspx/kb/322385
>> In the thread I mentioned earlier Andrew J Kelly gave a very good
>> description of what could be happening.
>> My question was more that we cannot have our cake and eat it too! If we
>> either change the affinity mask by using the GUI or sp_configure then
>> we are reducing the number of logical processors available to SQL by
>> half even though Windows will still see all logical processors.
>> Disabling in the BIOS would also reduce the logical processors
>> available to Windows in half. I am having a hard time convincing
>> developers that hyperthreading may be causing more performance problems
>> than it could be improving by having more logical processors.
>> Thanks for your speedy reply.
>> Chris
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com>
>> wrote in message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>> I am lead to believe that logical CPU's 0, 2 and 4 are the physical
>> CPU's.
>> This isn't really how HT is working. A physical processor (lets call
>> it "core" from now on, to avoid confusion if we have multi-core
>> sockets) exposes two logical processors. You can't say that one of
>> those logical processors is more physical than the other.
>> Also, Intel's recommendation for the BIOS/HW manufacturer is as below.
>> Say we have 4 core:
>> Processor 0, as seen by OS: Core 0, logical processor 0
>> Processor 1, as seen by OS: Core 1, logical processor 0
>> Processor 2, as seen by OS: Core 2, logical processor 0
>> Processor 3, as seen by OS: Core 3, logical processor 0
>> Processor 4, as seen by OS: Core 0, logical processor 1
>> Processor 5, as seen by OS: Core 1, logical processor 1
>> Processor 6, as seen by OS: Core 2, logical processor 1
>> Processor 7, as seen by OS: Core 3, logical processor 1
>> So, if you want to specify that only one logical processor per core
>> should be used by SQL Server, you should tell SQL Server to use
>> processors 0-3. However, disabling HT at the BIOS level might be a
>> better option.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>> Hi,
>> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We
>> have a server with 3 hyperthreaded CPUs that will show as 6 CPU's to
>> SQL2000 SP3A. I am lead to believe that logical CPU's 0, 2 and 4 are
>> the physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use
>> All Available Processors checked I am restricting SQL to only using
>> the 3 physical processors and reducing the horsepower available to
>> SQL to half. Is this statement true?
>> Thanks
>> Chris
>>
>>
>>
>>
>|||Chris,
I will be speaking at PASS in Denver this year along with TechEd in Orlando
and probably Dev Connections in Vegas as well. So if you are at any one of
them please look me up.
See you then.
--
Andrew J. Kelly SQL MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%23I1RD9sgHHA.4872@.TK2MSFTNGP03.phx.gbl...
> Andrew,
> We have held off from SP4 because of the move to a new server (the one the
> I/O app went to) and SQL2005 SP2. One app is starting converting to
> SQL2005 and the other will follow when we have enough staff. Both servers
> are W2K3 with SP1 but the old server has less than 4Gb memory while the
> new one has 6Gb memory with 4Gb for SQL. Once they are back together again
> we will be shoehorning 2 apps into less SQL cache so while I expect faster
> response than what is was before the separation I do not expect it to be
> anywhere as fast as when they were on their own.
> We may have to water down HT to make things work better.
> Thanks again.
> Hope to see you in Denver at PASS. I am sure I heard you talk in Orlando
> in 2004 PASS.
> Chris
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:u7DtGnsgHHA.4260@.TK2MSFTNGP03.phx.gbl...
>> Chris,
>> I have to say I have never seen a system with 3 processors. CXPackets can
>> be from several other things as well. Just poor parallel processing in
>> general can cause these waits. I don't remember too much of the original
>> thread :( but setting your MAXDOP to 1 can get rid of any simply due to
>> parallelism but will not fully alleviate the issues of HT. Are you
>> planning on upgrading to2005 or even SP4 any time soon? What OS are you
>> using? If it is Win2000 then you are even further behind when it come to
>> HT. Just buy a new server, its only money:)
>> --
>> Andrew J. Kelly SQL MVP
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:%23l28mErgHHA.4156@.TK2MSFTNGP02.phx.gbl...
>> Andrew,
>> Some weeks ago we moved a highly I/O intense SQL application off of an
>> SQL clustered server to its own SQL cluster because it could not live
>> with another SQL application. After some significant tuning of the code,
>> both apps, and dropping of old data we are about to put them back
>> together again. The clustered SQL server has 3 hyperthreaded CPU's with
>> hyperthreading switched on and available to SQL2000 SP3A build 818. I
>> had read that hyperthreading was not the best for SQL2000 and wanted to
>> see if notable SQL experts would comment. We did see some CXPACKET waits
>> before and from what you are saying if we see them again disabling
>> hyperthreading could be the best action rather than using the affinity
>> mask.
>> Thanks so much for your valued opinion.
>> Chris
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:%23AFJZsqgHHA.4140@.TK2MSFTNGP05.phx.gbl...
>> Chris,
>> Some systems follow the rules that Tibor mentioned and some don't in
>> regards to how they number their physical and logical processors. There
>> are some utilities out there on the net that can interrogate your
>> system to see which is which. But once you determine for sure which
>> ones are the physical ones and which are only logical you have several
>> options. You can disable the logical ones via the affinity mask and
>> that will prevent SQL Server from using them but not the OS or any
>> other apps. If you are only running SQL Server you are probably OK just
>> disabling them with the affinity mask. But if you really want to see
>> for sure if HT is helping or hurting I really suggest you turn it off
>> at the BIOS level so there is no mistaking the effects. Personally I
>> wish they never invented HT processors and everything was dual core:).
>> While I have seen some cases where HT made a positive difference I have
>> seen far too many where its behavior was misunderstood and it ended up
>> hurting more than helping. I wouldn't recommend anyone buy HT enable
>> processors for SQL Server going forward.
>> --
>> Andrew J. Kelly SQL MVP
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:OOrYfVqgHHA.3412@.TK2MSFTNGP02.phx.gbl...
>> Tibor,
>> We have reason to believe that we are following Processor mapping
>> table 2 as described in: -
>> http://support.microsoft.com/default.aspx/kb/322385
>> In the thread I mentioned earlier Andrew J Kelly gave a very good
>> description of what could be happening.
>> My question was more that we cannot have our cake and eat it too! If
>> we either change the affinity mask by using the GUI or sp_configure
>> then we are reducing the number of logical processors available to SQL
>> by half even though Windows will still see all logical processors.
>> Disabling in the BIOS would also reduce the logical processors
>> available to Windows in half. I am having a hard time convincing
>> developers that hyperthreading may be causing more performance
>> problems than it could be improving by having more logical processors.
>> Thanks for your speedy reply.
>> Chris
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com>
>> wrote in message news:eXArpGqgHHA.596@.TK2MSFTNGP06.phx.gbl...
>>> I am lead to believe that logical CPU's 0, 2 and 4 are the physical
>>> CPU's.
>> This isn't really how HT is working. A physical processor (lets call
>> it "core" from now on, to avoid confusion if we have multi-core
>> sockets) exposes two logical processors. You can't say that one of
>> those logical processors is more physical than the other.
>> Also, Intel's recommendation for the BIOS/HW manufacturer is as
>> below. Say we have 4 core:
>> Processor 0, as seen by OS: Core 0, logical processor 0
>> Processor 1, as seen by OS: Core 1, logical processor 0
>> Processor 2, as seen by OS: Core 2, logical processor 0
>> Processor 3, as seen by OS: Core 3, logical processor 0
>> Processor 4, as seen by OS: Core 0, logical processor 1
>> Processor 5, as seen by OS: Core 1, logical processor 1
>> Processor 6, as seen by OS: Core 2, logical processor 1
>> Processor 7, as seen by OS: Core 3, logical processor 1
>> So, if you want to specify that only one logical processor per core
>> should be used by SQL Server, you should tell SQL Server to use
>> processors 0-3. However, disabling HT at the BIOS level might be a
>> better option.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://sqlblog.com/blogs/tibor_karaszi
>>
>> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
>> news:%23VpU%237pgHHA.392@.TK2MSFTNGP06.phx.gbl...
>>> Hi,
>>>
>>> This is a follow-up to Ken's earlier Option (MAXDOP 1) thread. We
>>> have a server with 3 hyperthreaded CPUs that will show as 6 CPU's to
>>> SQL2000 SP3A. I am lead to believe that logical CPU's 0, 2 and 4 are
>>> the physical CPU's. If I uncheck CPU's 1, 3 and 5 but keep the Use
>>> All Available Processors checked I am restricting SQL to only using
>>> the 3 physical processors and reducing the horsepower available to
>>> SQL to half. Is this statement true?
>>>
>>> Thanks
>>>
>>> Chris
>>>
>>
>>
>>
>>
>
Sunday, February 19, 2012
Hyper Threading SQL 2000 Ent, Windows 2003 4GB RAM -> "Yes" or "No
Hi
What would be the best practice on subject? Are there any resources I should
read?
Our server have 2xXEON CPU's and 4 with HT (All are enabled on our SQL
2000), but we have some performance issue.
Thanks
Have a look here:
http://blogs.msdn.com/slavao/archive...12/492119.aspx
Bottom line is that you don't know for sure until you test it both ways
under the exact conditions you will run with. Sometimes it helps sometimes
it hurts.
Andrew J. Kelly SQL MVP
"Core" <Core@.discussions.microsoft.com> wrote in message
news:3E7FB0BD-07D0-426D-94D3-4BE515D0FE7A@.microsoft.com...
> Hi
> What would be the best practice on subject? Are there any resources I
> should
> read?
> Our server have 2xXEON CPU's and 4 with HT (All are enabled on our SQL
> 2000), but we have some performance issue.
> Thanks
What would be the best practice on subject? Are there any resources I should
read?
Our server have 2xXEON CPU's and 4 with HT (All are enabled on our SQL
2000), but we have some performance issue.
Thanks
Have a look here:
http://blogs.msdn.com/slavao/archive...12/492119.aspx
Bottom line is that you don't know for sure until you test it both ways
under the exact conditions you will run with. Sometimes it helps sometimes
it hurts.
Andrew J. Kelly SQL MVP
"Core" <Core@.discussions.microsoft.com> wrote in message
news:3E7FB0BD-07D0-426D-94D3-4BE515D0FE7A@.microsoft.com...
> Hi
> What would be the best practice on subject? Are there any resources I
> should
> read?
> Our server have 2xXEON CPU's and 4 with HT (All are enabled on our SQL
> 2000), but we have some performance issue.
> Thanks
hyper threading
Hi,
Are there any issues/benifits when running SQL Server 2000
EE SP3a/Windows 2000 Server SP4 on a machine that has CPUs
with hyper threading enabled?
--
Thanks
OskarOskar,
Works for me - I have some 4 way servers with hyperthreading. I've not
heard of anything that would cause any issues. Make sure you are on the
latest service packs though (looks like you are).
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602m.html
Oskar wrote:
> Hi,
> Are there any issues/benifits when running SQL Server 2000
> EE SP3a/Windows 2000 Server SP4 on a machine that has CPUs
> with hyper threading enabled?
> --
> Thanks
> Oskar|||At a minimum... you might consider changing max degree of parrelism to the
PHYSICAL number of processors rather than the logical. I've seen many cases
where you'll have problems with cxpacket waits if you get a 4X plan on a box
with 2 physical but 4 logical processors...
Of course this isn't always true. But something to think about...
--
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Oskar" <anonymous@.discussions.microsoft.com> wrote in message
news:2df001c4a217$c7278520$a601280a@.phx.gbl...
> Hi,
> Are there any issues/benifits when running SQL Server 2000
> EE SP3a/Windows 2000 Server SP4 on a machine that has CPUs
> with hyper threading enabled?
> --
> Thanks
> Oskar|||When is it true? And when is it NOT true?
Please give us details.
"Brian Moran" <brian@.solidqualitylearning.com> wrote in message
news:uQi0GkjoEHA.3900@.TK2MSFTNGP10.phx.gbl...
> At a minimum... you might consider changing max degree of parrelism to
> the
> PHYSICAL number of processors rather than the logical. I've seen many
> cases
> where you'll have problems with cxpacket waits if you get a 4X plan on a
> box
> with 2 physical but 4 logical processors...
> Of course this isn't always true. But something to think about...
> --
> Brian Moran
> Principal Mentor
> Solid Quality Learning
> SQL Server MVP
> http://www.solidqualitylearning.com
>
> "Oskar" <anonymous@.discussions.microsoft.com> wrote in message
> news:2df001c4a217$c7278520$a601280a@.phx.gbl...
>> Hi,
>> Are there any issues/benifits when running SQL Server 2000
>> EE SP3a/Windows 2000 Server SP4 on a machine that has CPUs
>> with hyper threading enabled?
>> --
>> Thanks
>> Oskar
>|||Have you heard that any of post SP3(a) fixes help? I can't
find a confirmation of this on MS website though.
--
Oskar
>--Original Message--
>Oskar,
>Works for me - I have some 4 way servers with
hyperthreading. I've not
>heard of anything that would cause any issues. Make sure
you are on the
>latest service packs though (looks like you are).
>--
>Mark Allison, SQL Server MVP
>http://www.markallison.co.uk
>Looking for a SQL Server replication book?
>http://www.nwsu.com/0974973602m.html
>
>Oskar wrote:
>> Hi,
>> Are there any issues/benifits when running SQL Server
2000
>> EE SP3a/Windows 2000 Server SP4 on a machine that has
CPUs
>> with hyper threading enabled?
>> --
>> Thanks
>> Oskar
>.
>
Are there any issues/benifits when running SQL Server 2000
EE SP3a/Windows 2000 Server SP4 on a machine that has CPUs
with hyper threading enabled?
--
Thanks
OskarOskar,
Works for me - I have some 4 way servers with hyperthreading. I've not
heard of anything that would cause any issues. Make sure you are on the
latest service packs though (looks like you are).
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602m.html
Oskar wrote:
> Hi,
> Are there any issues/benifits when running SQL Server 2000
> EE SP3a/Windows 2000 Server SP4 on a machine that has CPUs
> with hyper threading enabled?
> --
> Thanks
> Oskar|||At a minimum... you might consider changing max degree of parrelism to the
PHYSICAL number of processors rather than the logical. I've seen many cases
where you'll have problems with cxpacket waits if you get a 4X plan on a box
with 2 physical but 4 logical processors...
Of course this isn't always true. But something to think about...
--
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Oskar" <anonymous@.discussions.microsoft.com> wrote in message
news:2df001c4a217$c7278520$a601280a@.phx.gbl...
> Hi,
> Are there any issues/benifits when running SQL Server 2000
> EE SP3a/Windows 2000 Server SP4 on a machine that has CPUs
> with hyper threading enabled?
> --
> Thanks
> Oskar|||When is it true? And when is it NOT true?
Please give us details.
"Brian Moran" <brian@.solidqualitylearning.com> wrote in message
news:uQi0GkjoEHA.3900@.TK2MSFTNGP10.phx.gbl...
> At a minimum... you might consider changing max degree of parrelism to
> the
> PHYSICAL number of processors rather than the logical. I've seen many
> cases
> where you'll have problems with cxpacket waits if you get a 4X plan on a
> box
> with 2 physical but 4 logical processors...
> Of course this isn't always true. But something to think about...
> --
> Brian Moran
> Principal Mentor
> Solid Quality Learning
> SQL Server MVP
> http://www.solidqualitylearning.com
>
> "Oskar" <anonymous@.discussions.microsoft.com> wrote in message
> news:2df001c4a217$c7278520$a601280a@.phx.gbl...
>> Hi,
>> Are there any issues/benifits when running SQL Server 2000
>> EE SP3a/Windows 2000 Server SP4 on a machine that has CPUs
>> with hyper threading enabled?
>> --
>> Thanks
>> Oskar
>|||Have you heard that any of post SP3(a) fixes help? I can't
find a confirmation of this on MS website though.
--
Oskar
>--Original Message--
>Oskar,
>Works for me - I have some 4 way servers with
hyperthreading. I've not
>heard of anything that would cause any issues. Make sure
you are on the
>latest service packs though (looks like you are).
>--
>Mark Allison, SQL Server MVP
>http://www.markallison.co.uk
>Looking for a SQL Server replication book?
>http://www.nwsu.com/0974973602m.html
>
>Oskar wrote:
>> Hi,
>> Are there any issues/benifits when running SQL Server
2000
>> EE SP3a/Windows 2000 Server SP4 on a machine that has
CPUs
>> with hyper threading enabled?
>> --
>> Thanks
>> Oskar
>.
>
Subscribe to:
Posts (Atom)