►
From YouTube: Mimir community call 2023-05-25
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
Welcome
to
the
the
May,
the
mirror
Community
call
I'm
Vernon
Miller
software
engineer
on
mimir,
so
just
going
through
the
the
agenda.
Today
we
have
some
updates
of
stuff
we're
working
on
the
the
first
item
on
the
agenda
is
about
reducing
queer
memory
utilization
Marco.
Do
you
want
to
talk
about
that.
A
B
B
So
far
we
did
some
testing
in
a
def
linear
cluster
and
we
got
some
promising
results
in
terms
of
memory
utilization
reduction
in
in
the
query,
however,
we
just
tested-
you
know
there
is
more
set
of
queries
like
the
most
common
one.
Some
rate
is,
you
know,
is
the
first
query
from
which
we
started,
which
is
also
the
the
most
common
one
in
in
Prometheus.
B
So
more
testing
is
required
and
we
also
want
to
run.
We
also
want
to
start
testing
this.
This
new
feature,
you
know
in
the
big
Premiere
cluster,
but
so
far
dude.
The
results
we
got
are
pretty
interesting.
There's
one
main
downside
which
it's
something
we
are
still
working
on
when
you
enable
these
experimental
features,
it's
expected
to
increase
the
ingester
CPU
accreditation.
B
That's
definitely
something
we
you
know
we
will
keep
an
eye
on.
We
are
also
very
sensible
to
try
to
keep
the
Injustice
if
you
as
lowest
as
possible,
and
maybe
there
is
also
room
for
some
opportunities
there
I
think
we
will
have
some
data
to
share
not
for
the
next
release,
which
is
the
tour
time
expected.
B
A
All
right,
thanks,
Marco,
the
next
one
I
can
talk
about
so
a
feature
that
we've
started
working
on
is
per
series,
extended
retention
and
it's
still
we're
still
finishing
finishing
up
the
design
phase
and
working
on
a
proof
of
concept.
But
the
the
idea
is,
you
know
you
may
have
a
ton
of
a
ton
of
metrics.
A
A
A
D
D
A
D
D
A
B
However,
most
of
the
time
there
are
no
changes
to
the
rule.
Groups
between
you
know
two
consecutive
intervals,
but
unfortunately
the
ruler
doesn't
know
unless
you
know
keeps
checking
all
the
configured
rule
groups
in
the
storage.
What
we
did
was
introducing
another
way
to
sync
the
real
groups,
which
is
a
sort
of
event
based.
So
whenever
you
call
the
ruler,
config
API
to
change,
they
configure
the
rule
groups,
a
notification
is,
is
pushed
across
the
ruler,
replicas
and
everything
is,
is
triggered.
B
This
is
in
addition
of
the
periodic
polling,
but
we
expected
thanks
to
this
feature,
we
will
be
able
to
increase
the
polling
interval
because
you
know
we
expect
that
most
of
the
well
and
you
know,
unless
edge
cases
or
race
conditions
that
we
expected.
You
know
the
thinking
would
be
actually
triggered
Always
by
the
the
events
we
are
rolling
out.
B
B
So
after
some
work
and
some
refactoring
in
the
code,
we
changed
a
bit
how
we
discover
the
blocks
in
the
storage
and
we
have
been
able
to
reduce
sorry
to
completely
remove
this
objects
exist.
Api
call
this
feature:
I
mean
I.
Just
worked
this
week
on
this
I
merged
the
last
VR
three
hours
ago,
so
we
will
start
rolling
out
this
feature
on
to
our
Dev
clusters
next
week
to
our
product
clusters,
the
week
after
so
I
should
have.
You
know
some
results
to
share
in
a
couple
of
weeks
from
from
now,
okay.
C
B
So
the
number
of
API
calls
you
have
to
issue
to
list.
All
the
blocks
of
a
tenant
is
not
equal
to
the
number
of
blocks
for
that
tenant
inside
the
object
storage
because
we
list
a
thousand
with
just
one
call,
but
then
for
each
of
them
we
were
checking
if
the
meta
Json
file
was
existing
and
the
reason
why
we
did
it
was
to
check
if
the
block
were
sorry.
B
If
there
was
a
deletion
in
progress
on
the
Block,
which
means
when
we
delete
the
block,
we
started
deleting
The
Meta
Json
file.
It's
our
way
to
trigger
that
the
block
should
be
ignored
when
the
metagic
file
does
not
exist,
and
then
we
delete
all
other
files
of
that
block
until
all
the
block
is
deleted.
B
Now
there
could
be
a
deletion
in
progress
for
that
specific
block
between
when
we
issued
the
list
object
code-
and
you
know
when
the
compactor
run
the
planning
and
start
the
compaction
so
yeah.
We
were
basically
checking
every
meta
Json
file
of
each
block
here
to
see.
If
the
block
was
sorry,
if
there
was
a
in
progress,
deletion
or
not-
and
that
was
inadequate,
I
mean
this
code
was
years
old.
It
was
originally
inherited
from
from
Thanos.
You
know
in
a
different
state
of
the
world.
B
Now
we
have
the
packet
index
in
the
mirror,
which
is
mandatory,
so
we
can
infer
the
same
information
from
the
bucket
index
as
well.
So
before
listing
objects,
we
actually
you
know,
look
up
the
bucket
index,
which
is
just
one
call
pertinent
to
check
all
the
blocks
which
have
been
marked
for
deletion
and
and
then
we
use
this
information
to
check
whether
a
block
should
be
excluded
or
not
from
the
compactor,
because
the
compactor
that
doesn't
need
to
take
in
account
any
block
marked
for
from
for
deletion.
B
A
A
E
I
would
have
a
question
I
sorry,
I
I'm,
in
between
meetings,
so
like
I'm,
trying
to
to
see
how
much
time
I
have
the
I
see
that
there
is
a
recommend,
a
new
recommendation
now
in
the
documentation
for
the
compactor
to
basically
have
one
chart.
Every
8
million
active
series
instead
of
the
old
25
30.,
is
that
recommended
for
all
use
cases
for
big
tenants
as
well
is
what
what's
the
why
there
was
a
change?
E
E
B
So
there
was
something
discussion
internally,
whether
we
should
recommend
you
know
and
now
sorry
we
should
keep
recommending
a
one
shot.
I
think
we
were
recommending
the
documentation
going
short
every
20
or
25
million,
and
then
you
know
some
people
from
from
grafana
Lodge
suggested
that
we
actually
at
graphology.
We
actually
run
with
the
lower
Target
than
what
our
documentation
say.
B
C
B
B
E
B
E
B
E
Yeah
yeah
yeah,
yeah,
okay,
okay,
thanks!
Well,
that's
good
to
know,
so
we
don't
need
to
maybe
to
change
this
dramatically.
Maybe
I
I
I
will
try
to.
We
are
trying
to
get
the
the
number
of
shards
like
the
as
a
power
of
two
basically
and
the
shards
as
well,
that
the
query
use
so
at
least
they
can
kind
of
interact
with
each
other.
Even
if,
in
the
future
we
change
the
number
of
or
shards
or
for
the
compactor.