<?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"
	>
<channel>
	<title>Comments on: Performance tuning the AS/400: Fault rates and pools</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/iseries/performance-tuning-the-as400-fault-rates-and-pools/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/iseries/performance-tuning-the-as400-fault-rates-and-pools/</link>
	<description>A Search400.com blog</description>
	<pubDate>Thu, 26 Nov 2009 11:10:44 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: JessB</title>
		<link>http://itknowledgeexchange.techtarget.com/iseries/performance-tuning-the-as400-fault-rates-and-pools/#comment-530</link>
		<dc:creator>JessB</dc:creator>
		<pubDate>Sat, 06 Dec 2008 21:36:11 +0000</pubDate>
		<guid isPermaLink="false">http://iseries.blogs.techtarget.com/2008/11/24/performance-tuning-the-as400-fault-rates-and-pools/#comment-530</guid>
		<description>This article makes a lot of sense to me. I'm currently using an external storage system(DS8100) on my i570-MMA. We just recently implemented our Global Mirroring replication (managed by TPC-R) and immediately noticed a hit on disk response time on the i5/OS partition. Batch and Interactive jobs are now running 5 or more times longer than usual. The performance will get better when I suspend the replication process. I run a performance data report on disk utilization and found that disk write wait time is way high during Global Copy formation. I'm not sure if this is something that the i5/OS can fine tune. The CPU and Memory is not a question. The system have more than enough CPU and Memory to run. Any feedback is greatly appreciated. 

Thanks a lot.
JB</description>
		<content:encoded><![CDATA[<p>This article makes a lot of sense to me. I&#8217;m currently using an external storage system(DS8100) on my i570-MMA. We just recently implemented our Global Mirroring replication (managed by TPC-R) and immediately noticed a hit on disk response time on the i5/OS partition. Batch and Interactive jobs are now running 5 or more times longer than usual. The performance will get better when I suspend the replication process. I run a performance data report on disk utilization and found that disk write wait time is way high during Global Copy formation. I&#8217;m not sure if this is something that the i5/OS can fine tune. The CPU and Memory is not a question. The system have more than enough CPU and Memory to run. Any feedback is greatly appreciated. </p>
<p>Thanks a lot.<br />
JB</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Lumley</title>
		<link>http://itknowledgeexchange.techtarget.com/iseries/performance-tuning-the-as400-fault-rates-and-pools/#comment-529</link>
		<dc:creator>Rob Lumley</dc:creator>
		<pubDate>Mon, 01 Dec 2008 17:41:29 +0000</pubDate>
		<guid isPermaLink="false">http://iseries.blogs.techtarget.com/2008/11/24/performance-tuning-the-as400-fault-rates-and-pools/#comment-529</guid>
		<description>If you use ops navigator you can also set the tuning priority so typically Machine would be 1, Interactive 2 and spool/share 3</description>
		<content:encoded><![CDATA[<p>If you use ops navigator you can also set the tuning priority so typically Machine would be 1, Interactive 2 and spool/share 3</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim</title>
		<link>http://itknowledgeexchange.techtarget.com/iseries/performance-tuning-the-as400-fault-rates-and-pools/#comment-528</link>
		<dc:creator>Jim</dc:creator>
		<pubDate>Mon, 01 Dec 2008 16:28:44 +0000</pubDate>
		<guid isPermaLink="false">http://iseries.blogs.techtarget.com/2008/11/24/performance-tuning-the-as400-fault-rates-and-pools/#comment-528</guid>
		<description>The earlier article talking about RAISING the Max Act level until you get Wait-&#62;Inel entries.  I was taught, and my system seems to confirm, that Wait-&#62;Inel occurs because the Max Act is too LOW a number.

In database class years ago, they said that one downside of setting the Max Act too high is that the DB optimizer looks at that to divide up the memory:  if you have Max Act set to 500 and only really need 200, some of the database optimization gets written to disk, because it figures that there COULD be 500 jobs competing for the memory.  Since they, I've heard that this is no longer the case and there really isn't a downside to setting the Max Act too high, although I suspect that might be another case of incredibly fast hardware compensating for less-than-optimal tuning.</description>
		<content:encoded><![CDATA[<p>The earlier article talking about RAISING the Max Act level until you get Wait-&gt;Inel entries.  I was taught, and my system seems to confirm, that Wait-&gt;Inel occurs because the Max Act is too LOW a number.</p>
<p>In database class years ago, they said that one downside of setting the Max Act too high is that the DB optimizer looks at that to divide up the memory:  if you have Max Act set to 500 and only really need 200, some of the database optimization gets written to disk, because it figures that there COULD be 500 jobs competing for the memory.  Since they, I&#8217;ve heard that this is no longer the case and there really isn&#8217;t a downside to setting the Max Act too high, although I suspect that might be another case of incredibly fast hardware compensating for less-than-optimal tuning.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
<!-- dynamic -->