Investigate the oddness of GC owned memory

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

I don't think that this is related to Puma at all, but to general understanding how Ruby consumes memory and where it is lost.

Per my comment here: https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/7381#note_213556198

This is interesting. I have taken snapshot from dev.gitlab.org with smem:

  PID User     Command                         Swap      USS      PSS      RSS 
32323 1100     puma 3.12.0 (unix:///var/op        0   172408   204888   438156 
113185 1100     puma: cluster worker 3: 323        0   357972   385891   608436 
78887 1100     puma: cluster worker 4: 323        0   352008   386969   625088 
42352 1100     puma: cluster worker 6: 323        0   374068   404699   635912 
33678 1100     puma: cluster worker 7: 323        0   378760   410972   643608 
50972 1100     puma: cluster worker 5: 323        0   389260   420204   649964 
54550 1100     puma: cluster worker 1: 323        0   390752   423360   656552 
71897 1100     puma: cluster worker 2: 323        0   458184   489466   720744 
23551 1100     puma: cluster worker 0: 323        0   513784   544489   772028 

It means that USS (Unique Set Size) is around 370-500MB. Which is total of 3.7GB of unique memory if you sum PSS (Proportional Set Size). The RSS is around 5.6GB. It means that per process we share around 250MB, because of copy-on-write pages.

There are a bunch of discrepancies:

1. ruby_memory_bytes is around 5.5GB,
2. The GC owned memory is nowhere around the sum of USS: currently around 800MB of allocated pages.

What is funny, it does mean that memory used by application itself (Ruby) is around 28%. Where is the rest?