ruby-core

Issue #20443 has been updated by eightbitraptor (Matthew Valentine-House).


matz (Yukihiro Matsumoto) wrote in #note-20:
> First, If you clearly define what would happen when the (plugged) GC does=
 not generational scanning, I am OK for it. @byroot told me that calling th=
ose methods would raise `NotImplementedError` when GC does not provide gene=
rational GC.
>=20
> For API, I don't like the name `needs_major?`. At least, it should be `ne=
ed_major?` to follow Ruby's naming convention (no third-person singular pre=
sent).
>=20
> And in the developers' meeting, @byroot proposed `GC.config(full_mark: tr=
ue)`. How do you think?
>=20
> Matz.

I really like the idea of having a set of config parameters to the GC. That=
 seems like a much more robust way of providing custom features to the GC w=
ithout having to make new methods every time.

So, based on the latest discussions, what I'd like to propose is this:=20

* Introduce `GC.config`, currently with a single key `full_mark`.
  * `full_mark: true` should be the default behaviour - ie. the GC will wor=
k as it currently does.
* Ruby code can set `full_mark` to false like this: `GC.config(full_mark: f=
alse)` - In this case, no major GC's will be run unless explicitly requeste=
d using `GC.start(full_mark: true)`
* A user can check whether a major GC is needed at any time by checking `GC=
.latest_gc_info(:needs_major_by)`. Any value other than `nil` means that th=
e GC would do a major on the next invocation.

I think this has a few benefits over the existing approach that I proposed =
in this ticket

1. Introduces a flexible way of providing config information to the GC. Thi=
s will also allow pluggable GC's implemented in the future to define their =
own config keys without changing the interface of the `GC` module.
2. Does not introduce any new methods that are implementation specific to t=
he current GC. This removes the decision about how future GC module needs t=
o respond to these methods.


----------------------------------------
Feature #20443: Allow Major GC's to be disabled
https://bugs.ruby-lang.org/issues/20443#change-108763

* Author: eightbitraptor (Matthew Valentine-House)
* Status: Open
----------------------------------------
[[Github PR #10598]](https://github.com/ruby/ruby/pull/10598)

## Background

Ruby's GC running during Rails requests can have negative impacts on curren=
tly
running requests, causing applications to have high tail-latency.

A technique to mitigate this high tail-latency is Out-of-band GC (OOBGC). T=
his
is basically where the application is run with GC disabled, and then GC is
explicitly started after each request, or when no requests are in progress.

This can reduce the tail latency, but also introduces problems of its own. =
Long
GC pauses after each request reduce throughput. This is more pronounced on
threading servers like Puma because all the threads have to finish processi=
ng
user requests and be "paused" before OOBGC can be triggered.

This throughput decrease happens for a couple of reasons:

1. There are few heuristics available for users to determine when GC should=
 run,
this means that in OOBGC scenarios, it's possible that major GC's are being=
 run
more than necessary.  2. The lack of any GC during a request means that lot=
s of
garbage objects have been created and not cleaned up, so the process is usi=
ng
more memory than it should - requiring major GC's run as part of OOBGC to d=
o
more work and therefore take more time.

This ticket attempts to address these issues by:

1. Provide `GC.disable_major` and its antonym `GC.enable_major` to disable =
and
enable only major GC 2. Provide `GC.needs_major?` as a basic heuristic allo=
wing
users to tell when Ruby should run a Major GC.

These ideas were originally proposed by @ko1 and @byroot in [this rails
issue](https://github.com/rails/rails/issues/50449)

Disabling GC major's would still allow minor GC's to run during the request=
,
avoiding the ballooning memory usage caused by not running GC at all, and
reducing the time that a major takes when we do run it, because the nursery
objects have been cleaned up during the request already so there is less wo=
rk
for a major GC to do.

This can be used in combination with `GC.needs_major?` to selectively run a=
n
OOBGC only when necessary

## Implementation

This PR adds 3 new methods to the `GC` module

- `GC.disable_major` This prevents major GC's from running automatically. I=
t
  does not restrict minors. When `objspace->rgengc.need_major_gc` is set an=
d a
  GC is run, instead of running a major, new heap pages will be allocated a=
nd a
  minor run instead. `objspace->rgengc.need_major_gc` will remain set until=
 a
  major is manually run. If a major is not manually run then the process wi=
ll
  eventually run out of memory.
 =20
  When major GC's are disabled, object promotion is disabled. That is, no
  objects will increment their ages during a minor GC. This is to attempt t=
o
  minimise heap growth during the period between major GC's, by restricting=
 the
  number of old-gen objects that will remain unconsidered by the GC until t=
he
  next major.
 =20
  When `GC.start` is run, then major GC's will be enabled, a GC triggered w=
ith
  the options passed to `GC.start`, and then `disable_major` will be set to=
 the
  state it was in before `GC.start` was called.
 =20
- `GC.enable_major` This simply unsets the bit preventing major GC's. This =
will
  revert the GC to normal generational behaviour. Everything behaves as def=
ault
  again.

- `GC.needs_major?` This exposes the value of `objspace->rgengc.need_major_=
gc`
  to the user level API. This is already exposed in
  `GC.latest_gc_info[:need_major_by]` but I felt that a simpler interface w=
ould
  make this easier to use and result in more readable code. eg.
 =20
```
out_of_band do=20
  GC.start if GC.needs_major? =20
end=20
```

Because object aging is disabled when majors are disabled it is recommended=
 to
use this in conjunction with `Process.warmup`, which will prepare the heap =
by
running a major GC, compacting the heap, and promoting every remaining obje=
ct to
old-gen. This ensures that minor GC's are running over the smallets possibl=
e set
of young objects when `GC.disable_major` is true.

## Benchmarks

We ran some tests in production on Shopify's core monolith over a weekend a=
nd
found that:

**Mean time spent in GC, as well as p99.9 and p99.99 GC times are all
improved.**=20

<img width=3D"1000" alt=3D"Screenshot 2024-04-22 at 16 41 49"
src=3D"https://github.com/ruby/ruby/assets/31869/6cff5b11-2e21-40c1-bb84-d9=
94e0e1798d">

**p99 GC time is slightly higher.**=20

<img width=3D"1000" alt=3D"Screenshot 2024-04-22 at 16 44 55"
src=3D"https://github.com/ruby/ruby/assets/31869/dc645cbe-9495-46f0-8485-24=
e790c42f32">

We're running far fewer OOBGC major GC's now that we have `GC.needs_major?`=
 than
we were before, and we believe that this is contributing to a slightly incr=
eased
number of minor GC's. raising the p99 slightly.

**App response times are all improved**

We see a ~2% reduction in average response times when compared againststand=
ard GC=20
(~7% p99, ~3% p99.9 and ~4% p99.99).

<img width=3D"1000" alt=3D"Screenshot 2024-04-23 at 09 27 17" src=3D"https:=
//gist.github.com/assets/31869/70e81fa5-77b2-469a-8945-88bf8f8fefe9">

This drops slightly to an a ~1% reduction in average response times when co=
mpared
against our normal OOBGC approach  (~6% p99, ~2% p99.9 and ~3% p99.99).

<img width=3D"1000" alt=3D"Screenshot 2024-04-23 at 09 27 29" src=3D"https:=
//gist.github.com/assets/31869/cbaa3807-0cd1-4dba-a5e6-b9df91024d73">


EDIT: to correct a formula error in the original Average charts, numbers up=
dated.=20

---Files--------------------------------
Capture d=E2=80=99e=CC=81cran 2024-04-22 a=CC=80 18.41.52.png (279 KB)


--=20
https://bugs.ruby-lang.org/

Thread

Prev Next

In This Thread

Prev Next