From 90a4b18f1f53617c35c5bf07f8b5755f1f909129 Mon Sep 17 00:00:00 2001 From: Mikhail Kot <mikhail@neon.tech> Date: Wed, 11 Dec 2024 17:14:42 +0000 Subject: [PATCH 1/2] docs: max_connections,shared_buffers,default_pool_size changes --- content/docs/connect/choose-connection.md | 6 +- content/docs/connect/connection-pooling.md | 12 +-- content/docs/extensions/neon.md | 2 +- content/docs/manage/endpoints.md | 86 +++++++++++----------- content/docs/reference/compatibility.md | 58 ++++++++++----- content/docs/reference/glossary.md | 4 +- 6 files changed, 97 insertions(+), 71 deletions(-) diff --git a/content/docs/connect/choose-connection.md b/content/docs/connect/choose-connection.md index 5da914b080..eecd6b653f 100644 --- a/content/docs/connect/choose-connection.md +++ b/content/docs/connect/choose-connection.md @@ -57,7 +57,7 @@ You then need to decide whether to use direct connections or pooled connections If your application is focused mainly on tasks like migrations or administrative operations that require stable and long-lived connections, use an unpooled connection. <Admonition type="note"> -Connection pooling is not a magic bullet. PgBouncer can keep many application connections open (up to 10,000) concurrently, but only a limited number of these can be actively querying the Postgres server at any given time: 64 active backend connections (transactions between PgBouncer and Postgres) per user-database pair, as determined by the PgBouncer's `default_pool_size` setting. For example, the Postgres user `alex` can hold up to 64 connections to a single database at one time. +Connection pooling is not a magic bullet. PgBouncer can keep many application connections open (up to 10,000) concurrently, but only a limited number of these can be actively querying the Postgres server at any given time. For example, 64 active backend connections (transactions between PgBouncer and Postgres) per user-database pair, as determined by the PgBouncer's `default_pool_size` setting, mean that Postgres user `alex` can hold up to 64 connections to a single database at one time. </Admonition> For more information on these choices, see: @@ -71,7 +71,7 @@ Here are some key points to help you navigate potential issues. | Issue | Description | |----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Double pooling | **Neon-side pooling** uses PgBouncer to manage connections between your application and Postgres.<br /><br /> **Client-side pooling** occurs within the client library before connections are passed to PgBouncer.<br /><br />If you're using a pooled Neon connection (supported by PgBouncer), it's best to avoid client-side pooling. Let Neon handle the pooling to prevent retaining unused connections on the client side. If you must use client-side pooling, make sure that connections are released back to the pool promptly to avoid conflicts with PgBouncer. | -| Understanding limits | Don't confuse `max_connections` with `default_pool_size`.<br /><br />`max_connections` is the maximum number of concurrent connections allowed by Postgres and is determined by your [Neon compute size](/docs/connect/connection-pooling#connection-limits-without-connection-pooling).<br /><br />`default_pool_size` is the maximum number of backend connections or transactions that PgBouncer supports per user/database pair, which is set to 64 by default.<br /><br />Simply increasing your compute to get more `max_connections` may not improve performance if the bottleneck is actually on your `default_pool_size`. To increase your `default_pool_size`, contact [Support](/docs/introduction/support). | +| Understanding limits | Don't confuse `max_connections` with `default_pool_size`.<br /><br />`max_connections` is the maximum number of concurrent connections allowed by Postgres, determined by your [Neon compute size](/docs/connect/connection-pooling#connection-limits-without-connection-pooling).<br /><br />`default_pool_size` is the maximum number of backend connections or transactions that PgBouncer supports per user/database pair, also determined by compute size <br /><br />Simply increasing your compute to get more `max_connections` may not improve performance if the bottleneck is actually on your `default_pool_size`. To increase your `default_pool_size`, contact [Support](/docs/introduction/support). | | Use request handlers | In serverless environments such as Vercel Edge Functions or Cloudflare Workers, WebSocket connections can't outlive a single request. That means Pool or Client objects must be connected, used and closed within a single request handler. Don't create them outside a request handler; don't create them in one handler and try to reuse them in another; and to avoid exhausting available connections, don't forget to close them. See [Pool and Client](https://github.com/neondatabase/serverless?tab=readme-ov-file#pool-and-client) for details.| ## Configuration @@ -129,5 +129,5 @@ Here is a table summarizing the options we've walked through on this page: | | Direct Connections | Pooled Connections | Serverless Driver (HTTP) | Serverless Driver (WebSocket) | | --------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------- | --------------------------------------------- | | **Use Case** | Migrations, admin tasks requiring stable connections | High number of concurrent client connections, efficient resource management | One-shot queries, short-lived operations | Transactions requiring persistent connections | -| **Scalability** | Limited by `max_connections` tied to [compute size](/docs/manage/endpoints#how-to-size-your-compute) | Up to 10,000 application connections (between your application and PgBouncer); however, only 64 backend connections (active transactions between PgBouncer and Postgres) are allowed per user/database pair. This limit can be increased upon request. | Automatically scales | Automatically scales | +| **Scalability** | Limited by `max_connections` tied to [compute size](/docs/manage/endpoints#how-to-size-your-compute) | Up to 10,000 application connections (between your application and PgBouncer); however, only [`default_pool_size`](/docs/connect/connection-pooling#neon-pgbouncer-configuration-settings) backend connections (active transactions between PgBouncer and Postgres) are allowed per user/database pair. This limit can be increased upon request. | Automatically scales | Automatically scales | | **Performance** | Low overhead | Efficient for stable, high-concurrency workloads | Optimized for serverless | Optimized for serverless | diff --git a/content/docs/connect/connection-pooling.md b/content/docs/connect/connection-pooling.md index 93d099678a..def70343b4 100644 --- a/content/docs/connect/connection-pooling.md +++ b/content/docs/connect/connection-pooling.md @@ -27,7 +27,7 @@ The `-pooler` option routes the connection to a connection pooling port at the N ## Connection limits without connection pooling -Each Postgres connection creates a new process in the operating system, which consumes resources. Postgres limits the number of open connections for this reason. The Postgres connection limit is defined by the Postgres `max_connections` parameter. In Neon, `max_connections` is set according to your compute size — and if you are using Neon's Autoscaling feature, it is set according to your **minimum** compute size. +Each Postgres connection creates a new process in the operating system, which consumes resources. Postgres limits the number of open connections for this reason. The Postgres connection limit is defined by the Postgres `max_connections` parameter. In Neon, `max_connections` is set according to your compute size — and if you are using Neon's Autoscaling feature, it is set according to your **maximum** compute size. | Compute Size (CU) | vCPU | RAM | max_connections | | :---------------- | :--- | :----- | :-------------- | @@ -93,8 +93,8 @@ Some applications open numerous connections, with most eventually becoming inact The use of connection pooling, however, is not a magic bullet: As the name implies, connections to the pooler endpoint together share a pool of connections to the normal Postgres endpoint, so they still consume some connections to the main Postgres instance. -To ensure that direct access to Postgres is still possible for administrative tasks or similar, the pooler is configured to only open up to [64 connections](#neon-pgbouncer-configuration-settings) to Postgres for each user to each database. For example, there can be only 64 active connections from role `alex` to the `neondb` database through the pooler. All other connections by `alex` to the `neondb` database will have to wait for one of those 64 active connections to complete their transactions before the next connection's work is started. -At the same time, role `dana` will also be able to connect to the `neondb` database through the pooler and have up to 64 concurrent active transactions across 64 connections, assuming the endpoint started with a high enough minimum Neon compute size to have a high enough `max_connections` setting to support those 128 concurrent connections from the two roles. +To ensure that direct access to Postgres is still possible for administrative tasks or similar, the pooler is configured to only open up to [`default_pool_size`](#neon-pgbouncer-configuration-settings) to Postgres for each user to each database. For example, if `default_pool_size` is 64, there can be only 64 active connections from role `alex` to the `neondb` database through the pooler. All other connections by `alex` to the `neondb` database will have to wait for one of those 64 active connections to complete their transactions before the next connection's work is started. +At the same time, role `dana` will also be able to connect to the `neondb` database through the pooler and have up to 64 concurrent active transactions across 64 connections, assuming the endpoint started with a high enough maximum Neon compute size to have a high enough `max_connections` setting to support those 128 concurrent connections from the two roles. Similarly, even if role `alex` has 64 concurrently active transactions through the pooler to the `neondb` database, that role can still start up to 64 concurrent transactions in the `alex_db` database (a different database) when connected through the pooler; but again, only if the Postgres `max_connections` limit can support the number of connections managed by the pooler. @@ -116,16 +116,18 @@ Neon's PgBouncer configuration is shown below. The settings are not user-configu [pgbouncer] pool_mode=transaction max_client_conn=10000 -default_pool_size=64 +default_pool_size=0.9 * max_connections max_prepared_statements=0 query_wait_timeout=120 ``` +where `max_connections` is a Postgres setting. + The following list describes each setting. For a full explanation of each parameter, please refer to the official [PgBouncer documentation](https://www.pgbouncer.org/config.html). - `pool_mode=transaction`: The pooling mode PgBouncer uses, set to `transaction` pooling. - `max_client_conn=10000`: Maximum number of client connections allowed. -- `default_pool_size=64`: Default number of server connections to allow per user/database pair. +- `default_pool_size`: Default number of server connections to allow per user/database pair. - `max_prepared_statements=0`: Maximum number of prepared statements a connection is allowed to have at the same time. `0` means prepared statements are disabled. - `query_wait_timeout=120`: Maximum time queries are allowed to spend waiting for execution. Neon uses the default setting of `120` seconds. diff --git a/content/docs/extensions/neon.md b/content/docs/extensions/neon.md index 2d04d94301..db2ad27014 100644 --- a/content/docs/extensions/neon.md +++ b/content/docs/extensions/neon.md @@ -17,7 +17,7 @@ The `neon_stat_file_cache` view provides insights into how effectively your Neon ## What is the Local File Cache? -Neon computes have a Local File Cache (LFC), which is a layer of caching that stores frequently accessed data in the local memory of the Neon compute. Like Postgres [shared buffers](/docs/reference/glossary#shared-buffers), the LFC reduces latency and improves query performance by minimizing the need to fetch data from Neon storage. The LFC acts as an add-on or extension of Postgres shared buffers. In Neon computes, the `shared_buffers` parameter is always set to 128 MB, regardless of compute size. The LFC extends the cache memory to approximately 80% of your compute's RAM. To view the LFC size for each Neon compute size, see [How to size your compute](/docs/manage/endpoints#how-to-size-your-compute). +Neon computes have a Local File Cache (LFC), which is a layer of caching that stores frequently accessed data in the local memory of the Neon compute. Like Postgres [shared buffers](/docs/reference/glossary#shared-buffers), the LFC reduces latency and improves query performance by minimizing the need to fetch data from Neon storage. The LFC acts as an add-on or extension of Postgres shared buffers. In Neon computes, the `shared_buffers` parameter [scales with compute size](/docs/reference/compatibility#parameter-settings-that-differ-by-compute-size). The LFC extends the cache memory to approximately 80% of your compute's RAM. To view the LFC size for each Neon compute size, see [How to size your compute](/docs/manage/endpoints#how-to-size-your-compute). When data is requested, Postgres checks shared buffers first, then the LFC. If the requested data is not found in the LFC, it is read from Neon storage. Shared buffers and the LFC both cache your most recently accessed data, but they may not cache exactly the same data due to different cache eviction patterns. The LFC is also much larger than shared buffers, so it stores significantly more data. diff --git a/content/docs/manage/endpoints.md b/content/docs/manage/endpoints.md index 3978a2443e..9656ef280e 100644 --- a/content/docs/manage/endpoints.md +++ b/content/docs/manage/endpoints.md @@ -137,7 +137,7 @@ The `neon_utils` extension provides a `num_cpus()` function you can use to monit The size of your compute determines the amount of frequently accessed data you can cache in memory and the maximum number of simultaneous connections you can support. As a result, if your compute size is too small, this can lead to suboptimal query performance and connection limit issues. -In Postgres, the `shared_buffers` setting defines the amount of data that can be held in memory. In Neon, the `shared_buffers` parameter is always set to 128 MB, but Neon uses a Local File Cache (LFC) to extend the amount of memory available for caching data. The LFC can use up to 80% of your compute's RAM. +In Postgres, the `shared_buffers` setting defines the amount of data that can be held in memory. In Neon, the `shared_buffers` parameter [scales with compute size](/docs/reference/compatibility#parameter-settings-that-differ-by-compute-size) and Neon also uses a Local File Cache (LFC) to extend the amount of memory available for caching data. The LFC can use up to 80% of your compute's RAM. The Postgres `max_connections` setting defines your compute's maximum simultaneous connection limit and is set according to your compute size. Larger computes support higher maximum connection limits. @@ -147,50 +147,50 @@ The following table outlines the vCPU, RAM, LFC size (80% of RAM), and the `max_ Compute size support differs by [Neon plan](https://neon.tech/docs/introduction/plans). Autoscaling is supported up to 16 CU. Neon supports fixed compute sizes (no autoscaling) for computes sizes larger than 16 CU. </Admonition> -| Min. Compute Size (CU) | vCPU | RAM | LFC size | max_connections | -| ---------------------- | ---- | ------ | -------- | --------------- | -| 0.25 | 0.25 | 1 GB | 0.8 GB | 112 | -| 0.50 | 0.50 | 2 GB | 1.6 GB | 225 | -| 1 | 1 | 4 GB | 3.2 GB | 450 | -| 2 | 2 | 8 GB | 6.4 GB | 901 | -| 3 | 3 | 12 GB | 9.6 GB | 1351 | -| 4 | 4 | 16 GB | 12.8 GB | 1802 | -| 5 | 5 | 20 GB | 16 GB | 2253 | -| 6 | 6 | 24 GB | 19.2 GB | 2703 | -| 7 | 7 | 28 GB | 22.4 GB | 3154 | -| 8 | 8 | 32 GB | 25.6 GB | 3604 | -| 9 | 9 | 36 GB | 28.8 GB | 4000 | -| 10 | 10 | 40 GB | 32 GB | 4000 | -| 11 | 11 | 44 GB | 35.2 GB | 4000 | -| 12 | 12 | 48 GB | 38.4 GB | 4000 | -| 13 | 13 | 52 GB | 41.6 GB | 4000 | -| 14 | 14 | 56 GB | 44.8 GB | 4000 | -| 15 | 15 | 60 GB | 48 GB | 4000 | -| 16 | 16 | 64 GB | 51.2 GB | 4000 | -| 18 | 18 | 72 GB | 57.6 GB | 4000 | -| 20 | 20 | 80 GB | 64 GB | 4000 | -| 22 | 22 | 88 GB | 70.4 GB | 4000 | -| 24 | 24 | 96 GB | 76.8 GB | 4000 | -| 26 | 26 | 104 GB | 83.2 GB | 4000 | -| 28 | 28 | 112 GB | 89.6 GB | 4000 | -| 30 | 30 | 120 GB | 96 GB | 4000 | -| 32 | 32 | 128 GB | 102.4 GB | 4000 | -| 34 | 34 | 136 GB | 108.8 GB | 4000 | -| 36 | 36 | 144 GB | 115.2 GB | 4000 | -| 38 | 38 | 152 GB | 121.6 GB | 4000 | -| 40 | 40 | 160 GB | 128 GB | 4000 | -| 42 | 42 | 168 GB | 134.4 GB | 4000 | -| 44 | 44 | 176 GB | 140.8 GB | 4000 | -| 46 | 46 | 184 GB | 147.2 GB | 4000 | -| 48 | 48 | 192 GB | 153.6 GB | 4000 | -| 50 | 50 | 200 GB | 160 GB | 4000 | -| 52 | 52 | 208 GB | 166.4 GB | 4000 | -| 54 | 54 | 216 GB | 172.8 GB | 4000 | -| 56 | 56 | 224 GB | 179.2 GB | 4000 | +| Compute Size (CU) | vCPU | RAM | LFC size | max_connections | +| ------------------| ---- | ------ | -------- | --------------- | +| 0.25 | 0.25 | 1 GB | 0.8 GB | 112 | +| 0.50 | 0.50 | 2 GB | 1.6 GB | 225 | +| 1 | 1 | 4 GB | 3.2 GB | 450 | +| 2 | 2 | 8 GB | 6.4 GB | 901 | +| 3 | 3 | 12 GB | 9.6 GB | 1351 | +| 4 | 4 | 16 GB | 12.8 GB | 1802 | +| 5 | 5 | 20 GB | 16 GB | 2253 | +| 6 | 6 | 24 GB | 19.2 GB | 2703 | +| 7 | 7 | 28 GB | 22.4 GB | 3154 | +| 8 | 8 | 32 GB | 25.6 GB | 3604 | +| 9 | 9 | 36 GB | 28.8 GB | 4000 | +| 10 | 10 | 40 GB | 32 GB | 4000 | +| 11 | 11 | 44 GB | 35.2 GB | 4000 | +| 12 | 12 | 48 GB | 38.4 GB | 4000 | +| 13 | 13 | 52 GB | 41.6 GB | 4000 | +| 14 | 14 | 56 GB | 44.8 GB | 4000 | +| 15 | 15 | 60 GB | 48 GB | 4000 | +| 16 | 16 | 64 GB | 51.2 GB | 4000 | +| 18 | 18 | 72 GB | 57.6 GB | 4000 | +| 20 | 20 | 80 GB | 64 GB | 4000 | +| 22 | 22 | 88 GB | 70.4 GB | 4000 | +| 24 | 24 | 96 GB | 76.8 GB | 4000 | +| 26 | 26 | 104 GB | 83.2 GB | 4000 | +| 28 | 28 | 112 GB | 89.6 GB | 4000 | +| 30 | 30 | 120 GB | 96 GB | 4000 | +| 32 | 32 | 128 GB | 102.4 GB | 4000 | +| 34 | 34 | 136 GB | 108.8 GB | 4000 | +| 36 | 36 | 144 GB | 115.2 GB | 4000 | +| 38 | 38 | 152 GB | 121.6 GB | 4000 | +| 40 | 40 | 160 GB | 128 GB | 4000 | +| 42 | 42 | 168 GB | 134.4 GB | 4000 | +| 44 | 44 | 176 GB | 140.8 GB | 4000 | +| 46 | 46 | 184 GB | 147.2 GB | 4000 | +| 48 | 48 | 192 GB | 153.6 GB | 4000 | +| 50 | 50 | 200 GB | 160 GB | 4000 | +| 52 | 52 | 208 GB | 166.4 GB | 4000 | +| 54 | 54 | 216 GB | 172.8 GB | 4000 | +| 56 | 56 | 224 GB | 179.2 GB | 4000 | When selecting a compute size, ideally, you want to keep as much of your dataset in memory as possible. This improves performance by reducing the amount of reads from storage. If your dataset is not too large, select a compute size that will hold the entire dataset in memory. For larger datasets that cannot be fully held in memory, select a compute size that can hold your [working set](/docs/reference/glossary#working-set). Selecting a compute size for a working set involves advanced steps, which are outlined below. See [Sizing your compute based on the working set](#sizing-your-compute-based-on-the-working-set). -Regarding connection limits, you'll want a compute size that can support your anticipated maximum number of concurrent connections. If you are using **Autoscaling**, it is important to remember that your `max_connections` setting is based on the **minimum compute size** in your autoscaling configuration. The `max_connections` setting does not scale with your compute. To avoid the `max_connections` constraint, you can use a pooled connection with your application, which supports up to 10,000 concurrent user connections. See [Connection pooling](/docs/connect/connection-pooling). +Regarding connection limits, you'll want a compute size that can support your anticipated maximum number of concurrent connections. If you are using **Autoscaling**, it is important to remember that your `max_connections` setting is based on the **maximum compute size** in your autoscaling configuration, so it scales as you increase maximum compute size. To avoid the `max_connections` constraint, you can use a pooled connection with your application, which supports up to 10,000 concurrent user connections. See [Connection pooling](/docs/connect/connection-pooling). #### Sizing your compute based on the working set @@ -209,7 +209,7 @@ Autoscaling is most effective when your data (either your full dataset or your w Consider this scenario: If your data size is approximately 6 GB, starting with a compute size of .25 CU can lead to suboptimal performance because your data cannot be adequately cached. While your compute _will_ scale up from .25 CU on demand, you may experience poor query performance until your compute scales up and fully caches your working set. You can avoid this issue if your minimum compute size can hold your working set in memory. -As mentioned above, your `max_connections` setting is based on the minimum compute size in your autoscaling configuration and does not scale along with your compute. To avoid this `max_connections` constraint, you can use a pooled connection for your application. See [Connection pooling](/docs/connect/connection-pooling). +As mentioned above, your `max_connections` setting is based on the maximum compute size in your autoscaling configuration. To avoid the `max_connections` constraint, you can use a pooled connection for your application. See [Connection pooling](/docs/connect/connection-pooling). ### Scale to zero configuration diff --git a/content/docs/reference/compatibility.md b/content/docs/reference/compatibility.md index 42bc356ab5..8ca8cabcdd 100644 --- a/content/docs/reference/compatibility.md +++ b/content/docs/reference/compatibility.md @@ -59,7 +59,7 @@ Because Neon is a managed Postgres service, Postgres parameters are not user-con | `max_worker_processes` | 26 | The value differs by compute size. See [below](#parameter-settings-that-differ-by-compute-size). | | `password_encryption` | scram-sha-256 | | | `restart_after_crash` | off | | -| `shared_buffers` | 128MB | Neon uses a [Local File Cache (LFC)](/docs/extensions/neon#what-is-the-local-file-cache) in addition to `shared_buffers` to extend cache memory to 80% of your compute's RAM. | +| `shared_buffers` | 128MB | Neon uses a [Local File Cache (LFC)](/docs/extensions/neon#what-is-the-local-file-cache) in addition to `shared_buffers` to extend cache memory to 80% of your compute's RAM. The value differs by compute size. See [below](#parameter-settings-that-differ-by-compute-size). | | `superuser_reserved_connections` | 4 | | | `synchronous_standby_names` | 'walproposer' | | | `wal_level` | replica | Support for `wal_level=logical` is coming soon. See [logical replication](/docs/introduction/logical-replication). | @@ -68,22 +68,46 @@ Because Neon is a managed Postgres service, Postgres parameters are not user-con ### Parameter settings that differ by compute size -Of the parameter settings listed above, the `maintenance_work_mem`, `max_connections`, and `max_worker_processes` differ by compute size, which is defined in [Compute Units (CU)](/docs/reference/glossary#compute-unit-cu). The following table shows values for each compute size. - -| Compute Size (CU) | `max_connections` | `maintenance_work_mem` | `max_worker_processes` | -| :---------------- | :---------------- | :--------------------- | :--------------------- | -| 0.25 | 112 | 64 MB | 10 | -| 0.50 | 225 | 64 MB | 11 | -| 1 | 450 | 67 MB | 12 | -| 2 | 901 | 134 MB | 14 | -| 3 | 1351 | 201 MB | 16 | -| 4 | 1802 | 268 MB | 18 | -| 5 | 2253 | 335 MB | 20 | -| 6 | 2703 | 402 MB | 22 | -| 7 | 3154 | 470 MB | 24 | -| 8 | 3604 | 537 MB | 26 | -| 9 | 4000 | 604 MB | 28 | -| 10 | 4000 | 671 MB | 30 | +Of the parameter settings listed above, the `max_connections`, `maintenance_work_mem`, +`shared_buffers`, and `max_worker_processes` differ by compute size, which is defined in [Compute Units (CU)](/docs/reference/glossary#compute-unit-cu). +The following table shows values for each compute size. If autoscaling is turned on, the following +numbers are valid for maximum CU size. + +| Compute Size | `max_connections` | `maintenance_work_mem` | `max_worker_processes` | `shared_buffers` | +| :----------- | :---------------- | :--------------------- | :--------------------- | :--------------- | +| 0.25 | 112 | 64 MB | 12 | 128 MB | +| 0.50 | 225 | 64 MB | 13 | 128 MB | +| 1 | 450 | 67 MB | 14 | 128 MB | +| 2 | 901 | 134 MB | 16 | 230 MB | +| 3 | 1351 | 201 MB | 18 | 343 MB | +| 4 | 1802 | 268 MB | 20 | 456 MB | +| 5 | 2253 | 335 MB | 22 | 569 MB | +| 6 | 2703 | 402 MB | 24 | 682 MB | +| 7 | 3154 | 470 MB | 26 | 796 MB | +| 8 | 3604 | 537 MB | 28 | 909 MB | +| 9 | 4000 | 604 MB | 30 | 1008 MB | +| 10 | 4000 | 671 MB | 32 | 1009 MB | +| 16 | 4000 | 671 MB | 44 | 1012 MB | + +The formula for `max_connections` is + +```go +compute_size = min(max_compute_size, 8 * min_compute_size) +max_connections = max(100, min(4000, 450.5 * compute_size)) +``` + +The formula for `max_worker_processes` is + +```go +max_worker_processes := 12 + floor(2 * max_compute_size) +``` + +The formula for `shared_buffers` is + +```go +backends = 1 + max_connections + max_worker_processes +shared_buffers_mb = max(128, (1023 + backends * 256) / 1024) +``` <Admonition type="note"> You can use connection pooling in Neon to increase the number of supported connections. For more information, see [Connection pooling](/docs/connect/connection-pooling). diff --git a/content/docs/reference/glossary.md b/content/docs/reference/glossary.md index 8acbfc33e9..715324e24d 100644 --- a/content/docs/reference/glossary.md +++ b/content/docs/reference/glossary.md @@ -261,7 +261,7 @@ A feature provided by some hypervisors, such as QEMU, that allows the transfer o ## Local File Cache -The Local File Cache (LFC) is a layer of caching that stores frequently accessed data from the storage layer in the local memory of the compute. This cache helps to reduce latency and improve query performance by minimizing the need to fetch data from the storage layer repeatedly. The LFC acts as an add-on or extension of Postgres [shared buffers](#shared-buffers). In Neon the `shared_buffers` setting is always 128 MB, regardless of compute size. The LFC extends cache memory up to 80% of your compute's RAM. +The Local File Cache (LFC) is a layer of caching that stores frequently accessed data from the storage layer in the local memory of the compute. This cache helps to reduce latency and improve query performance by minimizing the need to fetch data from the storage layer repeatedly. The LFC acts as an add-on or extension of Postgres [shared buffers](#shared-buffers). In Neon the `shared_buffers` parameter [scales with compute size](/docs/reference/compatibility#parameter-settings-that-differ-by-compute-size). The LFC extends cache memory up to 80% of your compute's RAM. ### logical data size @@ -477,7 +477,7 @@ A cloud-based development model that enables developing and running applications ## shared buffers -A memory area in Postgres for caching blocks of data from storage (disk on standalone Postgres or Pageservers in Neon). This cache enhances the performance of database operations by reducing the need to access the slower storage for frequently accessed data. Neon uses a [Local File Cache (LFC)](#local-file-cache), which acts as an add-on or extension of shared buffers. In Neon the `shared_buffers` setting is always 128 MB, regardless of compute size. The LFC extends cache memory up to 80% of your compute's RAM. For additional information about shared buffers in Postgres, see [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html), in the Postgres documentation. +A memory area in Postgres for caching blocks of data from storage (disk on standalone Postgres or Pageservers in Neon). This cache enhances the performance of database operations by reducing the need to access the slower storage for frequently accessed data. Neon uses a [Local File Cache (LFC)](#local-file-cache), which acts as an add-on or extension of shared buffers. In Neon the `shared_buffers` parameter [scales with compute size](/docs/reference/compatibility#parameter-settings-that-differ-by-compute-size). The LFC extends cache memory up to 80% of your compute's RAM. For additional information about shared buffers in Postgres, see [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html), in the Postgres documentation. ## SNI From 93ea7556592d716c445e9d0cf6c0b11fb5d211f9 Mon Sep 17 00:00:00 2001 From: GitHub Action <action@github.com> Date: Tue, 17 Dec 2024 22:21:27 +0000 Subject: [PATCH 2/2] chore: format content markdown files with Prettier --- content/docs/connect/choose-connection.md | 8 ++-- content/docs/manage/endpoints.md | 2 +- content/docs/reference/compatibility.md | 54 +++++++++++------------ 3 files changed, 32 insertions(+), 32 deletions(-) diff --git a/content/docs/connect/choose-connection.md b/content/docs/connect/choose-connection.md index eecd6b653f..397c559155 100644 --- a/content/docs/connect/choose-connection.md +++ b/content/docs/connect/choose-connection.md @@ -126,8 +126,8 @@ For more details, see [How to use connection pooling](/docs/connect/connection-p Here is a table summarizing the options we've walked through on this page: -| | Direct Connections | Pooled Connections | Serverless Driver (HTTP) | Serverless Driver (WebSocket) | -| --------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------- | --------------------------------------------- | -| **Use Case** | Migrations, admin tasks requiring stable connections | High number of concurrent client connections, efficient resource management | One-shot queries, short-lived operations | Transactions requiring persistent connections | +| | Direct Connections | Pooled Connections | Serverless Driver (HTTP) | Serverless Driver (WebSocket) | +| --------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | --------------------------------------------- | +| **Use Case** | Migrations, admin tasks requiring stable connections | High number of concurrent client connections, efficient resource management | One-shot queries, short-lived operations | Transactions requiring persistent connections | | **Scalability** | Limited by `max_connections` tied to [compute size](/docs/manage/endpoints#how-to-size-your-compute) | Up to 10,000 application connections (between your application and PgBouncer); however, only [`default_pool_size`](/docs/connect/connection-pooling#neon-pgbouncer-configuration-settings) backend connections (active transactions between PgBouncer and Postgres) are allowed per user/database pair. This limit can be increased upon request. | Automatically scales | Automatically scales | -| **Performance** | Low overhead | Efficient for stable, high-concurrency workloads | Optimized for serverless | Optimized for serverless | +| **Performance** | Low overhead | Efficient for stable, high-concurrency workloads | Optimized for serverless | Optimized for serverless | diff --git a/content/docs/manage/endpoints.md b/content/docs/manage/endpoints.md index 9656ef280e..18b2264cbb 100644 --- a/content/docs/manage/endpoints.md +++ b/content/docs/manage/endpoints.md @@ -148,7 +148,7 @@ Compute size support differs by [Neon plan](https://neon.tech/docs/introduction/ </Admonition> | Compute Size (CU) | vCPU | RAM | LFC size | max_connections | -| ------------------| ---- | ------ | -------- | --------------- | +| ----------------- | ---- | ------ | -------- | --------------- | | 0.25 | 0.25 | 1 GB | 0.8 GB | 112 | | 0.50 | 0.50 | 2 GB | 1.6 GB | 225 | | 1 | 1 | 4 GB | 3.2 GB | 450 | diff --git a/content/docs/reference/compatibility.md b/content/docs/reference/compatibility.md index 8ca8cabcdd..e830970216 100644 --- a/content/docs/reference/compatibility.md +++ b/content/docs/reference/compatibility.md @@ -37,34 +37,34 @@ The following table shows parameter settings that are set explicitly for your Ne Because Neon is a managed Postgres service, Postgres parameters are not user-configurable outside of a [session, database, or role context](#configuring-postgres-parameters-for-a-session-database-or-role), but if you are a paid plan user and require a different Postgres instance-level setting, you can contact [Neon Support](/docs/introduction/support) to see if the desired setting can be supported. </Admonition> -| Parameter | Value | Note | -| ------------------------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `client_connection_check_interval` | 60000 | | -| `dynamic_shared_memory_type` | mmap | | -| `fsync` | off | Neon syncs data to the Neon Storage Engine to store your data safely and reliably | -| `hot_standby` | off | | -| `idle_in_transaction_session_timeout` | 300000 | | -| `listen_addresses` | '\*' | | -| `log_connections` | on | | -| `log_disconnections` | on | | -| `log_temp_files` | 1048576 | | -| `maintenance_work_mem` | 65536 | The value differs by compute size. See [below](#parameter-settings-that-differ-by-compute-size). | -| `max_connections` | 112 | The value differs by compute size. See [below](#parameter-settings-that-differ-by-compute-size). | -| `max_parallel_workers` | 8 | | -| `max_replication_flush_lag` | 10240 | | -| `max_replication_slots` | 10 | | -| `max_replication_write_lag` | 500 | | -| `max_wal_senders` | 10 | | -| `max_wal_size` | 1024 | | -| `max_worker_processes` | 26 | The value differs by compute size. See [below](#parameter-settings-that-differ-by-compute-size). | -| `password_encryption` | scram-sha-256 | | -| `restart_after_crash` | off | | +| Parameter | Value | Note | +| ------------------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `client_connection_check_interval` | 60000 | | +| `dynamic_shared_memory_type` | mmap | | +| `fsync` | off | Neon syncs data to the Neon Storage Engine to store your data safely and reliably | +| `hot_standby` | off | | +| `idle_in_transaction_session_timeout` | 300000 | | +| `listen_addresses` | '\*' | | +| `log_connections` | on | | +| `log_disconnections` | on | | +| `log_temp_files` | 1048576 | | +| `maintenance_work_mem` | 65536 | The value differs by compute size. See [below](#parameter-settings-that-differ-by-compute-size). | +| `max_connections` | 112 | The value differs by compute size. See [below](#parameter-settings-that-differ-by-compute-size). | +| `max_parallel_workers` | 8 | | +| `max_replication_flush_lag` | 10240 | | +| `max_replication_slots` | 10 | | +| `max_replication_write_lag` | 500 | | +| `max_wal_senders` | 10 | | +| `max_wal_size` | 1024 | | +| `max_worker_processes` | 26 | The value differs by compute size. See [below](#parameter-settings-that-differ-by-compute-size). | +| `password_encryption` | scram-sha-256 | | +| `restart_after_crash` | off | | | `shared_buffers` | 128MB | Neon uses a [Local File Cache (LFC)](/docs/extensions/neon#what-is-the-local-file-cache) in addition to `shared_buffers` to extend cache memory to 80% of your compute's RAM. The value differs by compute size. See [below](#parameter-settings-that-differ-by-compute-size). | -| `superuser_reserved_connections` | 4 | | -| `synchronous_standby_names` | 'walproposer' | | -| `wal_level` | replica | Support for `wal_level=logical` is coming soon. See [logical replication](/docs/introduction/logical-replication). | -| `wal_log_hints` | off | | -| `wal_sender_timeout` | 10000 | | +| `superuser_reserved_connections` | 4 | | +| `synchronous_standby_names` | 'walproposer' | | +| `wal_level` | replica | Support for `wal_level=logical` is coming soon. See [logical replication](/docs/introduction/logical-replication). | +| `wal_log_hints` | off | | +| `wal_sender_timeout` | 10000 | | ### Parameter settings that differ by compute size