Google Cloud SQL PG11：无法调整共享内存段的大小
Google Cloud SQL PG11 : could not resize shared memory segment
我最近在 Google Cloud SQL 上将 Postgres 9.6 实例升级到 11.1。从那时起，我开始注意到多个查询中存在大量以下错误：
org.postgresql.util.PSQLException: ERROR: could not resize shared
memory segment "/PostgreSQL.78044234" to 2097152 bytes: No space left
on device
据我了解，这可能是由于 PG10 中的更改所致，典型的解决方案是增加实例的共享内存。据我所知，这在 Google Cloud SQL 上是不可能的。我也试过调整 work_mem 但没有任何积极效果。
这可能无关紧要，但为了完整起见，该实例配置了 30 GB RAM、120 GB SSD hd space 和 8 个 CPU。我假设 Google 会为这些规范提供适当的共享内存设置，但也许不会？有什么想法吗？
更新
将数据库标志 random_page_cost 设置为 1 似乎减少了问题的影响。虽然这不是一个完整的解决方案，但如果有的话，仍然希望得到适当的修复。
这个想法归功于 this blog post。
更新 2
原始问题报告已关闭，并创建了 public 无法查看的新内部问题。然而，根据 GCP 客户经理的电子邮件回复，Google 于 2019 年 8 月 11 日推出了修复程序。
你可以考虑increasing Tier of the instance, that will have influence on machine memory, vCPU cores, and resources available to your Cloud SQL instance. Check available machine types
在Google Cloud SQL PostgreSQL中也可以更改database flags，对内存消耗有影响：
- max_connections：可以为每个客户端分配一些内存资源，因此最大客户端数表明最大可能的内存使用
- shared_buffers：确定有多少内存专用于 PostgreSQL 用于缓存数据
- autovacuum - 应该打开。
我建议降低限制，以降低内存消耗。
这对我有用，我认为 google 需要更改一个标志，说明他们如何在他们端启动 postgres 容器，我们无法影响 postgres 内部。
Bingo. Somehow your container tech is limiting shared memory. That
error is working as designed. You could figure out how to fix the
mount options, or you could disable parallelism with
max_parallel_workers_per_gather = 0.
show max_parallel_workers_per_gather;
-- 2
-- Run your query
-- Query fails
alter user ${MY_PROD_USER} set max_parallel_workers_per_gather=0;
-- Run query again -- query should work
alter user ${MY_PROD_USER} set max_parallel_workers_per_gather=2;
-- -- Run query again -- fails
我最近在 Google Cloud SQL 上将 Postgres 9.6 实例升级到 11.1。从那时起，我开始注意到多个查询中存在大量以下错误：
org.postgresql.util.PSQLException: ERROR: could not resize shared memory segment "/PostgreSQL.78044234" to 2097152 bytes: No space left on device
据我了解，这可能是由于 PG10 中的更改所致，典型的解决方案是增加实例的共享内存。据我所知，这在 Google Cloud SQL 上是不可能的。我也试过调整 work_mem 但没有任何积极效果。
这可能无关紧要，但为了完整起见，该实例配置了 30 GB RAM、120 GB SSD hd space 和 8 个 CPU。我假设 Google 会为这些规范提供适当的共享内存设置，但也许不会？有什么想法吗？
更新
将数据库标志 random_page_cost 设置为 1 似乎减少了问题的影响。虽然这不是一个完整的解决方案，但如果有的话，仍然希望得到适当的修复。
这个想法归功于 this blog post。
更新 2 原始问题报告已关闭，并创建了 public 无法查看的新内部问题。然而，根据 GCP 客户经理的电子邮件回复，Google 于 2019 年 8 月 11 日推出了修复程序。
你可以考虑increasing Tier of the instance, that will have influence on machine memory, vCPU cores, and resources available to your Cloud SQL instance. Check available machine types
在Google Cloud SQL PostgreSQL中也可以更改database flags，对内存消耗有影响：
- max_connections：可以为每个客户端分配一些内存资源，因此最大客户端数表明最大可能的内存使用
- shared_buffers：确定有多少内存专用于 PostgreSQL 用于缓存数据
- autovacuum - 应该打开。
我建议降低限制，以降低内存消耗。
这对我有用，我认为 google 需要更改一个标志，说明他们如何在他们端启动 postgres 容器，我们无法影响 postgres 内部。
Bingo. Somehow your container tech is limiting shared memory. That error is working as designed. You could figure out how to fix the mount options, or you could disable parallelism with max_parallel_workers_per_gather = 0.
show max_parallel_workers_per_gather;
-- 2
-- Run your query
-- Query fails
alter user ${MY_PROD_USER} set max_parallel_workers_per_gather=0;
-- Run query again -- query should work
alter user ${MY_PROD_USER} set max_parallel_workers_per_gather=2;
-- -- Run query again -- fails