►
From YouTube: 2019-10-17 :: Ceph Performance Meeting
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:
well,
let's
get
started
here
so
okay,
this
week,
let's
see
we
have
four
new
PRS
I've
got
one
for
keeping
Bono's
cashed
in
a
separate
indication
tree
list.
The
motivation
for
this
is
that
we
had
a
user
that
had
a
very
large
number
of
pinned
entries
in
their
booster
caches
and
it
was
making
it
so
that
the
old
trimming
behavior
was
not
successfully
trimming
everything
we
would
stop
before
we.
A
So
we
were
trying
to
keep
the
cache
as
small,
but
at
least
with
the
own
cache
we're
not
effectively
doing
so
because
there's
so
many
in
entries,
so
it
everything
just
kinda
didn't
work
very
well.
So
this
is
an
attempt
to
to
get
around
that
we'll
see,
but
so
far
it's
looking
pretty
good,
because
we
can
talk
about
later
the
the
upsides
and
downsides
of
this,
but
that's
it.
A
For
now
the
Radek,
oh
and
I'm-
sorry,
no
key
foo
has
a
PR
here
for
crimson,
just
lowering
log
levels,
I
assume
that's
just
a
small
performance
enhancement
enhancement
there.
They
are
working
on
trying
to
get
some
performance
and
efficiency
numbers
compared
to
classical
OSD
using
mem
store,
so
I.
Imagine
they
probably
saw
that
when
they
were
doing
that
testing.
A
Let's
see,
oh
I've
got
a
small
PR
here
that
just
increases
the
default
number
of
our
DW
book
of
charts.
That
probably
shouldn't
happen.
Well,
it's
debatable
whether
or
not
it
should
happen
until
after
the
next
PR
merges,
which
is
Eric's
PR
year
for
reducing
the
pressured
entry
count
during
ordered
bucket
listing.
A
So
this
is
the
one
we
were
talking
about
two
weeks
ago
where
the
idea
is
to
only
touch
a
smaller
number
of
listings
from
each
shard
and
then,
when
rgw
combines
them,
it
can
potentially
refetch
if
it
needs
to
otherwise
you,
hopefully
it's
gotten
most
of
them,
that
it
needs,
or
maybe
all
of
them,
that
it
needs
so
updated.
Prs,
let's
see.
Oh,
this
is
another
one
from
Eric
I
think
this.
A
B
The
user
is
able,
through
the
command
line,
I've,
read
us
to
have
you
and
then
to
set
two
non
prime
values
and
values
well
above
1000
line
running
on
as
well,
but
anyway,
I
think
there's
what
we
don't
want
to
go
up
too
high,
because
we
don't
know
how
super
high
numbers
of
Buchan
index
cards
couldn't
affect
the
whole
system.
So,
theoretically
we
can
go
up
to
like.
B
We're
using
a
to
determine
which
shard
something
goes
into,
we
come
to
hash
and
then
a
modulo
operation,
and
the
belief
is
that,
with
the
modulo
operation,
you
can
end
up
with
patterns
of
distribution
which
are
uneven.
When
you
have
non-crime
numbers
of
shards
that
multiple
multiples,
what
can
hit
the
same
guards
disproportionately
and
so
with
Prime's,
which
don't
have
a
multiple
it
tends
to
give
you
better
distribution,
okay,
interesting.
A
A
Okay
looks
like
tests
were
failing
on
that,
so
he
needs
to
figure
out
what
was
going
on
and
fixed
that
tuning
of
the
MDS
cache
memory
limit.
That
still
seems
to
be
gaining
lots
of
updates,
not
exactly
sure
what
the
newest
ones
are
but
looks
like
Patrick
continues
to
review
it
so
still
marching
on.
A
Let's
see
the
shorted
blue
store
work,
so
I've
been
I
ran
through
tests
last
week.
Of
that
it
seems
to
work.
Great,
no
I
ran
to
no
errors
with
it.
I
don't
know
if
it's
still
hitting
any
issues
in
thorgy,
but
at
least
for
me
it
had
no
no
issues
from
a
performance
standpoint.
I
didn't
really
do
much,
but
none
of
my
tests
were
limited
by
compaction
and
that's
really
where
it
seems
like
we
are
seeing
the
primary
benefit
from
it.
A
Is
that
it
it
does
appear
to
lower
compaction
over
an
significantly
I
think
in
the
test.
I
was
looking
at
between
four
to
six
times
less
write
amplification
during
compaction.
So
that's
exciting
that
should
potentially
help
in
a
lot
of
situations
where
people
are
hitting
that
with
very
large
OSD
databases.
So
it
looks
good
to
me,
I
think
if
it's
passing
tautology,
we're
ready
to
merge.
A
C
C
A
C
C
A
Alright
and
then
there
was
some
motion
on
the
I/o
uring
engine
PR
from
Roman
and
Sue's,
a
chief
who
went
back
and
installed
a
new
kernel
to
test
that
again,
his
test
results
were
a
little
weird
with
live
a
oh,
he
was
seeing
really
really
slow,
read
performance
to
the
point
where
it
to
me
at
least
it
looked
like
it
was.
Maybe
there
was
something
strange
going
on
with
those
results:
bio
urine
look
good
in
both
in
that
test
and
another
test.
A
So
I
think
if
everyone
is
an
agreement
that
it
looks
okay,
we
probably
can
merge
it.
The
only
kind
of
concern
I
have
is
that
it
requires
a
new
kernel
to
be
able
to
test
it
in
any
way,
so
we
won't
be
able
to
really
support
it.
Well,
unless
we
keep
a
machine
in
a
house
that
has
a
non-standard
10,000
row
kernel
so,
especially
for
downstream,
we
probably
want
to
be
a
little
bit
careful
with
this
I
I
wonder
a
little
bit.
We
should
market
experimental
for
now,
but
anyway
it
seems
to
be
working.
A
A
The
the
downside
with
this
PR
is
that
it
does
introduce
more
locking
contention
in
the
blue
store
cash
cards.
Oh
no
cash
cards
specifically,
and
it
is
a
little
slower
because
of
that.
Having
said
that,
it
looks
like
we
probably
can
mitigate
it.
Pretty
much
I
think,
probably
almost
entirely
by
increasing
the
number
of
blue
store.
Oh
no
cash
cards,
so
so
the
latest
version
that
PR
also
kind
of
disassociates
the
number
of
cash
droids
with
the
number
of
OSD
up
charts.
A
Is
that
what
we
call
it
I'm
off
shorts
yeah
previously
they
were
set
together.
This
basically
lets
you
set
them
independently
and
then
set
a
no
larger
number
of
cash.
Shirts
I
think
that's
probably
enough
to
basically
kind
of
mitigate.
Most
of
the
downsides
of
it,
while
keeping
some
of
the
upsides,
but
if,
if
anyone
is
kind
of
interested
in
this
stuff,
you
know
certainly
take
a
look
at
it.
A
If
you
think
there's
a
better
way
to
accomplish
the
same
thing,
yeah
I'm,
not
sure
it's
different
trade-offs,
so
yeah
that
was
the
only
thing
I
was
gonna
mention
any
anyone
have
any
questions
about
that
or
have
other
topics
they
will
bring
up
this
week.
D
Well,
my
results
look
pretty
good
except
the
one
case,
which
is
my
latest
PR,
making
single
like
a
TOEFL
score
and
Lopez.
In
this
case,
the
performance
for
small
rights
drops
dramatically.
I
did
some
analysis
on
that
and
it
looks
like
it's
caused
by
looking
contention
within
bitmap
allocator,
so
right
now,
I'm
trying
to
refactor
the
locator
by
introducing
the
Rocha
several
sharks
with
independent,
lock
breach,
but
well,
that's
mostly
more
relevant
for
single
allocated
staff
and
all
fit
4k.
D
A
I
am
I,
ran
through
some
tests
on
our
the
new
nodes
that
Intel
donated
for
the
community
with
their
newer,
TV
46:10
and
an
option
drives
in
them,
and
it
was
actually
significantly
faster
with
the
4k
Menelik
size
and
that's
an
that
is
with
16
K,
which
it
was
surprising
to
me
how
much
of
a
difference
it
made
positive
difference.
It
was
like
25
to
30
percent,
faster
I.
D
D
Iii,
don't
recall
anything
very
bad.
All
those
cases
may
be
no
benefit
at
all.
There's
some
in
significant
differences
case,
but
I
am
planning
to
to
do
the
three
tests
you
use
earnest
and
alone
a
fire
plugin
once
I'm
done
with
locator
stuff,
oh
well,
at
least.
Actually
we
have
two
settings.
They
have
different
settings
for
decays
and
for
SSD
one
followed
for
this
mean
Alex
I
saw
wait.
D
D
A
D
Saw
some
well
actually,
we
back
ported
lofs
monoxide
to
luminous
as
well,
so
they
are
probably
the
same.
Oh
that's
not
the
case
but
anyway.
Well,
it's
I
least.
A
A
All
right,
well,
anything
else
guys
are
to
be
reputable
early
today.