2017 at 3:33 PM, Ankit Malhotra
wrote:
> Wait, block-ns = 0.3ms (300,000ns). Also, why are we not adding in
> choose-ns?
>
> Thanks
> Ankit
>
> On 3/14/17, 6:26 PM, "Jagadish Venkatraman"
> wrote:
>
> I wou
ere will be only one thread that's processing messages. The
two other threads are not doing work, and entail a constant (albeit
insignificant) synchronization overhead.
On Tue, Mar 14, 2017 at 3:03 PM, Ankit Malhotra
wrote:
> Hi,
Hi,
We are trying to understand metrics that are being populated by our samza job
and are a little confused what each of these metrics mean especially since
we’re running the job with a thread pool.
· We have 3 input streams
· job.container.thread.pool.size=3
· 1 cont
e config.
Thanks,
Jagadish
On Thu, Mar 9, 2017 at 10:38 AM, Ankit Malhotra
wrote:
> Also, the PUTs are taking 10x of GETs is what baffles me a little bit.
> We’re running on SSDs and here is our config:
>
> stores.stage- store.write
they are useful.
On 3/9/17, 11:45 AM, "Ankit Malhotra" wrote:
Replies inline
On 3/9/17, 11:24 AM, "Jagadish Venkatraman" wrote:
I understand you are receiving messages from *all* partitions (but fewer
messages from some partitions).
. We are also
>> using an object cache of 2million objects with a write cache of 1m objects.
Input messages are ~ 5k/sec/partition aggregate for both input streams that we
are joining.
On Thu, Mar 9, 2017 at 5:20 AM, Ankit Malhotra
wrote:
> Replies inline.
&g
, our rocks store's average get across all tasks is around
20,000ns BUT average put is 5X or more. We have the object cache enabled.
> Thanks,
> Jagadish
>
>
> On Wed, Mar 8, 2017 at 1:05 PM, Ankit Malhotra
> wrote:
>
>> Hi,
>>
>> While joining st
Hi,
While joining streams from 2 partitions to join 2 streams, we see that some
containers start suffering in that, lag (messages behind high watermark) for
one of the tasks starts sky rocketing while the other one is ~ 0.
We are using default values for buffer sizes, fetch threshold, are using
Hi Jagadish,
Thanks for your reply. Is it safe to assume that you are running similar
machines in production YARN clusters where only SAMZA workloads run?
Ankit
> On Jan 31, 2017, at 3:49 PM, Jagadish Venkatraman
> wrote:
>
> Hi Ankit,
>
> We have benchmarked Samza on the following hardware
Hi - I am just curious if people can share hardware configurations on which you
have been running Samza? We are evaluating samza for a streaming join use case
which makes heavy use of RocksDB where the store spills to disk for most joins.
Specifically, how many cores/memory/SSDs (types of SSDs)/
10 matches
Mail list logo