• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 90
  • Last Modified:

SQL Server 2005 moved to newer, "faster" machine but performance suffers

Old System:

Windows Server 2008 Std
SQL Server 2005 SP4 64 Bit
2X Intel L5430 2.6 GHZ processors w/ 4 cores each HT enabled
32 Gigs RAM
Storage:  Local 1 5 disk RAID 5 (most data), a 2 disk RAID1 (tempdb), and a 2 disk RAID 1 (Logs/system)

New system:

Windows Server 2008 R2
SQL Server 2005 SP4 64 bit (tried SQL Server 2008 R2 and 2012 with same results)
4X Intel E7-4830 2.13 GHZ processors w/8 cores each HT not enabled (32 total cores)
132 Gigs RAM
Storage Local 1 10 SSD RAID 5 (data), a 2 SSD RAID 1 (tempdb), and a 2 SSD RAID1 (Logs, system)

I know you need more info but...

I've run lots of tests w/ SQLIO and found the disk system doing well.  I've also collected a lot of wait stats data, but unfortunately, nothing significant to report there.  I suspect memory or motherboard (FSB), because I do see significant network_async_io waits (300 ms on a 2 sec query) when executing longer queries locally on the new server using SSMS.  Since the only protocol used for these queries is Shared Memory, maybe there is something there.  Incidentally, I don't see the network_async_io waits when executing the same query from another client.

Any truth to the story that you can have too much memory/processing power for SQL Server?

Any obvious gotchas?

Any help / direction as to how to proceed?

Thanks,

David
0
dvdvon
Asked:
dvdvon
1 Solution
 
andyalderCommented:
Might be something in the 132GB of RAM, (unless it's a typo). Can't see how you can distribute that evenly between the 4 CPUs. If you had said 128GB I wouldn't have posted since I'd assume 1 * 8GB stick on each memory channel of each CPU giving what Intel call full hemisphere but there's 4GB left over so I'm not sure the RAM is distributed properly. It is possible to put the majority of the RAM on CPU1 and leave CPUs 2,3,4 with only a tiny amount, that would seriously upset it because all CPU2,3,4s memory access would have to go across the quickpath bus to CPU1's inbuild memory controller.

As a non-SQL expert I'd check that out and see that task manager and perfmon show all CPUs/cores are doing the same amount of work. Your old 5400 CPU machine had the RAM on the southbridge but the memory controller is embedded in the CPU on your new E7s and the OS is NUMA aware and tries to keep RAM access local.

Would like to eliminate shared memory protocol too, you can still use named pipes etc locally.
0
 
dvdvonAuthor Commented:
Thanks.  Dumb typo...128 GIGS.  Looking at a MS hotfix now related to CPU / memory interface.  I'll post more when I know more.
0
 
D_VanteCommented:
For both servers
What RAID container is your OS on?
What kind of network connections do you have?
What antivirus do you have running and do you have any exceptions defined?
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
andyalderCommented:
He's probably looking at http://support.microsoft.com/kb/2155311 or something similar. Best to keep everything outside the first 4GB or RAM on machines with loads of RAM since devices such as video overlay some of it but not much you can do about that from the user side since it's down to the kernel to say what goes where.
0
 
Scott PletcherSenior DBACommented:
First, be sure to specify a max memory for the SQL instance.  With 128G or RAM, I'd start with (at most!) 96G.  That should leave enough for Windows, memory mgmt, other s/w, etc..

Second, run the SELECT(s); then run UPDATE STATISTICS on the tables involved; then run the SELECT(s) again.  If there is improvement, run UPDATE STATISTICS on all tables when you can (for very large tables, you may need to explicitly specify a small sampling and/or pick an off time).

Finally, limit MAXDOP to, say, 2, to make sure parallelization (which SQL Server is not generally good at) doesn't cause an issue.  But, for index rebuilds, override with (MAXDOP 3|4) in the REBUILD command itself, since parallelization doesn't cause issues for index rebuilds.
0
 
Anthony PerkinsCommented:
I suspect memory or motherboard (FSB), because I do see significant network_async_io waits (300 ms on a 2 sec query) when executing longer queries locally on the new server using SSMS.
First, not to quibble but it is ASYNC_NETWORK_IO.  Secondly, I am not even sure this has anything to do with SQL Server, it is a network performance problem.  Simply put the ASYNC_NETWORK_IO wait type means that SQL Server is waiting on the client which is not faster enough for SQL Server.  This wait type is very common when using SSIS to import/export large data sets from SQL Server across the network.
0
 
Seth SimmonsSr. Systems AdministratorCommented:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now