WSL/Docker 환경에서 GitLab CE가 느릴 때 해결하는 방법

GitLab CE 메모리 최적화와 docker-compose 버전 고정하기

로컬 개발 환경에서 Docker로 GitLab CE를 실행하다 보면 PC가 갑자기 무거워지거나, GitLab 접속 속도가 느려지는 경우가 있습니다.

이번 글에서는 WSL과 Docker Desktop 환경에서 GitLab CE 컨테이너가 느려졌던 원인을 확인하고, 메모리 사용량을 줄이기 위해 적용한 설정과 명령어를 정리합니다.

핵심 원인은 GitLab 오류나 PC 고장이 아니라, 로컬 개발 환경에 비해 GitLab CE 기본 설정이 너무 무겁게 실행된 것이었습니다.

---

문제 상황

GitLab CE 컨테이너는 정상적으로 실행되고 있었지만, 전체적으로 시스템이 느려지는 현상이 있었습니다.

처음에는 디스크 공간 부족이나 컨테이너 장애를 의심했지만, 확인 결과 디스크 용량은 충분했고 GitLab 서비스도 대부분 정상 상태였습니다.

확인된 주요 상태는 다음과 같았습니다.

WSL 전체 메모리: 7.7GiB
사용 중 메모리: 6.7GiB
가용 메모리: 약 1.0GiB
Swap 사용량: 1.4GiB / 2.0GiB
GitLab 메모리 사용량: 약 5.65GiB

즉, 가장 큰 문제는 메모리 부족이었습니다.

WSL 전체 메모리가 약 7.7GiB인데, GitLab 컨테이너 하나가 약 5.65GiB를 사용하고 있었습니다. 이 때문에 남은 메모리가 부족해지고 swap 사용량이 늘어나면서 WSL과 Docker 전체가 느려진 것입니다.

---

1. 현재 실행 중인 컨테이너 확인하기

먼저 GitLab 컨테이너가 정상적으로 실행 중인지 확인합니다.

docker ps

GitLab 컨테이너만 보고 싶다면 아래처럼 실행합니다.

docker ps --filter name=gitlab

예상 결과는 아래와 비슷합니다.

CONTAINER ID   IMAGE                    STATUS                    PORTS                                      NAMES
9563d2a10ee2   gitlab/gitlab-ce:latest  Up 18 minutes (healthy)   0.0.0.0:8929->8929/tcp, 0.0.0.0:2424->22/tcp gitlab

여기서 STATUS가 healthy라면 GitLab 자체는 실행 중이라는 뜻입니다.

---

2. 디스크 용량 확인하기

GitLab은 저장소, 로그, 데이터베이스 등으로 디스크도 많이 사용할 수 있습니다. 먼저 디스크 용량이 부족하지 않은지 확인합니다.

df -h / /srv/gitlab /mnt/c

예상 결과 예시입니다.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdd        251G  4.4G  234G   2% /
C:\             120G   81G   40G  68% /mnt/c

이 경우 디스크 공간은 충분하므로, 느려지는 원인이 디스크 부족은 아니라고 볼 수 있습니다.

---

3. WSL 메모리 상태 확인하기

다음으로 WSL의 메모리 상태를 확인합니다.

free -h

문제가 있었던 당시 상태는 아래와 비슷했습니다.

              total        used        free      shared  buff/cache   available
Mem:          7.7Gi       6.7Gi        76Mi       294Mi       1.4Gi       1.0Gi
Swap:         2.0Gi       1.4Gi       603Mi

여기서 중요한 부분은 available과 Swap입니다.

available: 약 1.0GiB
Swap 사용량: 1.4GiB / 2.0GiB

실제로 사용할 수 있는 메모리가 거의 없고 swap까지 많이 사용 중인 상태였습니다. 이런 상태에서는 GitLab뿐 아니라 WSL 전체가 느려질 수 있습니다.

---

4. Docker 컨테이너별 리소스 사용량 확인하기

어떤 컨테이너가 메모리를 많이 쓰는지 확인합니다.

docker stats --no-stream

예상 결과 예시입니다.

CONTAINER ID   NAME      CPU %   MEM USAGE / LIMIT   MEM %
9563d2a10ee2   gitlab    0.83%   5.65GiB / 7.73GiB   73%

이 결과를 보면 GitLab 컨테이너 하나가 약 5.65GiB의 메모리를 사용하고 있었습니다.

---

5. GitLab 내부 서비스 상태 확인하기

GitLab 내부 서비스가 정상인지 확인합니다.

docker exec gitlab gitlab-ctl status

예상 결과는 아래처럼 여러 서비스가 run 상태로 나옵니다.

run: gitaly
run: gitlab-kas
run: nginx
run: puma
run: sidekiq
run: sshd

서비스가 대부분 run 상태라면 GitLab 장애라기보다는 리소스 사용량 문제일 가능성이 높습니다.

---

6. GitLab 내부 프로세스 메모리 사용량 확인하기

GitLab 컨테이너 내부에서 어떤 프로세스가 메모리를 많이 쓰는지 확인합니다.

docker exec gitlab ps -eo pid,ppid,comm,%cpu,%mem,rss --sort=-rss | head -30

예상 결과 예시입니다.

PID    PPID COMMAND   %CPU %MEM   RSS
1410   967  ruby      1.1  12.1   981168
...

GitLab은 내부적으로 Ruby 기반의 Puma, Sidekiq 등을 실행합니다. 기본 설정에서는 이 프로세스들이 여러 개 떠 있기 때문에 로컬 개발 PC에서는 메모리 사용량이 커질 수 있습니다.

---

원인 분석

GitLab CE는 기본 설정 그대로 실행하면 생각보다 많은 서비스를 함께 실행합니다.

특히 다음 구성 요소들이 메모리를 많이 사용할 수 있습니다.

Puma worker
Sidekiq
Prometheus
Exporter
Alertmanager

기본 설정에서는 Puma worker가 여러 개 실행되고, Sidekiq concurrency도 높게 설정되어 있습니다. 또한 Prometheus 계열 모니터링 서비스까지 함께 실행되기 때문에, 로컬 개발용 PC에서는 부담이 클 수 있습니다.

정리하면 이번 문제의 원인은 다음과 같습니다.

로컬 WSL/Docker 환경에 비해 GitLab CE 기본 구성이 너무 무거웠다.
GitLab 하나가 WSL 메모리 대부분을 사용했다.
메모리 부족으로 swap 사용량이 증가했다.
그 결과 GitLab 접속과 전체 WSL 환경이 느려졌다.

---

7. GitLab 설정 파일 확인하기

GitLab 설정 파일은 컨테이너 내부의 아래 경로에 있습니다.

/etc/gitlab/gitlab.rb

설정 파일을 확인하려면 다음 명령어를 실행합니다.

docker exec gitlab cat /etc/gitlab/gitlab.rb

현재 별도로 튜닝된 설정이 있는지 확인하려면 아래 명령어를 사용할 수 있습니다.

docker exec gitlab grep -n "^[^#].*\(puma\|sidekiq\|prometheus\|alertmanager\|exporter\|monitoring\|worker_processes\|concurrency\)" /etc/gitlab/gitlab.rb

아무 결과도 나오지 않는다면, 대부분 기본 설정으로 실행 중인 상태라고 볼 수 있습니다.

---

8. docker-compose.yml에서 GitLab 버전 고정하기

기존 설정이 아래처럼 되어 있었다면,

image: gitlab/gitlab-ce:latest

latest는 권장하지 않습니다. 컨테이너를 다시 만들 때 의도치 않게 GitLab 버전이 바뀔 수 있기 때문입니다.

아래 명령어로 latest를 현재 사용 중인 버전으로 고정합니다.

perl -0pi -e 's#image: gitlab/gitlab-ce:latest#image: gitlab/gitlab-ce:19.1.0-ce.0#' docker-compose.yml

변경이 잘 되었는지 확인합니다.

docker compose config | grep 'image:'

예상 결과입니다.

image: gitlab/gitlab-ce:19.1.0-ce.0

참고로 docker ps 명령에서는 여전히 gitlab/gitlab-ce:latest로 보일 수 있습니다. 이는 현재 실행 중인 컨테이너가 처음 latest 이미지로 생성되었기 때문입니다.

하지만 docker-compose.yml이 이미 고정 버전으로 변경되어 있다면, 다음에 docker compose up -d로 컨테이너를 재생성할 때 고정된 버전 기준으로 실행됩니다.

---

9. GitLab 저메모리 설정 추가하기

이제 GitLab 설정 파일인 /etc/gitlab/gitlab.rb에 로컬 개발용 저메모리 설정을 추가합니다.

아래 명령어를 그대로 실행합니다.

docker exec gitlab bash -c 'cat >> /etc/gitlab/gitlab.rb <<EOF

# ==============================
# Local development low-memory tuning
# ==============================

# Reduce Puma memory usage
puma["worker_processes"] = 2
puma["min_threads"] = 1
puma["max_threads"] = 2

# Reduce Sidekiq memory usage
sidekiq["concurrency"] = 5

# Disable monitoring services for local development
prometheus_monitoring["enable"] = false
EOF'

설정이 잘 들어갔는지 확인합니다.

docker exec gitlab sh -c "tail -30 /etc/gitlab/gitlab.rb"

아래와 비슷한 내용이 보이면 정상입니다.

# Local development low-memory tuning

puma["worker_processes"] = 2
puma["min_threads"] = 1
puma["max_threads"] = 2

sidekiq["concurrency"] = 5

prometheus_monitoring["enable"] = false

---

10. GitLab 설정 적용하기

설정을 변경했으므로 GitLab에 반영해야 합니다.

docker exec gitlab gitlab-ctl reconfigure

이 명령어는 GitLab 내부 설정을 다시 구성합니다. 실행 중 GitLab 서비스가 잠시 재시작될 수 있습니다.

정상적으로 완료되면 마지막에 아래와 비슷한 메시지가 나옵니다.

gitlab Reconfigured!

---

11. GitLab 상태 다시 확인하기

설정 적용 후 GitLab 서비스 상태를 다시 확인합니다.

docker exec gitlab gitlab-ctl status

정상이라면 주요 서비스들이 run 상태로 표시됩니다.

run: gitaly
run: gitlab-kas
run: nginx
run: puma
run: sidekiq
run: sshd

Docker 기준으로도 health 상태를 확인합니다.

docker ps --filter name=gitlab

예상 결과입니다.

STATUS
Up 18 minutes (healthy)

---

12. 메모리 사용량 다시 확인하기

이제 WSL 메모리 상태를 다시 확인합니다.

free -h

적용 후에는 아래처럼 개선되었습니다.

              total        used        free      shared  buff/cache   available
Mem:          7.7Gi       3.8Gi       2.1Gi       241Mi       2.2Gi       4.0Gi
Swap:         2.0Gi       892Mi       1.1Gi

핵심은 available 값입니다.

적용 전 available: 약 1.0GiB
적용 후 available: 약 4.0GiB

가용 메모리가 크게 늘어났습니다.

Docker 컨테이너 메모리도 다시 확인합니다.

docker stats --no-stream

적용 전에는 GitLab이 약 5.65GiB를 사용했지만, 적용 후에는 약 3.36GiB 수준으로 줄었습니다.

GitLab 메모리 사용량
적용 전: 약 5.65GiB
적용 후: 약 3.36GiB

---

13. GitLab 이미지 태그 확인하기

로컬 이미지 목록을 확인합니다.

docker images gitlab/gitlab-ce

만약 19.1.0-ce.0 태그가 없다면, 현재 latest 이미지에 버전 태그를 붙일 수 있습니다.

docker tag gitlab/gitlab-ce:latest gitlab/gitlab-ce:19.1.0-ce.0

다시 확인합니다.

docker images gitlab/gitlab-ce

예상 결과입니다.

REPOSITORY             TAG             IMAGE ID
gitlab/gitlab-ce       19.1.0-ce.0     fd4f06dcfd3b
gitlab/gitlab-ce       latest          fd4f06dcfd3b

이렇게 하면 같은 이미지에 latest와 19.1.0-ce.0 태그가 함께 붙어 있는 상태가 됩니다.

---

14. GitLab 접속 확인하기

브라우저에서 아래 주소로 접속합니다.

http://localhost:8929

기존과 동일한 주소로 접속하면 됩니다.

---

적용 전후 비교

항목적용 전적용 후

GitLab 메모리 사용량	약 5.65GiB	약 3.36GiB
WSL 가용 메모리	약 1.0GiB	약 4.0GiB
Swap 사용량	약 1.4GiB	약 892MiB
GitLab 상태	실행 중	healthy
CPU 사용률	불안정 가능	안정화 후 약 0.83%

---

전체 명령어 한 번에 정리

아래는 이번 작업에서 사용한 주요 명령어 전체입니다.

# 1. 컨테이너 상태 확인
docker ps
docker ps --filter name=gitlab

# 2. 디스크 확인
df -h / /srv/gitlab /mnt/c

# 3. WSL 메모리 확인
free -h

# 4. Docker 컨테이너별 리소스 확인
docker stats --no-stream

# 5. GitLab 내부 서비스 상태 확인
docker exec gitlab gitlab-ctl status

# 6. GitLab 내부 프로세스 메모리 확인
docker exec gitlab ps -eo pid,ppid,comm,%cpu,%mem,rss --sort=-rss | head -30

# 7. GitLab 설정 확인
docker exec gitlab cat /etc/gitlab/gitlab.rb

# 8. 기존 튜닝 설정 확인
docker exec gitlab grep -n "^[^#].*\(puma\|sidekiq\|prometheus\|alertmanager\|exporter\|monitoring\|worker_processes\|concurrency\)" /etc/gitlab/gitlab.rb

# 9. docker-compose.yml 이미지 버전 고정
perl -0pi -e 's#image: gitlab/gitlab-ce:latest#image: gitlab/gitlab-ce:19.1.0-ce.0#' docker-compose.yml

# 10. compose 설정 확인
docker compose config | grep 'image:'

# 11. GitLab 저메모리 설정 추가
docker exec gitlab bash -c 'cat >> /etc/gitlab/gitlab.rb <<EOF

# ==============================
# Local development low-memory tuning
# ==============================

# Reduce Puma memory usage
puma["worker_processes"] = 2
puma["min_threads"] = 1
puma["max_threads"] = 2

# Reduce Sidekiq memory usage
sidekiq["concurrency"] = 5

# Disable monitoring services for local development
prometheus_monitoring["enable"] = false
EOF'

# 12. 설정 추가 확인
docker exec gitlab sh -c "tail -30 /etc/gitlab/gitlab.rb"

# 13. GitLab 설정 반영
docker exec gitlab gitlab-ctl reconfigure

# 14. 적용 후 서비스 상태 확인
docker exec gitlab gitlab-ctl status
docker ps --filter name=gitlab

# 15. 적용 후 메모리 확인
free -h
docker stats --no-stream

# 16. 이미지 태그 확인
docker images gitlab/gitlab-ce

# 17. 필요한 경우 현재 latest 이미지에 고정 버전 태그 추가
docker tag gitlab/gitlab-ce:latest gitlab/gitlab-ce:19.1.0-ce.0

# 18. 태그 확인
docker images gitlab/gitlab-ce

---

마무리

이번 문제는 GitLab 자체 오류가 아니라, WSL/Docker Desktop 환경에서 GitLab CE 기본 구성이 너무 무겁게 실행된 것이 원인이었습니다.

GitLab CE는 기본값 그대로 실행하면 Puma, Sidekiq, Prometheus 계열 서비스들이 함께 실행됩니다. 서버 환경에서는 괜찮을 수 있지만, 8GB 전후의 WSL 개발 환경에서는 메모리 부담이 커질 수 있습니다.

로컬 개발용 GitLab이라면 다음 설정을 권장합니다.

1. GitLab 이미지는 latest 대신 명확한 버전으로 고정한다.
2. Puma worker 수를 줄인다.
3. Sidekiq concurrency를 낮춘다.
4. Prometheus 등 불필요한 모니터링 기능은 비활성화한다.
5. 변경 후 free -h, docker stats로 결과를 확인한다.

이번 최적화 후 GitLab은 정상적으로 실행되었고, WSL의 가용 메모리도 크게 늘어나 전체 개발 환경이 훨씬 안정적으로 바뀌었습니다.