accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: How to control Minor Compaction by programming
Date Fri, 31 Jul 2015 04:51:38 GMT
No, it's just a count of the minor compactions being run.

Hai Pham wrote:
> Hey William, Josh and David,
>
> Thanks for explaining, I might not have been clear: I used the web interface with port
50095 to monitor the real-time charts (ingest, scan, load average, minor compaction, major
compaction, ...).
>
> Nonetheless, as I witnessed, when I ingested about 100k entries ->  then minor compaction
happened ->  ingest was stuck ->  the level of minor compaction on the charts was just
about 1.0, 2.0 and max 3.0 while about>20k entries were forced out of memory (I knew this
by looking at the number of entries in memory w.r.t the table being ingested to) ->  then
when minor compaction ended, ingest resumed, somewhat faster.
>
> Thus I presume the level 1.0, 2.0, 3.0 is not representative for number of files being
minor-compacted from memory?
>
> Hai
> ________________________________________
> From: Josh Elser<josh.elser@gmail.com>
> Sent: Thursday, July 30, 2015 7:12 PM
> To: user@accumulo.apache.org
> Subject: Re: How to control Minor Compaction by programming
>
>> Also, can you please explain the number 0, 1.0, 2.0, ... in charts (web
>> monitoring) denoting the level of Minor Compaction and Major Compaction?
>
> On the monitor, the number of compactions are of the form:
>
> active (queued)
>
> e.g. 4 (2), would mean that 4 are running and 2 are queued.
>
>>
>> Thank you!
>>
>> Hai Pham
>>
>>
>>
>>

Mime
View raw message