Last time around, we found that block checksums was #1 (but then if we are
serving from block cache, it should not matter) and binarysearch into
indices was also high in terms of CPU.
We use a multi level index for HFile v2 right ? Is that just a multi level
binary search on all the start keys of
Yeah, that would seem to indicate that seeking into the block is not a
bottleneck (and you said earlier that everything fits into the blockcache).
Need to profile to know more. If you have time, would be cool if you can start
jvisualvm and attach it to the RS start the profiling and let the workl
Smaller block size (32K) does not give any performance gain and this is
strange, to say the least.
On Wed, Jul 31, 2013 at 9:33 PM, lars hofhansl wrote:
> Would be interesting to profile MultiGet. With RTT of 0.1ms, the internal
> RS friction is probably the main contributor.
> In fact MultiGet
Would be interesting to profile MultiGet. With RTT of 0.1ms, the internal RS
friction is probably the main contributor.
In fact MultiGet just loops over the set at the RS and calls single gets on the
various regions.
Each Get needs to reseek into the block (even when it is cached, since KVs have
Some final numbers :
Test config:
HBase 0.94.6
blockcache=true, block size = 64K, KV size = 62 bytes (raw).
5 Clients: 96GB, 16(32) CPUs (2.2Ghz), CentOS 5.7
1 RS Server: the same config.
Local network with ping between hosts: 0.1 ms
1. HBase client hits the wall at ~ 50K per sec regardless o
Enis Soztutar created HBASE-9107:
Summary: [0.94] Backport HBASE-6950 TestAcidGuarantees system test
now flushes too aggressively to 0.94
Key: HBASE-9107
URL: https://issues.apache.org/jira/browse/HBASE-9107
Enis Soztutar created HBASE-9106:
Summary: Do not fail TestAcidGuarantees for exceptions on table
flush
Key: HBASE-9106
URL: https://issues.apache.org/jira/browse/HBASE-9106
Project: HBase
I
Thanks for asking. I made progress (see my unit test thread) but had
forgotten Jeffrey's tool. I started up that thread again.
Thanks,
St.Ack
On Wed, Jul 31, 2013 at 3:16 PM, Nick Dimiduk wrote:
> This one has fallen by the way-side. Stack, are you still seeing this
> behavior? Maybe Jeffrey'
Did this get checked in?
Thanks,
St.Ack
On Wed, Mar 6, 2013 at 10:11 AM, Jeffrey Zhong wrote:
>
> I can check it into ./dev-tools unless someone objects.
>
> Thanks,
> -Jeffrey
>
> On 3/5/13 10:43 PM, "Stack" wrote:
>
> >Nice. Should we check it into ./dev-tools?
> >Thanks,
> >St.Ack
> >
> >
>
This one has fallen by the way-side. Stack, are you still seeing this
behavior? Maybe Jeffrey's Jenkins history utility can get you the
information you need?
On Sat, Jul 20, 2013 at 7:42 PM, Stack wrote:
> Any ideas on how to debug failures where all tests 'pass' but build still
> reported as fa
On Wed, Jul 31, 2013 at 1:44 PM, James Taylor wrote:
> Given that nothing depends on the order preserving types (i.e. no risk of
> breaking stuff), why not just include them?
>
I was wondering that too but haven't been following closely.
--
Best regards,
- Andy
Problems worthy of attack p
Ibragim Ismailov created HBASE-9105:
---
Summary: Add web ui for Region Checker
Key: HBASE-9105
URL: https://issues.apache.org/jira/browse/HBASE-9105
Project: HBase
Issue Type: New Feature
IMHO, the value is agreeing on a serialization format across multiple
products. Without a common serialization format, we won't have a good
interop story. Phoenix needs the serialization format to be order
preserving.
Given that nothing depends on the order preserving types (i.e. no risk of
breaki
On Wed, Jul 31, 2013 at 1:19 PM, James Taylor wrote:
> But the value in your patch is fixing the serialization format such that it
> is order preserving. Unfortunately, without this, Phoenix can't adopt it.
> It's existing type system and query processing is predicated on this.
>
Two patches, two
Ibragim Ismailov created HBASE-9104:
---
Summary: RegionChecker to track when regions go unavailable and
back opened
Key: HBASE-9104
URL: https://issues.apache.org/jira/browse/HBASE-9104
Project: HBase
But the value in your patch is fixing the serialization format such that it
is order preserving. Unfortunately, without this, Phoenix can't adopt it.
It's existing type system and query processing is predicated on this.
On Wed, Jul 31, 2013 at 12:04 PM, Nick Dimiduk wrote:
> On Wed, Jul 31, 20
On Wed, Jul 31, 2013 at 10:31 AM, Stack wrote:
> So what would be the incentive using the new API be?
>
Hopefully the new API is nicer than managing byte[]'s on manually. The only
incentive for users would be keeping up with progress, giving users the
chance to start migrating their applications
Jesse Yates created HBASE-9103:
--
Summary: Print lines that are longer than allowed in HadoopQA
output.
Key: HBASE-9103
URL: https://issues.apache.org/jira/browse/HBASE-9103
Project: HBase
Issue
On Wed, Jul 31, 2013 at 9:55 AM, Nick Dimiduk wrote:
> On Tue, Jul 30, 2013 at 9:38 PM, James Taylor >wrote:
>
> > So row key order won't match the natural sort order?
> >
>
> With the "Legacy" types that are based on Bytes, you get whatever you get.
> Strings and pass-through byte[]'s work like
Liyin Tang created HBASE-9102:
-
Summary: HFile block pre-loading for large sequential scan
Key: HBASE-9102
URL: https://issues.apache.org/jira/browse/HBASE-9102
Project: HBase
Issue Type: Improve
On Tue, Jul 30, 2013 at 9:38 PM, James Taylor wrote:
> So row key order won't match the natural sort order?
>
With the "Legacy" types that are based on Bytes, you get whatever you get.
Strings and pass-through byte[]'s work like normal; positive integers will
work, but not negatives; &c. HBase wo
Chao Shi created HBASE-9101:
---
Summary: Addendum to pluggable RpcScheduler
Key: HBASE-9101
URL: https://issues.apache.org/jira/browse/HBASE-9101
Project: HBase
Issue Type: Improvement
Comp
22 matches
Mail list logo
