►
From YouTube: GitLab 13.8 Kickoff - Enablement:Memory
Description
Kickoff for the 13.8 release for the memory team.
Planning issue: https://gitlab.com/gitlab-org/memory-team/team-tasks/-/issues/81
A
A
We
currently
recommend
at
least
four,
so
this
was
an
exploratory
exercise
conducted
in
a
synchronous
manner
with
the
team
and
as
an
outcome
of
that
we've
identified
several
issues
with
the
potential
memory
savings
that
we're
going
to
work
on
in
the
new
release,
13.8
and
ideally,
or
very
likely.
Also
beyond
that,
so
I'll
walk
you
through
some
of
the
most
impactful
changes
that
we
will
be
able
to
make.
A
A
There
are
some
changes
to
the
gc
compaction
before
four
king
puma
workers
that
we're
going
to
make
that
are
going
to
happen
in
13.8
and
also
running
puma
in
a
single
mode
for
a
constrained
environment.
So
those
are
ongoing
efforts
and
working
with
puma
and
configuring
it
in
such
a
way
that
it
reduces
less
memory
is
one
of
our
priorities.
A
Another
angle
of
attack
is
splitting
the
application
into
functional
parts
to
ensure
that
only
needed
code
is
loaded
with
all
dependencies,
and
that
also
makes
intuitive
sense.
We
should
really
only
load
the
parts
of
gitlab
that
are
needed
and
not
keep
all
the
dependencies
and
unneeded
other
parts
in
in
memory
if
we
can
avoid
it.
So
this
is
going
to
address
that
concern
and
investigate
how
that
works.
A
A
rather
large
item
that
has
been
broken
down
quite
well
by
one
of
our
engineers
here
is
the
gitlab
exporter
functionality,
and
so
we
are
exporting
some
parts,
some
metrics
via
github
exporter,
but
this
is
actually
a
relatively
old
part
of
git
lab.
There
are
several
metrics
endpoints
in
here
that
we
may
be
able
to
migrate
out
of
the
gitlab
exporter
into
more
modern
parts
of
the
applications.
A
Other
parts
of
the
application
and
there's
a
wider,
interesting
consideration
here
to
understand
that
the
metrics
stack
all
of
the
applications
that
have
to
do
with
monitoring
and
the
metrics
that
we
expose
consumes
a
relatively
large
amount
of
memory,
and
so
working
with
the
github
exporter
is
one
of
the
ways
of
reducing
the
memory
footprint
right
now.
There
may
be
some
future
work
as
well
to
understand
what
parts
of
the
metrics
and
monitoring
are
required,
especially
for
small
instances.
A
Finally-
and
there's
always
a
question
of
how
do
we
actually
measure
the
memory
improvements
against
the
baseline
metrics,
so
the
important
thing
here
to
know
is
that
this
is
an
ongoing
effort.
We
are
continuing
to
discuss
how
we
do
this
best
in
13.8
to
understand
the
impact
that
we're
making.
Essentially,
if
there's
a
change,
we
want
to
understand
how
does
that
impact?
Github,
summary
behavior
and
there's
a
wider
range
of
things
that
we
can
do
to
also
understand
trends
over
time.
A
So
we
are
discussing
about
the
logo
for
the
gitlab
memory
team,
and
this
was
graciously
designed
by
the
enablement
designer
synching.
So
you
may
see
me
wearing
a
gitlab
memory
hoodie
next
time.
I
present
this.
So
thanks
again,
I
hope
you
have
a
great
rest
of
the
year
and
that's
it
from
the
memory
team.