Postgres 的 tcp_keepalives_idle 未更新 AWS ELB 空闲超时答案

【问题标题】：Postgres's tcp_keepalives_idle Not Updating AWS ELB Idle TimeoutPostgres 的 tcp_keepalives_idle 未更新 AWS ELB 空闲超时
【发布时间】：2019-02-28 02:36:57
【问题描述】：

我在 Postgres 前面有一个 Amazon ELB。这是出于与 Kubernetes 相关的原因，请参阅 this question。我正在尝试解决最长 AWS ELB Idle Timeout limit 1 小时的问题，这样我就可以让客户端执行长时间运行的事务而不会被 ELB 断开连接。在我的情况下，我无法控制客户端配置，因此任何解决方法都需要在服务器端进行。

我在 Postgres 中遇到了tcp_keepalives_idle 设置，理论上它应该通过向客户端发送定期保活数据包来解决这个问题，从而创建活动，因此 ELB 不会认为客户端处于空闲状态。

我尝试通过将 ELB 上的 idle timeout 设置为 2 minutes 来进行测试。我将tcp_keepalives_idle 设置为30 秒，这将强制服务器每30 秒向客户端发送一次keepalive。然后我通过负载均衡器执行以下查询：psql -h elb_dns_name.com -U my_user -c "select pg_sleep(140)"。 2 分钟后，ELB 断开客户端。为什么keepalives没有通过客户端？ pg_sleep 有什么东西可能会阻止它们吗？如果是这样，是否有更好的方法来模拟长时间运行的查询/事务？

我担心这可能是一次深入研究，我可能需要使用 tcpdump 或类似工具。不幸的是，随着所有 k8s 的喋喋不休，事情的解析确实变得有点复杂。所以在走这条路之前，我想看看我是否遗漏了一些明显的东西。如果没有，任何关于如何最好地确定是否通过 ELB 实际将 keepalive 发送到服务器并最终到达客户端的提示将不胜感激。

更新：我就此联系了亚马逊。显然idle 被定义为不通过网络传输data。 Data 定义为任何具有有效负载的网络数据包。由于 TCP keep-alives 没有有效负载，因此客户端和服务器 keep-alives 被认为是空闲的。因此，除非有办法让服务器在其保持活动负载中发送数据，或者以其他形式发送数据，否则这可能是不可能的。

【问题讨论】：

尝试转向更具可扩展性的方法，它不需要单个长时间运行的事务，而是许多较小的事务。
不幸的是，我无法完全控制它。有许多有效的分析用例涉及长时间运行的查询，并且本质上不是不可扩展的，我不能忽视这些用例。

标签： postgresql amazon-web-services tcp-keepalive

【解决方案1】：

Keepalive 是在 TCP 级别发送的，远低于 PostgreSQL，因此如果服务器运行 pg_sleep 或其他什么都没有区别。

由于托管数据库有点像黑匣子，您可以尝试控制客户端的行为。好在PostgreSQL还提供keepalive parameters on the client side。

实验

psql 'host=elb_dns_name.com user=my_user keepalives_idle=1800' -c 'select pg_sleep(140)'

【讨论】：

在客户端处理它绝对是理想的方法。不幸的是，在这种情况下，我无法控制客户端。我会更新问题以反映这一点。
如果您既无法控制服务器也无法控制客户端，则很难进行任何配置。客户究竟是什么？它使用libpq吗？
我可以完全控制 Postgres 服务器。唯一的问题是它位于空闲超时为 60 分钟的 ELB 后面。但是，ELB 没有自定义逻辑/终止——它应该只是将 TCP 流量传递到 postgres 实例，这就是为什么我对服务器端 keepalive 不起作用的原因感到困惑。客户非常多样化。有些只是psql连接，有些使用libpq，有些使用各种golang驱动等等。
您可以按照我的建议尝试使用psql，看看是否有帮助。如果不是，那 ELB 对“空闲”的定义很有趣。
非常有趣——使用 psql 的客户端方法也会导致空闲超时......似乎在客户端或服务器端保持活动状态不足以重置 ELB 上的空闲超时设置.我将使用该信息更新问题。