Connection Memory¶

이 장이 정의하는 것 — connection 하나가 실제로 어떤 memory를 얼마나 할당하는가 (고정 비용과 HWM에 비례하는 가변 비용).

1. Connection memory 개요¶

각 transport connection은 두 종류의 memory를 사용한다. 하나는 connection을 만들 때 할당하는 고정 비용이며, 구성은 inproc와 socket 기반 transport가 다르다. 다른 하나는 queue가 보관하는 message storage와 pending request lifecycle state인 가변 비용으로, 고정된 connection 비용이 아니다. Queue storage는 각 frame의 실제 accounted byte와, queue에 유지할 byte를 제한하는 상한인 HWM에 따라 증가한다.

이 문서는 그 두 비용의 구성과, 이를 관찰·측정할 때의 한계를 정의한다. 대상 독자는 connection당 memory 사용량을 추정하고 capacity planning을 수행하는 개발자다.

관련 계약의 소유 문서는 다음과 같다.

관련 계약	정의하는 문서
memory budget 계산, byte 회계와 HWM admission	Auto HWM
socket 옵션과 HWM 관찰 동작	Socket 공통
각 용어의 짧은 정의	Core 용어

2. 고정 구성 요소¶

connection 하나를 만들 때 traffic 양과 무관하게 할당하는 구성 요소는 transport에 따라 다음과 같이 나뉜다.

Transport	고정 구성 요소
inproc	두 socket endpoint를 직접 연결하는 pipepair. session과 engine은 만들지 않으며 protocol handshake state와 운영체제 socket도 없다.
socket 기반 transport	session, engine, pipe endpoint와 queue chunk, routing ID와 endpoint metadata, protocol handshake state, 운영체제 socket 구조. TLS는 record와 handshake storage를 추가한다.

3. 가변 구성 요소¶

이 절의 계약 소유 — byte 회계, HWM admission과 budget 계산의 공개 계약과 내부 구현은 Auto HWM이 소유한다. 이 절은 그 결과를 connection 하나의 memory 비용 관점에서 요약한다.

3.1 Frame byte charge¶

한 application 방향의 message를 담는 물리 queue를 directional queue라 한다. Connection 하나의 가변 memory는 이 queue가 보관 중인 frame의 byte charge다. Charge의 산식(payload + sizeof(zlink_msg_t)), provisional→committed 전환과 반환 시점은 Auto HWM의 physical queue accounting이 소유하며, 이 문서는 그 결과만 인용한다: charge는 frame이 queue에 있는 동안만 connection의 memory 비용이고, binding이나 application이 dequeue 뒤 payload를 계속 보유하는 수명은 여기에 더해지지 않는다.

3.2 빈 pipe oversize 예외¶

빈 pipe의 complete message 수용 경계와 다음 write 차단은 Auto HWM의 message 처리 순서를 따른다.

3.3 Pending request lifecycle state¶

Pending map entry, callback과 timeout state는 live request 수에 따라 증가한다. Pair별 work·count 수용 한도와 reservation 반환은 Auto HWM의 pending request 수용을 따른다.

3.4 Completion progress lane¶

ROUTER-ROUTER의 completion progress lane은 terminal reply·error reply와 receive-flow-state frame의 별도 경로다. 이 lane과 DEALER-ROUTER Application queue의 HWM·회계는 Auto HWM §2 Completion lane HWM·회계를 따른다.

Completion lane의 SNDBUF·RCVBUF 기본값 -1은 transport 종류와 관계없이 OS 기본값과 autotuning을 유지한다. Application이 0 이상의 값을 명시하면 completion lane에는 최대 64 KiB로 제한한 값을 TCP·TLS·WS·WSS의 기반 TCP socket에 동일하게 적용한다.

4. 측정과 한계¶

실행 중 memory 상태를 조회하는 monitor는 application queue와 completion lane의 current byte, oversize 허용 이력을 구분해 제공한다. Snapshot의 ABI 예약 field와 반환값은 Auto HWM §3의 budget snapshot 계약을 따른다. Core budget — Core가 memory 입력에서 계산해 application queue들의 HWM을 나눌 때 기준으로 삼는 byte 총량 — 은 정상 상태의 pipe별 HWM 분배 기준이지 context 실제 사용량 hard cap이 아니다. 이 값은 Core 회계를 설명하지만 process resident memory의 정확한 측정값은 아니다.

Kernel buffer는 platform autotuning에 따라 증가할 수 있다. TLS는 record와 handshake storage를 추가한다. Monitor snapshot은 적용된 HWM 계획을 보고하지만 allocator와 kernel overhead 전체를 측정하지는 않는다.

DEALER-ROUTER는 logical peer마다 physical connection 하나를 사용하므로 ROUTER-ROUTER보다 idle session·engine·file descriptor와 기반 kernel·TLS·WebSocket storage가 한 connection만큼 적다. 이 차이는 Core budget을 process resident memory hard cap으로 바꾸지 않으며, kernel autotuning과 TLS storage가 monitor snapshot 밖이라는 경계도 바꾸지 않는다.

5. Capacity planning¶

Capacity planning에서는 production transport와 message-size 분포를 사용해 다음 세 값을 각각 측정한다.

idle memory
traffic 이후 잔류 memory
burst peak memory

6. 구현 및 contract test 검증 요구¶

byte 회계, admission, dequeue credit과 oversize 예외의 상세 검증 항목은 Auto HWM의 검증 요구가 소유한다. connection memory 관점에서 확인할 항목은 다음과 같다. 각 항목은 test 하나로 이어진다.

byte charge와 HWM - frame charge의 증가·전환·반환과 HWM admission의 관찰 항목은 Auto HWM §5가 소유한다. 이 문서는 항목을 반복하지 않는다.

oversize와 completion - 빈 queue oversize와 pending request 수용 검증은 Auto HWM의 검증 요구를 참조한다. - Completion lane의 운반은 ZMP request-reply lane, HWM·회계는 Auto HWM §2 Completion lane HWM·회계를 참조한다.

측정 - monitor는 application queue·completion의 current byte와 oversize 허용 이력을 구분해 보고하고, retained-credit 호환 field는 항상 0으로 보고한다. - Core budget은 정상 상태의 pipe별 HWM 분배 기준이며 context 실제 사용량 hard cap으로 동작하지 않는다 (상세 admission 계약은 Auto HWM 소유). - 같은 transport에서 DEALER-ROUTER logical peer는 physical connection 하나, ROUTER-ROUTER는 두 개를 사용한다. Idle resource 감소를 관찰해도 allocator·kernel·TLS를 포함한 process hard cap은 제공되지 않는다.

시스템 목차 | 이전: Thread safety | 다음: Auto HWM