golang:1.25로 다시 빌드했으니 런타임이 CPU limit 2를 인식할 거라고 기대했어요. 그런데 파드에서는 여전히 gomaxprocs=32 numcpu=32가 찍히고, nr_throttled도 실행할 때마다 몇천씩 올라가요. 워커를 16에서 4로 줄였더니 9분에서 7분으로만 줄었어요. 제가 뭘 놓치고 있는 걸까요? 감사합니다.
FROM golang:1.25 AS build
...
RUN CGO_ENABLED=0 go build -o /manifestd .module github.com/maxlab/manifestd
go 1.23.0resources:
requests:
cpu: "1"
limits:
cpu: "2"파드 env에 GOMAXPROCS는 없고, 코드에서 runtime.GOMAXPROCS를 값과 함께 호출하는 곳도 없어요. 같은 바이너리가 제 MacBook에서는 2.5분 정도 걸려요.
Rebuilt on golang:1.25 expecting the runtime to see the 2 CPU limit. The pod still logs gomaxprocs=32 numcpu=32 and nr_throttled climbs a few thousand per run. Workers 16 to 4 only took 9 min to 7. What am I missing? Thanks.
FROM golang:1.25 AS build
...
RUN CGO_ENABLED=0 go build -o /manifestd .module github.com/maxlab/manifestd
go 1.23.0resources:
requests:
cpu: "1"
limits:
cpu: "2"No GOMAXPROCS in the pod env, and nothing in the code calls runtime.GOMAXPROCS with a value. The same binary takes about 2.5 min on my MacBook.
go.mod에 1.23.0이라고 되어 있네요. 1.25로 바꿔 보세요.
go 1.25.0감사해요, 그런데 빌더가 이미 golang:1.25라서 툴체인은 충분히 최신이에요. go 줄은 최소 버전일 뿐이라고 생각했어요. 1.23.0이면 왜 그게 꺼지는 거예요?
Thanks, but the builder is already golang:1.25, so the toolchain is new enough. I thought the go line was only a minimum version. Why would 1.23.0 turn that off?
최소 버전일 뿐인 게 아니에요. 메인 모듈의 go 줄이 GODEBUG 기본값을 정해서, 1.23.0이면 예전 GOMAXPROCS 동작이 그대로 유지돼요.
저도 예전 go.mod에 새 툴체인을 썼다가 똑같이 당한 적이 있어요.
It is not only a minimum. The main module's go line sets the GODEBUG defaults, so 1.23.0 keeps the old GOMAXPROCS behaviour.
Same thing bit me once with an old go.mod and a new toolchain.
작은 보정 도구인데 코드는 아래에 있어요. 출력은 맞는데 너무 느려요. detrend+clip은 몇 초씩 걸리고, rms도 원래보다 느려요. 요소당 곱셈 한 번, 덧셈 한 번뿐인데도요. -O3랑 -march=native를 써…
센서 데이터를 평활화하고 있어요. 배열은 readings(nstation, ntime)이고, station이 먼저예요. 데이터 파일이 그렇게 배치돼 있고 다른 도구들도 읽기 때문이에요. station에 대해 루프를 한 번 돌…
크레이트 분리 이야기는 늘 누군가 빌드 시간 하나를 올리는 것으로 끝난다. 숫자는 두 개고, 움직이는 방향도 다르다. 클린 빌드는 빈 target에서 시작하는 전체 빌드다. 크레이트를 나누면 이쪽은 오히려 조금 나빠질 수 있…
