Skip to content

WIP: PoC: Preload application and run web-and-actioncable separate but together

Kamil Trzciński requested to merge web-and-actioncable-together into master

What does this MR do?

This is proof of concept that allows us to run ActionCable TOGETHER BUT SEPARATE :)

  • Together: because we continue loading the whole application
  • Separate: as Web and ActionCable has its own Puma master and Puma worker

This allows us to model ActionCable separately from Web, but still have efficient memory usage profile due to sharing of copy-on-write pages.

This allows us to decide and on GitLab.com run actioncable designated nodes, but on-premise run in this model.

This results in:

git@db4de08cf21f:~/gitlab$ smem
  PID User     Command                         Swap      USS      PSS      RSS 
  178 git      puma: cluster worker 0: 162        0     2472   156824   553668 
  162 git      puma 4.3.3.gitlab.2 (unix:/        0     2308   157049   555612 
  192 git      puma: cluster worker 0: 161        0    73460   200288   553520 
  161 git      puma 4.3.3.gitlab.2 (unix:/        0    73300   200725   555952 
   97 git      ruby ./bin/web_and_actionca        0   229052   306130   574428 

git@db4de08cf21f:~/gitlab$ ps auxf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
git         97 25.4  4.6 1427200 574420 pts/2  Sl+  08:38   0:25  \_ ruby ./bin/web_and_actioncable
git        161  0.5  4.5 1428220 555940 pts/2  Sl+  08:38   0:00      \_ puma 4.3.3.gitlab.2 (unix:///home/git/gitlab_actioncable.socket) [gitlab-actioncable-puma-worker]
git        192  0.0  4.5 1434364 553352 pts/2  Sl+  08:38   0:00      |   \_ puma: cluster worker 0: 161 [gitlab-actioncable-puma-worker]
git        162  0.3  4.5 1428220 555600 pts/2  Sl+  08:38   0:00      \_ puma 4.3.3.gitlab.2 (unix:///home/git/gitlab/tmp/sockets/gitlab.socket) [gitlab-puma-worker]
git        178  0.0  4.5 1705740 553328 pts/2  Sl+  08:38   0:00          \_ puma: cluster worker 0: 162 [gitlab-puma-worker]

Ideally it should be done as:

  • Gitlab::SidekiqCluster be abstracted into Gitlab::Process::Manager
  • Gitlab::SidekiqCluster::CLI to be extending Gitlab::Process::SidekiqCluster::CLI
  • adding Gitlab::Process::Manager::PumaCluster::CLI
  • etc.

The above when running with preload (even though unoptimised yet) leads to have two masters and two workers to consume a total of 1GB of RAM. It is likely that we should be able to optimise it further to around 800-900MB by "making the process hot".

Compare to running separately

When running completely separate masters and separate workers:

git@db4de08cf21f:~/gitlab$ ps auxf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
git        595 20.5  4.7 1361480 578964 pts/2  Sl   09:41   0:22  \_ puma 4.3.3.gitlab.2 (tcp://0.0.0.0:8090) [gitlab-actioncable-puma-worker]
git        627  0.2  4.5 1572996 564096 pts/2  Sl   09:42   0:00  |   \_ puma: cluster worker 0: 595 [gitlab-actioncable-puma-worker]
git        607 25.2  4.7 1356264 577624 pts/2  Sl+  09:42   0:23  \_ puma 4.3.3.gitlab.2 (tcp://0.0.0.0:8080) [gitlab-puma-worker]
git        656  0.2  4.5 1770624 563200 pts/2  Sl+  09:42   0:00      \_ puma: cluster worker 0: 607 [gitlab-puma-worker]

git@db4de08cf21f:~/gitlab$ smem
  PID User     Command                         Swap      USS      PSS      RSS 
  656 git      puma: cluster worker 0: 607        0    71076   314324   563608 
  627 git      puma: cluster worker 0: 595        0    80232   319415   564568 
  607 git      puma 4.3.3.gitlab.2 (tcp://        0    71480   319532   577712 
  595 git      puma 4.3.3.gitlab.2 (tcp://        0    80964   324933   579024

Results in ~1.3GB.

Does this MR meet the acceptance criteria?

Conformity

Edited by Kamil Trzciński

Merge request reports