Amazon Aurora PostgreSQL 参数系列之内存和查询方案管理（一）

现在的组织都有从传统数据库迁移的策略，在计划迁移时，他们不想在性能、可用性和安全特性上做出妥协。Amazon Aurora是一项云原生关系数据库服务，它将高端商业数据库的速度和可用性与开源数据库的简单性和成本效益相结合。兼容PostgreSQL的Aurora版本提供了3倍于标准PostgreSQL在相同硬件上运行的吞吐量，使现有的PostgreSQL应用程序和工具无需修改即可运行。PostgreSQL兼容性与Aurora企业数据库功能的结合为商业数据库迁移提供了一个理想的对象。

Aurora PostgreSQL在引擎级有了改进，这提高了高并发OLTP工作负载的性能，还帮助桥接了商业引擎和开源引擎之间的特性差距。虽然Aurora PostgreSQL的默认参数设置适用于大多数工作负载，但是从商业引擎迁移工作负载的客户可能需要根据性能和其他非功能需求调整一些参数。因为架构上的差异和引擎级别的优化，即便是从PostgreSQL迁移到Aurora PostgreSQL的工作负载也可能需要重新考虑一些参数设置。

在这个由四部分组成的系列中，我们将解释Aurora PostgreSQL特有的参数。我们还深入研究了应用于Aurora PostgreSQL的某些PostgreSQL数据库参数，它们的行为如何不同，以及如何设置这些参数来利用或控制Aurora PostgreSQL中的其他特性。在本篇文章，我们将介绍一些参数，这些参数对于调整Aurora PostgreSQL的内存使用是很有用的。我们还将讨论协助控制Aurora PostgreSQL的查询计划管理(QPM)特性行为的参数。

内存和缓冲区相关参数 

虽然Aurora PostgreSQL和PostgreSQL有一个相似的共享内存架构，但是它们在应用上有一些不同。在本节中，我们将介绍PostgreSQL的两个重要的共享内存参数shared_buffers和wal_buffers，并看看它们在Aurora中的解释是如何变化的。我们还将讨论apg_ccm_enabled，这将帮助您控制一个作为Aurora重要特征的行为：集群缓存管理。

shared_buffers

在PostgreSQL中，读写被缓存到一个共享内存区域，称为共享缓冲区，这个区域的大小由shared_buffers参数控制。就像任何其他关系数据库一样，如果PostgreSQL需要读取一个页面，它首先将该页面缓存到共享缓冲区中，然后再返回给客户端，引用同一页的后续查询只需要从共享缓冲区获取。类似地，在修改时，页面不会立即刷新到磁盘。写印操作缓存在共享缓冲区中(作为缓存块)并在检查点上刷新。Shared_buffers用于为邮件主管指定共享缓冲区保留的共享内存区域的大小。

PostgreSQL大量利用文件系统缓存来读取和写入I/O。参考文档中PostgreSQL的一般建议：“如果您有一个1GB或更多RAM的专用数据库服务器，那么shared_buffers的合理起始值应该是系统中内存的25%。在某些工作负载中，对shared_buffers进行更大的设置是有效的。但是因为PostgreSQL也依赖于操作系统缓存，所以将超过40%的RAM分配给shared_buffers不太可能比分配更小的内存更好。对shared_buffers进行较大的设置通常需要相应增加max_wal_size，以便将写入大量新数据或更改数据的过程扩展到更长的一段时间。”

使用Aurora PostgreSQL, I/O是由Aurora存储驱动处理的。表或索引没有文件系统或二级缓存。这意味着shared_buffers应该比PostgreSQL社区推荐的要大。设置越小，性能越差。通常，默认参数组中的shared_buffers的值使用公式SUM({DBInstanceClassMemory/12038}，-50003)来设置，这大约是可用内存的75%。对于大多数工作负载，默认值都是一个很好的起点。

如果你对Aurora PostgreSQL的共享缓冲区做了任何更改，你应该彻底测试它。如果pgbench只运行select，shared_buffers设置为15%内存，那么与db.r5.2xlarge实例的默认设置相比，性能降低了14%，VolumeReadIOPS增加了14%。测试使用pgbench的默认select-only脚本，使用500个客户机对规模为1,000的数据库进行初始化。

如果工作负载的工作集不能容纳在共享缓冲区中，那么Aurora实例需要从存储中获取更多的页面。在AmazonRDS管理控制台中，VolumeReadIOPS ([billing] VolumeReadIOPS)会增加，导致Aurora I/O话单增加。您可以查看BufferCacheHitRatio，以判断共享缓冲区利用率的效率。如果这个指标一直较低，您应该致力于减少您的工作集，例如通过归档旧数据、添加索引、实现表分区和调优查询。如果不能进一步优化工作负载，可以考虑增加实例类，为共享缓冲区分配更多内存。

另一个重要的区别是Aurora PostgreSQL可生存缓冲区的缓存特性。在社区PostgreSQL中，缓冲区缓存的内容不会在数据库引擎重启期间保存。Aurora PostgreSQL在重启期间和故障转移期间维护共享缓冲区内容(请参阅下一节中的apg_ccm_enabled)。这在重新启动之后(例如，在打补丁或故障转移过程期间)有显著的性能改进。但是，shared_buffers大小的更改会清除缓存，并导致与冷重启相关的性能问题。