<?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: Top 10 things that you must monitor on any server to look for performance and/or scalability issues</title>
	<atom:link href="http://unmanageability.com/index.php/2006/02/10/top-10-things-that-you-must-monitor-on-any-server-to-look-for-performance-andor-scalability-issues/feed/" rel="self" type="application/rss+xml" />
	<link>http://unmanageability.com/index.php/2006/02/10/top-10-things-that-you-must-monitor-on-any-server-to-look-for-performance-andor-scalability-issues/</link>
	<description>Performance Within Reach</description>
	<lastBuildDate>Sat, 05 Jul 2008 18:42:29 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Kirk</title>
		<link>http://unmanageability.com/index.php/2006/02/10/top-10-things-that-you-must-monitor-on-any-server-to-look-for-performance-andor-scalability-issues/comment-page-1/#comment-29</link>
		<dc:creator>Kirk</dc:creator>
		<pubDate>Fri, 10 Feb 2006 08:16:38 +0000</pubDate>
		<guid isPermaLink="false">http://codeperformance.com/index.php/2006/02/10/top-10-things-that-you-must-monitor-on-any-server-to-look-for-performance-andor-scalability-issues/#comment-29</guid>
		<description>On point 2, hi system time is typically due to high level of interrupt handling or the inability of threads to consume their entire time slice resulting in a lot of context switching. Some sort of very short term lock contention without any other underlying contention issues is a typical cause of this problem. If you have an I/O bottlenecks typically will result in long response times with an inability to fully utilize the CPU.</description>
		<content:encoded><![CDATA[<p>On point 2, hi system time is typically due to high level of interrupt handling or the inability of threads to consume their entire time slice resulting in a lot of context switching. Some sort of very short term lock contention without any other underlying contention issues is a typical cause of this problem. If you have an I/O bottlenecks typically will result in long response times with an inability to fully utilize the CPU.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
