我的 Heroku Rails 应用程序中的 Sidekiq 后台作业遭受巨大的持续内存泄漏(900mb 或更高)。在这些任务运行后,这些内存泄漏留在我的 Worker Dynos 中,导致它们在我的 Worker dyno 中触发许多 R14 甚至 R15 错误,除非我或 Heroku 重新启动我的 worker dyno(例如 24 小时后)。
减少这些内存泄漏影响的一个解决方案是将我们的 rake 任务转移到 Heroku 调度程序,在那里我们可以受益于 Heroku 旋转一次性 dynos,它们有自己独立的内存和进程来完成每个任务在再次降速之前为我们工作。对于计划任务,这为我们提供了很大的喘息空间来隔离这些内存泄漏的影响,因为每个内存泄漏都不会影响其他任务。
但是,我们的许多内存密集型后台作业无法转移到 Heroku 调度程序,因为它们是由人们在我们的应用程序中执行的操作触发的。
如何将应用程序触发的后台作业移动到 Heroku One-Off Dynos?
最佳答案
实现 IHMO 的最佳方法是使用 Heroku API .这种方法有很多优点:
- 无论是否启动了 dyno,你都会得到 api 响应
- 您可以选择动态大小,因此它可以与您的主应用程序不同,并且可以动态设置。我可以想象一个用例,当您根据任务大小启动不同大小的测力计时
- 你可以传递额外的 ENV 变量,所以你可以像对待参数一样对待它
- 你可以设置生活时间
这是来自文档的示例请求(它缺少身份验证 token ):
curl -n -X POST https://api.heroku.com/apps/$APP_ID_OR_NAME/dynos \
-d '{
"attach": true,
"command": "bash",
"env": {
"COLUMNS": "80",
"LINES": "24"
},
"force_no_tty": null,
"size": "standard-1X",
"type": "run",
"time_to_live": 1800
}' \
-H "Content-Type: application/json" \
-H "Accept: application/vnd.heroku+json; version=3"
一个可能的缺点是您需要通过 ENV 变量将身份验证 token 传递给您的应用程序,但我认为没有其他方法。使用不同的解决方案,您仍然需要传递身份验证 token 。
关于ruby-on-rails - 如何从我的应用程序中启动 Heroku One-Off Dynos?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42984562/