[Feature flag] Rollout of `trace_memory_allocations`
What
Remove the :trace_memory_allocations
feature flag ...
Related to:
Owners
- Team: Memory
- Most appropriate slack channel to reach out to:
#g_memory
- Best individual to reach out to: @ayufan
Expectations
What are we expecting to happen?
Logs will contain mem_objects
, mem_mallocs
, mem_bytes
.
What might happen if this goes wrong?
Ruby process in the worst case can crash. So far it was not observed on staging.
What can we monitor to detect problems with this?
Check how often did process restart in a given period. Detect a higher than usual value. We expect the graph a rate of how many changes process start-up time to be within the average. This will of course be a little higher during upgrade of GitLab fleet.
Roll Out Steps
-
Enable on staging ( /chatops run feature set trace_memory_allocations true --staging
) -
Test on staging -
Coordinate a time to enable the flag with the SRE oncall and release managers - In
#production
mention@sre-oncall
and@release-managers
. Once an SRE on call and Release Manager on call confirm, you can proceed with the rollout
- In
-
Enable on GitLab.com by running chatops command in #production
(/chatops run feature set trace_memory_allocations true
) -
Cross post chatops Slack command to #support_gitlab-com
(more guidance when this is necessary in the dev docs) and in your team channel -
Remove feature flag and add changelog entry -
After the flag removal is deployed, clean up the feature flag by running chatops command in #production
channel
Rollback Steps
-
This feature can be disabled by running the following Chatops command:
/chatops run feature set trace_memory_allocations false
Edited by Changzheng Liu