문제 15 — 메모리 오버커밋과 OOM Killer, 컨테이너(cgroup) 메모리 제한

게임서버를 리눅스 컨테이너(Docker/Kubernetes) 위에서 운영하다 보면 "메모리를 다 안 썼는데 프로세스가 갑자기 죽는" 현상을 겪게 된다. 이를 이해하려면 오버커밋·OOM Killer·cgroup 메모리 제한의 상호작용을 알아야 한다. 다음을 설명하라.

1. 메모리 오버커밋(overcommit): 리눅스가 실제 물리 메모리+스왑보다 더 많은 가상 메모리 할당(요청)을 허용하는 오버커밋 정책을 설명하라. vm.overcommit_memory의 세 값(0=heuristic, 1=always, 2=never)이 각각 어떤 기준으로 할당 요청을 허용/거부하는지, vm.overcommit_ratio(2 모드에서 사용)의 역할도 함께 설명하라.

2. 오버커밋이 존재하는 이유: 왜 커널이 "요청한 만큼 다 줄 수 없을지도 모르는데" 가상 메모리 할당을 우선 허용하는지 설명하라. fork() 후 대부분 exec()으로 바로 대체되는 관행에서 Copy-on-Write(COW)가 어떻게 오버커밋과 맞물리는지(자식 프로세스가 부모의 전체 주소공간을 "할당은 됐지만 실제로 안 쓰는" 상태로 시작하는 점), 그리고 많은 프로그램이 실제로 쓰는 것보다 넉넉히 할당(예약)만 해두고 실사용량은 적은 경향(sparse allocation)도 함께 짚어라.

3. OOM Killer의 동작: 실제 물리 메모리(+스왑)가 고갈되는 시점에 리눅스가 어떻게 대응하는지 설명하라. OOM Killer가 프로세스를 선정하는 기준인 oom_score(메모리 사용량 비중, 실행 시간, 루트 권한 여부 등이 반영되는 방식)와, 사용자가 oom_score_adj로 특정 프로세스를 보호/우선 희생시킬 수 있는 메커니즘을 설명하라.

4. 컨테이너(cgroup) 메모리 제한과의 차이: 컨테이너에 memory.limit_in_bytes(cgroup v1) 또는 memory.max(cgroup v2) 같은 메모리 상한을 설정했을 때, 그 컨테이너 안의 프로세스가 상한에 도달하면 무슨 일이 일어나는지 설명하라. 이것이 호스트 전체의 OOM Killer(시스템 전체 메모리 고갈 시 전역적으로 희생양을 고르는 것)와 어떻게 다른지 — cgroup 메모리 컨트롤러가 해당 cgroup 내부에서만 별도로 OOM Killer를 발동시켜(cgroup-scoped OOM) 그 그룹 내 프로세스만 희생시키는 점, 호스트의 다른 컨테이너/프로세스는 영향받지 않는 점을 대비해 설명하라. 또한 이 상한 도달과 오버커밋 정책이 상호작용하는 방식(cgroup 제한 내에서도 오버커밋된 가상 메모리가 실제 사용으로 전환되는 순간 제한에 걸릴 수 있음)도 짚어라.

5. 게임서버 운영 관점의 모니터링·방어: 이런 요소들(오버커밵, 시스템 OOM, cgroup OOM)을 게임서버 운영에서 어떻게 모니터링하고 방어할지 실무적으로 정리하라. 예: 메모리 사용량·페이지폴트·swap 사용 추이 모니터링, 컨테이너 메모리 limit/request 설정 시 여유(headroom) 확보, 특정 워커 프로세스의 oom_score_adj 조정으로 중요 프로세스 보호, 메모리 누수 조기 발견을 위한 알림 임계치 설정, graceful degradation(연결 수 제한·캐시 축소)으로 OOM 도달 자체를 회피하는 전략 등.