在Amazon中运行非常慢的查询

Question

我们一直在维护一个同时拥有网络和移动应用平台的项目。该项目的后端在Django 1.10中开发，并部署在AWS中。

起初，当用户很少时，我们使用一个EC2实例和一个带有PostgreSQL数据库的RDS实例进行部署。经过一段时间后，用户数量增加，我们面临的问题，如响应非常缓慢，超时在不同的页面等。由于性能问题，我们采取了以下措施：

• 我们开始对经常访问的数据使用Redis缓存(AWS中的ElasticCache)
• 我们部署在两个不同的EC2实例中(一个用于web平台，另一个用于移动应用程序的API )。
• 我们在RDS中创建了一个读副本，并增加了一个数据库路由器，它选择只使用主数据库进行写操作，并且所有的读操作都在读副本数据库中执行。

这个解决方案在几个星期内效果很好。一段时间后，所有的读取操作都变得太慢了。此时，到主数据库的数据库连接数平均为2-3个，有时上升到5-7个。但由于读取副本数据库中查询执行速度慢，在读副本数据库中常见的连接为30-50个.

使用JOIN和Aggregates的查询经常失败，读取副本中出现以下错误：

canceling statement due to conflict with recovery DETAIL: User query might have needed to see row versions that must be removed.

但是与主数据库，甚至最简单的选择查询相比，所有的查询在读副本中都非常慢。

为了确保问题不是针对特定的读-副本实例，我们创建了另一个读副本RDS实例(例如读-副本-2)，并将所有读取操作指向读-复制-2DB。这种配置开始表现良好，但性能在一天内显著下降(对于第一次阅读-复制，它花了3-4周)。

在那之后，我们修改了我们的数据库路由器，使得任意一个读副本和读副本2中的任意一个达到峰值，但是对两个读副本数据库的所有查询都被执行得非常慢。我们通过将读取操作切换到主数据库进行检查，并且在主数据库中相同的读取操作正在顺利执行，没有任何问题。

一些与服务器负载相关的信息：

• 高峰时，有500-1000名用户使用该系统，其中大多数来自移动应用程序(通过API EC2实例)。
• 在高峰时段，很少有用户访问web平台。但它们通常执行大量DB密集型任务(如数据的大容量导入和导出)。
• 在非高峰时间(在本地夜间的6小时窗口中)，系统中执行一些繁重的DB密集型cron作业，用于生成和维护报告。

在这种情况下，什么是适合我们的体系结构？我们漏掉了什么明显的东西吗？是什么原因导致相同的查询在主数据库中运行得很快，在RDS中的读副本数据库中运行得非常慢？

Answer 1

慢的其他问题，但我可以告诉您的查询时间，因为恢复错误。

由于与恢复细节冲突而取消语句:用户查询可能需要查看必须删除的行版本。

之所以会发生这种情况，是因为在运行select查询时，wal文件正被应用到read副本上。这将终止查询。

有两种解决办法。

1. hot_standby_feedback启用此功能。但是，如果假设replica查询运行时间更长，那么wal文件就会不断积累，从而导致磁盘满进程，延迟也会更高。所以不要提出一个理想的方法。
2. 启用这些参数，并考虑到执行任何特定查询所需的最高时间，这两个参数的值都会增加。假设最高查询在10分钟内在副本上运行，那么将以下参数的值保持在更高的值。

900000毫秒( 15分钟) max_standby_archive_delay = 900000

max_standby_streaming_delay = 900000

我也面临同样的问题，并采用这种方法解决了问题。

这些参数需要为副本参数组设置。