<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Upgrading the SSC SQL Servers: Part 2</title>
	<atom:link href="http://www.bradmcgehee.com/2010/01/upgrading-the-ssc-sql-servers-part-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.bradmcgehee.com/2010/01/upgrading-the-ssc-sql-servers-part-2/</link>
	<description>Brad M. McGehee, Director of DBA Education, Red Gate Software</description>
	<lastBuildDate>Mon, 06 Feb 2012 20:24:46 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: bradmcgehee</title>
		<link>http://www.bradmcgehee.com/2010/01/upgrading-the-ssc-sql-servers-part-2/#comment-125</link>
		<dc:creator>bradmcgehee</dc:creator>
		<pubDate>Tue, 05 Jan 2010 01:42:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.bradmcgehee.com/2010/01/upgrading-the-ssc-sql-servers-part-2/#comment-125</guid>
		<description>Thanks for the feedback.

On the old server, memory was never a problem. In fact, the servers never used all of its available memory, or even close to it. The servers never experienced any issues with running out of plan cache, and forcing unnecessary query compiliations. 

On the new server, it still isn&#039;t using much memory (relatively speaking), although it is using somewhat more than it did before. The upgrade to 24GB for the new servers was overkill, but I didn&#039;t make that decision. Most of it is sitting there unused.

The reason we went with RAID 1 in some cases, was because of limitations of the available hardware from our ISP (and our budget).</description>
		<content:encoded><![CDATA[<p>Thanks for the feedback.</p>
<p>On the old server, memory was never a problem. In fact, the servers never used all of its available memory, or even close to it. The servers never experienced any issues with running out of plan cache, and forcing unnecessary query compiliations. </p>
<p>On the new server, it still isn&#8217;t using much memory (relatively speaking), although it is using somewhat more than it did before. The upgrade to 24GB for the new servers was overkill, but I didn&#8217;t make that decision. Most of it is sitting there unused.</p>
<p>The reason we went with RAID 1 in some cases, was because of limitations of the available hardware from our ISP (and our budget).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jonathan Kehayias</title>
		<link>http://www.bradmcgehee.com/2010/01/upgrading-the-ssc-sql-servers-part-2/#comment-124</link>
		<dc:creator>Jonathan Kehayias</dc:creator>
		<pubDate>Tue, 05 Jan 2010 00:59:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.bradmcgehee.com/2010/01/upgrading-the-ssc-sql-servers-part-2/#comment-124</guid>
		<description>Brad,

I think you might have overlooked a part of your CPU and DiskIO issues.  Your old server had 4GB memory so with the /3GB switch your BPool would have been limited to roughly 2.6GB.  If your workload routinely used more than 2.6GB of data, you would constantly be hitting disk and rotating data through cache.  This increased DiskIO would also increase CPU utilization.  The bump in memory to 24GB would certainly reduce your total IO to disk because you have a much larger cache in memory.  More memory can be a relief for some IO bottlenecking if that bottleneck is related to constantly reading information that is being rotated in and out of cache.  

Also having a RAID 1 for data is good protection against a drive failure, but it isn&#039;t good performance wise for handling the physical IO needs.  Coupled with smaller memory, it would definitely increase the CPU utilization, and I&#039;d expect that your performance counters for disk would show significant queuing under the older configuration.

I am not trying to be critical, just pointing out things from my own experience that aren&#039;t covered above.</description>
		<content:encoded><![CDATA[<p>Brad,</p>
<p>I think you might have overlooked a part of your CPU and DiskIO issues.  Your old server had 4GB memory so with the /3GB switch your BPool would have been limited to roughly 2.6GB.  If your workload routinely used more than 2.6GB of data, you would constantly be hitting disk and rotating data through cache.  This increased DiskIO would also increase CPU utilization.  The bump in memory to 24GB would certainly reduce your total IO to disk because you have a much larger cache in memory.  More memory can be a relief for some IO bottlenecking if that bottleneck is related to constantly reading information that is being rotated in and out of cache.  </p>
<p>Also having a RAID 1 for data is good protection against a drive failure, but it isn&#8217;t good performance wise for handling the physical IO needs.  Coupled with smaller memory, it would definitely increase the CPU utilization, and I&#8217;d expect that your performance counters for disk would show significant queuing under the older configuration.</p>
<p>I am not trying to be critical, just pointing out things from my own experience that aren&#8217;t covered above.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

