Application Performance Group - 15.6 Planning

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Capacity

List any noteworthy PTO that may impact the capacity for the planned milestone

Planning

Indicate major efforts by linking to the appropriate epic. Under each epic indicate who is focusing on these efforts and list the individual issues assigned for this milestone.

Top Priorities for %15.6

Update supported Ruby version to 3.0

Who: @mkaeppler @rzwambag

As Ruby 2.7 EOL is expected to be March 2023 based on life expectancy of previous major releases, the ~"group::application performance" has been putting a lot of effort into the upgrade and reached a point where we were about to run the Ruby 3 pipeline on the main branch. As we are approaching the expected Ruby 2.7 EOL, we hope to finish the whole rollout in the next few milestones. In %15.6, our focus will be

Investigate Puma long-term memory use

Who: @alipniagov

In prior releases, we have added abilities to collect more metrics and diagnostic reports to help us troubleshoot GitLab instances' memory and performance issues. Currently, you could access them only by having SSH access to web server machines and the access is limited to SREs. Our goal is to enable engineers across the company, starting with Application Performance, with the ability to access such reports without requesting help from SREs. It would greatly speed up the feedback cycle and will allow us to iterate and investigate performance and memory problems faster, by having on-demand access to the data. It would also allow engineers to expand the diagnostic reports system by adding new reports. The consolidated high-level vision was that we should upload these reports to the dedicated Google Cloud Storage bucket available for engineers.

In %15.5, we explored multiple implementation approaches for solving that task. We also explored (and still continue) various performance and architectural concerns of every approach. We started implementing the report uploader based on the proposal from an internal discussion. In %15.6, we will continue to finish the uploader and enable it on GitLab.com.

Fixing and fine-tuning the Sidekiq memory killer

In prior releases, we have added the ability to use Sidekiq memory killer in read-only mode. We also introduced more metrics and better logging to help us to better understand what happens when we try to restart'

Since sidekiq memory killer currently does not kick in production. Our goal is to fine-tune the configuration for each sidekiq-shard, finding soft-spot that will allow sidekiq memory killer to kick in, but not too aggresivly.

In %15.6, we will continue Fine-tuning the Sidekiq memory killer, hopefully reducing the number of OOM kills.

Who: @nmilojevic1

Additional Issues for consideration

Kickoff Video

Edited by Changzheng Liu