gitlab 운영시 CPU 및 메모리 점유율 높아지는 현상 및 대처법
난 개인적으로 집에다가 서버를 구축하여 “gitlab” 을 직접 설치하여 운영중이다. gitlab 은 github(깃허브) 와 비슷한 형상관리 툴이다.
최근 대부분의 형상관리 작업은 “git” 으로 하고 있는 중이다. git은 회사에서도 기본적으로 사용하는 형상관리 툴이고 집에서도 개인적으로 관리하는 소스들은 죄다 git 으로 관리를 하고 있다. git 으로 관리를 하다보니 개인적으로 관리하는 소스들은 git remote 서버가 필요한데 프로그래머들이 가장 많이 사용하는 깃허브의 경우에는 무료로 사용하려면 소스를 전부 공개해야 하기 때문에 사정상 깃허브에 내가 관리하는 소스들을 공개할 수는 없었다.
따라서 대안을 찾아보니 “gitlab” 이라는 github 에 비슷한 형상관리 툴이 꽤나 유명했고 gitlab 의 경우에는 직접 설치를 하여 git remote 서버를 구성하는게 가능하다. 따라서 github 에 공개를 꺼리는 프로그래머들은 집에 NAS 나 개인서버를 구동하여 gitlab 을 설치하여 사용하는 경우가 꽤 많다.
NAS의 경우에는 “시놀로지” 제품군들이 유명하다. 하지만 NAS는 gitlab 설치가 가능하나 리소스가 부족한 편이라서 gitlab 을 설치하여 사용하기가 적절치 않다는 판단을 하였다.
위는 시놀로지 나스의 DS220+ 라는 제품의 스펙이다. 일단 gitlab 의 경우에는 메모리는 최소 4 GB 이상을 권장하고 있다. 시놀로지 제품은 기본적으로 Docker 를 통해 gitlab 사용이 가능하지만 아무래도 매모리가 2 GB 정도이면 부족하다고 볼 수 있다.
CPU는 Intel Celeron J4025 듀얼코어 인데 이 정도면 gitlab 을 동작시키는데 무리는 없을 것이다. 그런데 위의 시놀로지 나스의 가격이 하드디스크를 제외하고 거의 50만원에 육박한다. 차라리 직접 컴퓨터 부품을 구입하여 메모리를 16 GB 이상 구성하는 조립 PC에 gitlab 을 설치하는게 더 효율이 높다고 생각한다.
따라서 NAS는 파일공유나 다른 웹 서버를 돌리는데에는 충분하지만 gitlab 을 설치하는데에는 약간 부족하다고 볼 수 있다. 그래서 집에 있는 개발서버로 사용하는 PC 에 gitlab 을 설치하여 사용중이었다. 집에 있는 PC는 메모리 20 GB에 CPU는 “AMD A10-6800K APU with Radeon(tm) HD Graphics” 이다. 꽤 오래전에 구입한 AMD CPU 이지만 집에서 개발서버로 사용하기에는 충분하였다.
그래서 gitlab 을 설치하고 한동안은 잘 사용하였다. gitlab 은 사용해 보니 꽤나 훌륭한 형상관리 도구이다. 웹으로 접속하여 프로젝트 별로 git 레파지토리를 생성하고 커밋별로 소스 Diff 를 손쉽게 웹상에서 확인이 가능하다. 위키를 작성할 수 있으며 각 소스 라인별로 코멘트도 달 수 있다.
그러면서 프로젝트 갯수가 늘어나고 remote 레파지토리가 늘어나면서 문제가 발생하기 시작하였다.
서버의 CPU 점유율이 100프로에 육박하다
설치 초기만 해도 사용하는데에는 큰 지장이 없었다. 물론 gitlab 을 사용하다 보니 확실히 느껴지는 것은 gitlab 자체가 시스템 리소스를 굉장히 많이 소모하는 것은 분명했다. 20 GB의 메모리도 절반 이상을 소모하는 무지막지하게 gitlab은 메모리를 소비한다. 그래도 사용에는 큰 지장은 없었고 gitlab 웹 페이지가 다소 느린거 외에는 별다른 문제는 없었다.
문제는 최근에 와서야 붉어졌다. 어느 순간 부터 gitlab 웹 페이지 접속이 정상적이지 않은 것이다. 그래서 SSH로 서버 접근을 시도하였는데에도 SSH 조차 접속이 되질 않았다. 아니면 한참 기다려서야 SSH 접속이 되는 등의 문제가 발생했다.
집의 네트워크 상태가 좋지 않았나 싶어서 확인을 해보니 그게 아니었다. 집에서 직접 서버를 확인해보니 엄청난 상황이 발생해 있었다.
서버에서 gitlab 웹 접속이 잘 안되거나 SSH 접속이 잘 안됐을때의 “top” 을 실행한 화면의 모습이다. “bundle” 이라는 프로세스가 엄청나게 많이 돌고 있었으며 CPU가 100%에 육박하는 점유율로 동작을 하고 있었다.
황당했다. bundle 이라는 프로세스가 뭔지는 잘 모르겠지만 실행 user 가 git 인걸로 보아 gitlab 에서 실행되는게 분명했다. 좀더 자세히 원인을 파악하기 위해 “htop” 을 실행하여 상태를 확인해 보기로 했다.
htop 으로 확인해 보니 상황은 더욱더 심각했다. 시스템의 4개의 core 에서 거의 100 % 점유율을 유지하고 있었으며 메모리도 20 GB 중에 상당수의 메모리를 점유하고 있었다. 범인은 다름아닌 puma 라는 프로세스 였다.
확인해 보니 puma 는 gitlab 에서 웹 서버 프로세스인 것으로 보였다. 즉 gitlab 에서 웹 페이지에 접속을 하려면 웹 서버가 돌고 있어야 하는데 그 역할을 “puma” 라는 gitlab 용 웹서버 프로세스가 돌고 있어야 한다.
그런데 왜 갑자기 이렇게 CPU 점유율이 core 4개가 전부 100%에 육박하고 메모리도 엄청나게 많이 소모하는 걸까? gitlab 이 시스템의 리소스를 많이 소모하는 것으로 알고는 있었지만 이렇게 많이 소모할 줄은 꿈에도 몰랐다. 이내 해결 방법을 찾기 위해 알아보기 시작했다.
gitlab 의 시스템 자원의 Full 소모 원인은?
gitlab 을 설치하여 운영하는 초기만 해도 이렇게 까지 리소스를 많이 소모하진 않았었다. 같은 서버에서 gitlab 을 설치하기 전에는 개발 서버로도 나름 훌륭한 서버로 동작하기도 했다. CPU 점유율이 거의 FULL 이 되는 경우는 근래들어 인듯 했다.
왜 갑자기 이렇게 시스템 자원을 Full 로 먹는 걸까? gitlab 설치후 시간이 지나면서 프로젝트 갯수가 늘어나고 소스 파일이 늘어난거 외에는 없는데 말이다.
일단 관련하여 사례가 있는지 검색해 보기로 했다. 역시나 나와 같은 사례는 꽤 존재하는거 같았다. 또한 관련하여 시스템 리소스를 많이 잡아먹는거에 대해 gitlab 에서도 언급해 놓기도 했다.
gitlab 에서 가이드해놓은 메모리 최적화 관련 글이다. 이대로 따라서 해봤지만 실제 결과는 크게 다르지 않았다. gitlab 을 재시작하고 초기에만 메모리를 적게 먹고 시간이 지나면 이내 원래 상태로 되돌아 왔다.
gitlab 에서 가이드 한 대로 /etc/gitlab/gitlab.rb 파일을 수정한 다음에 “sudo gitlab-ctl reconfigure” 하여 gitlab 을 재설정하고 재 가동을 하였지만 위의 htop 모습을 봤을때도 예전과 크게 달라진 점은 없었다. 다만 웹접속이 끊기지 않으며 조금 빨라진 정도다.
추가적으로 gitlab 최적화를 시도해 봤다. 해본 것은 아래와 같다.
- gitlab 버전 업그레이드 진행 하지만 현상은 크게 나아진게 없음
- gitlab.rb 파일에서 설정을 더 바꿔서 재가동으로 해봤지만 크게 나아진게 없음.
- gitlab 이 CI/CD 기능 때문에 리소스가 많이 소모한다는 이야기가 없어서 관련 설정들을 죄다 Diable 해봤지만 나아진게 없음.
더 알아보고 gitlab CPU 점유율 문제와 메모리 문제를 확인해보려고 했으나 더이상의 시간 투입은 어려울꺼 같아서 일단 여기서 중지하기로 했다. 그래서 최근에 이렇게 CPU 점유율을 많이 먹는 것에 대하여 gitlab에서 새로 생성한 프로젝트에 대해 알아보니 기가 단위의 소스 파일이 올라간 프로젝트가 생성된 것을 알게 되었다.
1.7 GB 용량의 소스가 올라간 프로젝트가 총 4개였는데 4개 중에 2개를 일단 삭제를 해봤다. 삭제를 하고 나니 웹 접속 속도가 조금 더 빨라진 느낌을 받았지만 CPU나 메모리 점유율은 크게 변화는 없었다.
그래서 일단 결론을 이렇게 내리기로 했다. “gitlab은 꽤나 편리하고 괜찮은 형상관리 도구이지만 시스템 자원을 많이 소모하므로 대체 형상관리 도구를 찾아서 이전하는 것” 으로 결론을 내렸다.
gitlab 을 대체할 수 있는 형상관리 도구는?
gitlab 은 꽤 괜찮은 형상관리 도구이지만 언급한 대로 시스템 리소스를 꽤나 많이 잡아먹는다. 현재 gitlab 을 설치한 서버의 CPU는 예전 AMD CPU 이긴 하지만 최대 4.4 Ghz 클럭으로 동작하는 CPU 이고 x86 CPU 이기 때문에 나름 성능은 괜찮은 CPU 이다. 또한 메모리는 20 GB 정도 있는데에도 이 메모리를 거의 Full 로 소모한다.
이정도로 시스템 자원을 소모하면 gitlab 서버 외에는 다른 용도로 전혀 활용할 수 가 없고 gitlab 웹 접속 조차 정상적으로 동작하지 않는다. 분명 문제가 있다고 볼 수 있고 gitlab 을 사용하려면 Intel Xeon CPU 같은 서버 CPU나 좀더 성능이 좋은 CPU를 사용하는거 외에는 다른 방법이 없을 듯 하다.
관련하여 gitlab 같이 설치형 형상 관리 도구이지만 시스템 리소스를 최대한 적게 먹고 git remte 서버 역할에 충실한 형상 관리 도구를 찾아보기로 했다. 그리고 최소한으로 웹 접속으로 소스의 히스토리 파악이나 커밋 Diff 기능이 기본적으로 갖춰져 있는 형상관리 도구를 찾아봤다.(CI/CD 기능은 굳이 없어도 된다.)
찾아보니 꽤나 괜찮은 구축형 형상관리 도구가 있었다. 속도도 빠르고 가벼운 “gitea” 이다.
gitea 는 gitlab 과 같이 구축형 형상관리 도구이다. gitlab 과 같이 기본적인 기능을 제공하는데 뭐니뭐니 해도 장점은 가볍고 빠르다는 것이다. 알아본 바에 의하면 라즈베리파이 3B+ 에 설치하여 사용이 가능할 정도로 시스템 자원을 적게 소모한다고 한다.
gitea 공식 사이트에서 제시해 놓은 gitea 의 특징이다. 설치가 쉽고 가벼우며, 오픈소스라고 되어 있다. 여기에는 아예 라즈베리파이에서 구동시킬 수 있다고 명시가 되어 있다. 내게 딱 맞는 형상관리 도구라고 볼 수 있다.
그래서 gitlab 을 못쓰는 것은 다소 아쉽지만 이번 기회에 gitea 로 설치하여 이전을 하기로 결정하였다. 그동안 gitlab 에서 관리하던 프로젝트 들과 소스들이 꽤 많이 있어 이전하는게 꽤나 귀찮은 일이지만 서버를 활용하기 위해서는 어쩔수 없다는 생각이 든다.
gitea 설치 및 구성, 소스 이전에 관련해서는 별도의 포스트를 통해 공유를 해 보도록 하겠다.