[jira] [Commented] (HBASE-11341) ZKProcedureCoordinatorRpcs should respond only to members
[
https://issues.apache.org/jira/browse/HBASE-11341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031481#comment-14031481
]
Matteo Bertozzi commented on HBASE-11341:
-
{quote}It does not listen for create event on /hbase/proc/reached/instance.
Does it sound right?{quote}
no, in ZKProcedureCoordinatorRpcs.start() we are watching the acquired,
reached, abort znodes and then on nodeCreate() we dispatch the events to
the right Procedure.
https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/procedure/ZKProcedureMemberRpcs.java#L74
https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/procedure/ZKProcedureUtil.java#L88
ZKProcedureCoordinatorRpcs should respond only to members
-
Key: HBASE-11341
URL: https://issues.apache.org/jira/browse/HBASE-11341
Project: HBase
Issue Type: Bug
Affects Versions: 0.99.0, 0.94.20, 0.98.3
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Minor
Fix For: 0.99.0, 0.94.21, 0.98.4
Attachments: HBASE-11341-v0.patch
ZKProcedureCoordinatorRpcs nodeCreated() responds to events of every znode
under the procedure and not only members.
{code}
INFO: Received created event: /hbase/proc/reached/instance
INFO: Received created event: /hbase/proc/reached/instance/member
{code}
the result is a warning (no other side effects)
{code}
WARN [main-EventThread] procedure.ProcedureCoordinator: Member 'instance'
is trying to release an unknown procedure 'reached
{code}
[~apurtell] posted in HBASE-10926 the steps to reproduce it:
{noformat}
$ cd ./src/hbase
$ git checkout master
$ mvn -DskipTests clean install
{noformat}
In one console:
{noformat}
$ ./bin/hbase master start
{noformat}
In another console:
{noformat}
$ ./bin/hbase org.apache.hadoop.hbase.util.LoadTestTool -num_keys 10 \
-read 10:100 -write 1:100:10
{noformat}
In a third console:
{noformat}
$ ./bin/hbase shell
hbase while true do ; flush 'cluster_test' ; sleep 10 ; end
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11322) SnapshotHFileCleaner makes the wrong check for lastModified time thus causing too many cache refreshes
[
https://issues.apache.org/jira/browse/HBASE-11322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031482#comment-14031482
]
Lars Hofhansl commented on HBASE-11322:
---
This is quite different in trunk. Not sure offhand whether it's correct there
or not.
SnapshotHFileCleaner makes the wrong check for lastModified time thus causing
too many cache refreshes
--
Key: HBASE-11322
URL: https://issues.apache.org/jira/browse/HBASE-11322
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.19
Reporter: churro morales
Assignee: churro morales
Priority: Critical
Fix For: 0.94.21
Attachments: 11322.94.txt, HBASE-11322.patch
The SnapshotHFileCleaner calls the SnapshotFileCache if a particular HFile in
question is part of a snapshot.
If the HFile is not in the cache, we then refresh the cache and check again.
But the cache refresh checks to see if anything has been modified since the
last cache refresh but this logic is incorrect in certain scenarios.
The last modified time is done via this operation:
{code}
this.lastModifiedTime = Math.min(dirStatus.getModificationTime(),
tempStatus.getModificationTime());
{code}
and the check to see if the snapshot directories have been modified:
{code}
// if the snapshot directory wasn't modified since we last check, we are done
if (dirStatus.getModificationTime() = lastModifiedTime
tempStatus.getModificationTime() = lastModifiedTime) {
return;
}
{code}
Suppose the following happens:
dirStatus modified 6-1-2014
tempStatus modified 6-2-2014
lastModifiedTime = 6-1-2014
provided these two directories don't get modified again all subsequent checks
wont exit early, like they should.
In our cluster, this was a huge performance hit. The cleaner chain fell
behind, thus almost filling up dfs and our namenode heap.
Its a simple fix, instead of Math.min we use Math.max for the lastModified, I
believe that will be correct.
I'll apply a patch for you guys.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11322) SnapshotHFileCleaner makes the wrong check for lastModified time thus causing too many cache refreshes
[
https://issues.apache.org/jira/browse/HBASE-11322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031486#comment-14031486
]
churro morales commented on HBASE-11322:
Hi Lars,
That is correct, but maybe I'm missing something with the Math.max solution.
Provided that if we say lastModifiedTime is the greater of the two modified
times for the directories in question.
And we say that when doing any given check, the maximum value that
lastModifiedTime can have is the current timestamp.
Then, if any of the directories is modified between the current check and the
next subsequent check in the future. Their respective modified times must be
larger than the previous lastModifiedTime variable as long as the next check
happens in the future.
On the other hand maybe its late and I'm not thinking of a condition where this
could be incorrect.
We applied the patch in production today and the cleaner could finally keep up
without us having to manually step in and delete files manually from the
archive directory. Our namenode was finally happy and we stopped running out
of dfs disk space.
SnapshotHFileCleaner makes the wrong check for lastModified time thus causing
too many cache refreshes
--
Key: HBASE-11322
URL: https://issues.apache.org/jira/browse/HBASE-11322
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.19
Reporter: churro morales
Assignee: churro morales
Priority: Critical
Fix For: 0.94.21
Attachments: 11322.94.txt, HBASE-11322.patch
The SnapshotHFileCleaner calls the SnapshotFileCache if a particular HFile in
question is part of a snapshot.
If the HFile is not in the cache, we then refresh the cache and check again.
But the cache refresh checks to see if anything has been modified since the
last cache refresh but this logic is incorrect in certain scenarios.
The last modified time is done via this operation:
{code}
this.lastModifiedTime = Math.min(dirStatus.getModificationTime(),
tempStatus.getModificationTime());
{code}
and the check to see if the snapshot directories have been modified:
{code}
// if the snapshot directory wasn't modified since we last check, we are done
if (dirStatus.getModificationTime() = lastModifiedTime
tempStatus.getModificationTime() = lastModifiedTime) {
return;
}
{code}
Suppose the following happens:
dirStatus modified 6-1-2014
tempStatus modified 6-2-2014
lastModifiedTime = 6-1-2014
provided these two directories don't get modified again all subsequent checks
wont exit early, like they should.
In our cluster, this was a huge performance hit. The cleaner chain fell
behind, thus almost filling up dfs and our namenode heap.
Its a simple fix, instead of Math.min we use Math.max for the lastModified, I
believe that will be correct.
I'll apply a patch for you guys.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11322) SnapshotHFileCleaner makes the wrong check for lastModified time thus causing too many cache refreshes
[
https://issues.apache.org/jira/browse/HBASE-11322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031487#comment-14031487
]
churro morales commented on HBASE-11322:
I believe if you can take the Math.max instead of the Math.min in trunk and it
would work as well. I looked over it quickly but I think that will work too
SnapshotHFileCleaner makes the wrong check for lastModified time thus causing
too many cache refreshes
--
Key: HBASE-11322
URL: https://issues.apache.org/jira/browse/HBASE-11322
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.19
Reporter: churro morales
Assignee: churro morales
Priority: Critical
Fix For: 0.94.21
Attachments: 11322.94.txt, HBASE-11322.patch
The SnapshotHFileCleaner calls the SnapshotFileCache if a particular HFile in
question is part of a snapshot.
If the HFile is not in the cache, we then refresh the cache and check again.
But the cache refresh checks to see if anything has been modified since the
last cache refresh but this logic is incorrect in certain scenarios.
The last modified time is done via this operation:
{code}
this.lastModifiedTime = Math.min(dirStatus.getModificationTime(),
tempStatus.getModificationTime());
{code}
and the check to see if the snapshot directories have been modified:
{code}
// if the snapshot directory wasn't modified since we last check, we are done
if (dirStatus.getModificationTime() = lastModifiedTime
tempStatus.getModificationTime() = lastModifiedTime) {
return;
}
{code}
Suppose the following happens:
dirStatus modified 6-1-2014
tempStatus modified 6-2-2014
lastModifiedTime = 6-1-2014
provided these two directories don't get modified again all subsequent checks
wont exit early, like they should.
In our cluster, this was a huge performance hit. The cleaner chain fell
behind, thus almost filling up dfs and our namenode heap.
Its a simple fix, instead of Math.min we use Math.max for the lastModified, I
believe that will be correct.
I'll apply a patch for you guys.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11347) For some errors, the client can retry infinitely
[ https://issues.apache.org/jira/browse/HBASE-11347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-11347: Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to master 0.98 branches, thanks for the review, Ted and Lars. For some errors, the client can retry infinitely Key: HBASE-11347 URL: https://issues.apache.org/jira/browse/HBASE-11347 Project: HBase Issue Type: Bug Components: Client Affects Versions: 0.99.0, 0.98.3 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Priority: Critical Fix For: 0.99.0, 0.98.4 Attachments: 11347.v1.patch As the title says... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11273) Fix jersey and slf4j deps
[ https://issues.apache.org/jira/browse/HBASE-11273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031499#comment-14031499 ] Nicolas Liochon commented on HBASE-11273: - Committed, (without a hadoop-qa run, but seems to work locally). Thanks for the review, Stack. Fix jersey and slf4j deps - Key: HBASE-11273 URL: https://issues.apache.org/jira/browse/HBASE-11273 Project: HBase Issue Type: Bug Affects Versions: 0.99.0 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Priority: Minor Fix For: 0.99.0 Attachments: 11273.v1.patch Hadoop 2.4 wants newer version than us, it's always dangerous to downgrade 3rd parties versions... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11273) Fix jersey and slf4j deps
[ https://issues.apache.org/jira/browse/HBASE-11273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-11273: Resolution: Fixed Release Note: Committed, (without a hadoop-qa run, but seems to work locally). Thanks for the review, Stack. Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Fix jersey and slf4j deps - Key: HBASE-11273 URL: https://issues.apache.org/jira/browse/HBASE-11273 Project: HBase Issue Type: Bug Affects Versions: 0.99.0 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Priority: Minor Fix For: 0.99.0 Attachments: 11273.v1.patch Hadoop 2.4 wants newer version than us, it's always dangerous to downgrade 3rd parties versions... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11273) Fix jersey and slf4j deps
[ https://issues.apache.org/jira/browse/HBASE-11273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-11273: Release Note: (was: Committed, (without a hadoop-qa run, but seems to work locally). Thanks for the review, Stack.) Fix jersey and slf4j deps - Key: HBASE-11273 URL: https://issues.apache.org/jira/browse/HBASE-11273 Project: HBase Issue Type: Bug Affects Versions: 0.99.0 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Priority: Minor Fix For: 0.99.0 Attachments: 11273.v1.patch Hadoop 2.4 wants newer version than us, it's always dangerous to downgrade 3rd parties versions... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-8315) Documentation should have more information of LRU Stats
[
https://issues.apache.org/jira/browse/HBASE-8315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031509#comment-14031509
]
Daisuke Kobayashi commented on HBASE-8315:
--
Thanks [~stack] and [~misty]!
Documentation should have more information of LRU Stats
---
Key: HBASE-8315
URL: https://issues.apache.org/jira/browse/HBASE-8315
Project: HBase
Issue Type: Improvement
Components: documentation
Affects Versions: 0.95.0
Reporter: Daisuke Kobayashi
Assignee: Misty Stanley-Jones
Labels: documentation
Fix For: 0.99.0
Attachments: 8351.txt, Screen Shot 2014-06-13 at 10.59.05 AM.png
Unfortunately, there's no documentation to explain the meaning of each LRU
Stats in the regionserver logs. So this is for creating a new paragraph
regarding this. My current idea is below, but it's a little bit difficult to
explain the difference between 'cachingAccesses' and 'accesses' from an
administrator or a user views.
Could you guys help to improve the content?
{noformat}
total: The current memory size of the cache in use.
free: The total free memory currently available to store more cache entries.
max: Maximum allowed memory size of the cache.
blocks: Caches store blocks of data; this number is the current # of blocks
stored, which use up the total memory space.
accesses: The total number of times the cache was accessed, regardless of
result.
hits: The total number of times the cache was accessed and the result was a
successful hit (presence of looked up element in cache is a hit).
hitRatio: The current percentage for hits / accesses.
Unclear:
cachingAccesses: cachingHits + The number of getBlock requests that were
cache misses, but only from requests that were set to use the block cache.
cachingHits: The number of getBlock requests that were cache hits, but only
from requests that were set to use the block cache. This is because all reads
=
cachingHitsRatio: The current percentage for cachintHits / cachingAccesses
evictions: The total number of times an eviction has occurred (based on the
use of the LRU algorithm)
evicted: The total number of blocks that have been evicted (based on the use
of the LRU algorithm)
evictedPerRun: The total number of blocks that have been evicted overall /
The number of times an eviction has occurred overall
{noformat}
And also, where should we add this paragraph in the documentation?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-10771) Primitive type put/get APIs in ByteRange
[ https://issues.apache.org/jira/browse/HBASE-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031519#comment-14031519 ] Anoop Sam John commented on HBASE-10771: bq.Where do you confirm that the long and int writing is same as BBs Just wrote a test to confirm. I write using BR API and create a BB wrapping the byte[] and do read back using BB APIs. Looks good. Will add that test case also on commit. bq. You should note in the implementations that they are equivalent in a comment on commit. Sure. Primitive type put/get APIs in ByteRange - Key: HBASE-10771 URL: https://issues.apache.org/jira/browse/HBASE-10771 Project: HBase Issue Type: Improvement Reporter: Anoop Sam John Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-10771.patch, HBASE-10771_V2.patch, HBASE-10771_V3.patch, HBASE-10771_V4.patch While doing HBASE-10713 I came across the need to write int/long (and read also) from a ByteRange. CellBlocks are backed by ByteRange. So we can add such APIs. Also as per HBASE-10750 we return a ByteRange from MSLAB and also discussion under HBASE-10191 suggest we can have BR backed HFileBlocks etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11347) For some errors, the client can retry infinitely
[ https://issues.apache.org/jira/browse/HBASE-11347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031536#comment-14031536 ] Hudson commented on HBASE-11347: SUCCESS: Integrated in HBase-TRUNK #5204 (See [https://builds.apache.org/job/HBase-TRUNK/5204/]) HBASE-11347 For some errors, the client can retry infinitely (liochon: rev 3fa92647d24dc87cc958b33c5becd8dda16d1326) * hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncProcess.java * hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestAsyncProcess.java For some errors, the client can retry infinitely Key: HBASE-11347 URL: https://issues.apache.org/jira/browse/HBASE-11347 Project: HBase Issue Type: Bug Components: Client Affects Versions: 0.99.0, 0.98.3 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Priority: Critical Fix For: 0.99.0, 0.98.4 Attachments: 11347.v1.patch As the title says... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11347) For some errors, the client can retry infinitely
[ https://issues.apache.org/jira/browse/HBASE-11347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031543#comment-14031543 ] Hudson commented on HBASE-11347: SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #318 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/318/]) HBASE-11347 For some errors, the client can retry infinitely (liochon: rev 9ce175146f4dd8ad984eac69819d8cd375368e61) * hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncProcess.java * hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestAsyncProcess.java For some errors, the client can retry infinitely Key: HBASE-11347 URL: https://issues.apache.org/jira/browse/HBASE-11347 Project: HBase Issue Type: Bug Components: Client Affects Versions: 0.99.0, 0.98.3 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Priority: Critical Fix For: 0.99.0, 0.98.4 Attachments: 11347.v1.patch As the title says... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11347) For some errors, the client can retry infinitely
[ https://issues.apache.org/jira/browse/HBASE-11347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031544#comment-14031544 ] Hudson commented on HBASE-11347: SUCCESS: Integrated in HBase-0.98 #337 (See [https://builds.apache.org/job/HBase-0.98/337/]) HBASE-11347 For some errors, the client can retry infinitely (liochon: rev 9ce175146f4dd8ad984eac69819d8cd375368e61) * hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncProcess.java * hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestAsyncProcess.java For some errors, the client can retry infinitely Key: HBASE-11347 URL: https://issues.apache.org/jira/browse/HBASE-11347 Project: HBase Issue Type: Bug Components: Client Affects Versions: 0.99.0, 0.98.3 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Priority: Critical Fix For: 0.99.0, 0.98.4 Attachments: 11347.v1.patch As the title says... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11273) Fix jersey and slf4j deps
[ https://issues.apache.org/jira/browse/HBASE-11273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031562#comment-14031562 ] Hudson commented on HBASE-11273: SUCCESS: Integrated in HBase-TRUNK #5205 (See [https://builds.apache.org/job/HBase-TRUNK/5205/]) HBASE-11273 Fix jersey and slf4j deps (liochon: rev 047463c278e53f03a2005a6ba208fb3fbbe8db78) * pom.xml Fix jersey and slf4j deps - Key: HBASE-11273 URL: https://issues.apache.org/jira/browse/HBASE-11273 Project: HBase Issue Type: Bug Affects Versions: 0.99.0 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Priority: Minor Fix For: 0.99.0 Attachments: 11273.v1.patch Hadoop 2.4 wants newer version than us, it's always dangerous to downgrade 3rd parties versions... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11353) Wrong Write Request Count
Nicolas Liochon created HBASE-11353: --- Summary: Wrong Write Request Count Key: HBASE-11353 URL: https://issues.apache.org/jira/browse/HBASE-11353 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.98.3, 0.99.0 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Fix For: 0.99.0, 0.98.4 See title... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11353) Wrong Write Request Count
[ https://issues.apache.org/jira/browse/HBASE-11353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-11353: Attachment: 11353.v1.patch Wrong Write Request Count - Key: HBASE-11353 URL: https://issues.apache.org/jira/browse/HBASE-11353 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.99.0, 0.98.3 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Fix For: 0.99.0, 0.98.4 Attachments: 11353.v1.patch See title... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11353) Wrong Write Request Count
[ https://issues.apache.org/jira/browse/HBASE-11353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-11353: Status: Patch Available (was: Open) Wrong Write Request Count - Key: HBASE-11353 URL: https://issues.apache.org/jira/browse/HBASE-11353 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.98.3, 0.99.0 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Fix For: 0.99.0, 0.98.4 Attachments: 11353.v1.patch See title... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11353) Wrong Write Request Count
[
https://issues.apache.org/jira/browse/HBASE-11353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031586#comment-14031586
]
Hadoop QA commented on HBASE-11353:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12650447/11353.v1.patch
against trunk revision .
ATTACHMENT ID: 12650447
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/9774//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/9774//console
This message is automatically generated.
Wrong Write Request Count
-
Key: HBASE-11353
URL: https://issues.apache.org/jira/browse/HBASE-11353
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.99.0, 0.98.3
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
Fix For: 0.99.0, 0.98.4
Attachments: 11353.v1.patch
See title...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11059) ZK-less region assignment
[ https://issues.apache.org/jira/browse/HBASE-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-11059: Resolution: Fixed Status: Resolved (was: Patch Available) Integrated into trunk. Thanks Stack, Jeffrey, and Mikhail a lot for the review and discussion. ZK-less region assignment - Key: HBASE-11059 URL: https://issues.apache.org/jira/browse/HBASE-11059 Project: HBase Issue Type: Improvement Components: master, Region Assignment Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.99.0 Attachments: hbase-11059.patch, hbase-11059_v2.1.patch, hbase-11059_v2.2.patch, hbase-11059_v2.patch, hbase-11059_v3.0.patch, zk-less_am.pdf, zk-less_assignment.png It seems that most people don't like region assignment with ZK (HBASE-5487), which causes many uncertainties. This jira is to support ZK-less region assignment. We need to make sure this patch doesn't break backward compatibility/rolling upgrade. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11323) BucketCache all the time!
[
https://issues.apache.org/jira/browse/HBASE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031609#comment-14031609
]
Anoop Sam John commented on HBASE-11323:
{quote}
bq.block buf refer the offheap memory? So in the read path, the Cells will
refer to this memory?
Yes, that's what I'm suggesting.
{quote}
So we have to make sure the read path having Cell flowing through. (I think
this is mostly done)
And the Cell should be supported being backed by BB. (offheap) We will need new
comparators.
The Cell interface is having get***Array() APIs which return byte[]. We use
them for the compare. When the Cells are backed by BB, calling these APIs will
need us to create temp byte[] objects and copying. Need ways to solve this.
BucketCache all the time!
-
Key: HBASE-11323
URL: https://issues.apache.org/jira/browse/HBASE-11323
Project: HBase
Issue Type: Sub-task
Components: io
Reporter: stack
Fix For: 0.99.0
Attachments: ReportBlockCache.pdf
One way to realize the parent issue is to just enable bucket cache all the
time; i.e. always have offheap enabled. Would have to do some work to make
it drop-dead simple on initial setup (I think it doable).
So, upside would be the offheap upsides (less GC, less likely to go away and
never come back because of full GC when heap is large, etc.).
Downside is higher latency. In Nick's BlockCache 101 there is little to no
difference between onheap and offheap. In a basic compare doing scans and
gets -- details to follow -- I have BucketCache deploy about 20% less ops
than LRUBC when all incache and maybe 10% less ops when falling out of cache.
I can't tell difference in means and 95th and 99th are roughly same (more
stable with BucketCache). GC profile is much better with BucketCache -- way
less. BucketCache uses about 7% more user CPU.
More detail on comparison to follow.
I think the numbers disagree enough we should probably do the [~lhofhansl]
suggestion, that we allow you to have a table sit in LRUBC, something the
current bucket cache layout does not do.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11323) BucketCache all the time!
[ https://issues.apache.org/jira/browse/HBASE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031612#comment-14031612 ] Andrew Purtell commented on HBASE-11323: bq. But on creation, it only has Path context... nought else. Yeah when opening a reader we only have the metadata in the HFile, we are disconnected from schema at the HFile level. If you look at the patch for HBASE-9857, there are some TODOs where we have regex constants down in HFile for what should be Store level detail (path and dir layout conventions). We should hook up read side to Store. Possibly we could do that by adding a method HFileContext Store#getFileContext(Path) ? Would set up a context with schema and flags based on the Store level knowledge of what the Path encodes. BucketCache all the time! - Key: HBASE-11323 URL: https://issues.apache.org/jira/browse/HBASE-11323 Project: HBase Issue Type: Sub-task Components: io Reporter: stack Fix For: 0.99.0 Attachments: ReportBlockCache.pdf One way to realize the parent issue is to just enable bucket cache all the time; i.e. always have offheap enabled. Would have to do some work to make it drop-dead simple on initial setup (I think it doable). So, upside would be the offheap upsides (less GC, less likely to go away and never come back because of full GC when heap is large, etc.). Downside is higher latency. In Nick's BlockCache 101 there is little to no difference between onheap and offheap. In a basic compare doing scans and gets -- details to follow -- I have BucketCache deploy about 20% less ops than LRUBC when all incache and maybe 10% less ops when falling out of cache. I can't tell difference in means and 95th and 99th are roughly same (more stable with BucketCache). GC profile is much better with BucketCache -- way less. BucketCache uses about 7% more user CPU. More detail on comparison to follow. I think the numbers disagree enough we should probably do the [~lhofhansl] suggestion, that we allow you to have a table sit in LRUBC, something the current bucket cache layout does not do. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11323) BucketCache all the time!
[ https://issues.apache.org/jira/browse/HBASE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031616#comment-14031616 ] Andrew Purtell commented on HBASE-11323: We have various results that all indicate _some_ penalty for using the bucket cache, with commensurate improvement in GC related metrics. It can be a trade off well worth making but should not be a global decision. I think we should make combined LRU cache + bucket cache the default, but only if we can have the default placement for data blocks still be on heap and plumb down schema level selection of block placement off heap. Then you can have, on a per CF basis, such strategies as large warm data off heap with block encoding (trade scanning CPU for serde/copying costs) and smaller hot data on heap with no encoding. At a future time we could have a few caching strategies like this automatically managed by ergonomics. BucketCache all the time! - Key: HBASE-11323 URL: https://issues.apache.org/jira/browse/HBASE-11323 Project: HBase Issue Type: Sub-task Components: io Reporter: stack Fix For: 0.99.0 Attachments: ReportBlockCache.pdf One way to realize the parent issue is to just enable bucket cache all the time; i.e. always have offheap enabled. Would have to do some work to make it drop-dead simple on initial setup (I think it doable). So, upside would be the offheap upsides (less GC, less likely to go away and never come back because of full GC when heap is large, etc.). Downside is higher latency. In Nick's BlockCache 101 there is little to no difference between onheap and offheap. In a basic compare doing scans and gets -- details to follow -- I have BucketCache deploy about 20% less ops than LRUBC when all incache and maybe 10% less ops when falling out of cache. I can't tell difference in means and 95th and 99th are roughly same (more stable with BucketCache). GC profile is much better with BucketCache -- way less. BucketCache uses about 7% more user CPU. More detail on comparison to follow. I think the numbers disagree enough we should probably do the [~lhofhansl] suggestion, that we allow you to have a table sit in LRUBC, something the current bucket cache layout does not do. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11059) ZK-less region assignment
[ https://issues.apache.org/jira/browse/HBASE-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031637#comment-14031637 ] Hudson commented on HBASE-11059: SUCCESS: Integrated in HBase-TRUNK #5206 (See [https://builds.apache.org/job/HBase-TRUNK/5206/]) HBASE-11059 ZK-less region assignment (jxiang: rev 58549428a66550aed83bfb6f1da405decc1b0f61) * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestZKLessSplitOnCluster.java * hbase-server/src/test/java/org/apache/hadoop/hbase/master/MockRegionServer.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/RegionStates.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterRpcServices.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionMergeTransactionOnCluster.java * hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransactionOnCluster.java * hbase-client/src/main/java/org/apache/hadoop/hbase/catalog/MetaReader.java * hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestMasterFailover.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/RegionStateStore.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/ServerManager.java * hbase-server/src/main/java/org/apache/hadoop/hbase/util/ConfigUtil.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerNoMaster.java * hbase-client/src/main/java/org/apache/hadoop/hbase/HRegionInfo.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/handler/ServerShutdownHandler.java * hbase-client/src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWatcher.java * hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestZKLessAMOnCluster.java * hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsck.java * hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManagerOnCluster.java * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/RegionServerStatusProtos.java * hbase-protocol/src/main/protobuf/RegionServerStatus.proto * hbase-client/src/main/java/org/apache/hadoop/hbase/master/RegionState.java * hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestOpenedRegionHandler.java * hbase-client/src/main/java/org/apache/hadoop/hbase/RegionLoad.java * hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestScannersFromClientSide.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/handler/CloseRegionHandler.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionServerServices.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/handler/OpenRegionHandler.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionMergeTransaction.java * hbase-server/src/test/java/org/apache/hadoop/hbase/zookeeper/TestRecoverableZooKeeper.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/handler/TestCloseRegionHandler.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestEndToEndSplitTransaction.java * hbase-server/src/test/java/org/apache/hadoop/hbase/TestDrainingServer.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/handler/TestOpenRegionHandler.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/UnAssignCallable.java * hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestZKBasedOpenCloseRegion.java * hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestRestartCluster.java * hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManager.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * hbase-server/src/test/java/org/apache/hadoop/hbase/MockRegionServerServices.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/SplitTransaction.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignCallable.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestZKLessMergeOnCluster.java ZK-less region assignment - Key: HBASE-11059 URL: https://issues.apache.org/jira/browse/HBASE-11059 Project: HBase Issue Type: Improvement Components: master, Region Assignment Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.99.0 Attachments: hbase-11059.patch, hbase-11059_v2.1.patch, hbase-11059_v2.2.patch, hbase-11059_v2.patch, hbase-11059_v3.0.patch, zk-less_am.pdf, zk-less_assignment.png It seems that most people don't like region assignment with ZK (HBASE-5487), which causes many uncertainties. This jira is to support ZK-less region
[jira] [Resolved] (HBASE-11309) Remove USE_POSITION_BEFORE and related code from PrefixTreeSeeker
[ https://issues.apache.org/jira/browse/HBASE-11309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu resolved HBASE-11309. Resolution: Later Remove USE_POSITION_BEFORE and related code from PrefixTreeSeeker - Key: HBASE-11309 URL: https://issues.apache.org/jira/browse/HBASE-11309 Project: HBase Issue Type: Task Reporter: Ted Yu Priority: Trivial This constant is always false in PrefixTreeSeeker. We can remove this variable and the code depending on this boolean to be true. Thanks to Matt Corgan who confirmed the above. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10771) Primitive type put/get APIs in ByteRange
[ https://issues.apache.org/jira/browse/HBASE-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031697#comment-14031697 ] stack commented on HBASE-10771: --- Still +1 on commit. You can add the notes on commit [~anoop.hbase] Primitive type put/get APIs in ByteRange - Key: HBASE-10771 URL: https://issues.apache.org/jira/browse/HBASE-10771 Project: HBase Issue Type: Improvement Reporter: Anoop Sam John Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-10771.patch, HBASE-10771_V2.patch, HBASE-10771_V3.patch, HBASE-10771_V4.patch While doing HBASE-10713 I came across the need to write int/long (and read also) from a ByteRange. CellBlocks are backed by ByteRange. So we can add such APIs. Also as per HBASE-10750 we return a ByteRange from MSLAB and also discussion under HBASE-10191 suggest we can have BR backed HFileBlocks etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11353) Wrong Write Request Count
[ https://issues.apache.org/jira/browse/HBASE-11353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031696#comment-14031696 ] stack commented on HBASE-11353: --- +1 Funny we've never had a test like the one you add here. Wrong Write Request Count - Key: HBASE-11353 URL: https://issues.apache.org/jira/browse/HBASE-11353 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.99.0, 0.98.3 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Fix For: 0.99.0, 0.98.4 Attachments: 11353.v1.patch See title... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11350) [PE] Allow random value size
[ https://issues.apache.org/jira/browse/HBASE-11350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-11350: -- Resolution: Fixed Fix Version/s: 0.99.0 Status: Resolved (was: Patch Available) Committed this small addition to PE that no one but [~ndimiduk] cares about I'd say. [PE] Allow random value size Key: HBASE-11350 URL: https://issues.apache.org/jira/browse/HBASE-11350 Project: HBase Issue Type: Improvement Components: Performance Reporter: stack Assignee: stack Fix For: 0.99.0 Attachments: 11348.txt Allow PE to write random value sizes. Helpful mimic'ing 'real' sizings. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11323) BucketCache all the time!
[ https://issues.apache.org/jira/browse/HBASE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031717#comment-14031717 ] stack commented on HBASE-11323: --- [~anoop.hbase] I'll take a look sir. BucketCache all the time! - Key: HBASE-11323 URL: https://issues.apache.org/jira/browse/HBASE-11323 Project: HBase Issue Type: Sub-task Components: io Reporter: stack Fix For: 0.99.0 Attachments: ReportBlockCache.pdf One way to realize the parent issue is to just enable bucket cache all the time; i.e. always have offheap enabled. Would have to do some work to make it drop-dead simple on initial setup (I think it doable). So, upside would be the offheap upsides (less GC, less likely to go away and never come back because of full GC when heap is large, etc.). Downside is higher latency. In Nick's BlockCache 101 there is little to no difference between onheap and offheap. In a basic compare doing scans and gets -- details to follow -- I have BucketCache deploy about 20% less ops than LRUBC when all incache and maybe 10% less ops when falling out of cache. I can't tell difference in means and 95th and 99th are roughly same (more stable with BucketCache). GC profile is much better with BucketCache -- way less. BucketCache uses about 7% more user CPU. More detail on comparison to follow. I think the numbers disagree enough we should probably do the [~lhofhansl] suggestion, that we allow you to have a table sit in LRUBC, something the current bucket cache layout does not do. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11323) BucketCache all the time!
[
https://issues.apache.org/jira/browse/HBASE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031716#comment-14031716
]
stack commented on HBASE-11323:
---
Hm. Maybe I am making this harder than it needs to be (the Lars and now Andrew
ask that it be possible to have tables keep their DATA blocks in LruBlockCache):
The HCD#setInMemory javadoc says:
* @param inMemory True if we are to keep all values in the HRegionServer
cache
So, if I am allowed extrapolate, if a CF has IN_MEMORY set and we are using
CombinedBlockCache -- i.e. LruBC and BucketCache -- then lets just cache the CF
DATA blocks in LruBC too?
This small change is all that is needed:
{code}
diff --git
a/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/CombinedBlockCache.java
b/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/CombinedBlockCache.java
index 7564cc2..23cdf83 100644
---
a/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/CombinedBlockCache.java
+++
b/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/CombinedBlockCache.java
@@ -56,7 +56,7 @@ public class CombinedBlockCache implements BlockCache,
HeapSize {
@Override
public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf, boolean
inMemory) {
boolean isMetaBlock = buf.getBlockType().getCategory() !=
BlockCategory.DATA;
-if (isMetaBlock) {
+if (isMetaBlock || inMemory) {
lruCache.cacheBlock(cacheKey, buf, inMemory);
} else {
bucketCache.cacheBlock(cacheKey, buf, inMemory);
{code}
Running with it, I was able to check it was actually working by looking at the
block cache dump by files. It reports counts of blocks and whether DATA
blocks. Creating a table which is IN_MEMORY has its data blocks got into LruBC.
Of note, hbase:meta and other system tables now will have their DATA blocks up
in LruBC too since they are marked as IN_MEMORY.
If the above is allowed, I'll go through and amend all references to IN_MEMORY
to make note of this expanded definition of its meaning.
BucketCache all the time!
-
Key: HBASE-11323
URL: https://issues.apache.org/jira/browse/HBASE-11323
Project: HBase
Issue Type: Sub-task
Components: io
Reporter: stack
Fix For: 0.99.0
Attachments: ReportBlockCache.pdf
One way to realize the parent issue is to just enable bucket cache all the
time; i.e. always have offheap enabled. Would have to do some work to make
it drop-dead simple on initial setup (I think it doable).
So, upside would be the offheap upsides (less GC, less likely to go away and
never come back because of full GC when heap is large, etc.).
Downside is higher latency. In Nick's BlockCache 101 there is little to no
difference between onheap and offheap. In a basic compare doing scans and
gets -- details to follow -- I have BucketCache deploy about 20% less ops
than LRUBC when all incache and maybe 10% less ops when falling out of cache.
I can't tell difference in means and 95th and 99th are roughly same (more
stable with BucketCache). GC profile is much better with BucketCache -- way
less. BucketCache uses about 7% more user CPU.
More detail on comparison to follow.
I think the numbers disagree enough we should probably do the [~lhofhansl]
suggestion, that we allow you to have a table sit in LRUBC, something the
current bucket cache layout does not do.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11323) BucketCache all the time!
[ https://issues.apache.org/jira/browse/HBASE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031720#comment-14031720 ] Andrew Purtell commented on HBASE-11323: Do we want IN_MEMORY to be synonymous with on heap? I would not want my largish but able to fit collectively in RAM table to require big heaps when I have all this off heap memory available I could take advantage of without risk of long stop the world pauses. BucketCache all the time! - Key: HBASE-11323 URL: https://issues.apache.org/jira/browse/HBASE-11323 Project: HBase Issue Type: Sub-task Components: io Reporter: stack Fix For: 0.99.0 Attachments: ReportBlockCache.pdf One way to realize the parent issue is to just enable bucket cache all the time; i.e. always have offheap enabled. Would have to do some work to make it drop-dead simple on initial setup (I think it doable). So, upside would be the offheap upsides (less GC, less likely to go away and never come back because of full GC when heap is large, etc.). Downside is higher latency. In Nick's BlockCache 101 there is little to no difference between onheap and offheap. In a basic compare doing scans and gets -- details to follow -- I have BucketCache deploy about 20% less ops than LRUBC when all incache and maybe 10% less ops when falling out of cache. I can't tell difference in means and 95th and 99th are roughly same (more stable with BucketCache). GC profile is much better with BucketCache -- way less. BucketCache uses about 7% more user CPU. More detail on comparison to follow. I think the numbers disagree enough we should probably do the [~lhofhansl] suggestion, that we allow you to have a table sit in LRUBC, something the current bucket cache layout does not do. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11323) BucketCache all the time!
[ https://issues.apache.org/jira/browse/HBASE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031721#comment-14031721 ] Andrew Purtell commented on HBASE-11323: On the other hand it's an easy change and we could have IN_MEMORY mean this now as long as we can get to more precise specification of per CF placement at a later time when someone actually needs it. +1 BucketCache all the time! - Key: HBASE-11323 URL: https://issues.apache.org/jira/browse/HBASE-11323 Project: HBase Issue Type: Sub-task Components: io Reporter: stack Fix For: 0.99.0 Attachments: ReportBlockCache.pdf One way to realize the parent issue is to just enable bucket cache all the time; i.e. always have offheap enabled. Would have to do some work to make it drop-dead simple on initial setup (I think it doable). So, upside would be the offheap upsides (less GC, less likely to go away and never come back because of full GC when heap is large, etc.). Downside is higher latency. In Nick's BlockCache 101 there is little to no difference between onheap and offheap. In a basic compare doing scans and gets -- details to follow -- I have BucketCache deploy about 20% less ops than LRUBC when all incache and maybe 10% less ops when falling out of cache. I can't tell difference in means and 95th and 99th are roughly same (more stable with BucketCache). GC profile is much better with BucketCache -- way less. BucketCache uses about 7% more user CPU. More detail on comparison to follow. I think the numbers disagree enough we should probably do the [~lhofhansl] suggestion, that we allow you to have a table sit in LRUBC, something the current bucket cache layout does not do. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11322) SnapshotHFileCleaner makes the wrong check for lastModified time thus causing too many cache refreshes
[
https://issues.apache.org/jira/browse/HBASE-11322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031729#comment-14031729
]
Lars Hofhansl commented on HBASE-11322:
---
Hmm... True, assuming no races and or clock skew in any way you are correct.
I agree Math.max is fine too. Either way is fine with me. Keeping both times is
more explicit and easier to reason about. Math.max on the other hand is simpler.
+1 on Math.max if you like that better :)
SnapshotHFileCleaner makes the wrong check for lastModified time thus causing
too many cache refreshes
--
Key: HBASE-11322
URL: https://issues.apache.org/jira/browse/HBASE-11322
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.19
Reporter: churro morales
Assignee: churro morales
Priority: Critical
Fix For: 0.94.21
Attachments: 11322.94.txt, HBASE-11322.patch
The SnapshotHFileCleaner calls the SnapshotFileCache if a particular HFile in
question is part of a snapshot.
If the HFile is not in the cache, we then refresh the cache and check again.
But the cache refresh checks to see if anything has been modified since the
last cache refresh but this logic is incorrect in certain scenarios.
The last modified time is done via this operation:
{code}
this.lastModifiedTime = Math.min(dirStatus.getModificationTime(),
tempStatus.getModificationTime());
{code}
and the check to see if the snapshot directories have been modified:
{code}
// if the snapshot directory wasn't modified since we last check, we are done
if (dirStatus.getModificationTime() = lastModifiedTime
tempStatus.getModificationTime() = lastModifiedTime) {
return;
}
{code}
Suppose the following happens:
dirStatus modified 6-1-2014
tempStatus modified 6-2-2014
lastModifiedTime = 6-1-2014
provided these two directories don't get modified again all subsequent checks
wont exit early, like they should.
In our cluster, this was a huge performance hit. The cleaner chain fell
behind, thus almost filling up dfs and our namenode heap.
Its a simple fix, instead of Math.min we use Math.max for the lastModified, I
believe that will be correct.
I'll apply a patch for you guys.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11351) Experiments with OffHeap memstores
[ https://issues.apache.org/jira/browse/HBASE-11351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-11351: -- Attachment: 11351-0.94.txt Here's the hacked up patch. WARNING: Total hack. * For some reason MapDB wants *everything* Serializable * All code in Memstore.java * Currently KVs are serialized twice into the off heap map (could work around this if we forked MapDB NavigableSet implementation). * Much slower * Generates more GC churn (but should be young gen only) * 0.94 only right now * Just for playing! Experiments with OffHeap memstores -- Key: HBASE-11351 URL: https://issues.apache.org/jira/browse/HBASE-11351 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Attachments: 11351-0.94.txt I have been experimenting with offheap memstores using an offheap BTree implementation of ConcurrentMap provided by MapDB (www.mapdb.org) So far I hooked this up in an experimental way with inefficient serialization (in the sense that due to our special usage of the set api we need to back the set by a map, which in the off heap case means we need to serialize and store the value twice. It is used as key and value). But it works. It's quite a bit slower and due to need to deserialize upon scan it produces *more* short term garbage. Let's use this issue to discuss. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11350) [PE] Allow random value size
[ https://issues.apache.org/jira/browse/HBASE-11350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031747#comment-14031747 ] Hudson commented on HBASE-11350: SUCCESS: Integrated in HBase-TRUNK #5207 (See [https://builds.apache.org/job/HBase-TRUNK/5207/]) HBASE-11350 [PE] Allow random value size (stack: rev 63f0dffdba6b9e70fc26a653dd8b1ea64a4e2b70) * hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHFileOutputFormat2.java * hbase-server/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java * hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHFileOutputFormat.java [PE] Allow random value size Key: HBASE-11350 URL: https://issues.apache.org/jira/browse/HBASE-11350 Project: HBase Issue Type: Improvement Components: Performance Reporter: stack Assignee: stack Fix For: 0.99.0 Attachments: 11348.txt Allow PE to write random value sizes. Helpful mimic'ing 'real' sizings. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11323) BucketCache all the time!
[ https://issues.apache.org/jira/browse/HBASE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031767#comment-14031767 ] Lars Hofhansl commented on HBASE-11323: --- That can work. InMemory also implies a different arena in the block cache, though. If we can pass inMemory down to where it matters, why can't we pass another flag down this way? BucketCache all the time! - Key: HBASE-11323 URL: https://issues.apache.org/jira/browse/HBASE-11323 Project: HBase Issue Type: Sub-task Components: io Reporter: stack Fix For: 0.99.0 Attachments: ReportBlockCache.pdf One way to realize the parent issue is to just enable bucket cache all the time; i.e. always have offheap enabled. Would have to do some work to make it drop-dead simple on initial setup (I think it doable). So, upside would be the offheap upsides (less GC, less likely to go away and never come back because of full GC when heap is large, etc.). Downside is higher latency. In Nick's BlockCache 101 there is little to no difference between onheap and offheap. In a basic compare doing scans and gets -- details to follow -- I have BucketCache deploy about 20% less ops than LRUBC when all incache and maybe 10% less ops when falling out of cache. I can't tell difference in means and 95th and 99th are roughly same (more stable with BucketCache). GC profile is much better with BucketCache -- way less. BucketCache uses about 7% more user CPU. More detail on comparison to follow. I think the numbers disagree enough we should probably do the [~lhofhansl] suggestion, that we allow you to have a table sit in LRUBC, something the current bucket cache layout does not do. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11351) Experiments with OffHeap memstores
[ https://issues.apache.org/jira/browse/HBASE-11351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031769#comment-14031769 ] Lars Hofhansl commented on HBASE-11351: --- Hmm... Doesn't work quite yet. I must have broken something playing around. Stay tuned. Experiments with OffHeap memstores -- Key: HBASE-11351 URL: https://issues.apache.org/jira/browse/HBASE-11351 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Attachments: 11351-0.94.txt I have been experimenting with offheap memstores using an offheap BTree implementation of ConcurrentMap provided by MapDB (www.mapdb.org) So far I hooked this up in an experimental way with inefficient serialization (in the sense that due to our special usage of the set api we need to back the set by a map, which in the off heap case means we need to serialize and store the value twice. It is used as key and value). But it works. It's quite a bit slower and due to need to deserialize upon scan it produces *more* short term garbage. Let's use this issue to discuss. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11351) Experiments with OffHeap memstores
[ https://issues.apache.org/jira/browse/HBASE-11351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-11351: -- Attachment: 11351-0.94-v2.txt This one works. MapDB requires each class do be serializable. Experiments with OffHeap memstores -- Key: HBASE-11351 URL: https://issues.apache.org/jira/browse/HBASE-11351 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Attachments: 11351-0.94-v2.txt, 11351-0.94.txt I have been experimenting with offheap memstores using an offheap BTree implementation of ConcurrentMap provided by MapDB (www.mapdb.org) So far I hooked this up in an experimental way with inefficient serialization (in the sense that due to our special usage of the set api we need to back the set by a map, which in the off heap case means we need to serialize and store the value twice. It is used as key and value). But it works. It's quite a bit slower and due to need to deserialize upon scan it produces *more* short term garbage. Let's use this issue to discuss. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11351) Experiments with OffHeap memstores
[ https://issues.apache.org/jira/browse/HBASE-11351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031775#comment-14031775 ] Lars Hofhansl commented on HBASE-11351: --- Next: * Make it work in 0.96+ (protobufs). Although could keep the current serialization as well * Better serialization (that makes use of the the sorted nature of the keys and does prefix compression) * Only store key portion in the key of the map * Fork the set implementation so that we do not need to store KV in a map (which in offheap means two copies of the KV) * Do comparisons off heap! Needs more access into the BTree details (i.e. to the data before it is deserialized onto the heap again) Not sure how much time I'll get on those. If somebody wants to experiment I'm happy to collaborate. Experiments with OffHeap memstores -- Key: HBASE-11351 URL: https://issues.apache.org/jira/browse/HBASE-11351 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Attachments: 11351-0.94-v2.txt, 11351-0.94.txt I have been experimenting with offheap memstores using an offheap BTree implementation of ConcurrentMap provided by MapDB (www.mapdb.org) So far I hooked this up in an experimental way with inefficient serialization (in the sense that due to our special usage of the set api we need to back the set by a map, which in the off heap case means we need to serialize and store the value twice. It is used as key and value). But it works. It's quite a bit slower and due to need to deserialize upon scan it produces *more* short term garbage. Let's use this issue to discuss. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (HBASE-11351) Experiments with OffHeap memstores
[ https://issues.apache.org/jira/browse/HBASE-11351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031775#comment-14031775 ] Lars Hofhansl edited comment on HBASE-11351 at 6/15/14 3:52 AM: Next: * Make it work in 0.96+ (protobufs). Although could keep the current serialization as well * Better serialization (that makes use of the the sorted nature of the keys and does prefix compression) * Only store key portion in the key of the map * Add code to MapDB to allow serialization from an array with offset * Fork the set implementation so that we do not need to store KV in a map (which in offheap means two copies of the KV) * Do comparisons off heap! Needs more access into the BTree details (i.e. to the data before it is deserialized onto the heap again) Not sure how much time I'll get on those. If somebody wants to experiment I'm happy to collaborate. was (Author: lhofhansl): Next: * Make it work in 0.96+ (protobufs). Although could keep the current serialization as well * Better serialization (that makes use of the the sorted nature of the keys and does prefix compression) * Only store key portion in the key of the map * Fork the set implementation so that we do not need to store KV in a map (which in offheap means two copies of the KV) * Do comparisons off heap! Needs more access into the BTree details (i.e. to the data before it is deserialized onto the heap again) Not sure how much time I'll get on those. If somebody wants to experiment I'm happy to collaborate. Experiments with OffHeap memstores -- Key: HBASE-11351 URL: https://issues.apache.org/jira/browse/HBASE-11351 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Attachments: 11351-0.94-v2.txt, 11351-0.94.txt I have been experimenting with offheap memstores using an offheap BTree implementation of ConcurrentMap provided by MapDB (www.mapdb.org) So far I hooked this up in an experimental way with inefficient serialization (in the sense that due to our special usage of the set api we need to back the set by a map, which in the off heap case means we need to serialize and store the value twice. It is used as key and value). But it works. It's quite a bit slower and due to need to deserialize upon scan it produces *more* short term garbage. Let's use this issue to discuss. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11351) Experiments with OffHeap memstores
[ https://issues.apache.org/jira/browse/HBASE-11351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-11351: -- Attachment: 11143-0.94-v3.txt Very slightly better. Stores only the key portion of the KV in the off heap map's key. Experiments with OffHeap memstores -- Key: HBASE-11351 URL: https://issues.apache.org/jira/browse/HBASE-11351 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Attachments: 11143-0.94-v3.txt, 11351-0.94-v2.txt, 11351-0.94.txt I have been experimenting with offheap memstores using an offheap BTree implementation of ConcurrentMap provided by MapDB (www.mapdb.org) So far I hooked this up in an experimental way with inefficient serialization (in the sense that due to our special usage of the set api we need to back the set by a map, which in the off heap case means we need to serialize and store the value twice. It is used as key and value). But it works. It's quite a bit slower and due to need to deserialize upon scan it produces *more* short term garbage. Let's use this issue to discuss. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11351) Experiments with OffHeap memstores
[ https://issues.apache.org/jira/browse/HBASE-11351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-11351: -- Attachment: (was: 11143-0.94-v3.txt) Experiments with OffHeap memstores -- Key: HBASE-11351 URL: https://issues.apache.org/jira/browse/HBASE-11351 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Attachments: 11351-0.94-v2.txt, 11351-0.94-v3.txt, 11351-0.94.txt I have been experimenting with offheap memstores using an offheap BTree implementation of ConcurrentMap provided by MapDB (www.mapdb.org) So far I hooked this up in an experimental way with inefficient serialization (in the sense that due to our special usage of the set api we need to back the set by a map, which in the off heap case means we need to serialize and store the value twice. It is used as key and value). But it works. It's quite a bit slower and due to need to deserialize upon scan it produces *more* short term garbage. Let's use this issue to discuss. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11351) Experiments with OffHeap memstores
[ https://issues.apache.org/jira/browse/HBASE-11351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-11351: -- Attachment: 11351-0.94-v3.txt Right patch this time. Experiments with OffHeap memstores -- Key: HBASE-11351 URL: https://issues.apache.org/jira/browse/HBASE-11351 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Attachments: 11351-0.94-v2.txt, 11351-0.94-v3.txt, 11351-0.94.txt I have been experimenting with offheap memstores using an offheap BTree implementation of ConcurrentMap provided by MapDB (www.mapdb.org) So far I hooked this up in an experimental way with inefficient serialization (in the sense that due to our special usage of the set api we need to back the set by a map, which in the off heap case means we need to serialize and store the value twice. It is used as key and value). But it works. It's quite a bit slower and due to need to deserialize upon scan it produces *more* short term garbage. Let's use this issue to discuss. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11323) BucketCache all the time!
[ https://issues.apache.org/jira/browse/HBASE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031778#comment-14031778 ] stack commented on HBASE-11323: --- Thanks for the feedback lads. I'll add new config on CacheConfig and will use it figuring whether to DATA blocks are L1 or L2 (Turns out BucketCache gives blocks marked IN_MEMORY higher priority trying to mimic roughly what is happening in LruBlockCache). BucketCache all the time! - Key: HBASE-11323 URL: https://issues.apache.org/jira/browse/HBASE-11323 Project: HBase Issue Type: Sub-task Components: io Reporter: stack Fix For: 0.99.0 Attachments: ReportBlockCache.pdf One way to realize the parent issue is to just enable bucket cache all the time; i.e. always have offheap enabled. Would have to do some work to make it drop-dead simple on initial setup (I think it doable). So, upside would be the offheap upsides (less GC, less likely to go away and never come back because of full GC when heap is large, etc.). Downside is higher latency. In Nick's BlockCache 101 there is little to no difference between onheap and offheap. In a basic compare doing scans and gets -- details to follow -- I have BucketCache deploy about 20% less ops than LRUBC when all incache and maybe 10% less ops when falling out of cache. I can't tell difference in means and 95th and 99th are roughly same (more stable with BucketCache). GC profile is much better with BucketCache -- way less. BucketCache uses about 7% more user CPU. More detail on comparison to follow. I think the numbers disagree enough we should probably do the [~lhofhansl] suggestion, that we allow you to have a table sit in LRUBC, something the current bucket cache layout does not do. -- This message was sent by Atlassian JIRA (v6.2#6252)
