Re: How to control Minor Compaction by programmingre i t w e kejj

[Cristiano De Toni <fu...@gmail.com>]

R5 tot
Il 31/Lug/2015 06:51, "Josh Elser" <jo...@gmail.com> ha scritto:

> 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<jo...@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
>>>
>>>
>>>
>>>
>>>