@st.cache_data memory growth across reruns: choosing eviction settings to keep RSS stable

Goal

I am designing a Streamlit app (version 1.18 or later) that uses @st.cache_data to cache large DataFrames returned from a data-loading function. Widget interactions rerun the script with varying filter parameters, so each distinct parameter combination creates a new cache entry. The goal is to keep the server process memory footprint bounded over long uptimes without excessive recomputation.

Constraints and uncertainty

From the documentation, cached values persist for the lifetime of the server process unless evicted by ttl or max_entries, and st.cache_data.clear() releases entries programmatically. What is unclear is how to size these knobs: an aggressive TTL bounds memory but increases reload latency, while max_entries evicts by recency, which may thrash if users cycle among many parameter sets. There is also ambiguity about how server-wide cache memory interacts with per-session st.session_state objects holding derived data, since they have different lifecycles, and whether figures created inside cached functions need explicit closing to avoid additional retention.

Questions

• For a workload with many distinct parameter combinations, is max_entries or a moderate ttl the more predictable way to bound RSS, and how should the two be combined?
• When profiling, how can I cleanly separate memory held by the shared cache from memory held by per-session state?
• Is calling st.cache_data.clear() on a schedule a reasonable safety net, or does it risk evicting entries other concurrent sessions still need?