## Problem One of the goals of the ~"group::memory" team is to ensure GitLab can support smaller instances sizes, and one of the biggest challenges with that is our memory consumption. Currently we say 4GB of RAM and 4GB of swap is the recommended minimum size. ## Goals We should target certain common machine types as goals for reducing our memory consumption. Targets identified today: * [ ] 4 GB RAM: Common 2vCPU 4GB RAM configuration, for example `t2.medium` * [ ] 3.75 GB RAM: On GCP, `n1-standard-1` instances only have 3.75GB of RAM and 1vCPU * [ ] 2GB RAM: Raspberry Pi and other SBC's (https://gitlab.com/groups/gitlab-org/-/epics/3524), as well as some `high cpu` instance types like `n2`, `e2` and `t3a.small`. * [ ] 1.8GB RAM: `n1-highcpu-1` ## Estimated memory savings by issue | Issue | Link | Estimated memory reduction (MB) | |-------|------|---------------------------------| | Extend Omnibus to automatically disable non-essential services (monitoring) if running in constrained environment | gitlab-org/gitlab#291039 | TBD | | Reduce memory impact of GitLab Monitoring | gitlab-org/gitlab#290738 | 350MB | | Optimise GC and jemalloc of GitLab | gitlab-org/gitlab#289838 | TBD | | Run GC compact before forking into Puma workers | gitlab-org/gitlab#288042 | (1) - ~20 MB for the master process which affects every worker | | Reduce Puma's memory footprint | https://gitlab.com/groups/gitlab-org/-/epics/5034| 250 MB | | Reconsider gitlab-exporter's role in monitoring | https://gitlab.com/groups/gitlab-org/-/epics/5035 | 30MB | | Find mechanism to dynamically load gems | gitlab-org/gitlab#288044 | Tens of MB (2) | | Optimise GC and jemalloc of all other processes other than GitLab Rails | gitlab-org/gitlab#289842 | TBD | | Rework docs for running GitLab on constrained environments | gitlab-org/gitlab#291037 | - | (1) This does not so much result in raw bytes saved rather than a cleaner memory layout, which could then _enable_ bytes saved, depending on the overall memory requirements by the app (and how the GC is tuned) (2) You cannot put a single number on this because it will not affect every service or even customer equally. It will benefit those users most that run many replicas of a particular service. For example, [Remove GraphQL gem ](https://gitlab.com/gitlab-org/memory-team/memory-team-2gb-week/-/issues/9) showed that with just disabling Graphql gem, we will save ~17Mb, and by not loading Graphql files, we will load 1274 files less on boot time. ## Exit Criteria There are a few items we've discussed regarding exit criteria for this epic. - Identify memory savings implemented - Including detailing the smallest memory footprint we comfortably support - Identify issues for future memory savings - We are time boxing our efforts. There may be some issues that don't make sense to address now. For those ideally we can identify a backend team to own for future milestone consideration. - [Create documentation outlining the differences of running GitLab in a Memory Constrained Environment (#289909) ](https://gitlab.com/gitlab-org/gitlab/-/issues/289909)