View Source mix active_memory.candidates (ActiveMemory v0.8.1)
Reads your database's own table statistics through the application's Ecto repo
and reports which tables have the high-read, low-write workload that makes them
candidates for an ActiveMemory.Table.
$ mix active_memory.candidates
$ mix active_memory.candidates -r MyApp.Repo
$ mix active_memory.candidates --min-ratio 25 --max-rows 10000
The repo comes from -r/--repo, or from the application's :ecto_repos
configuration, exactly as the ecto.* tasks resolve it. PostgreSQL and
MySQL/MariaDB are supported; the statistics sources and what counts as a "read"
on each are described in ActiveMemory.Candidates.
options
Options
-r,--repo— the Ecto repo to read statistics through--min-ratio— reads per write to call a table a candidate (default 10; ten times this is a strong candidate)--max-rows— tables above this row count are flagged as too large for the in-memory sweet spot (default 50000)--min-reads— tables with fewer total operations than this are reported as having too little traffic to judge, since a stray read of an untouched table would otherwise look infinitely read-heavy (default 100)--timeout— query timeout in milliseconds, for schemas so large the statistics views themselves are slow (default is the repo's own timeout)
safe-against-production
Safe against production
The task performs only read-only queries against the database's statistics views — it never touches application tables — and it does not start your application: only its configuration is loaded, and the one repo you name is started with a two connection pool. Nothing else connects: no other repos, no job processors, no endpoints. Use read-only credentials anyway; they cost nothing. The expected impact is the connections themselves plus a few statistics queries.
reading-the-report
Reading the report
Statistics are cumulative — since the last statistics reset on PostgreSQL, since server start on MySQL — so run this against a database that has seen production-like traffic. A development database exercised only by your test suite will tell you nothing useful.
A candidate is worth confirming by eye: the numbers say "read constantly, written rarely", but only you know whether the table is authoritative data your application could load at boot and serve from memory.