►
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
Hi
everyone,
so
this
is
the
application
performance
kickoff
session
for
15a
GitHub
release.
Today,
I
have
Alexi
and
I
will
introduce
the
features
that
we
are
going
to
do
in
the
next
release.
I
also,
we
have
a
special
guest
Roger
joining
us
as
a
PM
for
this
group.
A
So
welcome
Roger
excited
to
be
ramping
up
here,
so
yeah,
okay,
cool,
so
first
topic
that
I'm
going
to
cover
is
the
Ruby
version
3
upgrade,
and
so,
as
we
know
that
the
Ruby
2.7
end
of
life,
support
will
be
marked
2023.
So
there
is
an
urgency
for
us
to
upload
to
to
the
Ruby
three
in
the
157
release.
A
We
completed
our
gem
audit
for
Ruby
3
compatibility
and
in
the
next
release
we
will
be
supporting
other
engineering
groups
to
fix
the
issues
that
we
find
in
that
audit,
and
also
we
will
try
to
achieve
our
pipeline
to
be
running
green
with
the
Ruby
3
version,
so
that
that
will
help
us
to
eventually
upgrade
our
system
to
Ruby.
Three
I
will
hand
over
to
Alexi
for
the
next
topic.
B
Yeah,
the
next
topic
we're
going
to
cover
in
15.8
Milestone,
is
investigating
Puma,
long-term
memory
use
and
in
15.7
we
allowed
the
ability
to
collect
through
the
General
reports
and
in
this
Milestone
we
will
work
on
ability
to
collect
Ruby,
hip
dumps
and
obtaining
these
hip
dumps
will
allow
us
to
cause
investigation,
investigate
potential
memory,
issues
of
the
application
and
make
a
data-driven
decisions
on
fixing
them,
and
also
there
are
certain
topics
coming
up
to
this
epic,
for
example.
B
B
That's
it
for
Puma,
long-term
memory
use
theme
and
the
next
epic
we
are
going
to
work
on
is
gitlab
memory,
exposure
production
rollout.
So
in
previous
releases
we
introduced
gitlab
memory
exposure
which
will
replace
our
Ruby
exporter
for
metrics
EA
GitHub
memory.
Exporter
is
considered
to
be
faster,
but
currently
we
have
a
memory
issue
we
are
currently
investigating.
So
in
the
next
Milestone
we
plan
to
resolve
this
memory
issue
make
gitlab
memory.
Exporter,
production,
ready
and
roll
it
out
and
the
next
one
is
for
you,
City
yeah,.
A
The
next
topic
that
we
are
going
to
work
on
is
a
fixed
and
fine-tuning
psychic
memory
killer
that
so
we
have
worked
on
with
the
psychic
process,
memory
Killers,
which
will
kicked
in
and
restart
the
process.
When
the
memory
usage
of
psychic
goes
beyond
a
threshold
and
in
our
system
we
have
a
different
memory
pillars
for
different
type
of
processes.
A
We
implemented
a
new
memory
killer,
we
called
it
a
watchdog,
so
we
are
going
to
use
this
Watchdog
to
manage
all
other
processes,
Puma
processes
and
also
the
psychic
processes.
So
in
the
next
release
we
are
going
to
experiment
switching
and
the
existing
psychic
memory
killer
with
our
new
watchdog,
and
this
should
shouldn't
be
any
difference
or
user
experience
for
our
customers.
A
So
we
don't
expect
it.
This
will
be
disruptive.
However,
we
will
keep
the
old
psychic
memory
killer
for
a
few
releases
before
we
completely
remove
it.
Just
like
in
case
some.
Some
unexpecting
happens
and
I
think
this
can
be
configurable,
it's
user
configurable.
A
The
users
can
choose
like
which
memory
header
they
are
going
to
use
in
their
deployment
yeah.
But
the
other
goal
is
to
use
the
watchdog
and
to
replace
all
the
ecosystem
memory
cards
for
different
processes.
B
No
yes
for
this
topic,
yes
and
last
but
not
least,
we
are
currently
our
team
is
working
on
writing
and
proposal
to
using
radio
success
control
list
to
restrict
access
to
certain
commands.