docs.gitlab.com/ee/administrat

tl;dr:

"GitLab has memory leaks."

Their solution is monkey patching their application to check its memory usage after every 16th HTTP request and commit suicide if it's too much. This page is telling sysadmins who install their own GitLab instance how to configure this.

Follow

You know, I empathise with GitLab here. git.sr.ht had a memory leak once. My solution was pretty interesting: I wrote a shell script on a cronjob set to every 5 minutes, which checked the heap size of the git.sr.ht backend and, if it was within a certain percentage of system memory, it sent a SIGTERM along and

Wait, no, none of that is what happened. What happened is I fixed the memory leak.

I'm hitting the new git.sr.ht API backend 100x/sec with a non-trivial query and it's using 4M of RAM and 2% of one CPU core

@sir I remember the days when PHP's per-request limit was 8MB and anything demanding higher limits was rightly considered a war crime

Even MediaWiki only needs 20MB

@sir I've been a rails developer since the beginning, and have delt with many memory leaks. It's pretty hard to leak memory in Ruby itself, the vast majority of the time it's from deep within C extensions, like imagemagik or libxml.

@sir I hope you did notice there was a section called 'Switch to Puma' right above the page's link in the navigation sidebar.

"As of GitLab 12.9, Puma has replaced Unicorn. as the default web server. [...]

Why switch to Puma?

Puma has a multi-thread architecture which uses less memory than a multi-process application server like Unicorn. [...]"

source : docs.gitlab.com/ee/administrat

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!