Hi
We will within the next week move our SQL 2000 server SP4 to a new high
performance server (2 x ghz XEON, 4 GB RAM)
The database which is to be running on the server has a physical size of 50
mb on disk.
Is there a way to optimize the SQL 2000 to keep as much as possible
in-memory so searching will as quick as possible? The read / write rate is
approx 1000/1 (we read 1000 x as often as writing)
Is the some memory settings we can tweak or are we better of letting sql
server 2000 handle it?
Thanks in regards
Anders JacobsenJust checking 50Mb not 50 Gb. If so then there's not much you can do, with
4Gb of RAM it will all reside in memory.
--
Simon Sabin
SQL Server MVP
http://sqljunkies.com/weblog/simons
"Anders" <anderskj1@.yahoo.dk> wrote in message
news:%23j7EngYXGHA.4432@.TK2MSFTNGP04.phx.gbl...
> Hi
> We will within the next week move our SQL 2000 server SP4 to a new high
> performance server (2 x ghz XEON, 4 GB RAM)
> The database which is to be running on the server has a physical size of
> 50 mb on disk.
> Is there a way to optimize the SQL 2000 to keep as much as possible
> in-memory so searching will as quick as possible? The read / write rate is
> approx 1000/1 (we read 1000 x as often as writing)
> Is the some memory settings we can tweak or are we better of letting sql
> server 2000 handle it?
> Thanks in regards
> Anders Jacobsen
>|||"Anders" <anderskj1@.yahoo.dk> wrote in message
news:%23j7EngYXGHA.4432@.TK2MSFTNGP04.phx.gbl...
> Hi
> We will within the next week move our SQL 2000 server SP4 to a new high
> performance server (2 x ghz XEON, 4 GB RAM)
> The database which is to be running on the server has a physical size of
50
> mb on disk.
> Is there a way to optimize the SQL 2000 to keep as much as possible
> in-memory so searching will as quick as possible? The read / write rate is
> approx 1000/1 (we read 1000 x as often as writing)
> Is the some memory settings we can tweak or are we better of letting sql
> server 2000 handle it?
Generally you're better off letting SQL Server handle it. It will grab as
much RAM as it can (2GB with Standard, more with Enterprise with the proper
switches) and use it to cache.
Check perfmon and look at the cache hit ratio for one thing to see how
you're doing.
If it's truly 50MB, that'll fit into RAM absolutely w/o problems.
> Thanks in regards
> Anders Jacobsen
>|||> Generally you're better off letting SQL Server handle it. It will grab as
> much RAM as it can (2GB with Standard, more with Enterprise with the
> proper
> switches) and use it to cache.
> Check perfmon and look at the cache hit ratio for one thing to see how
> you're doing.
> If it's truly 50MB, that'll fit into RAM absolutely w/o problems.
Sounds great.
Thanks
Showing posts with label xeon. Show all posts
Showing posts with label xeon. Show all posts
Friday, March 30, 2012
Optimizing SQL 2000 SP4 for large amount of memory
Hi
We will within the next week move our SQL 2000 server SP4 to a new high
performance server (2 x ghz XEON, 4 GB RAM)
The database which is to be running on the server has a physical size of 50
mb on disk.
Is there a way to optimize the SQL 2000 to keep as much as possible
in-memory so searching will as quick as possible? The read / write rate is
approx 1000/1 (we read 1000 x as often as writing)
Is the some memory settings we can tweak or are we better of letting sql
server 2000 handle it?
Thanks in regards
Anders JacobsenJust checking 50Mb not 50 Gb. If so then there's not much you can do, with
4Gb of RAM it will all reside in memory.
Simon Sabin
SQL Server MVP
http://sqljunkies.com/weblog/simons
"Anders" <anderskj1@.yahoo.dk> wrote in message
news:%23j7EngYXGHA.4432@.TK2MSFTNGP04.phx.gbl...
> Hi
> We will within the next week move our SQL 2000 server SP4 to a new high
> performance server (2 x ghz XEON, 4 GB RAM)
> The database which is to be running on the server has a physical size of
> 50 mb on disk.
> Is there a way to optimize the SQL 2000 to keep as much as possible
> in-memory so searching will as quick as possible? The read / write rate is
> approx 1000/1 (we read 1000 x as often as writing)
> Is the some memory settings we can tweak or are we better of letting sql
> server 2000 handle it?
> Thanks in regards
> Anders Jacobsen
>|||"Anders" <anderskj1@.yahoo.dk> wrote in message
news:%23j7EngYXGHA.4432@.TK2MSFTNGP04.phx.gbl...
> Hi
> We will within the next week move our SQL 2000 server SP4 to a new high
> performance server (2 x ghz XEON, 4 GB RAM)
> The database which is to be running on the server has a physical size of
50
> mb on disk.
> Is there a way to optimize the SQL 2000 to keep as much as possible
> in-memory so searching will as quick as possible? The read / write rate is
> approx 1000/1 (we read 1000 x as often as writing)
> Is the some memory settings we can tweak or are we better of letting sql
> server 2000 handle it?
Generally you're better off letting SQL Server handle it. It will grab as
much RAM as it can (2GB with Standard, more with Enterprise with the proper
switches) and use it to cache.
Check perfmon and look at the cache hit ratio for one thing to see how
you're doing.
If it's truly 50MB, that'll fit into RAM absolutely w/o problems.
> Thanks in regards
> Anders Jacobsen
>|||> Generally you're better off letting SQL Server handle it. It will grab as
> much RAM as it can (2GB with Standard, more with Enterprise with the
> proper
> switches) and use it to cache.
> Check perfmon and look at the cache hit ratio for one thing to see how
> you're doing.
> If it's truly 50MB, that'll fit into RAM absolutely w/o problems.
Sounds great.
Thanks
We will within the next week move our SQL 2000 server SP4 to a new high
performance server (2 x ghz XEON, 4 GB RAM)
The database which is to be running on the server has a physical size of 50
mb on disk.
Is there a way to optimize the SQL 2000 to keep as much as possible
in-memory so searching will as quick as possible? The read / write rate is
approx 1000/1 (we read 1000 x as often as writing)
Is the some memory settings we can tweak or are we better of letting sql
server 2000 handle it?
Thanks in regards
Anders JacobsenJust checking 50Mb not 50 Gb. If so then there's not much you can do, with
4Gb of RAM it will all reside in memory.
Simon Sabin
SQL Server MVP
http://sqljunkies.com/weblog/simons
"Anders" <anderskj1@.yahoo.dk> wrote in message
news:%23j7EngYXGHA.4432@.TK2MSFTNGP04.phx.gbl...
> Hi
> We will within the next week move our SQL 2000 server SP4 to a new high
> performance server (2 x ghz XEON, 4 GB RAM)
> The database which is to be running on the server has a physical size of
> 50 mb on disk.
> Is there a way to optimize the SQL 2000 to keep as much as possible
> in-memory so searching will as quick as possible? The read / write rate is
> approx 1000/1 (we read 1000 x as often as writing)
> Is the some memory settings we can tweak or are we better of letting sql
> server 2000 handle it?
> Thanks in regards
> Anders Jacobsen
>|||"Anders" <anderskj1@.yahoo.dk> wrote in message
news:%23j7EngYXGHA.4432@.TK2MSFTNGP04.phx.gbl...
> Hi
> We will within the next week move our SQL 2000 server SP4 to a new high
> performance server (2 x ghz XEON, 4 GB RAM)
> The database which is to be running on the server has a physical size of
50
> mb on disk.
> Is there a way to optimize the SQL 2000 to keep as much as possible
> in-memory so searching will as quick as possible? The read / write rate is
> approx 1000/1 (we read 1000 x as often as writing)
> Is the some memory settings we can tweak or are we better of letting sql
> server 2000 handle it?
Generally you're better off letting SQL Server handle it. It will grab as
much RAM as it can (2GB with Standard, more with Enterprise with the proper
switches) and use it to cache.
Check perfmon and look at the cache hit ratio for one thing to see how
you're doing.
If it's truly 50MB, that'll fit into RAM absolutely w/o problems.
> Thanks in regards
> Anders Jacobsen
>|||> Generally you're better off letting SQL Server handle it. It will grab as
> much RAM as it can (2GB with Standard, more with Enterprise with the
> proper
> switches) and use it to cache.
> Check perfmon and look at the cache hit ratio for one thing to see how
> you're doing.
> If it's truly 50MB, that'll fit into RAM absolutely w/o problems.
Sounds great.
Thanks
Monday, March 12, 2012
Opteron vs Xeon
I've recently been attempting to put into production some Itanium based
servers. I'm running (amongst other things) Remedy, which means highly
serialised transactions (thus limiting the effect of the Itanium) and has
lead me to discover that the low clock speed on the Itanium is causing the
application to run slower (the biggest test of this was a basic bulk insert
into a table with no indexes that would run 50% slower on a 4x1.6GHZ
Itanium vs a 2x2.4GHZ Xeon).
I'm now looking into going to back to a 32bit system, folks are touting the
benefits of the Opteron processor as opposed to the Xeon, stating that the
performance difference is pretty large.
My question is, does the slower clock speed on the Opteron translate into
the same problems that I was experiencing on the Itanium, or am I actually
going to find better i/o performance through the AMD processor?
Thanks
Nic
On Thu, 01 Sep 2005 04:20:11 -0700, Nicholas Cain
<nicholas.cain@.nospam.t-mobile.com> wrote:
>I've recently been attempting to put into production some Itanium based
>servers. I'm running (amongst other things) Remedy, which means highly
>serialised transactions (thus limiting the effect of the Itanium) and has
>lead me to discover that the low clock speed on the Itanium is causing the
>application to run slower (the biggest test of this was a basic bulk insert
>into a table with no indexes that would run 50% slower on a 4x1.6GHZ
>Itanium vs a 2x2.4GHZ Xeon).
>I'm now looking into going to back to a 32bit system, folks are touting the
>benefits of the Opteron processor as opposed to the Xeon, stating that the
>performance difference is pretty large.
>My question is, does the slower clock speed on the Opteron translate into
>the same problems that I was experiencing on the Itanium, or am I actually
>going to find better i/o performance through the AMD processor?
Seems unlikely that CPU speed is really the limiting factor on a bulk
load.
J.
|||JXStern <JXSternChangeX2R@.gte.net> wrote in
news:i7rdh114n67mjuc7uor55clv95k5f8a3uq@.4ax.com:
> Seems unlikely that CPU speed is really the limiting factor on a bulk
> load.
> J.
>
I've had the gurus at HP look and tell me that this is the limiting factor
(after a lot of consideration and followup with MS).
I didn't believe it myself, however all indications point to that problem.
|||I've also seen high CPU utilization with bulk inserts, at least the
fully-logged variety.
Hope this helps.
Dan Guzman
SQL Server MVP
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C45AE8629B4nicholascainnospamtm@.207.46.2 48.16...
> JXStern <JXSternChangeX2R@.gte.net> wrote in
> news:i7rdh114n67mjuc7uor55clv95k5f8a3uq@.4ax.com:
>
> I've had the gurus at HP look and tell me that this is the limiting factor
> (after a lot of consideration and followup with MS).
> I didn't believe it myself, however all indications point to that problem.
|||"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in
news:ulSIjWvrFHA.1168@.TK2MSFTNGP11.phx.gbl:
> I've also seen high CPU utilization with bulk inserts, at least the
> fully-logged variety.
>
The cpu utilisation was extremely high on the Itanium, the majority of that
was kernel usage.
Changing the max degree of parallelism made no difference, nor did setting
offsets on the disk, nor sp4, adding numa options, setting affinity masks
or anything.
The bulk insert itself was a single 1.5GB file into a table with no
indexes. The db itself was in simple recovery mode, db and logs on seperate
luns on a Hitachi XP1024 SAN with a 40GB cache.
Performance speeds for the bulk insert were idnetical on both a Dell and HP
Itanium based system with the same specs.
|||I was acutally looking at the dual core.
I guess my best course of action would be to throw a Xeon and a Opteron in
a head to head and see what comes out as the leader.
"Coldman" <nomorespam@.mail.com> wrote in
news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
> hehe - me again
> and u can get double core opterons - and have 2 cpu while paying
> licence for 1,
> and there r IMHO no double core Xeons
>
|||good idea
y dont u post the results here after the test
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C477204FE4Bnicholascainnospamtm@.207.46.2 48.16...
>I was acutally looking at the dual core.
> I guess my best course of action would be to throw a Xeon and a Opteron in
> a head to head and see what comes out as the leader.
>
> "Coldman" <nomorespam@.mail.com> wrote in
> news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
>
|||If you are going to do that you should test a dual core Pentium against the
dual core Opteron. I have several clients with single core Opterons and
they are very happy with them but I think Dual Core processors will rule the
earth very soon<g>.
Andrew J. Kelly SQL MVP
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C477204FE4Bnicholascainnospamtm@.207.46.2 48.16...
>I was acutally looking at the dual core.
> I guess my best course of action would be to throw a Xeon and a Opteron in
> a head to head and see what comes out as the leader.
>
> "Coldman" <nomorespam@.mail.com> wrote in
> news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
>
|||but there r no dual core Xeons yet i think, and Pentium 4 lacks server class
motherboards(w/ a lot of 64bit slots and dual power connectors)
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:e9qbrgxrFHA.2272@.TK2MSFTNGP11.phx.gbl...
> If you are going to do that you should test a dual core Pentium against
> the dual core Opteron. I have several clients with single core Opterons
> and they are very happy with them but I think Dual Core processors will
> rule the earth very soon<g>.
> --
> Andrew J. Kelly SQL MVP
>
> "Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
> news:Xns96C477204FE4Bnicholascainnospamtm@.207.46.2 48.16...
>
servers. I'm running (amongst other things) Remedy, which means highly
serialised transactions (thus limiting the effect of the Itanium) and has
lead me to discover that the low clock speed on the Itanium is causing the
application to run slower (the biggest test of this was a basic bulk insert
into a table with no indexes that would run 50% slower on a 4x1.6GHZ
Itanium vs a 2x2.4GHZ Xeon).
I'm now looking into going to back to a 32bit system, folks are touting the
benefits of the Opteron processor as opposed to the Xeon, stating that the
performance difference is pretty large.
My question is, does the slower clock speed on the Opteron translate into
the same problems that I was experiencing on the Itanium, or am I actually
going to find better i/o performance through the AMD processor?
Thanks
Nic
On Thu, 01 Sep 2005 04:20:11 -0700, Nicholas Cain
<nicholas.cain@.nospam.t-mobile.com> wrote:
>I've recently been attempting to put into production some Itanium based
>servers. I'm running (amongst other things) Remedy, which means highly
>serialised transactions (thus limiting the effect of the Itanium) and has
>lead me to discover that the low clock speed on the Itanium is causing the
>application to run slower (the biggest test of this was a basic bulk insert
>into a table with no indexes that would run 50% slower on a 4x1.6GHZ
>Itanium vs a 2x2.4GHZ Xeon).
>I'm now looking into going to back to a 32bit system, folks are touting the
>benefits of the Opteron processor as opposed to the Xeon, stating that the
>performance difference is pretty large.
>My question is, does the slower clock speed on the Opteron translate into
>the same problems that I was experiencing on the Itanium, or am I actually
>going to find better i/o performance through the AMD processor?
Seems unlikely that CPU speed is really the limiting factor on a bulk
load.
J.
|||JXStern <JXSternChangeX2R@.gte.net> wrote in
news:i7rdh114n67mjuc7uor55clv95k5f8a3uq@.4ax.com:
> Seems unlikely that CPU speed is really the limiting factor on a bulk
> load.
> J.
>
I've had the gurus at HP look and tell me that this is the limiting factor
(after a lot of consideration and followup with MS).
I didn't believe it myself, however all indications point to that problem.
|||I've also seen high CPU utilization with bulk inserts, at least the
fully-logged variety.
Hope this helps.
Dan Guzman
SQL Server MVP
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C45AE8629B4nicholascainnospamtm@.207.46.2 48.16...
> JXStern <JXSternChangeX2R@.gte.net> wrote in
> news:i7rdh114n67mjuc7uor55clv95k5f8a3uq@.4ax.com:
>
> I've had the gurus at HP look and tell me that this is the limiting factor
> (after a lot of consideration and followup with MS).
> I didn't believe it myself, however all indications point to that problem.
|||"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in
news:ulSIjWvrFHA.1168@.TK2MSFTNGP11.phx.gbl:
> I've also seen high CPU utilization with bulk inserts, at least the
> fully-logged variety.
>
The cpu utilisation was extremely high on the Itanium, the majority of that
was kernel usage.
Changing the max degree of parallelism made no difference, nor did setting
offsets on the disk, nor sp4, adding numa options, setting affinity masks
or anything.
The bulk insert itself was a single 1.5GB file into a table with no
indexes. The db itself was in simple recovery mode, db and logs on seperate
luns on a Hitachi XP1024 SAN with a 40GB cache.
Performance speeds for the bulk insert were idnetical on both a Dell and HP
Itanium based system with the same specs.
|||I was acutally looking at the dual core.
I guess my best course of action would be to throw a Xeon and a Opteron in
a head to head and see what comes out as the leader.
"Coldman" <nomorespam@.mail.com> wrote in
news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
> hehe - me again
> and u can get double core opterons - and have 2 cpu while paying
> licence for 1,
> and there r IMHO no double core Xeons
>
|||good idea
y dont u post the results here after the test
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C477204FE4Bnicholascainnospamtm@.207.46.2 48.16...
>I was acutally looking at the dual core.
> I guess my best course of action would be to throw a Xeon and a Opteron in
> a head to head and see what comes out as the leader.
>
> "Coldman" <nomorespam@.mail.com> wrote in
> news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
>
|||If you are going to do that you should test a dual core Pentium against the
dual core Opteron. I have several clients with single core Opterons and
they are very happy with them but I think Dual Core processors will rule the
earth very soon<g>.
Andrew J. Kelly SQL MVP
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C477204FE4Bnicholascainnospamtm@.207.46.2 48.16...
>I was acutally looking at the dual core.
> I guess my best course of action would be to throw a Xeon and a Opteron in
> a head to head and see what comes out as the leader.
>
> "Coldman" <nomorespam@.mail.com> wrote in
> news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
>
|||but there r no dual core Xeons yet i think, and Pentium 4 lacks server class
motherboards(w/ a lot of 64bit slots and dual power connectors)
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:e9qbrgxrFHA.2272@.TK2MSFTNGP11.phx.gbl...
> If you are going to do that you should test a dual core Pentium against
> the dual core Opteron. I have several clients with single core Opterons
> and they are very happy with them but I think Dual Core processors will
> rule the earth very soon<g>.
> --
> Andrew J. Kelly SQL MVP
>
> "Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
> news:Xns96C477204FE4Bnicholascainnospamtm@.207.46.2 48.16...
>
Opteron vs Xeon
I've recently been attempting to put into production some Itanium based
servers. I'm running (amongst other things) Remedy, which means highly
serialised transactions (thus limiting the effect of the Itanium) and has
lead me to discover that the low clock speed on the Itanium is causing the
application to run slower (the biggest test of this was a basic bulk insert
into a table with no indexes that would run 50% slower on a 4x1.6GHZ
Itanium vs a 2x2.4GHZ Xeon).
I'm now looking into going to back to a 32bit system, folks are touting the
benefits of the Opteron processor as opposed to the Xeon, stating that the
performance difference is pretty large.
My question is, does the slower clock speed on the Opteron translate into
the same problems that I was experiencing on the Itanium, or am I actually
going to find better i/o performance through the AMD processor?
Thanks
NicOn Thu, 01 Sep 2005 04:20:11 -0700, Nicholas Cain
<nicholas.cain@.nospam.t-mobile.com> wrote:
>I've recently been attempting to put into production some Itanium based
>servers. I'm running (amongst other things) Remedy, which means highly
>serialised transactions (thus limiting the effect of the Itanium) and has
>lead me to discover that the low clock speed on the Itanium is causing the
>application to run slower (the biggest test of this was a basic bulk insert
>into a table with no indexes that would run 50% slower on a 4x1.6GHZ
>Itanium vs a 2x2.4GHZ Xeon).
>I'm now looking into going to back to a 32bit system, folks are touting the
>benefits of the Opteron processor as opposed to the Xeon, stating that the
>performance difference is pretty large.
>My question is, does the slower clock speed on the Opteron translate into
>the same problems that I was experiencing on the Itanium, or am I actually
>going to find better i/o performance through the AMD processor?
Seems unlikely that CPU speed is really the limiting factor on a bulk
load.
J.|||JXStern <JXSternChangeX2R@.gte.net> wrote in
news:i7rdh114n67mjuc7uor55clv95k5f8a3uq@.4ax.com:
> Seems unlikely that CPU speed is really the limiting factor on a bulk
> load.
> J.
>
I've had the gurus at HP look and tell me that this is the limiting factor
(after a lot of consideration and followup with MS).
I didn't believe it myself, however all indications point to that problem.|||I've also seen high CPU utilization with bulk inserts, at least the
fully-logged variety.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C45AE8629B4nicholascainnospamtm@.207.46.248.16...
> JXStern <JXSternChangeX2R@.gte.net> wrote in
> news:i7rdh114n67mjuc7uor55clv95k5f8a3uq@.4ax.com:
>
>> Seems unlikely that CPU speed is really the limiting factor on a bulk
>> load.
>> J.
>>
> I've had the gurus at HP look and tell me that this is the limiting factor
> (after a lot of consideration and followup with MS).
> I didn't believe it myself, however all indications point to that problem.|||"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in
news:ulSIjWvrFHA.1168@.TK2MSFTNGP11.phx.gbl:
> I've also seen high CPU utilization with bulk inserts, at least the
> fully-logged variety.
>
The cpu utilisation was extremely high on the Itanium, the majority of that
was kernel usage.
Changing the max degree of parallelism made no difference, nor did setting
offsets on the disk, nor sp4, adding numa options, setting affinity masks
or anything.
The bulk insert itself was a single 1.5GB file into a table with no
indexes. The db itself was in simple recovery mode, db and logs on seperate
luns on a Hitachi XP1024 SAN with a 40GB cache.
Performance speeds for the bulk insert were idnetical on both a Dell and HP
Itanium based system with the same specs.|||not being an expert in SQL optimizations, i`d recomend Opterons
in task w/ no parallelism (like games) opterons rule, and in smp system
unlike xeons each opteron has its own memory controller
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C45EC16CAACnicholascainnospamtm@.207.46.248.16...
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in
> news:ulSIjWvrFHA.1168@.TK2MSFTNGP11.phx.gbl:
>> I've also seen high CPU utilization with bulk inserts, at least the
>> fully-logged variety.
> The cpu utilisation was extremely high on the Itanium, the majority of
> that
> was kernel usage.
> Changing the max degree of parallelism made no difference, nor did setting
> offsets on the disk, nor sp4, adding numa options, setting affinity masks
> or anything.
> The bulk insert itself was a single 1.5GB file into a table with no
> indexes. The db itself was in simple recovery mode, db and logs on
> seperate
> luns on a Hitachi XP1024 SAN with a 40GB cache.
> Performance speeds for the bulk insert were idnetical on both a Dell and
> HP
> Itanium based system with the same specs.|||i believe there were xeons vs opterons tests (w/ DB2 and MySQL) on
anandtech.com
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C45EC16CAACnicholascainnospamtm@.207.46.248.16...
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in
> news:ulSIjWvrFHA.1168@.TK2MSFTNGP11.phx.gbl:
>> I've also seen high CPU utilization with bulk inserts, at least the
>> fully-logged variety.
> The cpu utilisation was extremely high on the Itanium, the majority of
> that
> was kernel usage.
> Changing the max degree of parallelism made no difference, nor did setting
> offsets on the disk, nor sp4, adding numa options, setting affinity masks
> or anything.
> The bulk insert itself was a single 1.5GB file into a table with no
> indexes. The db itself was in simple recovery mode, db and logs on
> seperate
> luns on a Hitachi XP1024 SAN with a 40GB cache.
> Performance speeds for the bulk insert were idnetical on both a Dell and
> HP
> Itanium based system with the same specs.|||hehe - me again
and u can get double core opterons - and have 2 cpu while paying licence for
1,
and there r IMHO no double core Xeons
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C45EC16CAACnicholascainnospamtm@.207.46.248.16...
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in
> news:ulSIjWvrFHA.1168@.TK2MSFTNGP11.phx.gbl:
>> I've also seen high CPU utilization with bulk inserts, at least the
>> fully-logged variety.
> The cpu utilisation was extremely high on the Itanium, the majority of
> that
> was kernel usage.
> Changing the max degree of parallelism made no difference, nor did setting
> offsets on the disk, nor sp4, adding numa options, setting affinity masks
> or anything.
> The bulk insert itself was a single 1.5GB file into a table with no
> indexes. The db itself was in simple recovery mode, db and logs on
> seperate
> luns on a Hitachi XP1024 SAN with a 40GB cache.
> Performance speeds for the bulk insert were idnetical on both a Dell and
> HP
> Itanium based system with the same specs.|||I was acutally looking at the dual core.
I guess my best course of action would be to throw a Xeon and a Opteron in
a head to head and see what comes out as the leader.
"Coldman" <nomorespam@.mail.com> wrote in
news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
> hehe - me again
> and u can get double core opterons - and have 2 cpu while paying
> licence for 1,
> and there r IMHO no double core Xeons
>|||good idea :)
y dont u post the results here after the test
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C477204FE4Bnicholascainnospamtm@.207.46.248.16...
>I was acutally looking at the dual core.
> I guess my best course of action would be to throw a Xeon and a Opteron in
> a head to head and see what comes out as the leader.
>
> "Coldman" <nomorespam@.mail.com> wrote in
> news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
>> hehe - me again
>> and u can get double core opterons - and have 2 cpu while paying
>> licence for 1,
>> and there r IMHO no double core Xeons
>|||If you are going to do that you should test a dual core Pentium against the
dual core Opteron. I have several clients with single core Opterons and
they are very happy with them but I think Dual Core processors will rule the
earth very soon<g>.
--
Andrew J. Kelly SQL MVP
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C477204FE4Bnicholascainnospamtm@.207.46.248.16...
>I was acutally looking at the dual core.
> I guess my best course of action would be to throw a Xeon and a Opteron in
> a head to head and see what comes out as the leader.
>
> "Coldman" <nomorespam@.mail.com> wrote in
> news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
>> hehe - me again
>> and u can get double core opterons - and have 2 cpu while paying
>> licence for 1,
>> and there r IMHO no double core Xeons
>|||but there r no dual core Xeons yet i think, and Pentium 4 lacks server class
motherboards(w/ a lot of 64bit slots and dual power connectors)
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:e9qbrgxrFHA.2272@.TK2MSFTNGP11.phx.gbl...
> If you are going to do that you should test a dual core Pentium against
> the dual core Opteron. I have several clients with single core Opterons
> and they are very happy with them but I think Dual Core processors will
> rule the earth very soon<g>.
> --
> Andrew J. Kelly SQL MVP
>
> "Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
> news:Xns96C477204FE4Bnicholascainnospamtm@.207.46.248.16...
>>I was acutally looking at the dual core.
>> I guess my best course of action would be to throw a Xeon and a Opteron
>> in
>> a head to head and see what comes out as the leader.
>>
>> "Coldman" <nomorespam@.mail.com> wrote in
>> news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
>> hehe - me again
>> and u can get double core opterons - and have 2 cpu while paying
>> licence for 1,
>> and there r IMHO no double core Xeons
>>
>
servers. I'm running (amongst other things) Remedy, which means highly
serialised transactions (thus limiting the effect of the Itanium) and has
lead me to discover that the low clock speed on the Itanium is causing the
application to run slower (the biggest test of this was a basic bulk insert
into a table with no indexes that would run 50% slower on a 4x1.6GHZ
Itanium vs a 2x2.4GHZ Xeon).
I'm now looking into going to back to a 32bit system, folks are touting the
benefits of the Opteron processor as opposed to the Xeon, stating that the
performance difference is pretty large.
My question is, does the slower clock speed on the Opteron translate into
the same problems that I was experiencing on the Itanium, or am I actually
going to find better i/o performance through the AMD processor?
Thanks
NicOn Thu, 01 Sep 2005 04:20:11 -0700, Nicholas Cain
<nicholas.cain@.nospam.t-mobile.com> wrote:
>I've recently been attempting to put into production some Itanium based
>servers. I'm running (amongst other things) Remedy, which means highly
>serialised transactions (thus limiting the effect of the Itanium) and has
>lead me to discover that the low clock speed on the Itanium is causing the
>application to run slower (the biggest test of this was a basic bulk insert
>into a table with no indexes that would run 50% slower on a 4x1.6GHZ
>Itanium vs a 2x2.4GHZ Xeon).
>I'm now looking into going to back to a 32bit system, folks are touting the
>benefits of the Opteron processor as opposed to the Xeon, stating that the
>performance difference is pretty large.
>My question is, does the slower clock speed on the Opteron translate into
>the same problems that I was experiencing on the Itanium, or am I actually
>going to find better i/o performance through the AMD processor?
Seems unlikely that CPU speed is really the limiting factor on a bulk
load.
J.|||JXStern <JXSternChangeX2R@.gte.net> wrote in
news:i7rdh114n67mjuc7uor55clv95k5f8a3uq@.4ax.com:
> Seems unlikely that CPU speed is really the limiting factor on a bulk
> load.
> J.
>
I've had the gurus at HP look and tell me that this is the limiting factor
(after a lot of consideration and followup with MS).
I didn't believe it myself, however all indications point to that problem.|||I've also seen high CPU utilization with bulk inserts, at least the
fully-logged variety.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C45AE8629B4nicholascainnospamtm@.207.46.248.16...
> JXStern <JXSternChangeX2R@.gte.net> wrote in
> news:i7rdh114n67mjuc7uor55clv95k5f8a3uq@.4ax.com:
>
>> Seems unlikely that CPU speed is really the limiting factor on a bulk
>> load.
>> J.
>>
> I've had the gurus at HP look and tell me that this is the limiting factor
> (after a lot of consideration and followup with MS).
> I didn't believe it myself, however all indications point to that problem.|||"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in
news:ulSIjWvrFHA.1168@.TK2MSFTNGP11.phx.gbl:
> I've also seen high CPU utilization with bulk inserts, at least the
> fully-logged variety.
>
The cpu utilisation was extremely high on the Itanium, the majority of that
was kernel usage.
Changing the max degree of parallelism made no difference, nor did setting
offsets on the disk, nor sp4, adding numa options, setting affinity masks
or anything.
The bulk insert itself was a single 1.5GB file into a table with no
indexes. The db itself was in simple recovery mode, db and logs on seperate
luns on a Hitachi XP1024 SAN with a 40GB cache.
Performance speeds for the bulk insert were idnetical on both a Dell and HP
Itanium based system with the same specs.|||not being an expert in SQL optimizations, i`d recomend Opterons
in task w/ no parallelism (like games) opterons rule, and in smp system
unlike xeons each opteron has its own memory controller
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C45EC16CAACnicholascainnospamtm@.207.46.248.16...
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in
> news:ulSIjWvrFHA.1168@.TK2MSFTNGP11.phx.gbl:
>> I've also seen high CPU utilization with bulk inserts, at least the
>> fully-logged variety.
> The cpu utilisation was extremely high on the Itanium, the majority of
> that
> was kernel usage.
> Changing the max degree of parallelism made no difference, nor did setting
> offsets on the disk, nor sp4, adding numa options, setting affinity masks
> or anything.
> The bulk insert itself was a single 1.5GB file into a table with no
> indexes. The db itself was in simple recovery mode, db and logs on
> seperate
> luns on a Hitachi XP1024 SAN with a 40GB cache.
> Performance speeds for the bulk insert were idnetical on both a Dell and
> HP
> Itanium based system with the same specs.|||i believe there were xeons vs opterons tests (w/ DB2 and MySQL) on
anandtech.com
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C45EC16CAACnicholascainnospamtm@.207.46.248.16...
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in
> news:ulSIjWvrFHA.1168@.TK2MSFTNGP11.phx.gbl:
>> I've also seen high CPU utilization with bulk inserts, at least the
>> fully-logged variety.
> The cpu utilisation was extremely high on the Itanium, the majority of
> that
> was kernel usage.
> Changing the max degree of parallelism made no difference, nor did setting
> offsets on the disk, nor sp4, adding numa options, setting affinity masks
> or anything.
> The bulk insert itself was a single 1.5GB file into a table with no
> indexes. The db itself was in simple recovery mode, db and logs on
> seperate
> luns on a Hitachi XP1024 SAN with a 40GB cache.
> Performance speeds for the bulk insert were idnetical on both a Dell and
> HP
> Itanium based system with the same specs.|||hehe - me again
and u can get double core opterons - and have 2 cpu while paying licence for
1,
and there r IMHO no double core Xeons
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C45EC16CAACnicholascainnospamtm@.207.46.248.16...
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in
> news:ulSIjWvrFHA.1168@.TK2MSFTNGP11.phx.gbl:
>> I've also seen high CPU utilization with bulk inserts, at least the
>> fully-logged variety.
> The cpu utilisation was extremely high on the Itanium, the majority of
> that
> was kernel usage.
> Changing the max degree of parallelism made no difference, nor did setting
> offsets on the disk, nor sp4, adding numa options, setting affinity masks
> or anything.
> The bulk insert itself was a single 1.5GB file into a table with no
> indexes. The db itself was in simple recovery mode, db and logs on
> seperate
> luns on a Hitachi XP1024 SAN with a 40GB cache.
> Performance speeds for the bulk insert were idnetical on both a Dell and
> HP
> Itanium based system with the same specs.|||I was acutally looking at the dual core.
I guess my best course of action would be to throw a Xeon and a Opteron in
a head to head and see what comes out as the leader.
"Coldman" <nomorespam@.mail.com> wrote in
news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
> hehe - me again
> and u can get double core opterons - and have 2 cpu while paying
> licence for 1,
> and there r IMHO no double core Xeons
>|||good idea :)
y dont u post the results here after the test
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C477204FE4Bnicholascainnospamtm@.207.46.248.16...
>I was acutally looking at the dual core.
> I guess my best course of action would be to throw a Xeon and a Opteron in
> a head to head and see what comes out as the leader.
>
> "Coldman" <nomorespam@.mail.com> wrote in
> news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
>> hehe - me again
>> and u can get double core opterons - and have 2 cpu while paying
>> licence for 1,
>> and there r IMHO no double core Xeons
>|||If you are going to do that you should test a dual core Pentium against the
dual core Opteron. I have several clients with single core Opterons and
they are very happy with them but I think Dual Core processors will rule the
earth very soon<g>.
--
Andrew J. Kelly SQL MVP
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C477204FE4Bnicholascainnospamtm@.207.46.248.16...
>I was acutally looking at the dual core.
> I guess my best course of action would be to throw a Xeon and a Opteron in
> a head to head and see what comes out as the leader.
>
> "Coldman" <nomorespam@.mail.com> wrote in
> news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
>> hehe - me again
>> and u can get double core opterons - and have 2 cpu while paying
>> licence for 1,
>> and there r IMHO no double core Xeons
>|||but there r no dual core Xeons yet i think, and Pentium 4 lacks server class
motherboards(w/ a lot of 64bit slots and dual power connectors)
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:e9qbrgxrFHA.2272@.TK2MSFTNGP11.phx.gbl...
> If you are going to do that you should test a dual core Pentium against
> the dual core Opteron. I have several clients with single core Opterons
> and they are very happy with them but I think Dual Core processors will
> rule the earth very soon<g>.
> --
> Andrew J. Kelly SQL MVP
>
> "Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
> news:Xns96C477204FE4Bnicholascainnospamtm@.207.46.248.16...
>>I was acutally looking at the dual core.
>> I guess my best course of action would be to throw a Xeon and a Opteron
>> in
>> a head to head and see what comes out as the leader.
>>
>> "Coldman" <nomorespam@.mail.com> wrote in
>> news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
>> hehe - me again
>> and u can get double core opterons - and have 2 cpu while paying
>> licence for 1,
>> and there r IMHO no double core Xeons
>>
>
Opteron vs Xeon
I've recently been attempting to put into production some Itanium based
servers. I'm running (amongst other things) Remedy, which means highly
serialised transactions (thus limiting the effect of the Itanium) and has
lead me to discover that the low clock speed on the Itanium is causing the
application to run slower (the biggest test of this was a basic bulk insert
into a table with no indexes that would run 50% slower on a 4x1.6GHZ
Itanium vs a 2x2.4GHZ Xeon).
I'm now looking into going to back to a 32bit system, folks are touting the
benefits of the Opteron processor as opposed to the Xeon, stating that the
performance difference is pretty large.
My question is, does the slower clock speed on the Opteron translate into
the same problems that I was experiencing on the Itanium, or am I actually
going to find better i/o performance through the AMD processor?
Thanks
NicOn Thu, 01 Sep 2005 04:20:11 -0700, Nicholas Cain
<nicholas.cain@.nospam.t-mobile.com> wrote:
>I've recently been attempting to put into production some Itanium based
>servers. I'm running (amongst other things) Remedy, which means highly
>serialised transactions (thus limiting the effect of the Itanium) and has
>lead me to discover that the low clock speed on the Itanium is causing the
>application to run slower (the biggest test of this was a basic bulk insert
>into a table with no indexes that would run 50% slower on a 4x1.6GHZ
>Itanium vs a 2x2.4GHZ Xeon).
>I'm now looking into going to back to a 32bit system, folks are touting the
>benefits of the Opteron processor as opposed to the Xeon, stating that the
>performance difference is pretty large.
>My question is, does the slower clock speed on the Opteron translate into
>the same problems that I was experiencing on the Itanium, or am I actually
>going to find better i/o performance through the AMD processor?
Seems unlikely that CPU speed is really the limiting factor on a bulk
load.
J.|||JXStern <JXSternChangeX2R@.gte.net> wrote in
news:i7rdh114n67mjuc7uor55clv95k5f8a3uq@.
4ax.com:
> Seems unlikely that CPU speed is really the limiting factor on a bulk
> load.
> J.
>
I've had the gurus at HP look and tell me that this is the limiting factor
(after a lot of consideration and followup with MS).
I didn't believe it myself, however all indications point to that problem.|||I've also seen high CPU utilization with bulk inserts, at least the
fully-logged variety.
Hope this helps.
Dan Guzman
SQL Server MVP
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C45AE8629B4nicholascainnospamt
m@.207.46.248.16...
> JXStern <JXSternChangeX2R@.gte.net> wrote in
> news:i7rdh114n67mjuc7uor55clv95k5f8a3uq@.
4ax.com:
>
> I've had the gurus at HP look and tell me that this is the limiting factor
> (after a lot of consideration and followup with MS).
> I didn't believe it myself, however all indications point to that problem.|||"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in
news:ulSIjWvrFHA.1168@.TK2MSFTNGP11.phx.gbl:
> I've also seen high CPU utilization with bulk inserts, at least the
> fully-logged variety.
>
The cpu utilisation was extremely high on the Itanium, the majority of that
was kernel usage.
Changing the max degree of parallelism made no difference, nor did setting
offsets on the disk, nor sp4, adding numa options, setting affinity masks
or anything.
The bulk insert itself was a single 1.5GB file into a table with no
indexes. The db itself was in simple recovery mode, db and logs on seperate
luns on a Hitachi XP1024 SAN with a 40GB cache.
Performance speeds for the bulk insert were idnetical on both a Dell and HP
Itanium based system with the same specs.|||I was acutally looking at the dual core.
I guess my best course of action would be to throw a Xeon and a Opteron in
a head to head and see what comes out as the leader.
"Coldman" <nomorespam@.mail.com> wrote in
news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
> hehe - me again
> and u can get double core opterons - and have 2 cpu while paying
> licence for 1,
> and there r IMHO no double core Xeons
>|||good idea
y dont u post the results here after the test
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C477204FE4Bnicholascainnospamt
m@.207.46.248.16...
>I was acutally looking at the dual core.
> I guess my best course of action would be to throw a Xeon and a Opteron in
> a head to head and see what comes out as the leader.
>
> "Coldman" <nomorespam@.mail.com> wrote in
> news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
>
>|||If you are going to do that you should test a dual core Pentium against the
dual core Opteron. I have several clients with single core Opterons and
they are very happy with them but I think Dual Core processors will rule the
earth very soon<g>.
Andrew J. Kelly SQL MVP
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C477204FE4Bnicholascainnospamt
m@.207.46.248.16...
>I was acutally looking at the dual core.
> I guess my best course of action would be to throw a Xeon and a Opteron in
> a head to head and see what comes out as the leader.
>
> "Coldman" <nomorespam@.mail.com> wrote in
> news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
>
>|||but there r no dual core Xeons yet i think, and Pentium 4 lacks server class
motherboards(w/ a lot of 64bit slots and dual power connectors)
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:e9qbrgxrFHA.2272@.TK2MSFTNGP11.phx.gbl...
> If you are going to do that you should test a dual core Pentium against
> the dual core Opteron. I have several clients with single core Opterons
> and they are very happy with them but I think Dual Core processors will
> rule the earth very soon<g>.
> --
> Andrew J. Kelly SQL MVP
>
> "Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
> news:Xns96C477204FE4Bnicholascainnospamt
m@.207.46.248.16...
>
servers. I'm running (amongst other things) Remedy, which means highly
serialised transactions (thus limiting the effect of the Itanium) and has
lead me to discover that the low clock speed on the Itanium is causing the
application to run slower (the biggest test of this was a basic bulk insert
into a table with no indexes that would run 50% slower on a 4x1.6GHZ
Itanium vs a 2x2.4GHZ Xeon).
I'm now looking into going to back to a 32bit system, folks are touting the
benefits of the Opteron processor as opposed to the Xeon, stating that the
performance difference is pretty large.
My question is, does the slower clock speed on the Opteron translate into
the same problems that I was experiencing on the Itanium, or am I actually
going to find better i/o performance through the AMD processor?
Thanks
NicOn Thu, 01 Sep 2005 04:20:11 -0700, Nicholas Cain
<nicholas.cain@.nospam.t-mobile.com> wrote:
>I've recently been attempting to put into production some Itanium based
>servers. I'm running (amongst other things) Remedy, which means highly
>serialised transactions (thus limiting the effect of the Itanium) and has
>lead me to discover that the low clock speed on the Itanium is causing the
>application to run slower (the biggest test of this was a basic bulk insert
>into a table with no indexes that would run 50% slower on a 4x1.6GHZ
>Itanium vs a 2x2.4GHZ Xeon).
>I'm now looking into going to back to a 32bit system, folks are touting the
>benefits of the Opteron processor as opposed to the Xeon, stating that the
>performance difference is pretty large.
>My question is, does the slower clock speed on the Opteron translate into
>the same problems that I was experiencing on the Itanium, or am I actually
>going to find better i/o performance through the AMD processor?
Seems unlikely that CPU speed is really the limiting factor on a bulk
load.
J.|||JXStern <JXSternChangeX2R@.gte.net> wrote in
news:i7rdh114n67mjuc7uor55clv95k5f8a3uq@.
4ax.com:
> Seems unlikely that CPU speed is really the limiting factor on a bulk
> load.
> J.
>
I've had the gurus at HP look and tell me that this is the limiting factor
(after a lot of consideration and followup with MS).
I didn't believe it myself, however all indications point to that problem.|||I've also seen high CPU utilization with bulk inserts, at least the
fully-logged variety.
Hope this helps.
Dan Guzman
SQL Server MVP
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C45AE8629B4nicholascainnospamt
m@.207.46.248.16...
> JXStern <JXSternChangeX2R@.gte.net> wrote in
> news:i7rdh114n67mjuc7uor55clv95k5f8a3uq@.
4ax.com:
>
> I've had the gurus at HP look and tell me that this is the limiting factor
> (after a lot of consideration and followup with MS).
> I didn't believe it myself, however all indications point to that problem.|||"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in
news:ulSIjWvrFHA.1168@.TK2MSFTNGP11.phx.gbl:
> I've also seen high CPU utilization with bulk inserts, at least the
> fully-logged variety.
>
The cpu utilisation was extremely high on the Itanium, the majority of that
was kernel usage.
Changing the max degree of parallelism made no difference, nor did setting
offsets on the disk, nor sp4, adding numa options, setting affinity masks
or anything.
The bulk insert itself was a single 1.5GB file into a table with no
indexes. The db itself was in simple recovery mode, db and logs on seperate
luns on a Hitachi XP1024 SAN with a 40GB cache.
Performance speeds for the bulk insert were idnetical on both a Dell and HP
Itanium based system with the same specs.|||I was acutally looking at the dual core.
I guess my best course of action would be to throw a Xeon and a Opteron in
a head to head and see what comes out as the leader.
"Coldman" <nomorespam@.mail.com> wrote in
news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
> hehe - me again
> and u can get double core opterons - and have 2 cpu while paying
> licence for 1,
> and there r IMHO no double core Xeons
>|||good idea
y dont u post the results here after the test
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C477204FE4Bnicholascainnospamt
m@.207.46.248.16...
>I was acutally looking at the dual core.
> I guess my best course of action would be to throw a Xeon and a Opteron in
> a head to head and see what comes out as the leader.
>
> "Coldman" <nomorespam@.mail.com> wrote in
> news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
>
>|||If you are going to do that you should test a dual core Pentium against the
dual core Opteron. I have several clients with single core Opterons and
they are very happy with them but I think Dual Core processors will rule the
earth very soon<g>.
Andrew J. Kelly SQL MVP
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96C477204FE4Bnicholascainnospamt
m@.207.46.248.16...
>I was acutally looking at the dual core.
> I guess my best course of action would be to throw a Xeon and a Opteron in
> a head to head and see what comes out as the leader.
>
> "Coldman" <nomorespam@.mail.com> wrote in
> news:#AAvQowrFHA.528@.TK2MSFTNGP09.phx.gbl:
>
>|||but there r no dual core Xeons yet i think, and Pentium 4 lacks server class
motherboards(w/ a lot of 64bit slots and dual power connectors)
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:e9qbrgxrFHA.2272@.TK2MSFTNGP11.phx.gbl...
> If you are going to do that you should test a dual core Pentium against
> the dual core Opteron. I have several clients with single core Opterons
> and they are very happy with them but I think Dual Core processors will
> rule the earth very soon<g>.
> --
> Andrew J. Kelly SQL MVP
>
> "Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
> news:Xns96C477204FE4Bnicholascainnospamt
m@.207.46.248.16...
>
Subscribe to:
Posts (Atom)