<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Crash Dump Analysis Patterns (Part 62)</title>
	<link>https://www.dumpanalysis.org/blog/index.php/2008/05/28/crash-dump-analysis-patterns-part-62/</link>
	<description>Structural and Behavioral Patterns for Software Diagnostics, Forensics and Prognostics</description>
	<pubDate>Wed, 06 May 2026 22:46:50 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>By: Crash Dump Analysis &#187; Blog Archive &#187; Insufficient memory, handle leak, wait chain, deadlock, inconsistent dump and overaged system: pattern cooperation</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2008/05/28/crash-dump-analysis-patterns-part-62/#comment-103490</link>
		<dc:creator>Crash Dump Analysis &#187; Blog Archive &#187; Insufficient memory, handle leak, wait chain, deadlock, inconsistent dump and overaged system: pattern cooperation</dc:creator>
		<pubDate>Sun, 08 Nov 2009 22:48:56 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2008/05/28/crash-dump-analysis-patterns-part-62/#comment-103490</guid>
		<description>[...] We also notice the system uptime which might suggest that all these abnormalities had been gradually accumulated (see Overaged System): [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] We also notice the system uptime which might suggest that all these abnormalities had been gradually accumulated (see Overaged System): [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Crash Dump Analysis &#187; Blog Archive &#187; Crash Dump Analysis Patterns (Part 73)</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2008/05/28/crash-dump-analysis-patterns-part-62/#comment-36105</link>
		<dc:creator>Crash Dump Analysis &#187; Blog Archive &#187; Crash Dump Analysis Patterns (Part 73)</dc:creator>
		<pubDate>Tue, 29 Jul 2008 19:22:03 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2008/05/28/crash-dump-analysis-patterns-part-62/#comment-36105</guid>
		<description>[...] to Overaged System sometimes we can see Young System pattern. This means that the system didn&#8217;t have time to [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] to Overaged System sometimes we can see Young System pattern. This means that the system didn&#8217;t have time to [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chae</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2008/05/28/crash-dump-analysis-patterns-part-62/#comment-28851</link>
		<dc:creator>Chae</dc:creator>
		<pubDate>Thu, 29 May 2008 18:34:27 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2008/05/28/crash-dump-analysis-patterns-part-62/#comment-28851</guid>
		<description>Hello,

Following is what happened one of our overaged servers. Virtual Memory Address fragmentation seems inevitable even if we're using LFH (Low Fragmentation Heap). This machine have had plenty of free physical memory but we had to restart the service.

Usually large Uncommitted Ranges are bad but in this case 200 UCR caused 98% Virtual Address Fragmentation though which is a little bit strange.

0:020&#62; !heap -s
  Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast
                   (k)     (k)    (k)     (k) length      blocks cont. heap
-----------------------------------------------------------------------------
006c0000 00001002 2565820   7232 658924   1302   160   200    0 44f3b4   LFH
   External fragmentation  18 % (160 free blocks)
   Virtual address fragmentation  98 % (200 uncommited ranges)</description>
		<content:encoded><![CDATA[<p>Hello,</p>
<p>Following is what happened one of our overaged servers. Virtual Memory Address fragmentation seems inevitable even if we&#8217;re using LFH (Low Fragmentation Heap). This machine have had plenty of free physical memory but we had to restart the service.</p>
<p>Usually large Uncommitted Ranges are bad but in this case 200 UCR caused 98% Virtual Address Fragmentation though which is a little bit strange.</p>
<p>0:020&gt; !heap -s<br />
  Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast<br />
                   (k)     (k)    (k)     (k) length      blocks cont. heap<br />
&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8211;<br />
006c0000 00001002 2565820   7232 658924   1302   160   200    0 44f3b4   LFH<br />
   External fragmentation  18 % (160 free blocks)<br />
   Virtual address fragmentation  98 % (200 uncommited ranges)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
