2013-03-16 75 views
2

目前我正在试图理解为什么我的一些在我的Python应用程序的Heroku要求采取> 30秒。即使是简单的请求,绝对没有什么。Heroku的平均负载高得惊人

一个我做的事情是看看我的DYNOS平均负载。我做了三件事情:

1)看看Heroku的日志。偶尔,它会打印负载。下面举例说明:

Mar 16 11:44:50 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 heroku[web.2] Dyno load average (1m): 11.900

Mar 16 11:45:11 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 heroku[web.2] Dyno load average (1m): 8.386

Mar 16 11:45:32 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 heroku[web.2] Dyno load average (1m): 6.798

Mar 16 11:45:53 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 heroku[web.2] Dyno load average (1m): 8.031

2)运行 “的Heroku运行正常运行时间” 好几次,每次都打在不同的机器(运行验证“主机名”)。下面是从刚才的示例输出:

13:22:09 up 3 days, 13:57, 0 users, load average: 15.33, 20.55, 22.51

3)测量在其上我住DYNOS使用psutil发送度量石墨机的平均负载。这些图表证实随时随地5和20之间

的数字我不知道这是否说明了简单的要求采取非常长或没有,但任何人都可以说,为什么在Heroku上的平均负载数字是如此之高?

回答

0

也许它的预期dyno idling

PS。我怀疑没有意义的运行heroku run uptime - 每次都会运行一次新的一次性测试。

+0

我没有看到赛道空转如何导致的高负荷率与发送你的跑步DYNOS的周期载荷的消息。至于一次性:当然有一点是,我写了(“每次验证不同的机器” - 我知道,它是故意的):*许多*我这样“采样”的不同机器平均负荷很高。 – 2013-03-17 16:26:20

1

Heroku的子虚拟化主机到客户机“戴诺”您是通过LXC使用。当你运行'正常运行时间'时,你会看到整个主机正常运行而不是你的容器,正如@ jon-mountjoy指出的那样,当你这样做时,你正在得到一个新的LXC容器,而不是你正在运行的Dynos中的一个。

Heroku的DYNO负荷计算也不同于传统的UNIX/LINUX负荷计算。

Heroku加载平均值反映了就绪队列中(即正在等待处理的)CPU任务的数量。 dyno管理器大约每20秒就为每个测功机计算可运行任务的数量。计算指数衰减移动平均值,计算前30分钟内可运行任务的数量,其中时间为1,5或15分钟(以秒为单位),count_of_runnable_tasks是队列中任务数的条目在给定的时间点,而平均是从最后一次迭代先前计算的指数平均负载

Heroku的平均负载之间的区别的Linux是Linux还包括在不间断的过程睡眠状态(通常等待磁盘活动),如果很多进程在I/O中被阻塞,这会导致明显不同的结果由于繁忙或停滞的I/O系统。

在CPU绑定Dyno的我会认为这不会有太大的区别。在IO绑定Dyno上,Heroku报告的负载平均值将远低于您在LXC容器上获得TRUE正常运行时间所获得的平均值。

您还可以启用通过启用日志运行时度量