추측 없이 CODE 컨테이너의 메모리 제한을 높이는 방법

Collabora Online CODE 컨테이너에 더 많은 메모리를 할당하려면 컨테이너를 생성하는 구성에서 Docker 제한 값을 높인 다음 컨테이너를 다시 생성하고 docker inspect또는 명령어를 사용하여 적용된 제한 값을 확인하십시오 docker stats. 애플리케이션 설정을 높여도 Docker 컨테이너의 메모리 제한은 증가하지 않으며, 호스트 또는 Docker Desktop 가상 머신에 더 높은 제한 값을 적용할 수 있는 충분한 메모리가 있어야 합니다.

본문 전체에 걸쳐 사용된 예시는 가상 사례입니다. Riley는 단일 호스트 Docker Compose 배포를 관리합니다. docker stats여러 문서가 열려 있는 동안 2GiB의 용량 제한이 표시되고 사용량이 그 한계에 근접한다고 가정해 보겠습니다. Riley는 4GiB의 용량 제한을 고려하고 있습니다. 이 수치는 예시일 뿐이며 Collabora의 용량 권장 사항, 성능 보증 또는 테스트 결과가 아닙니다. 실제 용량 제한은 관찰된 부하와 호스트 용량을 기반으로 설정해야 합니다.

1. 용기가 뚜껑에 제대로 닿는지 확인하십시오.

Docker 호스트에서 다음 명령어를 실행하세요. 단, collabora실제 컨테이너 이름으로 바꿔야 합니다.

docker stats --no-stream collabora
docker inspect --format 'Memory={{.HostConfig.Memory}} OOMKilled={{.State.OOMKilled}}' collabora

docker stats현재 사용량과 컨테이너 제한을 보여줍니다. inspect 출력은 구성된 메모리 제한(바이트)과 Docker가 컨테이너를 OOM-kill로 기록하는지 여부를 보고합니다. inspect 값이 0이라는 0것은 Docker에 해당 컨테이너에 대한 명시적인 하드 제한이 없다는 의미이며, 시스템에 무제한 RAM이 있다는 것을 의미하지는 않습니다. 높은 값만으로는 메모리 부족 오류가 발생했다는 증거가 될 수 없으므로 재시작 기록, 로그 및 사용자가 오류를 목격한 시간과 함께 비교해야 합니다.

메모리 사용량 제한을 늘리기 전에 운영 체제 및 기타 서비스에 사용할 수 있는 RAM 용량을 확인하십시오. Docker 리소스 가이드 에서는 애플리케이션 요구 사항을 테스트하고 충분한 리소스를 갖춘 호스트에서 컨테이너를 실행할 것을 권장합니다. Docker Desktop의 경우 설정 > 리소스 에서도 확인하십시오 . Docker VM에 할당된 메모리는 컨테이너들이 공유하는 별도의 제한값입니다. CODE의 제한값을 해당 할당량 이상으로 늘려도 물리적 메모리가 추가되는 것은 아닙니다. 자세한 내용은 Docker Desktop 리소스 설정을 참조하십시오 .

2. Compose 서비스 제한 변경

Compose 파일에서 기존 CODE 서비스를 편집합니다. 현재 이미지 태그, 포트, 환경, 볼륨, 네트워크 및 재시작 정책은 그대로 유지하고 메모리 설정만 추가하거나 업데이트합니다. Riley의 가상 예시인 4GiB의 경우 다음과 같습니다.

services:
  collabora:
    image: collabora/code:your-current-tag
    mem_limit: 4g
    # Keep the service’s existing settings below

이 예제에서는 Collabora의 공식 CODE Docker 이미지를 사용합니다 . 배포에서 이미 사용 중인 태그를 그대로 유지하세요. ` mem_limitresidual`은 예약이 아닌 엄격한 상한선입니다. Docker는 컨테이너가 해당 용량까지 사용할 수 있도록 허용하지만, 호스트에서 해당 용량만큼의 RAM을 예약하는 것은 아닙니다. Docker Compose 서비스 참조에서는 ` residual` 을 정의하고 mem_limit있으며, 두 값이 모두 존재하는 경우 일치해야 한다고 명시하고 있습니다 deploy.resources.limits.memory. 배포에서 오케스트레이터 또는 플랫폼 관리형 Compose 파일을 사용하는 경우 해당 플랫폼에서 지원하는 리소스 필드를 사용하고 중복된 제한 값을 일관되게 유지하세요.

CODE를 직접 실행했다면 docker run, 원래 명령어를 사용하여 다시 생성 --memory=4g하고 현재 옵션을 모두 유지하세요. 기존 Linux 컨테이너를 런타임에 빠르게 변경하려면 Docker에서 `compose up` 명령어도 지원합니다 docker update --memory 4g <container_name>. 나중에 컨테이너를 교체해도 이전 설정이 복원되지 않도록 Compose 파일 또는 원래 실행 명령어를 기준으로 삼으세요. Docker 컨테이너 업데이트 참조를 확인하세요 .

3. 저장된 제한이 적용되도록 코드를 다시 생성하세요.

활성화된 Compose 파일이 있는 디렉터리에서 병합된 구성을 검증한 다음 CODE 서비스만 다시 생성합니다.

docker compose config
docker compose up -d --no-deps --force-recreate collabora

파일에서 서비스 키를 가져와서 사용하십시오 collabora. 새 제한을 적용하기 전에 렌더링된 구성을 검토하십시오. CODE를 다시 생성하면 해당 컨테이너에 의존하는 편집 세션이 잠시 중단되므로 짧은 서비스 중단이 허용되는 시점에 변경 작업을 예약하십시오. 볼륨을 제거하거나 명령을 실행하지 마십시오. docker compose down -v이러한 작업은 메모리 제한 변경에 불필요하며 다른 서비스에 속한 영구 데이터를 삭제할 수 있습니다.

4. 새 캡을 검증하고 부하 시 동작을 확인합니다.

서비스 응답이 돌아오면 YAML 파일뿐 아니라 실제 컨테이너를 확인하십시오.

docker inspect --format 'Memory={{.HostConfig.Memory}} OOMKilled={{.State.OOMKilled}}' collabora
docker stats --no-stream collabora

예시 값의 경우 4g, 검사 출력은 약 4GiB 바이트를 나타내며, docker stats4GiB 근처의 제한값을 보여야 합니다. 아래 이미지는 설명을 위한 샘플 출력입니다. 그런 다음 배포 환경에 중요한 문서 유형과 대략적인 동시 세션 수를 열면서 코드를 관찰하십시오. 컨테이너가 계속 실행되고, 사용자에게 표시되는 오류가 사라지며, 호스트가 다른 프로세스를 위해 메모리를 유지하는지 확인하십시오.

문제가 계속되면

새로운 제한이 적용되었는데도 CODE가 계속 재시작되는 경우, docker inspect상태를 확인 docker logs하고 호스트 커널 또는 Docker 이벤트에서 메모리 부족 오류가 있는지 살펴보십시오. 컨테이너는 정상적으로 유지되지만 문서 처리 중에 정리 작업이 계속 발생하는 경우, Docker가 병목 현상의 원인이 아닐 수 있습니다. Collabora 자체 coolwsd구성은 Docker cgroup 제한과는 별개의 메모리 관리 동작을 가지고 있으며, 프로젝트 구성 템플릿 에 서버 측 제어 방식이 설명되어 있습니다. 변경하기 전에 설치된 CODE 릴리스의 구성을 확인하십시오.

컨테이너에 무제한 메모리를 설정하거나 메모리 부족 시 종료 기능을 비활성화하는 방식으로 불확실성을 해결하지 마십시오. Docker는 무제한 컨테이너가 호스트 메모리를 고갈시키고 관련 없는 서비스에도 영향을 미칠 수 있다고 경고합니다. 호스트에 충분한 여유 공간이 없다면, 진정한 해결책은 호스트 또는 Docker VM 용량을 추가하거나, 동시 실행 작업량을 줄이거나, 작업을 분산하는 것이지, 사용 가능한 RAM 용량 이상으로 제한을 높이는 것이 아닙니다.