对于重事务服务器，Postgres 12调优配置，我是否将值设置得太低？

Question

我们有一个postgres 12环境。它有130 it的内存和32个CPU，最近几个月一直在监视服务器的内存使用情况，它使用了服务器上大约一半的内存，我知道进行shared_buffers更改需要重新启动，但是如果更改了effective_cache_size，是否需要同时执行shared_buffers (知道effective_cache_size不需要重新启动，只需重新加载)。

服务器是一个高度事务性的系统。

一些重要的postgres配置：

listen_addresses = '*'
max_connections = 1000
effective_cache_size = 60GB
shared_buffers = 25GB
temp_buffers = 32MB
max_prepared_transactions = 1000
work_mem = 256MB
maintenance_work_mem = 1GB

effective_io_concurrency = 200
random_page_cost = 1.1

max_worker_processes = 14
max_parallel_workers_per_gather = 7
max_parallel_workers = 14
max_parallel_maintenance_workers = 7

wal_level = logical
wal_buffers = 1MB
checkpoint_timeout = 5min
checkpoint_completion_target = 0.9
max_wal_senders = 6
max_wal_size = 4GB
min_wal_size = 256MB
wal_keep_segments = 400
wal_sender_timeout = 5min
wal_receiver_timeout = 5min
max_replication_slots = 6 

我还有一个复制从服务器，它的资源稍微少一点，这会有什么区别吗？

我已经看到shared_buffers的推荐是服务器的一半或更多。

除了将shared_buffers修改为更高的值之外，服务器不会使用更多的内存(130 5GB中的60 5GB和5GB/14 5GB的交换)

任何帮助都是非常感谢的。

Answer 1

我将通过你的设置，并指出我认为有改进的空间。A假设您有本地SSD存储或类似的存储。

• max_connections = 1000不是一个好主意，它有32个核；默认的100是足够的。使用连接池，并将其大小限制在略高于32的这中以获得更多详细信息。
• 只有当您知道您需要准备好的事务，当然不是1000个时，才会使用max_prepared_transactions = 1000。准备好的事务对数据库来说是一个健康风险。
• 对于事务工作负载而言，work_mem = 256MB非常高，但这不会造成任何损害。
• effective_io_concurrency = 200 random_page_cost = 1.1本地SSD，对吗？
• max_worker_processes = 14 max_parallel_workers_per_gather = 7 max_parallel_workers = 14 max_parallel_maintenance_workers = 7具有您通常希望优化吞吐量的事务工作负载，而并行查询对此不利。它以牺牲额外资源为代价，使查询速度更快。当您需要处理事务工作负载时，是否需要一个意外的大查询来占用您的32个核心中的8个？不是的。将max_parallel_workers_per_gather设置为0，并将max_parallel_maintenance_workers设置为更温和的内容，如默认的2。
• wal_buffers = 1MB --它可能与您的工作负载无关，但是将其设置得如此小并没有好处。保持它的默认值-1。
• checkpoint_timeout = 5min max_wal_size = 4GB现在是调优写量大的工作负载的最大潜力。更少的检查点意味着更少的写作。将max_wal_size设置为大(几十个GB很好)，并将checkpoint_timeout提高到半个小时或更长时间。在不太可能发生崩溃的情况下，您所付出的唯一代价就是多一点磁盘空间和长时间的恢复时间。
• wal_keep_segments = 400复制槽更有效。

您可能考虑的另一个参数是设置synchronous_commit = off。如果在不太可能发生崩溃的情况下损失半秒钟的已提交事务，这是提高性能的简单方法。