-Re: increase "running scans" in monitor?
Keith Turner 2013-04-04, 01:15
On Tue, Apr 2, 2013 at 11:35 AM, Marc Reichman <[EMAIL PROTECTED]> wrote:
> I apologize, I neglected to include row counts. For the above split sizes
> mentioned, there are roughly ~55K rows, ~300K rows, ~800K rows, and ~2M
> I'm not necessarily hard-set on the idea that lower "running scans" are
> affecting my overall job time negatively, and I realize that my jobs
> themselves may simply be starving the tablet servers (cpu-wise). In my
> experiences thus-far, running all 8 CPU cores per node leads to an overall
> quicker job completion than pulling one core out of the mix to let accumulo
> itself have more breathing room.
Scans in accumulo fetch batches of key/values. When a scan is
fetching one of these batches and storing it in a buffer on the tablet
server, its counted as running. While that batch is being serialized
and sent to the client its not counted as running. In my experience
the speed at which a batch of key values can be read from RFiles, is
much faster than the speed at which a batch can be serialized, sent to
client, and then deserialized. Maybe this explains what you are
Have you tried running listscans in the shell while your map reduce
job is running? This will show all of the mappers scan sessions. For
each scan session you can see its state, the running state should
correspond to the run count on the monitor page.
I suspect if you ran a map reduce job that pushed a lot of work into
iterators on the tablet servers, then you would see much higher
running scans counts. For example if your mappers setup a filter
that only returned 1/20th of the data, then scans would spend a lot
more time reading a batch of data relative to the time spent
transmitting a batch of data.
> On Tue, Apr 2, 2013 at 10:20 AM, Marc Reichman <[EMAIL PROTECTED]>
>> Hi Josh,
>> Thanks for writing back. I am doing all explicit splits using addSplits in
>> the Java API since the keyspace is easy to divide evenly. Depending on the
>> table size for some of these experiments, I've had 128 splits, 256, 512, or
>> 1024 splits. My jobs are executing properly, MR-wise, in the sense that I do
>> have a proper amount of map tasks created (as the count of splits above,
>> respectively). My concern is that the jobs may not be quite as busy as they
>> can be, dataflow-wise and I think the "Running Scans" per table/tablet
>> server seem to be good indicators of that.
>> My data is a 32-byte key (an md5 value), and I have one column family with
>> 3 columns which contain "bigger" data, anywhere from 50-100k to an
>> occasional 10M-15M piece.
>> On Tue, Apr 2, 2013 at 10:06 AM, Josh Elser <[EMAIL PROTECTED]> wrote:
>>> Hi Marc,
>>> How many tablets are in the table you're running MR over (see the
>>> monitor)? Might adding some more splits to your table (`addsplits` in the
>>> Accumulo shell) get you better parallelism?
>>> What does your data look like in your table? Lots of small rows? Few very
>>> large rows?
>>> On 4/2/13 10:56 AM, Marc Reichman wrote:
>>>> I am running a accumulo-based MR job using the AccumuloRowInputFormat on
>>>> 1.4.1. Config is more-or-less default, using the native-standalone 3GB
>>>> template, but with the TServer memory put up to 2GB in accumulo-env.sh from
>>>> its default. accumulo-site.xml has tserver.memory.maps.max at 1G,
>>>> tserver.cache.data.size at 50M, and tserver.cache.index.size at 512M.
>>>> My tables are created with maxversions for all three types (scan, minc,
>>>> majc) at 1 and compress type as gz.
>>>> I am finding, on an 8 node test cluster with 64 map task slots, that
>>>> when a job is running, the 'Running Scans' count in the monitor is roughly
>>>> 0-4 on average for each tablet server. When viewed at the table view, this
>>>> puts the running scans anywhere from 4-24 on average. I would expect/hope
>>>> the scans to be somewhere close to the map task count. To me, this means one