问题标签 [oink]

在我的 Rails 应用程序中，总对象随着每个请求而增加。GC 运行后对象未释放。我正在使用 Rails 3.2.3 和 ruby​​ 1.9.3。

有人可以指出我正确的方向吗？从哪儿开始？

有哪些可用的工具？

我试过的工具。ObjectSpace 没有引用创建这些对象的行。Memprof 不适用于 ruby​​ 1.9.3。Oink 没有引用创建这些对象的行。

我有内存泄漏并试图追踪它，因此我试图在 Heroku 服务器上使用 oink。由于 Heroku 不提供日志存档，我通过 Papertrail 插件将它们导出到 Amazon S3。

我已经能够成功地做到这一点，但是，为了使用 oink，我的日志文件必须采用一种称为“Hodel 3000 兼容记录器”的特殊格式。我已经设法在开发中这样做了，但是我不知道如何在生产中创建这样的日志文件（*heroku）。任何帮助，将不胜感激。

提前致谢，

胡安·拉格朗日

我在 Heroku 的应用程序上运行 oink gem 时遇到问题。我已将它包含在我的 gemfile 和 gemfile.lock 中，上传它们，然后安装。它甚至创建了 oink.log（不幸的是，我无法查看）。当我跑

heroku run bundle exec oink --threshold=0 log/* --app my_app

我明白了

运行 bundle exec oink --threshold=0
log/delayed_job.log log/development.log log/oink.log log/production.log log/test.log 附加到终端... up, run.3
/app/.bundle /gems/ruby/1.8/gems/oink-0.9.3/bin/../lib/oink/cli.rb:88:in get_file_listing'：
无法
从 /app找到“log/delayed_job.log”（RuntimeError） /.bundle/gems/ruby/1.8/gems/oink-0.9.3/bin/../lib/oink/cli.rb:86:ineach'
来自 /app/.bundle/gems/ruby/1.8/gems/ oink-0.9.3/bin/../lib/oink/cli.rb:86:in get_file_listing'
来自 /app/.bundle/gems/ruby/1.8/gems/oink-0.9.3/bin/../ lib/oink/cli.rb:59:inprocess'
来自 /app/.bundle/gems/ruby/1.8/gems/oink-0.9.3/bin/oink:4
来自 /app/.bundle/gems/ruby/1.8 /bin/oink:19:in '加载'
来自 /app/.bundle/gems/ruby/1.8/bin/oink:19

我也尝试过运行每个单独的文件，并得到相同的结果。该命令在我的本地机器上运行良好。

在我的 production.rb 文件中，我有

config.logger = Hodel3000CompliantLogger.new(config.paths.log.first)
config.middleware.use(Oink::Middleware)

作为配置。

你能告诉我我在这里做错了什么吗？我的理解是日志是只读的，但我不知道这是否意味着它们只能通过heroku logs命令访问。如果有一种方法我也可以查看 oink.log 文件——知道如何做到这一点也值得赞赏，或者知道如何在实际的 Heroku 日志中使用heroku logs.

更新：上面显示的 oink 配置允许命令在我的本地主机上成功运行。

谢谢！

-安德鲁

我正在使用 oink 来帮助确定应用程序中内存膨胀的原因，但我很难理解 oink 产生的输出（或基于它做出任何可行的决定）。如果有一些文档或博客可以更详细地解释，那将非常有用（尽管我找不到任何东西）。

例如，我通过 oink 运行日志得到以下输出：

如果有人可以帮助我理解输出，将不胜感激。例如，每一列的含义是什么（我知道它们是内存，但它是动作占用的内存总量吗？）

*注意 - 这些结果是使用内存选项运行的（非活动记录）

我正在使用 oink gem 来分析我的应用程序的内存使用情况，并且我得到了一些我不理解的奇怪输出。

我的主页使用加载一些公寓Apartment.where(visible: true)

当我在控制台中运行此查询时，Apartment.where(visible: true).count我得到 8。

但是当我加载应该加载相同的 8 套公寓的主页时，我的 Oink 日志显示：

你知道这些额外的公寓是从哪里来的吗？

谢谢，乌里

以前的问题似乎让 Oink 使用此设置成功登录 Heroku 中的标准（这反映了arches.io 上的这篇文章中的设置）：

宝石文件：

应用程序.rb：

从前面问题的时间来看，他们可能正在使用 Rails 3。我们正在使用 Rails 4.1.4，目前无法让它在 Heroku 中登录到标准。如果使用 Rails 4，Heroku 的开发人员建议使用rails_stdout_logginggem 确保您的日志将发送到标准输出。我们目前正在使用这个 gem，所以我想知道它是否会阻止 Oink 使用上述设置登录到标准输出？

本地 Oink 记录得很好。

PS我尝试将LOG_LEVEL设置为信息但没有成功

R14最近我在 Heroku 上遇到的错误数量让我有些担心。

我不知道这是否与使用独角兽有关。或者最近安装了 New Relic 或 Logentries。我真的搞不定。

我已经“安装”了 Oink 并且刚刚收到以下分析，但不知道如何完全理解它试图告诉我的内容。

作为外行，我担心我message#getmessagecount正在吃很多记忆。是不是上面的意思？

如果是这样......例程很简单：

而且我不知道这怎么会“泄漏”内存。

过去一天 Heroku 上的内存使用图如下所示：

我正在使用Ruby 2.1.4，Rails 4.1.7如果有任何帮助。我正在使用两个 Web dynos 和一个 Worker。

哦......我的删除消息例程是：

定义删除消息

结尾

这每 3 个小时左右就会扼杀我的表现（如果这是正确的话）。我不知道为什么每 10 分钟就会增加一次（我希望通过阅读图表来推断）。10 分钟可能很重要，因为我有一个 iPhone 应用程序，它getmessagecount每 10 分钟使用一个测试应用程序轮询一次例程。我只能想知道如果应用程序的 10 个副本（或 1,000 个）开始访问服务器会发生什么？

任何帮助将不胜感激。

几周前，我们安装了Oink来分析我们的 Rails 应用程序糟糕的内存性能。不幸的是，我们错过了使用 Hodel 3000 Compliant 记录仪的机会。在发生灾难性的内存事件后，我们开始将 700 mb 分页到交换中，我去了 Oink 分析器，却发现它无法以当前默认的 Rails 记录器格式解析我们的日志。

当前格式的 Oink 日志条目：

所需的 Hodel 3000 格式的 Oink 日志条目。

有什么办法可以挽救吗？排名靠前的是否有所有必要的信息？

我有一个在 Heroku 上运行的 Rails 4.2 应用程序，Ruby 版本是 2.2.4

当我重新启动应用程序时，使用 Heroku 的 log-runtime-metrics 应用程序会记录以下内容：

只需单击应用程序登陆中的不同页面即可报告以下详细信息：

Oink 报告：内存使用情况：435416

进入应用程序我有一些带有分页的数据表，当在页面中移动时内存不断增加：

此刻Oink报告：内存使用：602352

如果我转到应用程序 Heroku 报告的更简单的页面：

Oink 报告内存使用情况：604744

在 Heroku 移动 5 分钟后，报告的内存总量在 360 到 400+ MB 之间。它不会出现内存配额错误，但如果新的网络工作者会被解雇，我敢打赌。

我还从 ObjectSpace 中获取了一些数据。浏览网站（这次是在本地），首先使用最简单的页面，然后进入带有分页的部分，获取更多数据，然后出去等等。以下是来自 ObjectSpace.count_objects 的一些日志：

{:TOTAL=>556379, :FREE=>1142, :T_OBJECT=>27740, :T_CLASS=>7356, :T_MODULE=>1563, :T_FLOAT=>9, :T_STRING=>241807, :T_REGEXP=>2481, : T_ARRAY=>92685, :T_HASH=>16081, :T_STRUCT=>1118, :T_BIGNUM=>13, :T_FILE=>117, :T_DATA=>81408, :T_MATCH=>6132, :T_COMPLEX=>1, :T_RATIONAL= >909, :T_SYMBOL=>1691, :T_NODE=>62347, :T_ICLASS=>11779}

{:TOTAL=>556379, :FREE=>1211, :T_OBJECT=>27540, :T_CLASS=>7354, :T_MODULE=>1565, :T_FLOAT=>9, :T_STRING=>241100, :T_REGEXP=>2478, : T_ARRAY=>93344, :T_HASH=>16763, :T_STRUCT=>1078, :T_BIGNUM=>13, :T_FILE=>122, :T_DATA=>81422, :T_MATCH=>6031, :T_COMPLEX=>1, :T_RATIONAL= >911, :T_SYMBOL=>1690, :T_NODE=>61968, :T_ICLASS=>11779}

{:TOTAL=>556379, :FREE=>946, :T_OBJECT=>24257, :T_CLASS=>7523, :T_MODULE=>1565, :T_FLOAT=>9, :T_STRING=>251448, :T_REGEXP=>2362, : T_ARRAY=>83078, :T_HASH=>15272, :T_STRUCT=>1175, :T_BIGNUM=>63, :T_FILE=>128, :T_DATA=>89152, :T_MATCH=>5952, :T_COMPLEX=>1, :T_RATIONAL= >963, :T_SYMBOL=>2028, :T_NODE=>58656, :T_ICLASS=>11801}

输入带有分页的数据表，每页 25 条记录，检索到的数据包含唯一的字符串（实际上是地址）。

{:TOTAL=>556379, :FREE=>906, :T_OBJECT=>26280, :T_CLASS=>7363, :T_MODULE=>1563, :T_FLOAT=>9, :T_STRING=>252024, :T_REGEXP=>2474, : T_ARRAY=>87445, :T_HASH=>15347, :T_STRUCT=>1144, :T_BIGNUM=>16, :T_FILE=>133, :T_DATA=>80601, :T_MATCH=>6686, :T_COMPLEX=>1, :T_RATIONAL= >985, :T_SYMBOL=>1690, :T_NODE=>59906, :T_ICLASS=>11806}

{:TOTAL=>556379, :FREE=>146, :T_OBJECT=>18752, :T_CLASS=>7359, :T_MODULE=>1563, :T_FLOAT=>9, :T_STRING=>295002, :T_REGEXP=>2304, : T_ARRAY=>81885, :T_HASH=>13791, :T_STRUCT=>867, :T_BIGNUM=>15, :T_FILE=>11, :T_DATA=>77634, :T_MATCH=>847, :T_COMPLEX=>1, :T_RATIONAL= >1251, :T_SYMBOL=>1679, :T_NODE=>41463, :T_ICLASS=>11800}

{:TOTAL=>571870, :FREE=>433, :T_OBJECT=>19352, :T_CLASS=>7369, :T_MODULE=>1565, :T_FLOAT=>9, :T_STRING=>294098, :T_REGEXP=>2358, : T_ARRAY=>91079, :T_HASH=>14983, :T_STRUCT=>879, :T_BIGNUM=>15, :T_FILE=>16, :T_DATA=>77945, :T_MATCH=>1128, :T_COMPLEX=>1, :T_RATIONAL= >1591, :T_SYMBOL=>2028, :T_NODE=>45197, :T_ICLASS=>11824}

{:TOTAL=>628109, :FREE=>343, :T_OBJECT=>20647, :T_CLASS=>7360, :T_MODULE=>1563, :T_FLOAT=>9, :T_STRING=>318169, :T_REGEXP=>2346, : T_ARRAY=>115854, :T_HASH=>17767, :T_STRUCT=>949, :T_BIGNUM=>15, :T_FILE=>10, :T_DATA=>79152, :T_MATCH=>1243, :T_COMPLEX=>1, :T_RATIONAL= >1789, :T_SYMBOL=>1685, :T_NODE=>47405, :T_ICLASS=>11802}

{:TOTAL=>727564, :FREE=>470, :T_OBJECT=>22820, :T_CLASS=>7361, :T_MODULE=>1563, :T_FLOAT=>9, :T_STRING=>362350, :T_REGEXP=>2390, : T_ARRAY=>152959, :T_HASH=>22342, :T_STRUCT=>1035, :T_BIGNUM=>33, :T_FILE=>11, :T_DATA=>81286, :T_MATCH=>2167, :T_COMPLEX=>1, :T_RATIONAL= >2497, :T_SYMBOL=>1686, :T_NODE=>54779, :T_ICLASS=>11805}

{:TOTAL=>811122, :FREE=>392, :T_OBJECT=>24361, :T_CLASS=>7362, :T_MODULE=>1563, :T_FLOAT=>9, :T_STRING=>409740, :T_REGEXP=>2434, : T_ARRAY=>176571, :T_HASH=>25118, :T_STRUCT=>1076, :T_BIGNUM=>51, :T_FILE=>13, :T_DATA=>82701, :T_MATCH=>2858, :T_COMPLEX=>1, :T_RATIONAL= >3093, :T_SYMBOL=>1686, :T_NODE=>60285, :T_ICLASS=>11808}

现在将数据表和分页留在应用程序上的一个更简单的页面

{:TOTAL=>819681, :FREE=>494, :T_OBJECT=>24601, :T_CLASS=>7374, :T_MODULE=>1563, :T_FLOAT=>9, :T_STRING=>413540, :T_REGEXP=>2437, : T_ARRAY=>178899, :T_HASH=>25953, :T_STRUCT=>1118, :T_BIGNUM=>93, :T_FILE=>14, :T_DATA=>83043, :T_MATCH=>2924, :T_COMPLEX=>1, :T_RATIONAL= >3121, :T_SYMBOL=>1688, :T_NODE=>60999, :T_ICLASS=>11810}

我也可以获得 gc profiler 数据。但是让我担心的是，如果报告的数据和分配的东西大部分来自所需的宝石，我无论如何都需要。

所以...

我正在尝试检测内存泄漏，或者内存占用如此之高的原因，并尽可能减少它。欢迎任何建议如何从这里开始。

很高兴理解为什么在第一次单击后 - 重新启动后 - Heroku 报告的内存加倍，尽管我想这是在大多数对象被构造并分配内存之后。

但是 Oink 报告的内容和 Heroku 报告的内容之间的差异是巨大的，我猜 Oink 以字节为单位报告。我再次想象他们正在报道不同的事情，或者至少 Heroku 正在报道更多的事情。

任何好的提示如何解释所有这些数据？对于 Heroku 应用程序来说，300-400 MB 的内存占用不是太多了吗？

谢谢。