►
From YouTube: GitLab 15.1 Kickoff - Enablement:Memory
Description
Kickoff for the Memory Group for the GitLab 15.1 release
Planning issue: https://gitlab.com/gitlab-org/memory-team/team-tasks/-/issues/115
Memory Group Past Kickoff Videos: https://youtube.com/playlist?list=PL05JrBw4t0Kq1HDOIfQ8ov6lfyJkWK2Yr
Presentation by: Yannis Roussos, Sr. Product Manager, Memory and Database Groups
A
So
let
me
take
you
through
our
top
priorities.
Our
first
priority
is
investigating
the
puma
long-term
memory
issues
that
we
see
so
puma
is
our
the
web
server
that
abuses.
So
we
have
noticed
that
puma
can
see
climate
memory
usage
in
production
of
github.com
over
a
period
of
period
of
days.
So
let
me
zoom
in
so
here
in
blue.
A
You
can
see
the
average
memory
that
our
puma
fleet,
our
puma
servers,
use,
and
you
can
see
it
going
up
and
whenever
we
make
a
deployment
goes
back
down
and
up
and
down,
but
during
weekends,
when
we
don't
run
in
deployments,
you
can
see
it's
very
evident
that
goes
up
and
up
and
up
until
we
do
the
next
deployment
on
a
monday
morning.
In
contrast,
you
can
see
in
yellow
it's
the
other
average
memory
of
the
side,
flip
fleet,
so
sighting
is
the
way
we
run
background
jobs.
A
You
can
see
it
also
having
some
variants
and
going
up
it
down,
but
during
the
weekend,
when
we
don't
do
when
we
don't
have
a
lot
of
traffic,
you
can
see
plateauing,
which
is
what
we
would
expect
also
for
women.
So
that
indicates
to
us
that
we
may
have
a
potential
a
runaway
memory
issue
and
we
want
to
investigate
and
find
the
root
cause
and
fix
the
problem.
It
may
be
just
a
hit:
a
ruby
heap
fragmentation
or
a
memory
leak
or
whatever,
whatever
it
is.
A
It
affects
the
performance
of
our
servers
and
we
want
to
figure
out
ways
figure
out
what
the
problem
is
and
fix
it.
This
is
also
very
important
for
self-managed
instances,
because
we
are
getting
the
reports
from
self-managed
instances
that
the
puma
memory
killer
frequently
kills
the
puma
processes
due
to
too
much
memory
which
causes
throughput
issues.
So
this
will
once
we
feel
gear
out
and
fix
the
root
cause.
We
will
hopefully
affect
and
help
a
lot
with
our
self-managed
instances
as
a
secondary
follow-up.
We
also
after
the
investigation
completes.
A
We
may
also
increase
the
max
memory
per
movement
which,
by
default,
is
a
bit
too
low,
so
we
may
increase
it
a
little
bit
more
like
we
have
done
git.com,
that's
why
we
don't
see
those
restarts
at
all
in
gitlab.com.
A
Our
second
priority
is
upgrading
the
supported
ruby
version
to
3.0.
So
during
15.
15.0
we
reach
a
major
milestone.
So
now
we
have
a
green
ruby,
3
hitler
build,
and
so
that
means
that
we
are
now
running
a
secondary
pipeline,
say
pipeline
against
ruby
3
every
few
hours,
so
our
next
steps
for
15.1
will
be
to
remove
any
additional
blockers
that
we
may
have
and
continue
with
achieving,
having
ruby3
builds
for
all
gitlab
components
and
libraries.
A
Our
next
priority
is
creating
slice
and
slos
for
global
search.
So
let
me
show
you
how
global
search
works.
This
is
an
amazing
feature
where
global
search
group
has
built.
So
if
I
say
here
on
the
top
pane,
we
have
this
search
bar.
If
I
search
for
for
four
months-
optimization,
for
example,
not
like
that
yeah,
I
added
an
end
here.
A
So
you
can
see
that
with
the
global
search
feature
we
can
search
over
most
features
that
we
offer
we
are
searching
in
gitlab.
So,
for
example,
here
I'm
searching,
I
have
searches
for
on
epics,
all
epics,
that
reference
performance,
optimization
or
I
can
search
for
issues
that
are
related
to
the
to
the
search
terms,
merge
requests
and
even
code,
which
is
an
amazing
new
feature
that
the
global
search
group
is
working
on,
and
I
find
it
very
useful
when
I
try
to
find
things
in
our
code.
So
this
is
a
catch-all.
A
This
is
a
a
huge
feature
where
we
can
search
all
over
the
place
and
against
completely
different
things
in
gitlab.
So
what's
the
problem
here
so,
as
you
can
see,
as
I
move
around
those
things
are
completely
different.
So,
for
example,
on
epics
we
go
and
search
on
posters
on
our
using
the
running
queries
on
our
postgresql.
A
While
on
issues
we
may
use
our
postgresql
or
if
advanced
search,
which
is
a
premium
gitlab
feature,
is
enabled
we
use
the
elasticsearch
indexes
that
we
have
either
on
github.com
or
a
self-managed
instance,
and
the
same
is
true
for
other
features.
Like
searching
through
codes
or
even
commits
where
you
can
go
through
an
elastic
search
index
or
directly
contact
digitally
and
to
search
through
the
community
indeed,
so
that
the
implementation
of
all
those
different
tabs
is
completely
different
and
the
characteristics
are
also
different.
A
So
it's
because
it's
different
searching
through
epics
than
searching
through
code,
for
example.
The
problem
is
that,
as
you
can
see
up
here,
we're
using
the
same
endpoint.
So
all
those
things
are
running
are
sending
requests
to
slash
search.
A
If
I
go
here,
it's
also
searched
and
what
changes
is
the
scope
so,
depending
on
the
scope,
we
are
doing
something
completely
different
and
at
the
moment,
because
we're
using
a
single
endpoint,
the
matrix
that
we
have
this
lies
so
the
way
that
we
gather
and
track
our
performance
and
error.
Metrics
are
reported
back
to
us
in
aggregate.
So
all
those
features
together
are
grouped
in
aggregate
together.
A
Finally,
our
last
priority:
this
is
a
long-term
priority
initiative
that
we
are
running.
We
have,
we
are
setting
it
as
a
secondary
priority
due
to
various
capacity
constraints.
We
have
this
milestone,
so
we
will
work
on
it
after
we're
done
with
the
puma
memory
issues,
and
we
have
covered
that
more
pressing
issue.
So
on
this
one
is
the
introduction
of
the
new
gitlab
matrix
exporter,
which
is
written
in
golem,
it's
more
than
eight
times
faster
than
our
existing
implementation.