accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Havanki" <bhava...@clouderagovt.com>
Subject Re: Review Request 23093: ACCUMULO-2947 - Limit cells per mutation in memory stress test
Date Tue, 01 Jul 2014 16:44:24 GMT


> On July 1, 2014, 12:29 p.m., Mike Drob wrote:
> > test/src/main/java/org/apache/accumulo/test/stress/random/RandomMutations.java,
line 50
> > <https://reviews.apache.org/r/23093/diff/2/?file=621369#file621369line50>
> >
> >     I don't know why, but I like this. I would have done (i < max &&
i < remaining), but this is much cleaner. :)

I did have something like (i < max && i < remaining) at first, but realized
the whole thing could be precomputed since max and remaining are invariant.


> On July 1, 2014, 12:29 p.m., Mike Drob wrote:
> > test/src/main/java/org/apache/accumulo/test/stress/random/RandomMutations.java,
line 53
> > <https://reviews.apache.org/r/23093/diff/2/?file=621369#file621369line53>
> >
> >     I assume we are decrementing this after each put() instead of all at once is
because we are worried about an exception getting thrown? In which case, it would make sense
to not decrement the remaining count at all, since those mutation bits will never be returned.

I hadn't thought of that, actually ... it just turned out that way. At this stage, I would
be fine with it failing horribly if a put() throws an exception. In that case, I can actually
just say this once:

cells_remaining_in_row -= cells;

How's that?


- Bill


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23093/#review47078
-----------------------------------------------------------


On July 1, 2014, 12:23 p.m., Bill Havanki wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23093/
> -----------------------------------------------------------
> 
> (Updated July 1, 2014, 12:23 p.m.)
> 
> 
> Review request for accumulo and Bill Slacum.
> 
> 
> Bugs: ACCUMULO-2947
>     https://issues.apache.org/jira/browse/ACCUMULO-2947
> 
> 
> Repository: accumulo
> 
> 
> Description
> -------
> 
> A new switch to the memory stress test Write utility, --max-cells-per-mutation, controls
the maximum number of cells to be written in any mutation. If the maximum is hit before the
configured row width, the current mutation is used and the next mutation picks up where it
left off, in the same row.
> 
> The core logic is in the RandomMutations class. It uses a counter for how many cells
are remaining in the current row, with 0 indicating that a new row should be started. Otherwise,
the last row is used. The counter is used as the loop counter for writing cells. When it hits
zero or the maximum, writes stop.
> 
> 
> Diffs
> -----
> 
>   test/src/main/java/org/apache/accumulo/test/stress/random/RandomMutations.java c4504b2

>   test/src/main/java/org/apache/accumulo/test/stress/random/Write.java 9c29871 
>   test/src/main/java/org/apache/accumulo/test/stress/random/WriteOptions.java c213528

>   test/system/stress/stress-env.sh.example 1360c67 
>   test/system/stress/writer.sh 7d9b283 
> 
> Diff: https://reviews.apache.org/r/23093/diff/
> 
> 
> Testing
> -------
> 
> Ran memory stress test on single-node 1.5.2 cluster. With max-cells-per-mutation = 4
and row-width ranging from 1 to 7, saw rows still being written with 5 or more cells.
> 
> 
> Thanks,
> 
> Bill Havanki
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message