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

Question

GoalI 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 uncertaintyFrom 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.QuestionsFor 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?

Tasadduq Burney · Answer

Answer the question first
For a workload that can generate many distinct cache keys, max_entries is the most reliable knob to bound RSS.  It guarantees that no more than the configured number of DataFrames are kept in memory, regardless of how long each one lives.  A moderate ttl can be layered on top to drop entries that are unlikely to be reused after a user’s session ends, but it does not provide a hard limit.

Set max_entries to a value that, when multiplied by the average DataFrame size, stays below your RSS budget.
Optionally set ttl (e.g., 300–600 s) so that stale entries from abandoned sessions are evicted sooner, keeping the cache lean when users cycle through many filters.
Use st.cache_data.get_cache_info() to confirm the entry count and a rough size estimate; adjust max_entries until info.current_entries matches your target.
When profiling, call st.cache_data.get_cache_info() before and after a rerun to isolate cache memory from st.session_state memory.  session_state lives in a separate dictionary and is not affected by cache eviction.
Figures created inside cached functions are retained as long as the cache entry exists.  Close or reuse them explicitly (e.g., plt.close(fig)) to avoid extra retention.
Scheduled st.cache_data.clear() removes all cached entries globally.  This is safe only if you can guarantee that no active session still needs the data.  In multi‑user deployments it risks evicting data required by concurrent users; prefer per‑session isolation or rely on max_entries and ttl instead.

Diagnostic detail needed
If you can provide the average size (in MB) of the DataFrames you cache and the RSS budget you need to stay within, I can give a more precise max_entries recommendation.

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

Goal

Constraints and uncertainty

Questions

1 answer

Answer the question first

Diagnostic detail needed

Your perspective belongs here.

0 question comments