Skip to content

feat: add calculate default maps size by session - #622

Merged
pirog-spb merged 1 commit into
edgecomllc:mainfrom
VITEK-THE-BEST:feat/add-calculate-default-map-size
Jun 4, 2025
Merged

pirog-spb merged 1 commit into
edgecomllc:mainfrom
VITEK-THE-BEST:feat/add-calculate-default-map-size

Conversation

@VITEK-THE-BEST

Copy link
Copy Markdown
Contributor

No description provided.

@pirog-spb
pirog-spb merged commit 5653b09 into edgecomllc:main Jun 4, 2025
pirog-spb pushed a commit to martin-mat/eupf that referenced this pull request Oct 22, 2026
Since edgecomllc#622 an unset map size is derived from max_sessions, whose default
is 65535: PDR, FAR and URR maps of 131,070 entries and a QER map of
65,535. Those maps are allocated at startup and charged to the pod, about
115 MiB, a working set of about 140 MiB with the process. The chart's
default memory limit is 128 Mi, set for the 1024-entry maps of the 0.7.1
image, so an image built from main fails at startup with the chart's
defaults: "creating map: map create: cannot allocate memory".

The chart now sets UPF_MAX_SESSIONS to 1024 in defaultEnv, which keeps the
maps at the size the limit was set for (a working set of about 30 MiB),
and the README says how max_sessions and the memory limit scale together:
about 1.8 MiB per 1024 sessions on top of the process's ~30 MiB. In
ConfigMap mode max_sessions goes into config.data, since the default
variables are not injected there.

Measured on a kind cluster with the kubelet's accounting: main's defaults
start under 192 Mi and above, not under 128 Mi; with UPF_MAX_SESSIONS=1024
the pod starts under 128 Mi and passes the same tests as 0.7.1.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Signed-off-by: Martin Matyas <[email protected]>
pirog-spb pushed a commit to martin-mat/eupf that referenced this pull request Oct 22, 2026
Since edgecomllc#622 an unset map size is derived from max_sessions, whose default
is 65535: PDR, FAR and URR maps of 131,070 entries and a QER map of
65,535. Those maps are allocated at startup and charged to the pod, about
115 MiB, a working set of about 140 MiB with the process. The chart's
default memory limit is 128 Mi, set for the 1024-entry maps of the 0.7.1
image, so an image built from main fails at startup with the chart's
defaults: "creating map: map create: cannot allocate memory".

The chart now sets UPF_MAX_SESSIONS to 1024 in defaultEnv, which keeps the
maps at the size the limit was set for (a working set of about 30 MiB),
and the README says how max_sessions and the memory limit scale together:
about 1.8 MiB per 1024 sessions on top of the process's ~30 MiB. In
ConfigMap mode max_sessions goes into config.data, since the default
variables are not injected there.

Measured on a kind cluster with the kubelet's accounting: main's defaults
start under 192 Mi and above, not under 128 Mi; with UPF_MAX_SESSIONS=1024
the pod starts under 128 Mi and passes the same tests as 0.7.1.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Signed-off-by: Martin Matyas <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants