On Wed, Jul 7, 2010 at 11:28 AM, Y. S. Ramakrishna <span dir="ltr">&lt;<a href="mailto:y.s.ramakrishna@oracle.com">y.s.ramakrishna@oracle.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
<br>
On 07/07/10 08:45, Todd Lipcon wrote:<br>
...<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Overnight I saw one &quot;concurrent mode failure&quot;.<br>
</blockquote></div>
...<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2010-07-07T07:56:27.786-0700: 28490.203: [GC 28490.203: [ParNew (promotion failed): 59008K-&gt;59008K(59008K), 0.0179250 secs]28490.221: [CMS2010-07-07T07:56:27.901-0700: 28490.317: [CMS-concurrent-preclean: 0.556/0.947 secs] [Times:<br>


 user=5.76 sys=0.26, real=0.95 secs]  (concurrent mode failure): 6359176K-&gt;4206871K(8323072K), 17.4366220 secs] 6417373K-&gt;4206871K(8382080K), [CMS Perm : 18609K-&gt;18565K(31048K)], 17.4546890 secs] [Times: user=11.17 sys=0.09, real=17.45 secs] <br>


I&#39;ve interpreted pauses like this as being caused by fragmentation, since the young gen is 64M, and the old gen here has about 2G free. If there&#39;s something I&#39;m not understanding about CMS, and I can tune it more smartly to avoid these longer pauses, I&#39;m happy to try.<br>


</blockquote>
<br></div>
Yes the old gen must be fragmented. I&#39;ll look at the data you have<br>
made available (for CMS). The CMS log you uploaded does not have the<br>
suffix leading into the concurrent mode failure ypu display above<br>
(it stops less than 2500 s into the run). If you could include<br>
the entire log leading into the concurrent mode failures, it would<br>
be a great help. </blockquote><div><br></div><div>Just uploaded the full log from the entire 11-hour run, all the way up through the 218-second GC pause which caused the server to get kicked out of the cluster (since it stopped heartbeating to the master)</div>

<div><br></div><div><a href="http://cloudera-todd.s3.amazonaws.com/cms-full-gc-log.txt.gz">http://cloudera-todd.s3.amazonaws.com/cms-full-gc-log.txt.gz</a></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Do you have large arrays in your<br>
application? </blockquote><div><br></div><div>The primary heap consumers in the application are:</div><div>- RPC buffers - in this case I&#39;m configured for 40 RPC handlers, each of which is usually handling a byte[] around 2-3MB for a &quot;put&quot;. These buffers then get passed along into the memstore:</div>

<div>- Memstore - this is allocated 40% of the heap, and it&#39;s made up of some hundreds of separate ConcurrentSkipListMaps. The values of the map are small objects which contain offsets into to the byte[]s passed in above. So, typically this is about 2GB of heap, corresponding to around a million of the offset containers, and maybe 100 thousand of the actual byte arrays.</div>

<div><br></div><div>These memstores are always being &quot;flushed&quot; to disk (basically we take one of the maps and write it out, then drop references to the map to let GC free up memory)</div><div><br></div><div>- LRU block cache - this is a large ConcurrentHashMap&lt;String,CachedBlock&gt;, where a CachedBlock is basically a wrapper for a ByteBuffer. These ByteBuffers represent around 64KB each. Typically this is allocated 20% of the heap, so on the order of 20,000 entries in the map here.</div>

<div><br></div><div>Eviction is done by manually accounting heap usage, and when it gets too high, we remove blocks from the cache.</div><div><br></div><div>So to answer your question simply: there shouldn&#39;t be any byte arrays floating around larger than 2MB, though there are a fair number at that size and a fair number at 64KB. Can I use jmap or another program to do any useful analysis?</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The shape of the promotion graph for CMS is somewhat<br>
jagged, indicating _perhaps_ that. Yes, +PrintTenuringDistribution<br>
would shed a bit more light. </blockquote><div><br></div><div>I&#39;ll restart the test with this option on and collect some more logs for you guys.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

 As regards fragmentation, it can be<br>
tricky to tune against, but we can try once we understand a bit<br>
more about the object sizes and demographics.<br>
<br>
I am sure you don&#39;t have an easily shared test case, so we<br>
can reproduce both the CMS fragmentation and the G1 full gc<br>
issues locally for quickest progress on this?<br><br></blockquote><div>Well, the project itself is open source, but to really get serious load going into it you need beefy machines/disks. I&#39;m running my tests on a 5-node cluster of dual quad core Nehalems, 24G RAM, 12 disks each. I can try to set up a mocked workload (eg skip actual disk IO) from the same codebase, but it would be a fair bit of work and I don&#39;t think I can get to it this month (leaving for vacation next week)</div>

<div><br></div><div>If it&#39;s useful to look at the source, here are some pointers to the relevant RAM consumers:</div><div><br></div><div>Cache:</div><div><a href="http://github.com/apache/hbase/blob/trunk/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java">http://github.com/apache/hbase/blob/trunk/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java</a></div>

<div><br></div><div>MemStore:</div><div><a href="http://github.com/apache/hbase/blob/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java">http://github.com/apache/hbase/blob/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java</a></div>

<div><br></div><div>Wrapper class held by memstore:</div><div><a href="http://github.com/apache/hbase/blob/trunk/src/main/java/org/apache/hadoop/hbase/KeyValue.java">http://github.com/apache/hbase/blob/trunk/src/main/java/org/apache/hadoop/hbase/KeyValue.java</a></div>

</div><div><br></div><div>The class used by RPC to receive &quot;Put&quot; requests:</div><a href="http://github.com/apache/hbase/blob/trunk/src/main/java/org/apache/hadoop/hbase/client/Put.java">http://github.com/apache/hbase/blob/trunk/src/main/java/org/apache/hadoop/hbase/client/Put.java</a><div>

<br></div><div>Thanks again for all the help, it&#39;s much appreciated.</div><div>-Todd<br>-- <br>Todd Lipcon<br>Software Engineer, Cloudera<br>
</div>