반응형 전체 글61 4코어 서버가 2.75코어만 쓰고 있었다: 컨테이너 CPU 한도와 스로틀 읽기 이미지 편집 엔진 4코어 서버가 2.75코어만 쓰고 있었다: 컨테이너 CPU 한도와 스로틀 읽기 사양을 올리기 전에 1분이면 확인되는 것, 그리고 한도가 만드는 파생 오류 핵심 요약 처리가 느릴 때 후보는 셋이다 — 코드가 느리거나, 서버가 작거나, 한도가 막고 있거나. 밖에서 응답 시간만 보면 셋이 똑같이 보인다. 구분하는 값은 커널이 세어 준다. cgroup v2라면 컨테이너 안에서 nr_throttled가 그냥 읽히고, 0이 아니면 한도가 실제로 작업을 막고 있다는 뜻이다. 이 서버는 4코어인데 한도 합이 2.75였다. 목표 사양이 2 vCPU이던 시절 값이 그대로 남아 1.25코어가 아무에게도 할당되지 않은 채 놀고 있었다. 한도를 풀자 같은 부하에서 1... 2026. 8. 24. 서버 한 대로 무중단 배포하기: Caddy 헬스체크가 못 막는 502 이미지 편집 엔진 서버 한 대로 무중단 배포하기: Caddy 헬스체크가 못 막는 502 상태 위치 조사부터 재시도 설정까지, 실측 557건으로 확인한 절차 핵심 요약 무중단의 전제는 서버 대수가 아니라 상태의 위치다. 상태를 안 가진 계층만 교체할 수 있고, 그 계층만 골라내면 VPS 한 대로도 된다. 인스턴스를 둘 띄우되 로드밸런싱은 하지 않는 선택도 정당하다. 프로세스 메모리에 사는 것(요청 한도 카운터 등)이 있으면 트래픽을 나누는 순간 그 값이 두 배가 된다. 헬스체크만으로는 못 막는 구간이 원리적으로 남는다. 관찰이 주기적이기 때문이다. 롤링 중 555번 중 3번이 502였다. 연결 실패에만 재시도를 걸어 그 구간을 덮었다. 재측정 557번 중 실패 0,.. 2026. 8. 24. Docker 메모리 한도를 감으로 정하지 않는 법: 최악 입력과 RSS 기울기 이미지 편집 엔진 Docker 메모리 한도를 감으로 정하지 않는 법: 최악 입력과 RSS 기울기 가끔 죽는 컨테이너에서 시작해 한도를 실측으로 다시 잡기까지 핵심 요약 간헐 장애는 재현하려 하지 말고 흔적을 찾는다. 자동 복구가 로그를 지우는 동안에도 재시작 카운터는 쌓인다 — 그게 restarts=3을 가리켰다. 재보지 않으면 손에 있던 픽스처가 한도를 정해 버린다. 먼저 정할 것은 "시스템이 받아들이는 가장 무거운 입력"이고, 입력 제약이 여러 개면 그 지점은 어느 한 상한이 아니라 상한들이 함께 걸리는 모서리에 있다. 올릴지 고칠지는 값이 아니라 기울기로 가른다. 재시작 후 같은 작업을 여러 건 넣고 RSS를 찍어 평평하면 한도 상향이 해결, 우상향이면 시간 벌기.. 2026. 8. 24. CI가 초록인데 라이브가 깨졌다: 배포 검증을 어디서 끝낼 것인가 이미지 편집 엔진 CI가 초록인데 라이브가 깨졌다: 배포 검증을 어디서 끝낼 것인가 각 신호가 실제로 증명하는 것, 그리고 자동화가 멈춰야 하는 지점 핵심 요약 테스트 189개, config 검증, 헬스체크, 필수값 가드가 전부 초록인 채로 법적 고지가 깨져서 배포됐다. 넷 다 정상 동작했다 — 각자 다른 것을 증명하고 있었을 뿐이다. 설정값이 여러 파일을 건널 때 중간이 끊겨도 아무것도 실패하지 않는다. 빌드는 성공하고 컨테이너는 뜬다. 이 경계에는 타입 검사에 해당하는 것이 없다. 검사를 만들어 두는 것으로 끝나지 않는다. 실행되지 않는 검사는 없는 검사보다 나쁘다 — 있다고 믿는 만큼 확인을 덜 하기 때문이다. 그래서 배포 마지막에 라이브 페이지를 직접 긁게.. 2026. 8. 24. 이전 1 2 3 4 ··· 16 다음 반응형
