Memory Group - 15.1 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
The group will be at 65% capacity due to a team member on parental leave and another one in the process of relocating.
Planning
%15.1
Top Priorities forInvestigate Puma long-term memory use
Who: @mkaeppler
We have observed that Puma can see climbing memory use in production over a period of days, especially during weekends, where there are no deploys that would reset these gauges. Meanwhile, this is also affecting self managed instances; we are getting an increased number of customer reports complaining that the Puma memory killer frequently kills Puma processes, which causes throughput issues.
We plan to investigate further and try to figure out the reason for any potential runaway memory issues, be it just Ruby heap fragmentation or a memory leak.
Related issue that may also be addressed depending on the findings: gitlab-org/gitlab#334831 (closed)
Update supported Ruby version to 3.0
Who: @alipniagov
(@rzwambag
as a secondary priority)
In %15.0 we have achieved our primary goal of achieving a green Ruby 3 GitLab build
In %15.1 we plan to remove any other remaining blockers and work towards adding Ruby 3 builds for various components and GitLab libraries. We don't expect to switch our ruby 2 and ruby 3 testing pipelines yet, but we'll be monitoring and prepare for when we are ready to build Ruby 3 by default.
Create custom SLIs for Global Search
Who: @rzwambag
The existing SLI for global search is defined over a single end point (/search
). That means that there is no visibility for the performance or other issues encountered on the different types of searches (basic / advanced) or scopes (e.g. code, issues, merge requests, etc).
Those types of searches and scopes vary in execution approach (through Elastic Search, PostgreSQL or even Gitaly) and characteristics, which makes the aggregate performance and error metrics not that useful.
We want to support groupglobal search on setting up the custom SLIs for this overloaded end point. We will follow the results of the discussion with the Scalability team and start by introducing the global_search_apdex
and global_search_success
custom SLIs. We will also evaluate how can we facilitate the introduction of the global_search_indexing_apdex
custom SLI.
%15.1
Secondary Priorities forImprove efficiency and maintainability of application metrics exporters
Who: @mkaeppler
We are revisiting our approach for serving application metrics into Prometheus by adding a new metrics exporter for GitLab application metrics which is written in Golang.
In %15.1 we will continue our work towards the production readiness of gitlab-metrics-exporter
:
-
Phase 1: run in sidecar mode
- Our primary goal with this phase is to replace the existing in-app Ruby Prometheus exporters distributed with and running in gitlab-rails.
Note Due to our capacity constraints this is switched to a secondary priority that will follow the completion of the investigation of Puma's long-term memory usage.