Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> GC and High CPU


Copy link to this message
-
Re: GC and High CPU
This is the way I read it. "Low processors" == "high CPU tasks, e.g. high
load".   So, Incremental takes GC down a number of notches when it comes to
competing with CPU for APP threads.  That being the case the deadlock is
less likely.  It would be useful to add code to the RS that will start
blocking any RPC calls should this condition be detected, if we block say
for 10 seconds, GC could finish doing it 'dirty' work and release CPU :)
-Jack
On May 16, 2011 5:53 PM, "Stack" <[EMAIL PROTECTED]> wrote:
> I don't understand what of the below made a difference though the
> difference is plain from the GC logs you show.
>
> See below:
>
> On Mon, May 16, 2011 at 5:06 PM, Jack Levin <[EMAIL PROTECTED]> wrote:
>> Those are the lines I added:
>>
>> -XX:+CMSIncrementalMode \  <--------
>
>
> From the doc., it says about i-cms and java6 "This feature is useful
> when applications that need the low pause times provided by the
> concurrent collector are run on machines with small numbers of
> processors (e.g., 1 or 2)." [See
> http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#icms
]
> Don't you have > 2 processors per machine?
>
> St.Ack
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB