You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
engine: validate memory budget sizing at startup (refuse or warn on an impossible config) #281
Follow-up to EN-9 (#275), which adds a per-graph memory budget (max_graph_memory_bytes), a per-query limit (max_query_memory_bytes) and a process-wide query pool (max_total_query_memory_bytes, which defaults to a share of the detected cgroup memory limit).
The documented sizing rule is:
(sum of graph budgets) + (process-wide query pool) + server overhead <= 0.8 x container memory limit
Stored graph facts and query working memory are separate budgets, so they add up. Today nothing checks the rule. An operator can set values that break it, and the process is OOM-killed while every individual limit holds.
Ask: at startup, read the detected container memory limit and validate the configured budgets against the rule:
refuse to start, or warn loudly, on a config that cannot hold, for example a per-query limit above the pool, or pool + graph budgets over 0.8 x the limit;
warn when no container limit can be detected and the pool falls back to unlimited.
The graph term needs a decision: the number of graphs is not known at startup. Options are a configured graph count, max_knowledge_graphs, or checking at graph creation time.
Activity