任务队列以“(2062, 'Cloud SQL socket open failed with error: No such file or directory')”结束

Posted 2023-02-24

【中文标题】任务队列以“(2062, \'Cloud SQL socket open failed with error: No such file or directory\')”结束

【英文标题】：Task queues end up with "(2062, 'Cloud SQL socket open failed with error: No such file or directory')"任务队列以“(2062, 'Cloud SQL socket open failed with error: No such file or directory')”结束

【发布时间】：2016-06-20 02:35:00

【问题描述】：

我们正在构建一个使用繁重的后端任务（任务队列）的应用程序，并且在每个任务中 - 我们都在 Google Cloud SQL 中进行 I/O。

由于 GAE 有 12 个并发连接的限制（不确定这是否是问题？我在 https://***.com/a/26155819/687692 看到）

""在标准环境中运行或使用标准兼容 API 的每个 App Engine 实例与 Google Cloud SQL 实例的并发连接不能超过 12 个。" - https://cloud.google.com/sql/faq"

由于这个问题，我的大部分后端任务（每秒 100-500 个任务）都失败了。

另外，我检查了过去 4 天的活动连接：我没有看到任何连接超过 12 个连接。

那么，我需要采取什么方法来解决这个问题？连接池（如何在 GAE 中使用 GCS？）？还是其他修复？

任何帮助 - 非常感谢指导。 如果有人需要更多信息，请告诉我。

谢谢，

【问题讨论】：

您提到的错误通常表明已达到12个连接限制。请注意，每个 /App Engine 实例 / 的限制是 12 个并发连接，而​​不是整个应用程序。您知道您的应用程序中的每个 App Engine 实例正在处理多少个任务队列请求吗？根据链接的帖子设置最大 max_concurrent_requests 是否适合您？ （请注意，设置较低的 max_concurrent_requests 值可能会导致启动更多 App Engine 实例来处理请求）。

max_concurrent_requests 用于前端实例。我的任务队列通常在一秒钟内运行 100-500 个任务。 （我希望这对于大型项目来说不是很大的数字）

max_concurrent_requests 适用于任何使用自动缩放的模块。你能再描述一下你的设置吗？您是在为您的任务处理程序使用后端 (cloud.google.com/appengine/docs/python/backends) 还是单独的模块？每个实例每秒处理多少个任务（不是任务总数）？

我正在使用任务队列 (cloud.google.com/appengine/articles/deferred)。这是由多个队列处理的 - 我有大约 10 个队列用于不同类型的任务并且处理方式不同。每个队列的限制为 500/s（桶 500） - 我猜，这是最大值。 ``` - name: 提醒率：500/s bucket_size: 500 retry_parameters: task_retry_limit: 2 ``` 以上是一个例子。我有 cron 作业 - 将任务添加到这些队列中。近 500 个任务。

您对处理任务的模块使用了哪种缩放方式？我写了一个小的load test app，它安排了 10,000 个任务来执行一些数据库工作（并在短时间内保持连接打开以增加争用）。测试能够以 0 个错误结束。我很想知道您的设置是否有任何不同。

【参考方案1】：

如果连接处理得当，您不太可能超过标准 Python App Engine 缩放设置的 12 个连接限制。

为了演示，我创建了一个small application，它安排了许多任务，每个任务获取一个数据库连接并做一些工作。我能够运行此测试而不会遇到连接问题。

值得确保的一点是您没有泄漏任何连接（即在某些地方或发生异常时没有关闭连接）。

对于 mysqldb，您可以通过使用来自 contextlib 的 closing 来保证不会泄漏连接：

from contextlib import closing

def getDbConnection():
    return MySQLdb.connect(unix_socket='/cloudsql/instance_name', db='db', user='user', charset='utf8') 

with closing(getDbConnection()) as db:
    # do stuff, database is guaranteed to be closed

【讨论】：

我想，这似乎解决了我的问题：但现在，我得到了新错误：OperationalError: (2013, "Lost connection to MySQL server at 'reading initial communication packet '，系统错误：38")。跟这个有关系吗？

多久发生一次？

一天一次到三次。

是否与更高的流量相吻合？您是否有可能达到整体并发限制？ cloud.google.com/sql/pricing#v1-pricing

对于第一代实例，并发连接限制取决于您的实例的层级。我之前评论中的链接按层列出了限制。如果您每天只看到几次此错误，则可能不值得升级到更高级别。我可以建议一些替代解决方案 1）什么都不做，让任务队列重试失败的任务。任务队列有重试机制，因为现实世界并不完美，有时会失败。 2）捕获连接数据库的错误，休眠一小段时间，然后重试。第二次尝试很可能会成功。