mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 09:25:06 +03:00
migrate(docs): troubleshooting 12 (#30942)
* migrate(docs): troubleshooting 12 database connections * Update database-error-remaining-connection-slots-are-reserved-for-non-replication-superuser-connections-3V3nIb.mdx * Update how-do-i-update-connection-pool-settings-in-my-dashboard-wAxTJ_.mdx Added missing content * Apply suggestions from code review --------- Co-authored-by: Kevin Brolly <kevin.brolly@supabase.io>
This commit is contained in:
CharisandKevin Brolly authored and GitHub committed
1 parent
a9ed0b4a66
commit
7837deee41
6 files changed
+194
No files matched your search
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title = "Database Error: remaining connection slots are reserved for non-replication superuser connections"
|
||||
github_url = "https://github.com/orgs/supabase/discussions/13995"
|
||||
date_created = "2023-04-27T10:39:24+00:00"
|
||||
topics = ["database"]
|
||||
keywords = ["connections", "connection slots", "reserved", "superuser"]
|
||||
|
||||
[[errors]]
|
||||
message = "remaining connection slots are reserved for non-replication superuser connections"
|
||||
---
|
||||
|
||||
This error usually occurs when the database reaches the maximum number of connections allowed based on the compute add-on.
|
||||
|
||||
To overcome this, the connections need to be optimized as mentioned here: https://supabase.com/docs/guides/platform/performance#optimizing-the-number-of-connections
|
||||
|
||||
Additionally, you can try using the connection pool to help solve this issue:
|
||||
https://supabase.com/docs/guides/database/connecting-to-postgres#connection-pooler
|
||||
|
||||
If you're already using connection pooling and still hitting the maximum connections, then it is suggested to upgrade your compute add-on that allows more connections: https://supabase.com/docs/guides/platform/compute-add-ons
|
||||
+33
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title = 'Error: "Connection refused" when trying to connect to Supabase database'
|
||||
github_url = "https://github.com/orgs/supabase/discussions/14929"
|
||||
date_created = "2023-06-09T10:38:06+00:00"
|
||||
topics = ["database", "cli"]
|
||||
keywords = ["connection", "fail2ban", "econnrefused"]
|
||||
|
||||
[api]
|
||||
cli = ["supabase-network-bans-get", "supabase-network-bans-remove"]
|
||||
|
||||
[[errors]]
|
||||
message = "connect ECONNREFUSED 1.2.3.4:5432"
|
||||
|
||||
[[errors]]
|
||||
message = 'psql: error: connection to server at "db.xxxxxxxxxxxxxxxxxxxx.supabase.co" (1.2.3.4), port 5432 failed: Connection refused Is the server running on that host and accepting TCP/IP connections?'
|
||||
---
|
||||
|
||||
If you're not able to connect to the Supabase database and see the error `connect ECONNREFUSED 1.2.3.4:5432` or `psql: error: connection to server at "db.xxxxxxxxxxxxxxxxxxxx.supabase.co" (1.2.3.4), port 5432 failed: Connection refused
|
||||
Is the server running on that host and accepting TCP/IP connections?`, this could be because there are banned IPs on your project caused by Fail2ban as it kicks in when attempting 2 wrong passwords in a row.
|
||||
|
||||
These bans will clear after 30mins but you can unban the IPs using the Supabase CLI https://supabase.com/docs/guides/cli following the commands below.
|
||||
|
||||
How to list the banned IPs:
|
||||
|
||||
```
|
||||
% supabase network-bans get --project-ref <project_reference_id> --experimental
|
||||
```
|
||||
|
||||
How to unban the IPs:
|
||||
|
||||
```
|
||||
% supabase network-bans remove --db-unban-ip <ip_address> --project-ref <project_reference_id> --experimental
|
||||
```
|
||||
+36
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title = "How do I update connection pool settings in my dashboard?"
|
||||
github_url = "https://github.com/orgs/supabase/discussions/16787"
|
||||
date_created = "2023-08-24T16:19:11+00:00"
|
||||
topics = ["database", "supavisor"]
|
||||
---
|
||||
|
||||
A few questions I have about updating settings for PgBouncer or Supavisor:
|
||||
|
||||
- How do I know which connection pooler I'm using?
|
||||
|
||||
The PgBouncer connection string looks like: `postgres://postgres:[YOUR-PASSWORD]@db.xxxxxxxxxx.supabase.co:6543/postgres`
|
||||
|
||||
The Supavisor connection string looks like: `postgres://postgres.xxxxxxxxx:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:6543/postgres`
|
||||
|
||||
The subdomain will vary depending on the region a project is deployed in. The project reference is to be included in the username following a `.`. If the username is `postgres` the username you use for Supavisor is `postgres.[PROJECT_REF]`.
|
||||
|
||||
- How do I update the size of the connection pool to the database?
|
||||
|
||||
You can set the `Max Client Connections` field in your database settings here:
|
||||
|
||||
[https://supabase.com/dashboard/project/\_/settings/database](https://supabase.com/dashboard/project/_/settings/database)
|
||||
|
||||
- How do I change the client connection limit?
|
||||
|
||||
You can set the `Default Pool Size` field in your database settings:
|
||||
|
||||
[https://supabase.com/dashboard/project/\_/settings/database](https://supabase.com/dashboard/project/_/settings/database)
|
||||
|
||||
- How do I use `session` mode?
|
||||
|
||||
With Supavisor you can automatically use `session` mode by using the connection string with port `5432` in it.
|
||||
|
||||
You can also set the pooler port 6543 to use `session` mode in the database settings:
|
||||
|
||||
[https://supabase.com/dashboard/project/\_/settings/database](https://supabase.com/dashboard/project/_/settings/database)
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
title = "How to change max database connections"
|
||||
github_url = "https://github.com/orgs/supabase/discussions/27197"
|
||||
date_created = "2024-06-12T02:49:15+00:00"
|
||||
topics = ["database", "supavisor", "cli"]
|
||||
keywords = ["connections", "postgres", "memory", "cpu"]
|
||||
|
||||
[api]
|
||||
cli = ["supabase-postgres-config-update"]
|
||||
---
|
||||
|
||||
> WARNING: Manually configuring the connection count hard codes it. This means if you upgrade or downgrade your database, the connection count will not auto-resize. You will have to make sure to manually update it.
|
||||
|
||||
# Changing Max Database Connections:
|
||||
|
||||
Each compute instance has a default direct connection and pooler connection settings. You can find the most recent settings in the [compute docs](https://supabase.com/docs/guides/platform/compute-add-ons#disk-io):
|
||||
|
||||
| Compute Size | Direct Connections | Pooler Connections |
|
||||
| ------------ | ------------------ | ------------------ |
|
||||
| Nano (free) | 60 | 200 |
|
||||
| Micro | 60 | 200 |
|
||||
| Small | 90 | 400 |
|
||||
| Medium | 120 | 600 |
|
||||
| Large | 160 | 800 |
|
||||
| XL | 240 | 1,000 |
|
||||
| 2XL | 380 | 1,500 |
|
||||
| 4XL | 480 | 3,000 |
|
||||
| 8XL | 490 | 6,000 |
|
||||
| 12XL | 500 | 9,000 |
|
||||
| 16XL | 500 | 12,000 |
|
||||
|
||||
## Configuring Direct Connections Limits
|
||||
|
||||
> Note: the Supavisor connection limits are hard-coded and cannot be changed without upgrading the compute size:
|
||||
|
||||
You can configure the maximum amount of connections that Postgres will tolerate with the [Supabase CLI.](https://supabase.com/docs/guides/platform/custom-postgres-config)
|
||||
|
||||
You can run the following commands:
|
||||
|
||||
```sh
|
||||
npx supabase login
|
||||
|
||||
npx supabase --experimental --project-ref <PROJECT REF> postgres-config update --config max_connections=<INTEGER VALUE>
|
||||
```
|
||||
|
||||
Then you could run the following SQL in the SQL Editor to see if the changes went through:
|
||||
|
||||
```sql
|
||||
SHOW max_connections;
|
||||
```
|
||||
|
||||
# Dangers of increasing the direct connection limits
|
||||
|
||||
**Three** factors must be taken into consideration when adjusting the direct connection limit:
|
||||
|
||||
### Process Schedulers and Postgres Internals:
|
||||
|
||||
Allowing too many direct connections in your database can overburden Postgres schedulers and other internal modules. This will result in a noticeable decrease in query throughput, despite having more connections available. EnterpriseDB wrote a wonderful [article](https://www.enterprisedb.com/postgres-tutorials/why-you-should-use-connection-pooling-when-setting-maxconnections-postgres) that outlines some of the considerations.
|
||||
|
||||
The default connection values are set based on a solid understanding of Postgres architecture, and straying too far from them is _likely_ to hinder performance. However, with some experimentation, you might discover a value better suited to your specific needs. Still, unless there's a compelling reason to adjust the setting, it's generally advisable to stick with the defaults or change the values judiciously.'
|
||||
|
||||
### Memory
|
||||
|
||||
> If you do not know how to monitor memory and CPU with Supabase Grafana, [check here](https://github.com/orgs/supabase/discussions/27141).
|
||||
|
||||
#### Each direct connection is a running process that will consume active memory
|
||||
|
||||
This is a Grafana Chart 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. However, when there is little available memory or uncached data is rapidly accessed, [thrashing](<https://en.wikipedia.org/wiki/Thrashing_(computer_science)>) can occur.
|
||||
|
||||
To avoid displacing cache or straining system resources, it is advised to not increase your direct connections unless you have a clear excess of unclaimed memory (green).
|
||||
|
||||
Postgres will allow you to overcommit memory. You can run the below query to find out the hypothetical max value you could change it to without risking memory failure:
|
||||
|
||||
> NOTE: You can find your server memory in the [compute add-ons docs](https://supabase.com/docs/guides/platform/compute-add-ons)
|
||||
|
||||
```sql
|
||||
select
|
||||
'(SERVER MEMORY - ' || current_setting('shared_buffers') || ' - (' || current_setting(
|
||||
'autovacuum_max_workers'
|
||||
) || ' * ' || current_setting('maintenance_work_mem') || ')) / ' || current_setting('work_mem');
|
||||
```
|
||||
|
||||
### CPU
|
||||
|
||||
The below chart is an example of what can occur to the CPU if 100s of connections are inappropriately opened/closed every second or many CPU intensive queries are run in parallel
|
||||
|
||||
|
||||
|
||||
If you plan on increasing your direct connection numbers, your database should have relatively predictable or low CPU usage, such as what the example displays below:
|
||||
|
||||
<img
|
||||
width="706"
|
||||
alt="Screenshot 2024-06-11 at 3 09 03 PM"
|
||||
src="https://github.com/supabase/supabase/assets/91111415/ee3e4f4c-87a1-4ef8-9ca5-af9094fc1b93"
|
||||
/>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 125 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 68 KiB |
Reference in new issue
Block a user