<?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>评论：JAVA性能优化-GC日志分析</title>
	<atom:link href="http://www.hashei.me/2009/06/analyse-the-gc-logs.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.hashei.me/2009/06/analyse-the-gc-logs.html?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=analyse-the-gc-logs</link>
	<description>一个系统工程师的絮叨</description>
	<lastBuildDate>Mon, 30 Jan 2012 02:37:27 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>来自：匿名</title>
		<link>http://www.hashei.me/2009/06/analyse-the-gc-logs.html/comment-page-1#comment-3943</link>
		<dc:creator>匿名</dc:creator>
		<pubDate>Wed, 22 Jun 2011 05:16:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.hashei.me/2009/06/analyse-the-gc-logs.html#comment-3943</guid>
		<description>你好，从你上面分析得日志来看，是采用分代算法么？还有，我该如何确定ibm jdk的当前算法了？谢谢。</description>
		<content:encoded><![CDATA[<p>你好，从你上面分析得日志来看，是采用分代算法么？还有，我该如何确定ibm jdk的当前算法了？谢谢。</p>
]]></content:encoded>
	</item>
	<item>
		<title>来自：聚沙成塔-小哈的记事薄 &#187; Investigating Out of Memory/Memory Leak Problems</title>
		<link>http://www.hashei.me/2009/06/analyse-the-gc-logs.html/comment-page-1#comment-907</link>
		<dc:creator>聚沙成塔-小哈的记事薄 &#187; Investigating Out of Memory/Memory Leak Problems</dc:creator>
		<pubDate>Thu, 24 Sep 2009 09:04:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.hashei.me/2009/06/analyse-the-gc-logs.html#comment-907</guid>
		<description>[...] 但现在这个网址已经无法访问，我在Metalink找到这篇文章并与大家分享。文章发表的较早，但是OOM发生的原理和解决的方法不变。文中提到的/3GB参数和垃圾回收日志分析的方法我在《JAVA性能优化—IBM JDK JVM参数设置》和《JAVA性能优化-GC日志分析》都提到过。如果英文的看起来比较麻烦，我google到台湾人做的一份翻译JavaAPsvr_A_200411_MemoryLeak，不过我看着“记忆体”觉得更别扭。 [...]</description>
		<content:encoded><![CDATA[<p>[...] 但现在这个网址已经无法访问，我在Metalink找到这篇文章并与大家分享。文章发表的较早，但是OOM发生的原理和解决的方法不变。文中提到的/3GB参数和垃圾回收日志分析的方法我在《JAVA性能优化—IBM JDK JVM参数设置》和《JAVA性能优化-GC日志分析》都提到过。如果英文的看起来比较麻烦，我google到台湾人做的一份翻译JavaAPsvr_A_200411_MemoryLeak，不过我看着“记忆体”觉得更别扭。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>来自：聚沙成塔-小哈的记事薄 &#187; IBM JDK的Java堆空间的碎片问题</title>
		<link>http://www.hashei.me/2009/06/analyse-the-gc-logs.html/comment-page-1#comment-566</link>
		<dc:creator>聚沙成塔-小哈的记事薄 &#187; IBM JDK的Java堆空间的碎片问题</dc:creator>
		<pubDate>Fri, 28 Aug 2009 04:02:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.hashei.me/2009/06/analyse-the-gc-logs.html#comment-566</guid>
		<description>[...] 对于IBM的JDK，设置恰当的最大堆和最小堆，设置-Xk和-Xp避免碎片问题，如果程序需要分配大对象较多，那么调整一下LOA的大小（判断标准是gc日志里大量AF是由于分配大于64K内容而产生的，gc日志的分析方法可以看这篇）。 [...]</description>
		<content:encoded><![CDATA[<p>[...] 对于IBM的JDK，设置恰当的最大堆和最小堆，设置-Xk和-Xp避免碎片问题，如果程序需要分配大对象较多，那么调整一下LOA的大小（判断标准是gc日志里大量AF是由于分配大于64K内容而产生的，gc日志的分析方法可以看这篇）。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>来自：WebSphere troubshooting-用工具分析GC Log &#124; 聚沙成塔-小哈的记事薄</title>
		<link>http://www.hashei.me/2009/06/analyse-the-gc-logs.html/comment-page-1#comment-351</link>
		<dc:creator>WebSphere troubshooting-用工具分析GC Log &#124; 聚沙成塔-小哈的记事薄</dc:creator>
		<pubDate>Thu, 02 Jul 2009 08:51:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.hashei.me/2009/06/analyse-the-gc-logs.html#comment-351</guid>
		<description>[...] 要进行gc performance tuning，不得不对gc log进行分析。之前说到了“人肉”的方法，总觉得不够形象，无法让不了解的开发人员抑或是技术负责人有个直观的了解，所以本文介绍几个分析GC log的工具。 [...]</description>
		<content:encoded><![CDATA[<p>[...] 要进行gc performance tuning，不得不对gc log进行分析。之前说到了“人肉”的方法，总觉得不够形象，无法让不了解的开发人员抑或是技术负责人有个直观的了解，所以本文介绍几个分析GC log的工具。 [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

