조용한 개발 노트

Linux 공식문서로 다시 이해하는 JVM 서버 실행 환경6편에서 우리는 OOMKill이 버그가 아니라 Linux 커널의 생존 전략이라는 점을 살펴봤다.이번 편에서는 그 OOMKill과 CPU 스로틀링의 근원이 되는 핵심 개념, cgroup(Control Group)을 다룬다.cgroup은 흔히 이렇게 설명된다.“컨테이너 리소스를 제한하는 기능”하지만 이 설명은 충분하지 않다.cgroup은 단순한 제한 장치가 아니라, 프로세스가 어떤 규칙 아래에서 실행되어야 하는지를 정의하는 시스템이다.cgroup이 등장한 이유cgroup이 도입되기 전의 Linux에서는 다음과 같은 문제가 반복적으로 발생했다.특정 프로세스가 메모리를 과도하게 사용다른 프로세스까지 함께 느려짐시스템 전체가 불안정해짐Linux 커널은 프로..

Linux 공식문서로 다시 이해하는 JVM 서버 실행 환경5편에서 Linux는 Heap을 모르고, 페이지와 가상 주소 공간만을 관리한다는 점을 살펴봤다.이번 편에서는 그 연장선에서 가장 당황스러운 현상 하나를 다룬다.“로그도 없이 프로세스가 죽었다”“JVM 예외는 없는데 컨테이너가 재시작됐다”이 현상의 주범은 대부분 OOMKill이다.OOMKill은 예외가 아니라 정책이다많은 개발자가 OOMKill을 이렇게 받아들인다.“메모리 버그가 터졌다”하지만 Linux 관점에서 OOMKill은 버그가 아니다.시스템을 살리기 위한 마지막 선택이다.Linux 커널의 우선순위는 명확하다.개별 프로세스보다시스템 전체의 생존메모리가 고갈되면, 커널은 프로세스를 선택해 제거한다.OutOfMemoryError와 OOMKill은..

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경6편에서는 종료 중에도 트랜잭션이 흐르고 있다는 사실을 봤다.이번 편에서는 운영 중 가장 많이 겪지만, 가장 오해가 많은 주제를 다룬다.“CPU랑 메모리 limit을 걸었을 뿐인데, 왜 서버가 느려질까?”이 질문의 답은 JVM이나 Spring 설정 하나로 설명되지 않는다.Kubernetes의 리소스 모델과 JVM의 실행 모델이 충돌하는 지점에서 문제가 생긴다.request와 limit은 “권장값”이 아니다Kubernetes 리소스 설정을 처음 접하면 이렇게 이해하기 쉽다.request는 최소 보장limit은 최대 사용개념적으로는 맞지만, JVM 관점에서는 이 설명이 너무 순하다.limit은 “경고선”이 아니라 “강제 제약”이다.CPU..