Collabora Online CODE 컨테이너의 메모리 제한을 늘리는 방법

Collabora Online Development Edition(CODE) 컨테이너가 부하 중에 종료되거나 Docker 메모리 제한에 지속적으로 근접하는 경우, 실질적인 해결 방법은 일반적으로 Collabora 자체의 설정을 변경하는 것이 아니라 컨테이너의 Docker 메모리 제한을 높이는 것입니다. Docker는 컨테이너 런타임 수준에서 메모리 제한을 적용하며, Collabora는 해당 제한 범위 내에서 실행됩니다.

이 가이드에서는 전체적으로 가상의 예시를 사용합니다. 예를 들어, 소규모 팀이 codeLinux Docker 호스트에서 컨테이너를 실행한다고 가정해 보겠습니다. 이 컨테이너는 2GiB의 하드 메모리 제한이 있으며, 편집 작업이 많은 기간에는 이 제한에 거의 근접합니다. 팀은 운영 체제 및 기타 서비스에 필요한 RAM을 충분히 확보하면서 4GiB까지 메모리 제한을 늘려 테스트하기로 결정합니다. 이 예시의 수치와 사용률은 설명을 위한 것이며, 실제 배포 환경에서 측정된 결과가 아닙니다.

2026년 10월 현재, 아래 명령어는 최신 Docker 문서와 일치합니다. Collabora 자체 Docker 문서에서는 CODE 이미지를 Docker로 배포되는 Collabora Online 옵션으로 정의하고 있으며, Docker는 컨테이너 리소스 제한을 적용하는 구성 요소입니다. 사용 환경에 맞게 단계를 조정할 때는 Collabora Online CODE Docker 공식 문서 와 Docker 리소스 제약 조건 문서를 참조하십시오.

메모리 제한을 늘리면 실제로 어떤 변화가 생기는가

Docker 메모리 제한은 컨테이너가 사용할 수 있는 RAM의 최대 용량을 나타냅니다. 이 제한을 높이면 컨테이너가 메모리 부족 또는 메모리 압박을 받기 전에 CODE에 더 많은 여유 공간을 확보할 수 있습니다. 하지만 이 제한을 설정한다고 해서 전체 용량이 미리 예약되는 것은 아니며, 문서 편집 속도가 반드시 빨라지는 것도 아닙니다. CPU 포화도, 스토리지 지연 시간, 네트워크 상태, 문서 복잡성, 동시 사용자 수, 애플리케이션 수준의 동작 등 다양한 요인이 여전히 병목 현상을 일으킬 수 있습니다.

Docker 문서에는 컨테이너의 물리적 메모리 제한으로 --memory`swap` 또는 ` swap`이 명시되어 있습니다. 또한 Docker는 메모리 제한이 설정될 때 RAM과 스왑 공간을 합친 총 메모리 사용량을 제어하는 ​​`swap` 옵션도 제공합니다. 스왑은 여유 공간을 제공할 수 있지만, 잦은 스왑은 성능 저하를 초래합니다. 사무용 편집 서비스의 경우, 스왑을 충분한 물리적 메모리 대신 사용하는 것은 바람직하지 않습니다.-m--memory-swap

1단계: 메모리 부족이 실제 문제인지 확인합니다.

먼저 실행 중인 CODE 컨테이너를 확인하고 현재 리소스 사용량을 관찰하십시오.

docker ps
docker stats code

가상 시나리오에서 컨테이너가 2.0GiB 제한 중 약 1.8GiB를 사용하고 있는 것으로 docker stats나타났습니다 . 이는 추가 조사가 필요한 상황이지만, 단일 스냅샷만으로는 영구적인 변경을 정당화하기에 충분하지 않습니다. 오류가 발생하는 워크로드 동안 사용량을 모니터링하고 컨테이너 로그에서 종료 또는 재시작 증상을 확인하십시오.code

유용한 판단 기준은 간단합니다. 컨테이너가 설정된 최대 메모리 용량에 반복적으로 근접하는 동시에 사용자가 세션 실패, 재시작 또는 OOM(메모리 부족) 관련 이벤트를 경험하는 경우, 용량 제한을 늘리는 것이 합리적인 다음 단계입니다. 메모리 사용량이 최대 용량보다 안정적으로 유지된다면, 용량 제한을 변경해도 근본적인 문제를 해결할 가능성은 낮습니다.

2단계: 구성된 Docker 메모리 제한을 읽습니다.

컨테이너에 구성된 메모리 값을 직접 확인하세요.

docker inspect code --format '{{.HostConfig.Memory}}'

Docker는 이 값을 바이트 단위로 보고합니다. 예를 들어, 21474836481바이트는 2GiB에 해당합니다. 이 값은 수동으로 또는 셸 연산을 사용하여 변환할 수 있습니다.

echo $((2147483648 / 1024 / 1024 / 1024))

inspect 값이 비어 있는 경우 0Docker는 일반적으로 컨테이너에 명시적인 메모리 제한이 없는 것으로 간주합니다. 이 경우 호스트 수준의 리소스 부족, 다른 오케스트레이터 또는 다른 제약 조건이 실제 원인일 수 있습니다. Docker는 제한이 구성되지 않는 한 컨테이너에는 기본적으로 리소스 제약이 없다고 명시합니다.

3단계: 기존 Linux 컨테이너의 제한을 늘립니다.

Docker는 `docker pip` 명령어를 사용하여 기존 컨테이너의 메모리 제한을 변경하는 것을 지원합니다 docker update. 예를 들어 2GiB에서 4GiB로 변경하려면 다음과 같이 하면 됩니다.

docker update --memory 4g --memory-swap 4g code

--memory-swap이 값을 동일한 값으로 설정하면 --memoryDocker의 메모리 스왑 규칙에 따라 해당 컨테이너가 스왑을 사용하지 못하게 됩니다. 운영 정책에서 스왑 사용을 허용하는 경우 이 예제 값을 그대로 복사하지 말고 신중하게 값을 선택하세요. 예를 들어, 더 큰 --memory-swap값은 RAM 제한을 초과하는 스왑 사용을 허용하고, 더 작은 값 -1은 호스트의 가용 스왑 용량에 따라 무제한 스왑을 허용합니다.

Docker의 최신 컨테이너 업데이트 문서에는--memory , --memory-reservation, 및 --memory-swap가 업데이트 가능한 설정으로 나열되어 있습니다 . 또한 Docker는 docker updateWindows 컨테이너에서는 가 지원되지 않는다고 명시하고 있습니다. CODE 배포는 일반적으로 Linux 컨테이너를 사용하지만, 다른 곳에서 명령어를 적용하는 경우 이러한 차이점이 중요합니다.

업데이트 후 구성 상태와 런타임 상태를 모두 확인하십시오.

docker inspect code --format '{{.HostConfig.Memory}}'
docker stats code

변경 후 백분율이 낮아졌다고 해서 서비스에 필요한 RAM 용량이 줄었다는 의미로 해석해서는 안 됩니다. 백분율이 낮아진 이유는 분모가 커졌기 때문입니다. 중요한 것은 이전에 메모리 부족 현상을 야기했던 작업 부하에서도 컨테이너가 안정적으로 작동하는지 여부입니다.

4단계: Docker Compose에서 변경 사항을 영구적으로 적용합니다.

컨테이너가 Docker Compose로 관리되는 경우, Compose 구성을 기준으로 업데이트하십시오. 그렇지 않으면, 향후 서비스를 다시 생성할 때 이전 제한을 복원하거나 런타임 전용 변경 사항을 제거할 수 있습니다.

최신 Docker Compose에서는 서비스 수준 mem_limit속성을 사용하여 컨테이너가 할당할 수 있는 메모리 양을 설정합니다.

services:
  collabora:
    image: collabora/code
    container_name: code
    restart: unless-stopped
    mem_limit: 4g
    ports:
      - "9980:9980"

Docker Compose 서비스 참조 문서에 따르면 `mem_limit`은 서비스 컨테이너의 메모리 제한을 설정하는 기능입니다 mem_limit. Compose는 `resource_limit`도 지원하며 deploy.resources.limits.memory, 두 가지 방식을 모두 사용하는 경우 메모리 값이 일관적이어야 한다고 명시되어 있습니다.

설정을 적용하세요:

docker compose up -d

그런 다음 다시 생성되거나 재시작된 서비스를 확인하십시오.

docker inspect code --format '{{.HostConfig.Memory}}'
docker stats code

메모리를 얼마나 할당해야 할까요?

모든 CODE 설치 환경에 적용할 수 있는 단일한 안전 용량은 없습니다. 적절한 용량 제한은 동시 편집 사용자 수, 문서 크기 및 복잡성, 호스트 용량, 다른 컨테이너, 그리고 서비스 통합 방식에 따라 달라집니다. Collabora의 최신 SDK 설명서에는 Kubernetes 리소스 구성 예시가 포함되어 있으며, 수 기가바이트의 메모리 요청 및 제한을 사용하는 프로덕션 환경 예시도 있지만, 이를 보편적인 Docker 용량 산정 공식으로 간주해서는 안 됩니다.

가상의 서버에서 2GiB에서 4GiB로 메모리 용량을 늘리는 것은 제어된 용량 변경으로 처리하는 것이 가장 좋습니다. 팀은 호스트에 충분한 여유 RAM이 있어 급증하는 부하를 감당할 수 있는지, 그리고 다른 중요 서비스에 메모리 부담을 주지 않는지 확인해야 합니다. 여유 RAM이 적은 호스트에서는 CODE 제한을 늘리는 것만으로도 컨테이너에서 호스트로 장애가 옮겨갈 수 있습니다.

실용적인 크기 조정 프로세스

• 대표적인 사용량이 많은 시간대의 현재 사용량 제한 및 최대 사용량을 기록하십시오.
• 한도를 사실상 무제한으로 만드는 것보다는 점진적으로 점진적으로 늘리는 것이 좋습니다.
• 호스트 운영 체제, 리버스 프록시, Nextcloud 또는 기타 통합 서비스, 데이터베이스 및 모니터링 에이전트를 위한 여유 공간을 확보하십시오.
• 워크로드를 반복 실행하고 실제 메모리 사용량, 컨테이너 재시작 횟수 및 사용자에게 표시되는 오류를 확인하십시오.
• 사용량이 계속해서 새로운 제한치에 근접한다면, RAM을 반복적으로 추가하는 대신 애플리케이션 동작을 조사하고, 패턴을 분석하고, 로그를 기록하십시오.

메모리 예약 및 스왑은 어떻게 처리하나요?

Docker는 하드 메모리 제한과 소프트 메모리 예약을 구분합니다. 예약은 호스트가 리소스 경합 상태에 있을 때 동작에 영향을 줄 수 있는 반면, 하드 제한은 절대적인 최대치로 유지됩니다. 많은 단일 호스트 CODE 설정에서는 명확한 하드 제한을 설정하는 것이 이해하기 쉽습니다. 호스트 수준의 리소스 공유 정책이 명확할 때만 예약을 추가하십시오.

스왑은 특히 주의해야 합니다. Docker 문서에 따르면 --memory-swap스왑 값이 양수로 설정되면 전체 메모리와 스왑 공간을 합한 값이 됩니다. 만약 `swap`이 0 --memory=4g이고 `swap`이 1인 경우 --memory-swap=6g, 컨테이너는 최대 4GiB의 RAM과 최대 2GiB의 추가 스왑 공간을 사용할 수 있습니다. 이는 일부 상황에서 갑작스러운 오류를 방지할 수 있지만, 스왑 활동이 지속되면 대화형 편집 속도가 느려질 수 있습니다. 스왑 공간이 자동으로 더 많이 확보된다고 가정하기보다는 스왑 사용량을 모니터링하는 것이 더 안전합니다.

변화가 효과가 있었는지 어떻게 알 수 있을까요?

4 GiB성공은 단순히 눈으로 확인하는 것만이 아닙니다 docker stats. 의미 있는 신호는 실제로 나타나는 것입니다.

• 설정된 제한값이 docker inspect의도한 값과 일치한다고 보고되었습니다.
• 컨테이너는 이전에 문제를 일으켰던 작업 부하 동안 새로운 천장 아래에 유지됩니다.
• 예기치 않은 재시작이나 메모리 부족 관련 오류가 유사한 조건에서 더 이상 발생하지 않습니다.
• Docker 호스트는 여전히 충분한 메모리 여유 공간을 유지하고 있으며 과도한 스와핑을 시작하지 않습니다.
• 편집은 단순히 종료를 피하는 것이 아니라 지속적으로 대응합니다.

컨테이너가 새로운 제한값보다 훨씬 낮은 수준에서도 계속 실패하는 경우, 다른 방법을 찾아야 합니다. docker logs code호스트 커널 로그, 리버스 프록시 오류, 통합 서버 로그, CPU 또는 I/O 포화도를 점검하십시오. 메모리 제한은 Collabora 배포의 여러 요소 중 하나일 뿐입니다.

흔히 저지르는 실수들을 피하는 방법

• 실행 중인 컨테이너만 변경하면 docker update 당장의 제한은 해결되지만, Compose로 관리되는 서비스도 Compose 파일에서 업데이트해야 합니다.
• CODE에 호스트 메모리 전체를 할당하는 것은 호스트와 인접 서비스에 여유 공간을 확보해 줍니다. 제한 없는 컨테이너는 호스트 전체의 불안정성을 야기할 수 있습니다.
• 스왑은 사용 가능한 메모리라고 가정할 때, 스왑은 RAM보다 속도가 느리며, Docker는 애플리케이션이 스왑을 자주 사용할 경우 성능 저하가 발생할 수 있다고 명시적으로 경고합니다.
• 컨테이너 메모리와 PHP 메모리를 혼동하지 마세요. Docker CODE 컨테이너의 메모리 제한은 Nextcloud와 같은 애플리케이션에서 사용하는 PHP 설정과는 별개입니다.
• 단일 시점의 데이터를 증거로 활용: 대표적인 수요 상황에서 측정하고 변화 전후의 행동을 비교합니다.

결론적으로

Collabora Online CODE 컨테이너의 메모리 제한을 늘리려면 먼저 기존 Docker 제한에 실제로 도달했는지 확인하십시오. 기존 Linux 컨테이너의 경우 docker update --memory ...런타임에 제한을 변경할 수 있습니다. Compose로 관리되는 배포의 경우, Compose 리소스 구성을 일관되게 유지하거나, 또는 동일한 Compose 리소스 구성을 사용하여 제한을 영구 저장한 mem_limit다음, 서비스를 다시 생성하거나 업데이트하고 결과를 확인하십시오.

가상의 2GiB에서 4GiB로의 증설 예시는 전체 의사결정 과정을 보여주기 때문에 유용합니다. 즉, 부하를 관찰하고, 설정된 제한을 확인하고, 의도적으로 제한을 늘리고, 설정을 저장하고, 동일한 작업 부하에서 검증하는 과정을 보여줍니다. 이러한 과정은 단순히 큰 값을 할당하고 문제가 해결되었다고 가정하는 것보다 훨씬 더 신뢰할 수 있습니다.