You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Billy Pearson (JIRA)" <ji...@apache.org> on 2008/01/16 03:27:34 UTC
[jira] Created: (HADOOP-2621) Memcache flush flushing every 60 secs
with out considering the max memcache size
Memcache flush flushing every 60 secs with out considering the max memcache size
--------------------------------------------------------------------------------
Key: HADOOP-2621
URL: https://issues.apache.org/jira/browse/HADOOP-2621
Project: Hadoop
Issue Type: Bug
Components: contrib/hbase
Reporter: Billy Pearson
Fix For: 0.16.0
looks like hbase is flushing all memcache to disk every 60 secs causing a lot of work for the compactor to keep up because column gets its own mapfile and every region is flushed at one time. This could be a vary large number of mapfiles to write if a region server is hosting 100 regions all with milti columns.
Idea memcache flush
keep all data in memory until memcache get larger then the conf size with hbase.hregion.memcache.flush.size.
When we reach this size we should flush the regions that are the largest first stopping once we drop back below the memcache max size maybe 20% below the max. This will to flush only as needed as each flush takes time to compact when compaction runs on a region. while we are flushing a region we should also be blocking new updates from happening on that region so the region server does not get over ran when a high update load hits a region server. By only blocking on the region we are flushing at that time other regions will still be able to do updates this.
We we still want to use the hbase.regionserver.optionalcacheflushinterval we should set to to run once an hour so something like that so we can recover memory from the memcache on region that do not have a lot updates in memory. But running at the default set now of 60 secs is not so good for the compactor if it has many regions to handle also not good for a scanner to have to scan many small files vs a few larger ones
Example a compactor may take 15 mins to compact a region in that time we will flush 15 times causeing all other regions to get a new mapfile to compact when it becomes it turn to get compacted if you had many regions getting compacted the last one on the list of say 10 regions would have 10 regions * 15 mins each = 150 mapfiles for each column in the last region written before the compactor can get to it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2621) Memcache flush flushing every 60 secs
with out considering the max memcache size
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-2621:
--------------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed (Ignoring failure in core).
> Memcache flush flushing every 60 secs with out considering the max memcache size
> --------------------------------------------------------------------------------
>
> Key: HADOOP-2621
> URL: https://issues.apache.org/jira/browse/HADOOP-2621
> Project: Hadoop
> Issue Type: Bug
> Components: contrib/hbase
> Reporter: Billy Pearson
> Assignee: stack
> Fix For: 0.16.0
>
> Attachments: optionalcacheflushinterval.patch
>
>
> looks like hbase is flushing all memcache to disk every 60 secs causing a lot of work for the compactor to keep up because column gets its own mapfile and every region is flushed at one time. This could be a vary large number of mapfiles to write if a region server is hosting 100 regions all with milti columns.
> Idea memcache flush
> keep all data in memory until memcache get larger then the conf size with hbase.hregion.memcache.flush.size.
> When we reach this size we should flush the regions that are the largest first stopping once we drop back below the memcache max size maybe 20% below the max. This will to flush only as needed as each flush takes time to compact when compaction runs on a region. while we are flushing a region we should also be blocking new updates from happening on that region so the region server does not get over ran when a high update load hits a region server. By only blocking on the region we are flushing at that time other regions will still be able to do updates this.
> We we still want to use the hbase.regionserver.optionalcacheflushinterval we should set to to run once an hour so something like that so we can recover memory from the memcache on region that do not have a lot updates in memory. But running at the default set now of 60 secs is not so good for the compactor if it has many regions to handle also not good for a scanner to have to scan many small files vs a few larger ones
> Example a compactor may take 15 mins to compact a region in that time we will flush 15 times causeing all other regions to get a new mapfile to compact when it becomes it turn to get compacted if you had many regions getting compacted the last one on the list of say 10 regions would have 10 regions * 15 mins each = 150 mapfiles for each column in the last region written before the compactor can get to it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2621) Memcache flush flushing every 60
secs with out considering the max memcache size
Posted by "Billy Pearson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559658#action_12559658 ]
Billy Pearson commented on HADOOP-2621:
---------------------------------------
With out a way to set a limit on memory usage and a limit where we start blocking updates the region server could reach a point where we run out of memory before it could flush the memcache causing a crash on the region server. I thank we should move back to using hbase.hregion.memcache.block.multiplier and hbase.hregion.memcache.flush.size. Maybe we can have an option flusher the splitter can call to force a flush on a region so the split can do its work.
> Memcache flush flushing every 60 secs with out considering the max memcache size
> --------------------------------------------------------------------------------
>
> Key: HADOOP-2621
> URL: https://issues.apache.org/jira/browse/HADOOP-2621
> Project: Hadoop
> Issue Type: Bug
> Components: contrib/hbase
> Reporter: Billy Pearson
> Fix For: 0.16.0
>
>
> looks like hbase is flushing all memcache to disk every 60 secs causing a lot of work for the compactor to keep up because column gets its own mapfile and every region is flushed at one time. This could be a vary large number of mapfiles to write if a region server is hosting 100 regions all with milti columns.
> Idea memcache flush
> keep all data in memory until memcache get larger then the conf size with hbase.hregion.memcache.flush.size.
> When we reach this size we should flush the regions that are the largest first stopping once we drop back below the memcache max size maybe 20% below the max. This will to flush only as needed as each flush takes time to compact when compaction runs on a region. while we are flushing a region we should also be blocking new updates from happening on that region so the region server does not get over ran when a high update load hits a region server. By only blocking on the region we are flushing at that time other regions will still be able to do updates this.
> We we still want to use the hbase.regionserver.optionalcacheflushinterval we should set to to run once an hour so something like that so we can recover memory from the memcache on region that do not have a lot updates in memory. But running at the default set now of 60 secs is not so good for the compactor if it has many regions to handle also not good for a scanner to have to scan many small files vs a few larger ones
> Example a compactor may take 15 mins to compact a region in that time we will flush 15 times causeing all other regions to get a new mapfile to compact when it becomes it turn to get compacted if you had many regions getting compacted the last one on the list of say 10 regions would have 10 regions * 15 mins each = 150 mapfiles for each column in the last region written before the compactor can get to it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2621) Memcache flush flushing every 60
secs with out considering the max memcache size
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559530#action_12559530 ]
stack commented on HADOOP-2621:
-------------------------------
Looks like hbase.hregion.memcache.flush.size is no longer being read/used. This probably means that the blocking mechanism -- when memcache > twice the limit, we stop taking on updates -- no longer works. Was useful for when regionservers were on occasion overwhelmed; it gave them a chance to catch their breath.
>From Billy's description up on IRC, compaction was being overrun by the number of files produced flushing when cluster was under load. In the past there was an attempt at striking an equilibrium between flush and compaction rates/sizes.
I'll take a look at this.
> Memcache flush flushing every 60 secs with out considering the max memcache size
> --------------------------------------------------------------------------------
>
> Key: HADOOP-2621
> URL: https://issues.apache.org/jira/browse/HADOOP-2621
> Project: Hadoop
> Issue Type: Bug
> Components: contrib/hbase
> Reporter: Billy Pearson
> Fix For: 0.16.0
>
>
> looks like hbase is flushing all memcache to disk every 60 secs causing a lot of work for the compactor to keep up because column gets its own mapfile and every region is flushed at one time. This could be a vary large number of mapfiles to write if a region server is hosting 100 regions all with milti columns.
> Idea memcache flush
> keep all data in memory until memcache get larger then the conf size with hbase.hregion.memcache.flush.size.
> When we reach this size we should flush the regions that are the largest first stopping once we drop back below the memcache max size maybe 20% below the max. This will to flush only as needed as each flush takes time to compact when compaction runs on a region. while we are flushing a region we should also be blocking new updates from happening on that region so the region server does not get over ran when a high update load hits a region server. By only blocking on the region we are flushing at that time other regions will still be able to do updates this.
> We we still want to use the hbase.regionserver.optionalcacheflushinterval we should set to to run once an hour so something like that so we can recover memory from the memcache on region that do not have a lot updates in memory. But running at the default set now of 60 secs is not so good for the compactor if it has many regions to handle also not good for a scanner to have to scan many small files vs a few larger ones
> Example a compactor may take 15 mins to compact a region in that time we will flush 15 times causeing all other regions to get a new mapfile to compact when it becomes it turn to get compacted if you had many regions getting compacted the last one on the list of say 10 regions would have 10 regions * 15 mins each = 150 mapfiles for each column in the last region written before the compactor can get to it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2621) Memcache flush flushing every 60
secs with out considering the max memcache size
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560155#action_12560155 ]
Hadoop QA commented on HADOOP-2621:
-----------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12373361/optionalcacheflushinterval.patch
against trunk revision r612974.
@author +1. The patch does not contain any @author tags.
javadoc +1. The javadoc tool did not generate any warning messages.
javac +1. The applied patch does not generate any new compiler warnings.
findbugs +1. The patch does not introduce any new Findbugs warnings.
core tests -1. The patch failed core unit tests.
contrib tests +1. The patch passed contrib unit tests.
Test results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1628/testReport/
Findbugs warnings: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1628/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1628/artifact/trunk/build/test/checkstyle-errors.html
Console output: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1628/console
This message is automatically generated.
> Memcache flush flushing every 60 secs with out considering the max memcache size
> --------------------------------------------------------------------------------
>
> Key: HADOOP-2621
> URL: https://issues.apache.org/jira/browse/HADOOP-2621
> Project: Hadoop
> Issue Type: Bug
> Components: contrib/hbase
> Reporter: Billy Pearson
> Assignee: stack
> Fix For: 0.16.0
>
> Attachments: optionalcacheflushinterval.patch
>
>
> looks like hbase is flushing all memcache to disk every 60 secs causing a lot of work for the compactor to keep up because column gets its own mapfile and every region is flushed at one time. This could be a vary large number of mapfiles to write if a region server is hosting 100 regions all with milti columns.
> Idea memcache flush
> keep all data in memory until memcache get larger then the conf size with hbase.hregion.memcache.flush.size.
> When we reach this size we should flush the regions that are the largest first stopping once we drop back below the memcache max size maybe 20% below the max. This will to flush only as needed as each flush takes time to compact when compaction runs on a region. while we are flushing a region we should also be blocking new updates from happening on that region so the region server does not get over ran when a high update load hits a region server. By only blocking on the region we are flushing at that time other regions will still be able to do updates this.
> We we still want to use the hbase.regionserver.optionalcacheflushinterval we should set to to run once an hour so something like that so we can recover memory from the memcache on region that do not have a lot updates in memory. But running at the default set now of 60 secs is not so good for the compactor if it has many regions to handle also not good for a scanner to have to scan many small files vs a few larger ones
> Example a compactor may take 15 mins to compact a region in that time we will flush 15 times causeing all other regions to get a new mapfile to compact when it becomes it turn to get compacted if you had many regions getting compacted the last one on the list of say 10 regions would have 10 regions * 15 mins each = 150 mapfiles for each column in the last region written before the compactor can get to it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2621) Memcache flush flushing every 60
secs with out considering the max memcache size
Posted by "Jim Kellerman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559660#action_12559660 ]
Jim Kellerman commented on HADOOP-2621:
---------------------------------------
You can configure the memcache flush size by setting the config parameter "hbase.hregion.memcache.flush.size" the default is 64M.
When a HRegion reaches this threshold, it will call for a cache flush.
If the cache is flushed, a request is queued to determine if a compaction is necessary.
If a compaction is done, then a request is queued to determine if the region needs to be split.
> Memcache flush flushing every 60 secs with out considering the max memcache size
> --------------------------------------------------------------------------------
>
> Key: HADOOP-2621
> URL: https://issues.apache.org/jira/browse/HADOOP-2621
> Project: Hadoop
> Issue Type: Bug
> Components: contrib/hbase
> Reporter: Billy Pearson
> Fix For: 0.16.0
>
>
> looks like hbase is flushing all memcache to disk every 60 secs causing a lot of work for the compactor to keep up because column gets its own mapfile and every region is flushed at one time. This could be a vary large number of mapfiles to write if a region server is hosting 100 regions all with milti columns.
> Idea memcache flush
> keep all data in memory until memcache get larger then the conf size with hbase.hregion.memcache.flush.size.
> When we reach this size we should flush the regions that are the largest first stopping once we drop back below the memcache max size maybe 20% below the max. This will to flush only as needed as each flush takes time to compact when compaction runs on a region. while we are flushing a region we should also be blocking new updates from happening on that region so the region server does not get over ran when a high update load hits a region server. By only blocking on the region we are flushing at that time other regions will still be able to do updates this.
> We we still want to use the hbase.regionserver.optionalcacheflushinterval we should set to to run once an hour so something like that so we can recover memory from the memcache on region that do not have a lot updates in memory. But running at the default set now of 60 secs is not so good for the compactor if it has many regions to handle also not good for a scanner to have to scan many small files vs a few larger ones
> Example a compactor may take 15 mins to compact a region in that time we will flush 15 times causeing all other regions to get a new mapfile to compact when it becomes it turn to get compacted if you had many regions getting compacted the last one on the list of say 10 regions would have 10 regions * 15 mins each = 150 mapfiles for each column in the last region written before the compactor can get to it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2621) Memcache flush flushing every 60 secs
with out considering the max memcache size
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-2621:
--------------------------
Status: Patch Available (was: Open)
Passing to hudson.
> Memcache flush flushing every 60 secs with out considering the max memcache size
> --------------------------------------------------------------------------------
>
> Key: HADOOP-2621
> URL: https://issues.apache.org/jira/browse/HADOOP-2621
> Project: Hadoop
> Issue Type: Bug
> Components: contrib/hbase
> Reporter: Billy Pearson
> Fix For: 0.16.0
>
> Attachments: optionalcacheflushinterval.patch
>
>
> looks like hbase is flushing all memcache to disk every 60 secs causing a lot of work for the compactor to keep up because column gets its own mapfile and every region is flushed at one time. This could be a vary large number of mapfiles to write if a region server is hosting 100 regions all with milti columns.
> Idea memcache flush
> keep all data in memory until memcache get larger then the conf size with hbase.hregion.memcache.flush.size.
> When we reach this size we should flush the regions that are the largest first stopping once we drop back below the memcache max size maybe 20% below the max. This will to flush only as needed as each flush takes time to compact when compaction runs on a region. while we are flushing a region we should also be blocking new updates from happening on that region so the region server does not get over ran when a high update load hits a region server. By only blocking on the region we are flushing at that time other regions will still be able to do updates this.
> We we still want to use the hbase.regionserver.optionalcacheflushinterval we should set to to run once an hour so something like that so we can recover memory from the memcache on region that do not have a lot updates in memory. But running at the default set now of 60 secs is not so good for the compactor if it has many regions to handle also not good for a scanner to have to scan many small files vs a few larger ones
> Example a compactor may take 15 mins to compact a region in that time we will flush 15 times causeing all other regions to get a new mapfile to compact when it becomes it turn to get compacted if you had many regions getting compacted the last one on the list of say 10 regions would have 10 regions * 15 mins each = 150 mapfiles for each column in the last region written before the compactor can get to it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2621) Memcache flush flushing every 60
secs with out considering the max memcache size
Posted by "Jim Kellerman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559586#action_12559586 ]
Jim Kellerman commented on HADOOP-2621:
---------------------------------------
There is an "optional cache flush period" which will cause the cache to be flushed every N seconds provided the memcache is not empty. If it is forcing too many cache flushes, adjusting this parameter may solve the problem.
The config parameter's name is 'hbase.regionserver.optionalcacheflushinterval' the default interval is 60 seconds. Units are in milliseconds.
> Memcache flush flushing every 60 secs with out considering the max memcache size
> --------------------------------------------------------------------------------
>
> Key: HADOOP-2621
> URL: https://issues.apache.org/jira/browse/HADOOP-2621
> Project: Hadoop
> Issue Type: Bug
> Components: contrib/hbase
> Reporter: Billy Pearson
> Fix For: 0.16.0
>
>
> looks like hbase is flushing all memcache to disk every 60 secs causing a lot of work for the compactor to keep up because column gets its own mapfile and every region is flushed at one time. This could be a vary large number of mapfiles to write if a region server is hosting 100 regions all with milti columns.
> Idea memcache flush
> keep all data in memory until memcache get larger then the conf size with hbase.hregion.memcache.flush.size.
> When we reach this size we should flush the regions that are the largest first stopping once we drop back below the memcache max size maybe 20% below the max. This will to flush only as needed as each flush takes time to compact when compaction runs on a region. while we are flushing a region we should also be blocking new updates from happening on that region so the region server does not get over ran when a high update load hits a region server. By only blocking on the region we are flushing at that time other regions will still be able to do updates this.
> We we still want to use the hbase.regionserver.optionalcacheflushinterval we should set to to run once an hour so something like that so we can recover memory from the memcache on region that do not have a lot updates in memory. But running at the default set now of 60 secs is not so good for the compactor if it has many regions to handle also not good for a scanner to have to scan many small files vs a few larger ones
> Example a compactor may take 15 mins to compact a region in that time we will flush 15 times causeing all other regions to get a new mapfile to compact when it becomes it turn to get compacted if you had many regions getting compacted the last one on the list of say 10 regions would have 10 regions * 15 mins each = 150 mapfiles for each column in the last region written before the compactor can get to it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2621) Memcache flush flushing every 60 secs
with out considering the max memcache size
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-2621:
--------------------------
Attachment: optionalcacheflushinterval.patch
Change the optionalcacheflushinterval default from one minute to 30. One minute is broke when under any kind of loading. Gets in the way of flushes triggered by sizes.
Make HADOOP-2636 so flushing gets a review. Doesn't seem too smart at the moment.
> Memcache flush flushing every 60 secs with out considering the max memcache size
> --------------------------------------------------------------------------------
>
> Key: HADOOP-2621
> URL: https://issues.apache.org/jira/browse/HADOOP-2621
> Project: Hadoop
> Issue Type: Bug
> Components: contrib/hbase
> Reporter: Billy Pearson
> Fix For: 0.16.0
>
> Attachments: optionalcacheflushinterval.patch
>
>
> looks like hbase is flushing all memcache to disk every 60 secs causing a lot of work for the compactor to keep up because column gets its own mapfile and every region is flushed at one time. This could be a vary large number of mapfiles to write if a region server is hosting 100 regions all with milti columns.
> Idea memcache flush
> keep all data in memory until memcache get larger then the conf size with hbase.hregion.memcache.flush.size.
> When we reach this size we should flush the regions that are the largest first stopping once we drop back below the memcache max size maybe 20% below the max. This will to flush only as needed as each flush takes time to compact when compaction runs on a region. while we are flushing a region we should also be blocking new updates from happening on that region so the region server does not get over ran when a high update load hits a region server. By only blocking on the region we are flushing at that time other regions will still be able to do updates this.
> We we still want to use the hbase.regionserver.optionalcacheflushinterval we should set to to run once an hour so something like that so we can recover memory from the memcache on region that do not have a lot updates in memory. But running at the default set now of 60 secs is not so good for the compactor if it has many regions to handle also not good for a scanner to have to scan many small files vs a few larger ones
> Example a compactor may take 15 mins to compact a region in that time we will flush 15 times causeing all other regions to get a new mapfile to compact when it becomes it turn to get compacted if you had many regions getting compacted the last one on the list of say 10 regions would have 10 regions * 15 mins each = 150 mapfiles for each column in the last region written before the compactor can get to it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HADOOP-2621) Memcache flush flushing every 60
secs with out considering the max memcache size
Posted by "Jim Kellerman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Kellerman reassigned HADOOP-2621:
-------------------------------------
Assignee: stack
> Memcache flush flushing every 60 secs with out considering the max memcache size
> --------------------------------------------------------------------------------
>
> Key: HADOOP-2621
> URL: https://issues.apache.org/jira/browse/HADOOP-2621
> Project: Hadoop
> Issue Type: Bug
> Components: contrib/hbase
> Reporter: Billy Pearson
> Assignee: stack
> Fix For: 0.16.0
>
> Attachments: optionalcacheflushinterval.patch
>
>
> looks like hbase is flushing all memcache to disk every 60 secs causing a lot of work for the compactor to keep up because column gets its own mapfile and every region is flushed at one time. This could be a vary large number of mapfiles to write if a region server is hosting 100 regions all with milti columns.
> Idea memcache flush
> keep all data in memory until memcache get larger then the conf size with hbase.hregion.memcache.flush.size.
> When we reach this size we should flush the regions that are the largest first stopping once we drop back below the memcache max size maybe 20% below the max. This will to flush only as needed as each flush takes time to compact when compaction runs on a region. while we are flushing a region we should also be blocking new updates from happening on that region so the region server does not get over ran when a high update load hits a region server. By only blocking on the region we are flushing at that time other regions will still be able to do updates this.
> We we still want to use the hbase.regionserver.optionalcacheflushinterval we should set to to run once an hour so something like that so we can recover memory from the memcache on region that do not have a lot updates in memory. But running at the default set now of 60 secs is not so good for the compactor if it has many regions to handle also not good for a scanner to have to scan many small files vs a few larger ones
> Example a compactor may take 15 mins to compact a region in that time we will flush 15 times causeing all other regions to get a new mapfile to compact when it becomes it turn to get compacted if you had many regions getting compacted the last one on the list of say 10 regions would have 10 regions * 15 mins each = 150 mapfiles for each column in the last region written before the compactor can get to it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.