hotel_run_eval.sh

placement.sh

remote_b.sh

도구 세 개 다 문법 검증 통과했어. linkstats awk 파서도 샘플로 테스트했고.

A. 결과 해석

STEP 3 — 통과 ✅

Latency 10.04ms avg / 99% 36.77ms,  Requests/sec 285.5 (목표 300)

파이프라인 완성이야. 이전 localhost 경로에서 700 RPS가 7.07초였던 걸 생각하면 완전히 다른 시스템이 됐어. timeout 2395는 서버 문제가 아니라 -c 512가 300 RPS엔 과한 것 — 커넥션당 1.7초에 한 번꼴이라 유휴 커넥션이 타임아웃으로 집계돼. WRK_C_AUTO=on이 처리해.

STEP 4-A — 네 top-5 선정이 맞았어. 내 진단 철회 확정.

TOTAL  694 → 954 → 1088 MB  (30초, 계속 상승 중)

유휴 44MB만 보고 "워킹셋 없다"고 한 건 완전히 틀렸어. 실제 실험(400s warmup + 180s measure, 더 높은 RPS)이면 훨씬 커질 거고.

그런데 이 숫자에 네 top3set 제안을 뒷받침하는 게 들어 있어:

네가 지목한 그 3개가 B 워킹셋의 81%야. geo/profile을 A로 돌려보내도 티어링 대상 메모리는 19%만 줄어. 반면 rate/reservation의 DB·캐시 왕복은 전부 사라지고. 링크 측정 결과를 보기 전인데도 이미 근거가 꽤 강해 — 네 감이 맞았어.

B. STEP 4-B가 0이었던 이유 — 내 명령이 틀렸음

OUTPUT 체인은 이 트래픽을 안 봐. B가 192.168.77.1:27021로 붙으면 패킷은 PREROUTING에서 DNAT돼서 컨테이너로 가고, 응답은 컨테이너 네임스페이스에서 생성돼. 호스트 입장에선 전부 **FORWARD**야. OUTPUT은 호스트가 직접 만든 패킷만 지나가.

FORWARD로 옮겨도 안 돼. 응답 패킷의 source port는 SNAT 복원 전이라 mongo 네 개가 전부 27017로 보여서 구분이 안 돼.