<?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: When bigger isnâ€™t better</title>
	<atom:link href="http://blog.nigelpoulton.com/when-bigger-isn%e2%80%99t-better/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.nigelpoulton.com/when-bigger-isn%e2%80%99t-better/#utm_source=feed&amp;utm_medium=feed&amp;utm_campaign=feed</link>
	<description>with nigel poulton</description>
	<lastBuildDate>Thu, 09 Feb 2012 07:49:05 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Heckers</title>
		<link>http://blog.nigelpoulton.com/when-bigger-isn%e2%80%99t-better/comment-page-1/#comment-1831</link>
		<dc:creator>Heckers</dc:creator>
		<pubDate>Thu, 09 Feb 2012 07:49:05 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=46#comment-1831</guid>
		<description>Hi Richard,I think hradware monitoring is available since ESX 3.5 Update 1, or do you mean something else?Viktor</description>
		<content:encoded><![CDATA[<p>Hi Richard,I think hradware monitoring is available since ESX 3.5 Update 1, or do you mean something else?Viktor</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nigel (mackem)</title>
		<link>http://blog.nigelpoulton.com/when-bigger-isn%e2%80%99t-better/comment-page-1/#comment-71</link>
		<dc:creator>Nigel (mackem)</dc:creator>
		<pubDate>Wed, 06 Dec 2006 16:02:31 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=46#comment-71</guid>
		<description>Thanks for the update Tim.  Id be curious to know what made them change their mind but that information is unlikely to be forthcoming - shame.  Id be curious if anyone else has experience with the ramsan in a large demanding environment.  I&#039;ll be sure to post about it if I find out.</description>
		<content:encoded><![CDATA[<p>Thanks for the update Tim.  Id be curious to know what made them change their mind but that information is unlikely to be forthcoming &#8211; shame.  Id be curious if anyone else has experience with the ramsan in a large demanding environment.  I&#8217;ll be sure to post about it if I find out.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tim</title>
		<link>http://blog.nigelpoulton.com/when-bigger-isn%e2%80%99t-better/comment-page-1/#comment-70</link>
		<dc:creator>tim</dc:creator>
		<pubDate>Wed, 06 Dec 2006 14:53:06 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=46#comment-70</guid>
		<description>Well, I found out why there was never a press release.  I guess I was in fact wrong, they never pushed the Ramsan&#039;s beyond their eval stage.  Last I had heard they were on their way up into production, I guess they ran into something they didn&#039;t like, or something better came along (would be nice to know what if that were the case).</description>
		<content:encoded><![CDATA[<p>Well, I found out why there was never a press release.  I guess I was in fact wrong, they never pushed the Ramsan&#8217;s beyond their eval stage.  Last I had heard they were on their way up into production, I guess they ran into something they didn&#8217;t like, or something better came along (would be nice to know what if that were the case).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tim</title>
		<link>http://blog.nigelpoulton.com/when-bigger-isn%e2%80%99t-better/comment-page-1/#comment-69</link>
		<dc:creator>tim</dc:creator>
		<pubDate>Mon, 04 Dec 2006 20:42:01 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=46#comment-69</guid>
		<description>I will ask our guy who works with that account all the time if I can spill the beans.  I have a feeling the answer is no, they&#039;re generally fairly tight lipped about their setup.  Needless to say, they&#039;re about as big as you can get online outside of google or msft, which is probably more than I should have said already :&gt;</description>
		<content:encoded><![CDATA[<p>I will ask our guy who works with that account all the time if I can spill the beans.  I have a feeling the answer is no, they&#8217;re generally fairly tight lipped about their setup.  Needless to say, they&#8217;re about as big as you can get online outside of google or msft, which is probably more than I should have said already :&gt;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nigel (mackem)</title>
		<link>http://blog.nigelpoulton.com/when-bigger-isn%e2%80%99t-better/comment-page-1/#comment-68</link>
		<dc:creator>Nigel (mackem)</dc:creator>
		<pubDate>Mon, 04 Dec 2006 19:15:26 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=46#comment-68</guid>
		<description>Thanks for the response Tim.  If you could find the press release that would be great as Id be very keen to know who it is and I know a lot of other people would too.
Im staggered that the other storage vendors are following Texas&#039; lead with the SSD.</description>
		<content:encoded><![CDATA[<p>Thanks for the response Tim.  If you could find the press release that would be great as Id be very keen to know who it is and I know a lot of other people would too.<br />
Im staggered that the other storage vendors are following Texas&#8217; lead with the SSD.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tim</title>
		<link>http://blog.nigelpoulton.com/when-bigger-isn%e2%80%99t-better/comment-page-1/#comment-67</link>
		<dc:creator>tim</dc:creator>
		<pubDate>Sun, 03 Dec 2006 20:36:54 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=46#comment-67</guid>
		<description>Let&#039;s try this again and hope your blog lets me post it.  I can tell you that texas ramsan that was posted above this is what at least one of the major online vendors uses.  I&#039;m not at liberty to say who (as I can&#039;t find a press release), but believe me, it&#039;s definitely &quot;mature&quot; if these guys are using it.  It&#039;s incredibly fast, and what they use for all of their database infrastructure.  TMS FTW!</description>
		<content:encoded><![CDATA[<p>Let&#8217;s try this again and hope your blog lets me post it.  I can tell you that texas ramsan that was posted above this is what at least one of the major online vendors uses.  I&#8217;m not at liberty to say who (as I can&#8217;t find a press release), but believe me, it&#8217;s definitely &#8220;mature&#8221; if these guys are using it.  It&#8217;s incredibly fast, and what they use for all of their database infrastructure.  TMS FTW!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nigel</title>
		<link>http://blog.nigelpoulton.com/when-bigger-isn%e2%80%99t-better/comment-page-1/#comment-66</link>
		<dc:creator>Nigel</dc:creator>
		<pubDate>Fri, 17 Nov 2006 23:26:26 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=46#comment-66</guid>
		<description>Check out this article on computerworld.com about the TexasMemory Systems RamSan based on SSD technology -

http://www.computerworld.com/action/article.do?command=viewArticleBasic&amp;articleId=9005207&amp;source=rss_topic19

Its replaced the traditional hard drives with solid state devices operating at approx 250 times the speed of a hard disk.  They&#039;re touting it as the fastest storage in the world.</description>
		<content:encoded><![CDATA[<p>Check out this article on computerworld.com about the TexasMemory Systems RamSan based on SSD technology -</p>
<p><a href="http://www.computerworld.com/action/article.do?command=viewArticleBasic&amp;articleId=9005207&amp;source=rss_topic19" rel="nofollow">http://www.computerworld.com/action/article.do?command=viewArticleBasic&amp;articleId=9005207&amp;source=rss_topic19</a></p>
<p>Its replaced the traditional hard drives with solid state devices operating at approx 250 times the speed of a hard disk.  They&#8217;re touting it as the fastest storage in the world.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: richard</title>
		<link>http://blog.nigelpoulton.com/when-bigger-isn%e2%80%99t-better/comment-page-1/#comment-65</link>
		<dc:creator>richard</dc:creator>
		<pubDate>Tue, 14 Nov 2006 02:50:02 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=46#comment-65</guid>
		<description>Mackem,
As you know, this situation would have been a lot worse if your friend was running Raid 5...  there are no magical â€˜firmware-levelâ€™ solutions and everyone has the same problems, including EMC &amp; HDS.

In situations like this, it would be handy to be able to replace some of the magnetic disks with plug-compatible SSDs, build a new raidgroup, relocate hot-spots, etc â€¦and try again.

From my experience, it is very difficult to go back to a â€˜slowâ€™ solution, providing the benefit can be easily demonstrated and the cost is right. Historically, this was the case with some of the old I/O caching solutions, going back to PDP11 days.</description>
		<content:encoded><![CDATA[<p>Mackem,<br />
As you know, this situation would have been a lot worse if your friend was running Raid 5&#8230;  there are no magical â€˜firmware-levelâ€™ solutions and everyone has the same problems, including EMC &amp; HDS.</p>
<p>In situations like this, it would be handy to be able to replace some of the magnetic disks with plug-compatible SSDs, build a new raidgroup, relocate hot-spots, etc â€¦and try again.</p>
<p>From my experience, it is very difficult to go back to a â€˜slowâ€™ solution, providing the benefit can be easily demonstrated and the cost is right. Historically, this was the case with some of the old I/O caching solutions, going back to PDP11 days.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mackem</title>
		<link>http://blog.nigelpoulton.com/when-bigger-isn%e2%80%99t-better/comment-page-1/#comment-64</link>
		<dc:creator>mackem</dc:creator>
		<pubDate>Mon, 13 Nov 2006 10:59:44 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=46#comment-64</guid>
		<description>An ex-colleague of mine, Joe, was recently doing some performance testing at a HP test facility in Holland (if memory serves me correctly).  They were pushing an XP12K and an Oracle database to see if they could get a certain number of transactions per second.  They were seeing good results on the XP until the cache write pending rate hit around the 40% mark.

On Hitachi boxes the destaging process starts picking up the pace at the around the 40% mark, basically shovelling data off to disk at a faster rate.  Once this 40% mark was breached, the performance of the XP took an absolute nose dive.  Now although this will no doubt have been in part to do with the caching and destaging algoithms, the back end disks were certainly starting to become a bottle neck. They were running RAID10 on 15K disks with the spindles doing no other work.  May be he could have benefited from SSD on the back end instead of spinning disks?

With disk being so MANY times slower than cache, they often do become a performance limiting factor in a busy environment.</description>
		<content:encoded><![CDATA[<p>An ex-colleague of mine, Joe, was recently doing some performance testing at a HP test facility in Holland (if memory serves me correctly).  They were pushing an XP12K and an Oracle database to see if they could get a certain number of transactions per second.  They were seeing good results on the XP until the cache write pending rate hit around the 40% mark.</p>
<p>On Hitachi boxes the destaging process starts picking up the pace at the around the 40% mark, basically shovelling data off to disk at a faster rate.  Once this 40% mark was breached, the performance of the XP took an absolute nose dive.  Now although this will no doubt have been in part to do with the caching and destaging algoithms, the back end disks were certainly starting to become a bottle neck. They were running RAID10 on 15K disks with the spindles doing no other work.  May be he could have benefited from SSD on the back end instead of spinning disks?</p>
<p>With disk being so MANY times slower than cache, they often do become a performance limiting factor in a busy environment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: SanGod</title>
		<link>http://blog.nigelpoulton.com/when-bigger-isn%e2%80%99t-better/comment-page-1/#comment-63</link>
		<dc:creator>SanGod</dc:creator>
		<pubDate>Sun, 12 Nov 2006 04:54:54 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=46#comment-63</guid>
		<description>No, the internal drive we were evaling weren&#039;t big enough to be taken seriously.

Then again, neither was MTI.  ;-)   However these drives would have been great for hobbiests at home, but not something i would put a production application on.  For the most part, I&#039;ll stick to my EMC arrays.  They have enough cache in them for any five applications.

Especially since I&#039;m currently working in a mostly windoze shop, there is no chance any dozen Microsquish servers could ever push an EMC array to it&#039;s limit.</description>
		<content:encoded><![CDATA[<p>No, the internal drive we were evaling weren&#8217;t big enough to be taken seriously.</p>
<p>Then again, neither was MTI.  <img src='http://blog.nigelpoulton.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' />    However these drives would have been great for hobbiests at home, but not something i would put a production application on.  For the most part, I&#8217;ll stick to my EMC arrays.  They have enough cache in them for any five applications.</p>
<p>Especially since I&#8217;m currently working in a mostly windoze shop, there is no chance any dozen Microsquish servers could ever push an EMC array to it&#8217;s limit.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

