Loc*_*Ann 8 postgresql performance amazon-web-services amazon-rds
我们正在针对发布Postgres数据库的应用程序运行负载测试.
在测试期间,我们突然错误率上升.在分析平台和应用程序行为后,我们注意到:
在postgres日志中,我们看到:
2018-08-21 08:19:48 UTC :: @:[XXXXX]:日志:服务器进程(PID XXXX)被信号9终止:被杀
在调查和阅读文档之后,似乎有一种可能性是linux oomkiller运行已经杀死了这个过程.
但由于我们使用的是RDS,因此我们无法访问系统日志/ var/log消息进行确认.
有人可以这样说:
我在这里找不到答案:
AWS 维护一个包含 RDS 服务最佳实践的页面：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html
\n\n在内存分配方面，建议如下：
\n\n\n\n\nAmazon RDS 性能最佳实践是分配足够的 RAM，以便您的工作集几乎完全驻留在内存中。要判断您的工作集是否几乎全部位于内存中，请在数据库实例处于负载状态时检查 ReadIOPS 指标（使用 Amazon CloudWatch）。ReadIOPS 的\n 值应该小且稳定。如果将数据库\n 实例类\xe2\x80\x94 扩展到具有更多 RAM 的类\xe2\x80\x94 会导致 ReadIOPS 大幅下降\n，则说明您的工作集并未几乎完全位于内存中。\n 继续扩展直到扩展操作后 ReadIOPS 不再大幅下降，或者 ReadIOPS 减少到非常小的数量。\n有关监控数据库实例指标的信息，请参阅查看数据库实例指标。
\n
此外，这是他们解决可能的操作系统问题的建议：
\n\n\n\n\nAmazon RDS 为您的数据库实例运行的操作系统 (OS)\n 提供实时指标。您可以使用控制台查看数据库实例的指标，或在您选择的监控系统中使用 Amazon CloudWatch Logs 的增强监控 JSON 输出。有关增强监控的详细信息，请参阅增强\n 监控
\n
那里有很多好的建议，包括查询调优。
\n\n请注意，作为最后的手段，您可以切换到Aurora，它与 PostgreSQL 兼容：
\n\n\n\n\nAurora 具有分布式、容错、自我修复的存储系统，每个数据库实例可自动扩展到 64TB。Aurora\n 通过多达 15 个低延迟\n 只读副本、时间点恢复、持续备份到 Amazon S3\n 以及跨三个可用区的复制来提供高性能和可用性。
\n
编辑：具体谈论您的 PostgreSQL 问题，请检查此Stack Exchange 线程- 他们有一个长连接，自动提交设置为 false。
\n\n\n\n\n我们有一个长连接，自动提交设置为 false：
\n\n\n\n
connection.setAutoCommit(false)在那段时间里，我们做了很多小查询和一些使用游标的查询：
\n\n\n\n
statement.setFetchSize(SOME_FETCH_SIZE)在 JDBC 中，您创建一个连接对象，然后从该连接创建语句。当您执行语句时，您会得到一个结果集。
\n\n现在，这些对象中的每一个都需要关闭，但是如果您关闭语句，则条目集将关闭，如果您关闭连接，则所有语句及其结果集都将关闭。
\n\n我们习惯于使用自己的连接来进行短暂的查询，因此我们从不关闭语句，假设连接一旦关闭就会处理这些事情。
\n\n现在的问题是这个长事务（约 24 小时）从未关闭连接。这些声明从未结束。显然，语句对象在运行代码的服务器和 PostgreSQL 数据库上都保存着资源。
\n\n我对数据库中剩余资源的最佳猜测是与游标相关的资源。使用游标的语句从未关闭，因此它们返回的结果集也从未关闭。这意味着数据库没有释放数据库中的相关游标资源，并且由于它位于一个巨大的表上，因此需要大量 RAM。
\n
希望能帮助到你！
\n| 归档时间： |
|
| 查看次数： |
623 次 |
| 最近记录： |