[
https://issues.apache.org/jira/browse/HBASE-10997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13981297#comment-13981297
]
stack commented on HBASE-10997:
-------------------------------
bq. I'm not sure how this is useful.
I use it like this.
I want to run a PE that does random reads and that runs for a good while, long
enough for the latency pattern to emerge. I want to run ten clients. Block
cache is small. I want the random reads to stay in block cache. As is, the
random reads range over a namespace that is clients X rows. To stay inside
block cache, I can set rows small but my test is over before a pattern is well
established. If I set rows to 1B, then clients will get 1B rows but if I add
the modulo, the keys will be confined to the lower part of the range (dependent
on what modulo is).
If I want to bust block cache but stay inside the os cache, I up the modulo
till just before i/o comes on.
I like your 'size' better than my modulo. I'll remove this if your size works.
Thanks.
Sorry for committing this w/o waiting on review. Didn't think anyone cared
(missed your size issue).
> Add a modulo argument to PE to constrain the key range
> ------------------------------------------------------
>
> Key: HBASE-10997
> URL: https://issues.apache.org/jira/browse/HBASE-10997
> Project: HBase
> Issue Type: Improvement
> Reporter: stack
> Assignee: stack
> Priority: Trivial
> Fix For: 0.99.0
>
> Attachments: modulo.txt
>
>
> Helps w/ keeping PE inside block cache but same number of clients.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
