Question

我正在使用oink来帮助确定应用程序中内存膨胀的原因，但是我很难理解oink产生的输出（或根据它做出任何可操作的决定）。如果有一些文档或博客更详细地解释，那将非常有用（虽然我还没有找到）。

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

---- MEMORY THRESHOLD ----
THRESHOLD: 10 MB

-- SUMMARY --
Worst Requests:
1. May 13 22:59:15, 69848 KB, api#action_1
2. May 13 22:56:15, 58128 KB, application#js_action
3. May 13 23:10:28, 12108 KB, application#js_action
4. May 13 23:10:46, 12108 KB, api#action_2
5. May 13 23:11:16, 12108 KB, api#update_action
6. May 13 23:11:21, 12108 KB, api#update_action
7. May 13 23:12:44, 11704 KB, api#update_action
8. May 13 23:13:44, 11704 KB, api#product_action
9. May 13 23:14:42, 11704 KB, application#js_action
10. May 13 23:16:11, 11704 KB, application#js_action

Worst Actions:
14, application#js_action
5, api#update_action
4, api#action_1
2, api#action_2
1, admin/products#index
1, admin/users#index
1, api#update_product
1, api#product_action

Aggregated Totals:
Action                          Max     Mean    Min     Total   Number of requests
application#js_action           58128   14408   10448   201724  14
api#action_1                    69848   25523   10664   102092  4
api#update_action               12108   11363   10448   56816   5
api#action_2                    12108   11512   10916   23024   2
api#product_action              11704   11704   11704   11704   1
api#update_product              10916   10916   10916   10916   1
admin/products#index            10548   10548   10548   10548   1
admin/users#index               10500   10500   10500   10500   1

如果有人能帮助我理解输出，那将非常感激。例如，每个列的含义是什么（我知道它们是内存，但它是操作占用的内存总量吗？）

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

运行的

Answer 1

让我们从标题开始：

---- MEMORY THRESHOLD ----
THRESHOLD: 10 MB

这给出了内存阈值的当前设置。即10MB，您可以使用-m选项更改它。

示例oink -m 20 path_to_log

接下来是摘要部分：

-- SUMMARY --
Worst Requests:
1. May 13 22:59:15, 69848 KB, api#action_1
2. May 13 22:56:15, 58128 KB, application#js_action
3. May 13 23:10:28, 12108 KB, application#js_action
4. May 13 23:10:46, 12108 KB, api#action_2
5. May 13 23:11:16, 12108 KB, api#update_action
6. May 13 23:11:21, 12108 KB, api#update_action
7. May 13 23:12:44, 11704 KB, api#update_action
8. May 13 23:13:44, 11704 KB, api#product_action
9. May 13 23:14:42, 11704 KB, application#js_action
10. May 13 23:16:11, 11704 KB, application#js_action

它显示从启动到服务器的最差请求及其相应的时间戳。

接下来是摘要部分：

Worst Actions:
14, application#js_action
5, api#update_action
4, api#action_1
2, api#action_2
1, admin/products#index
1, admin/users#index
1, api#update_product
1, api#product_action

此部分包含对特定操作发出的请求数。

Ex：应用程序#js_action被调用了14次，是内存使用率最差的之一。您可以查看以下部分的实际内存使用数量。

在这里我们可以看到请求的数量是14。 Max / Min是14个请求之一使用的最大/最小内存。平均值是所有14个请求内存使用量的平均值。

总计是所有请求的内存使用量之和。

Aggregated Totals:
Action                          Max     Mean    Min     Total   Number of requests
application#js_action           58128   14408   10448   201724  14
api#action_1                    69848   25523   10664   102092  4
api#update_action               12108   11363   10448   56816   5
api#action_2                    12108   11512   10916   23024   2
api#product_action              11704   11704   11704   11704   1
api#update_product              10916   10916   10916   10916   1
admin/products#index            10548   10548   10548   10548   1
admin/users#index               10500   10500   10500   10500   1

这三个部分都是相关的。如果你看一下“聚合总计”。应用程序＃js_action的最大内存使用量为 58128 ，如果您想知道此操作的时间，可以看到第一部分“最差请求”。它有一个记录

2. May 13 22:56:15, **58128 KB**, application#js_action

现在你知道最糟糕的行为是先修复它们，然后找出最糟糕的请求并找出它在那个特定时间发生的原因，可能是你运行了一些让你的服务器变慢的cronjob。

了解oink输出

1 个答案: