mirror of
https://github.com/supabase/supabase.git
synced 2026-09-22 13:37:53 +08:00
Saxon Fletcher
e0280cb650
<!-- CURSOR_AGENT_PR_BODY_BEGIN --> ## Stack Draft stack extracted from `docs/monitoring`. Merge bottom-up. The troubleshooting *catalog* rewrite (`content/troubleshooting` and the Diagnosing UI) stays out of scope. 1. #49503 move inspect and advisors 2. #49501 split Studio logs from ClickHouse queries 3. #49500 treat reports as signal dashboards 4. #49502 add Observe the data hub 5. #49506 add agent setup components 6. #49504 add hire-an-agent templates 7. **#49505** restructure observability nav, overview, Detecting, and flatten Observe the data ← **this PR** ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Docs update. Top layer in the observability stack. ## What is the current behavior? The section is still titled Monitoring and Debugging, with a Debugging / Monitoring split that does not match the new pages. The debugging guide is still the master layer-isolation + symptom table. Observe the data is split into “what data” vs “where to observe it,” which duplicates the source pages. ## What is the new behavior? - Section title is Observability - Overview groups Observe the data, Detect and resolve, Hire an agent, and Export - **Observe the data is flattened by source.** Logs, Metrics API, Database, Advisors, and Reports each list where to read that source. There is no separate MCP/API/CLI/Studio nav group. - **Observe vs Detecting:** Observe is the catalog (what exists, how to access it). Detecting is how to *use* those sources to pick up a Health / Security / Performance / Usage signal. Named errors skip to Diagnosing. - Studio Logs sits under Logs. Reports sits beside the other sources. - Troubleshooting stays in the global menu and also appears as Diagnosing under Detect and resolve ## Additional context This is the last PR in the stack. Together the seven PRs reconstruct the `docs/monitoring` observability IA and guide content, without shipping the troubleshooting catalog overhaul. <!-- CURSOR_AGENT_PR_BODY_END --> <div><a href="https://cursor.com/agents/bc-a3cb5ece-925b-4046-b58a-5d69e9a9d794?cursor_ref=pr_footer&cursor_cta=open_in_web"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a href="https://cursor.com/background-agent?bcId=bc-a3cb5ece-925b-4046-b58a-5d69e9a9d794&cursor_ref=pr_footer&cursor_cta=open_in_cursor"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </div> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Saxon Fletcher <SaxonF@users.noreply.github.com> Co-authored-by: Nik Richers <nik@validmind.ai>
48 lines
3.8 KiB
Plaintext
48 lines
3.8 KiB
Plaintext
---
|
||
title = "High RAM usage"
|
||
topics = [ "platform" ]
|
||
keywords = [ "memory", "RAM", "performance" ]
|
||
database_id = "a589d411-ee50-455a-892e-526914ddb40d"
|
||
---
|
||
|
||
<Admonition type="note">
|
||
|
||
High memory usage doesn't necessarily mean that your instance is at risk. Memory that is used for caching and buffers improves data access speed. But if you notice less performance alongside high memory usage, your memory usage might be unhealthy.
|
||
|
||
</Admonition>
|
||
|
||
## Base memory usage
|
||
|
||
You may observe elevated memory usage even when your database has little to no load. Supabase requires a wide range of services other than Postgres to operate, which can result in an elevated base memory usage. Especially on the smallest compute instance that comes with 1 GB of RAM, it is not unusual for your project to have a base memory usage of ~50%.
|
||
|
||
## Issues with high memory usage
|
||
|
||
Every Supabase project runs in its own dedicated virtual machine. Your instance will have a different set of hardware provisioned depending on your [compute add-on](/docs/guides/platform/compute-and-disk). Depending on your workload, your compute hardware may not be suitable and can result in high RAM usage.
|
||
|
||
A good proxy for unhealthy memory usage is swap usage. If you run out of RAM, your system will offload memory to your disk's much slower swap partition. If your swap is above 70%, chances are high that your compute hardware is not suitable for your workload. Head over to your project's [Database Health](/dashboard/project/_/observability/database) to see your swap usage.
|
||
|
||
High RAM usage could come with a range of issues:
|
||
|
||
- degraded performance overall when your instance has to use swap memory
|
||
- the operating system may start killing processes as your system runs out of memory
|
||
- in rare cases, your instance may become unresponsive
|
||
|
||
## Monitor your RAM
|
||
|
||
To check your RAM usage on the Supabase Platform, head over to [Database Health in the Observability section](/dashboard/project/_/observability/database).
|
||
|
||
It is also possible to monitor your resources and set up alerts using Prometheus/Grafana. With Grafana you will be able to see how much of your RAM is used for caching and you can track other metrics such as your Swap usage. Read the [Metrics Guide](/docs/guides/observability/metrics) to learn more.
|
||
|
||
## Common reasons for high RAM usage
|
||
|
||
Everything you do with your Supabase project requires memory in some form. Hence, there can be many reasons for high RAM usage. Here are some common ones:
|
||
|
||
- **Query performance:** Queries that take a long time to complete (>1 second) could be using your RAM inefficiently. Check our guide on [examining query performance](/docs/guides/platform/performance#examining-query-performance).
|
||
- **Too many connections:** Every connection to your database consumes memory. You can check the number of active connections under [Database Roles](/dashboard/project/_/database/roles) after you select your project. Read our guide on [too many open connections](/docs/guides/troubleshooting/http-api-issues#too-many-open-connections).
|
||
- **Extensions:** Some extensions such as `timescaledb` or `pg_cron` can use a lot of memory. It can also add up when you have too many extensions running. You can manage your database extensions in the dashboard under [Extensions](/dashboard/project/_/database/extensions).
|
||
|
||
## How to fix your memory issues
|
||
|
||
1. **Upgrade your compute:** You can get a Compute Add-on for your project. See your [upgrade options](/dashboard/project/_/settings/infrastructure) by selecting your project.
|
||
2. **Optimize performance:** Get more out of your instance's resources by optimizing your usage. Have a look at our [performance tuning guide](/docs/guides/platform/performance#examining-query-performance) and our [production readiness guide](/docs/guides/deployment/going-into-prod#performance).
|