From: "ko1 (Koichi Sasada) via ruby-core" Date: 2023-04-14T02:43:31+00:00 Subject: [ruby-core:113239] [Ruby master Feature#19571] Add REMEMBERED_WB_UNPROTECTED_OBJECTS_LIMIT_RATIO to the GC Issue #19571 has been updated by ko1 (Koichi Sasada). > We have very few unprotected objects, so our remembered_wb_unprotected_objects_limit was very low. This meant that we reached the limit very frequently, which triggered major GC very frequently. But because we have a lot of old objects, we have to scan a few million old objects and we only free a few thousand remembered WB unprotected objects. This caused poor p99 response times. It makes sense. I understand this proposal introducing better *lower-bound* to kick the major gc because of remembered WB-unprotected objects. They are not clear. * ratio to the old objects is acceptable? * how we confirm the 1% is best on default. * I'm afraid that (as you said) 2% is too much but 0.5% is too short on the Shopify app it can hurts other applications. To make analysis, can you logging measurements on each GC? One example is using https://github.com/ko1/gc_tracer (but not sure it works on 3.3dev). and culd you observe similar benefits on railsbench or other benchmarks? ---- To make it correctly, maybe we need to make a model and predict how many remembered WB-unprotect objects can be collected on the next major GC, and compare the costs with (1) minor gc performance because of remembered WB-unprotected objects (they are root objects) (2) major gc cost. ---- > We also found that a lower number (e.g. 0.005 or 0.0025) did not perform as well either. could you give us details? too many major gc because of it? >> This parameter is ratio for the "old objects" so I'm not sure it makes sense. > Do you mean RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR being used to calculate remembered_wb_unprotected_objects_limit? I agree in this case. It is confusing that RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR is used to calculate both old_objects_limit and remembered_wb_unprotected_objects_limit. I agree it is weird (I never think someone find this parameter). Anyway, I meant that the name `REMEMBERED_WB_UNPROTECTED_OBJECTS_LIMIT_RATIO` seems it will be applied on the number of "REMEMBERED_WB_UNPROTECTED_OBJECTS" to calc the limit (not for the number of old objects). ---------------------------------------- Feature #19571: Add REMEMBERED_WB_UNPROTECTED_OBJECTS_LIMIT_RATIO to the GC https://bugs.ruby-lang.org/issues/19571#change-102790 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/7577 The proposed PR adds the environment variable `RUBY_GC_HEAP_REMEMBERED_WB_UNPROTECTED_OBJECTS_LIMIT_RATIO` which is used to calculate the `remembered_wb_unprotected_objects_limit` using a ratio of `old_objects`. This should improve performance by reducing major GC because, in a major GC, we mark all of the old objects, so we should have more uncollectible WB unprotected objects before starting a major GC. The default has been set to 0.01 (1% of old objects). On one of [Shopify's highest traffic Ruby apps, Storefront Renderer](https://shopify.engineering/how-shopify-reduced-storefront-response-times-rewrite), we saw significant improvements after deploying this patch in production. In the graphs below, we have the `tuned` group which uses `RUBY_GC_HEAP_REMEMBERED_WB_UNPROTECTED_OBJECTS_LIMIT_RATIO=0.01` (the default value), and an `untuned` group, which turns this feature off with `RUBY_GC_HEAP_REMEMBERED_WB_UNPROTECTED_OBJECTS_LIMIT_RATIO=0`. We see that the tuned group spends significantly less time in GC, on average 0.67x of the time compared to the untuned group and 0.49x for p99. We see this improvement in GC time translate to improvements in response times. The average response time is now 0.96x of the time compared to the untuned group and 0.86x for p99. ![](Screenshot%202023-04-03%20at%2011.39.06%20AM.png) ---Files-------------------------------- Screenshot 2023-04-03 at 11.39.06 AM.png (554 KB) -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/