On 29/04/17 08:14 AM, Julien Danjou wrote:
> 1. get 'deleted' metrics
> 2. delete all things in storage
> -> if it fails, whatever, ignore, maybe a janitor is doing the same
> thing?
> 3. expunge from indexer
possibly? i was thinking it was possible that maybe it would partially
delete and
On Fri, Apr 28 2017, gordon chung wrote:
>>> refresh i believe is always disabled by default regardless of what
>>> interface you're using.
>>
>> You gotta to show me where it is 'cause I can't see that and I don't
>> recall any option for that. :/
>
>
On Fri, Apr 28 2017, gordon chung wrote:
>>> if the sack is unlocked, then it means a processing worker isn't looking
>>> at the sack, and when it does lock the sack, it first has to check sack
>>> for existing measures to process and then check indexer to validate that
>>> they are still active.
On 28/04/17 10:50 AM, Julien Danjou wrote:
> On Fri, Apr 28 2017, gordon chung wrote:
>
>> if the sack is unlocked, then it means a processing worker isn't looking
>> at the sack, and when it does lock the sack, it first has to check sack
>> for existing measures to process and then check
On 28/04/17 10:50 AM, Julien Danjou wrote:
> On Fri, Apr 28 2017, gordon chung wrote:
>
>> if the sack is unlocked, then it means a processing worker isn't looking
>> at the sack, and when it does lock the sack, it first has to check sack
>> for existing measures to process and then check
On 28/04/17 10:11 AM, Julien Danjou wrote:
> On Fri, Apr 28 2017, gordon chung wrote:
>
>> refresh i believe is always disabled by default regardless of what
>> interface you're using.
>
> You gotta to show me where it is 'cause I can't see that and I don't
> recall any option for that. :/
On Fri, Apr 28 2017, gordon chung wrote:
> if the sack is unlocked, then it means a processing worker isn't looking
> at the sack, and when it does lock the sack, it first has to check sack
> for existing measures to process and then check indexer to validate that
> they are still active.
On Fri, Apr 28 2017, gordon chung wrote:
> refresh i believe is always disabled by default regardless of what
> interface you're using.
You gotta to show me where it is 'cause I can't see that and I don't
recall any option for that. :/
> in the case of cross-metric aggregations, this is a
On 28/04/17 09:23 AM, Julien Danjou wrote:
> On Fri, Apr 28 2017, gordon chung wrote:
>
>> what if we just don't lock ever on delete, but if we still check lock to
>> see if it's processed. at that point, the janitor knows that metric(s)
>> is deleted, and since no one else is working on sack,
On 28/04/17 09:19 AM, Julien Danjou wrote:
> That's not what I meant. You can have the same mechanism as currently,
> but then you compute the sacks of all metrics and you
> itertools.groupby() per sack on them before locking the sack and
> expunging them.
yeah, we should do that. i'll add that
On Fri, Apr 28 2017, gordon chung wrote:
> what if we just don't lock ever on delete, but if we still check lock to
> see if it's processed. at that point, the janitor knows that metric(s)
> is deleted, and since no one else is working on sack, any metricd that
> follows will also know that
On Fri, Apr 28 2017, gordon chung wrote:
> so the tradeoff here is that now we're doing a lot more calls to
> indexer. additionally, we're pulling a lot more unused results from db.
> a single janitor currently just grabs all deleted metrics and starts
> attempting to clean them up one at a
On 28/04/17 03:48 AM, Julien Danjou wrote:
> Yes, I wrote that in a review somewhere. We need to rework 1. so
> deletion happens at the same time we lock the sack to process metrics
> basically. We might want to merge the janitor into the worker I imagine.
> Currently a janitor can grab metrics
On 28/04/17 03:48 AM, Julien Danjou wrote:
>
> Yes, I wrote that in a review somewhere. We need to rework 1. so
> deletion happens at the same time we lock the sack to process metrics
> basically. We might want to merge the janitor into the worker I imagine.
> Currently a janitor can grab
On Thu, Apr 27 2017, gordon chung wrote:
> so as we transition to the bucket/shard/sack framework for incoming
> writes, we've set up locks on the sacks so we only have one process
> handling any given sack. this allows us to remove the per-metric locking
> we had previously.
yay!
> the
hey,
so as we transition to the bucket/shard/sack framework for incoming
writes, we've set up locks on the sacks so we only have one process
handling any given sack. this allows us to remove the per-metric locking
we had previously.
the issue i've notice now is that if we only have per-sack
16 matches
Mail list logo
