Interpreting Supabase Grafana Memory Charts
Last edited: 1/15/2025
Here are examples of unhealthy memory usage:
- Yellow: represents active memory
- Red: represents SWAP, which is disk storage that the system treats as if it were actually memory
- Green: it is unclaimed (the system will always leave some memory unclaimed)
- Blue: it is cached data and a buffer
The cache in PostgreSQL is important because the database will store frequently accessed data in it for rapid retrieval. If too much active memory is needed, it runs the risk of excessively displacing cache. This will force queries to check disk, which is slow.
Most data in a database is idle, but in cases where there is little available memory or uncached data is rapidly accessed, thrashing can occur.
Ideally, you want queries to hit the cache 99% of the time. You can use the Supabase CLI inspect db cache hit command to check your cache hit rate. Alternatively, you can run the query found in the CLI's GitHub repo in the SQL Editor
_11# login to the CLI_11npx supabase login_11_11# initlize a local supabase directory_11npx supabase init_11_11#link your project_11npx supabase link_11_11# find cache hit rate_11npx supabase inspect db cache-hit --linked
If the cache hit rate begins to drop below the ideal amount, one should consider taking the following actions:
Optimizing:
- Apply indexes: can reduce the amount of data pulled from disk into memory
- Increasing the compute size
- Distribute load by using read-replicas
- Partitions: Generally should be used on very large tables to minimize data pulled from disk into memory
- Remove bloat: Bloat can fragment data across pages, causing redundant data to be pulled from disk.
- Table refactoring: Split tables to isolate columns that are less frequently accessed, so they are not redundantly pulled into memory while accessing hotter data