►
From YouTube: GitLab 13.11 Kickoff - Enablement:Memory
Description
Kickoff for the 13.11 release for the Memory team.
Planning issue: https://gitlab.com/gitlab-org/memory-team/team-tasks/-/issues/88
A
A
So
the
first
thing
to
know
is
that
the
team
is
currently
operationally
quite
involved
in
some
rapid
actions
to
resolve
performance
issues
on
the
overall
gitlab
platform.
So
the
planning
here
reflects
this,
because
we
have
some
sort
of
other
operational
work
to
do.
There's
not
as
much
new
going
on.
There
are
essentially
two
larger
themes
in
here
and
a
couple
of
things
that
prepare
us
for
the
major
release
for
14.0.
A
So
the
first
thing
that
I
wanted
to
talk
about
is
the
splitting
the
application
into
functional
parts
to
ensure
that
only
needed
code
is
loaded
with
all
dependencies,
and
this
has
been
something
where
nikola
was
really
involved
driving
this.
So
this
is
a
huge
architectural
change
that
provides
many
benefits
for
the
memory
team.
A
So
a
lot
of
work
has
gone
into
this
already
and
where
we
are
really
at
is
wrapping
up
the
ongoing
discussion
on
the
composable
code
base
and
then
based
on
the
outcomes
of
that
defining
very
clear
next
steps.
You
know
what
are
the
iterations
that
actually
bring
us
closer
to
a
world
where
gitlab
is
in
a
position
where
we
can
really
load
only
the
parts
that
we
that
we
need
and
require.
So
that's
something
that
will
happen
in
1311.
A
So
this
is
not
going
to
be
necessarily
an
actionable
sort
of
shipped
feature,
but
it
is
preparing
us
for
a
future
in
which
this
is
potentially
possible.
This
is
really
an
architectural
decision
that
also
requires
the
memory
team
to
provide
sort
of
information
and
guidelines
potentially
to
the
wider
gitlab
developer
community,
so
that
they
can
work
with
that
as
well.
A
A
That
now
allows
us
to
measure
sort
of
per
request
and
per
worker
memory
allocation
statistics,
and
that
is
really
valuable
because
it
allows
us
to
go
into
our
system
and
understand
in
detail.
You
know
what
feature
categories
or
what
specific
endpoints
use,
how
much
memory-
and
this
is
going
to
be
an
area
of
focus
for
us,
going
forward.
We're
going
to
focus
on
two
specific
components:
puma
and
side
kick.
A
What
we're
going
to
do
is
we're
going
to
identify
end
points
that
are
particularly
heavy
on
memory
allocation,
and
then
we
are
going
to
try
to
understand
how
we
can
actually
reduce
the
memory.
Consumption
fix
them
if
we
can
document
specific
patterns
that
we
observe
and
provide
ultimately
guidelines
and
maybe
in
a
later
iteration,
also
alerting
on
these
very
heavy
endpoints.
And
this
is
really,
I
think,
a
showcase.
For
you
know.
If
you
have
the
data,
you
can
look
at
specific,
problematic
areas.
You
can
really
understand.