如何随时间监视和记录进程的内存/ CPU使用情况？[关闭]

30

我正在寻找一种诊断问题的方法，例如交换交换死亡，缓慢的内存进程会填充交换并杀死整个计算机（例如apache）。

我已经在使用仙人掌，可以设置nagios（尽管宁愿不设置）或munin，但据我所知它们无法记录单个程序的使用情况-仅记录整体状态。

我知道我可以每隔30秒将脚本>>滚动到某个文件，但是我想看看是否存在现有的成熟解决方案。

再一次，理想情况下它将是：

  • 每N秒记录一次进程的内存使用情况
  • 每N秒记录一次进程的CPU使用率
  • 支持图表和历史记录
  • 支持平均值-就像mysqld在过去一天中使用了43％的CPU，平均使用400MB内存
  • 免费和开源

进程名称不是，也不应该事先知道-其想法是让它进行监视，然后查看最主要的违规者。

我的系统是Linux（OpenSUSE）。

linux  performance  monitoring  memory-usage 
— 阿特姆·鲁萨科夫斯基（Artem Russakovskii）
source
您是否要监视任何可能存在内存泄漏的进程（前N名内存占用），还是要监视一组已定义的进程（例如Apache Web服务器和Tomcat进程）？后者可以通过一些简单的Nagios或Cacti插件来实现。前者比较困难。您应该澄清这一点。
— Stefan Lasiewski，2010年
我已经在帖子中对其进行了澄清，但需要再次澄清：我想知道由于交换死亡而导致系统崩溃时的系统状态。我想知道谁是最严重的罪犯。顺便说一句，这并不一定是内存泄漏-只是流量的涌入，或任何导致高内存使用的原因。因此，同样，无需配置二进制名称的高级知识。
— Artem Russakovskii
— 沃伦
沃伦，这是一个完全不同的问题。
— Artem Russakovskii
8
关闭如此高质量的职位是一件坏事，尤其是追溯追溯4年之后。
— 彼得说恢复莫妮卡

Answers:

16

如果您只想让罪魁祸首，请考虑top在批处理模式下以相对较长的间隔（超过60秒）运行。您可能需要top运行多个程序才能捕获多个资源上的头号罪犯。我已将系统配置top为在资源被过度使用时运行几个周期。

考虑sar以批处理模式运行以捕获资源利用率。我意识到这是基于服务器的，但是对于确定问题发生的时间很有用。

运行munin并启用通知。这可能使您有机会进入并观察服务器故障。您可能可以在问题解决之前解决问题。

对于内存泄漏，交换使用率的稳定增长表明存在问题。我曾经看到一台服务器在几天之内缓慢消失。问题服务是一个程序，用于监视其他进程的内存泄漏。系统管理员一直坚持认为增加交换使用率不是问题，直到服务器停止响应为止。

您可能会发现，发生问题时，cfengine可以使用的异常检测来触发脚本以捕获系统状态。除了使用最多资源的过程之外，您可能还需要很多信息。对于突然的使用量，您可能需要网络连接列表（按地址而非名称）。内存使用情况也很有用。

— 比尔·索尔
source
9

我以前用过：

http://freshmeat.net/projects/atop/

“上面是一个ASCII全屏性能监视器，它能够报告所有进程的活动（即使进程在该时间间隔内已完成），每日记录系统和进程的活动以进行长期分析，并通过使用来突出显示过载的系统资源颜色等。它定期显示与CPU，内存，交换，磁盘和网络层有关的系统级活动，对于每个活动进程，它显示CPU利用率，内存增长，优先级，用户名，状态，并退出代码。”

— 忍者猫
source
顶上似乎没有一份报告可以为我提供我想要的东西。如果我错了，请纠正我。
— Artem Russakovskii
它照顾您的前两个要点（按进程存储/ cpu）。您可以使用该库来收集这些统计信息，然后根据数据进行历史记录/作图。
— NinjaCat 2010年
4
@ artem-russakovskii-默认情况下，atop每十分钟将数据记录到一个文件中一次。如果服务器在3:45时崩溃，则可以从开始atop -r log_filename，按m切换到每个进程的内存使用情况视图，然后按t以10分钟的增量前进，直到3:40。可以详细了解使用在顶上的基础知识lwn.net/Articles/387202并看到在识别内存泄漏的一例atoptool.nl/download/case_leakage.pdf
— 松鼠
6

您尝试过收集吗？
它非常强大且可自定义。
有很多插件，可以与nagios集成。

http://collectd.org/features.shtml

— 皮尔
source
Collected非常轻巧，设置起来不太困难，并且可以让您看到内存/交换随时间的增长。但是，它不会查明有问题的进程-但也许您将能够及时注意到并捕获内存的增长，并使用手动检查情况top。
— Marius Gedminas
1
我不得不说我没有尝试过该插件，而是从收集的流程插件手册中读取信息：“如果选择了流程，则将收集以下信息。所有这些信息均由流程名称汇总。其常驻段大小，用户时间和系统时间，使用该名称的进程数，线程数（所有进程的总和），主要和次要页面错误的数量粗略的I / O数量（应写入和读取的字节数）到系统调用的过程中。）
— PiL 2010年
您可以选择进程，也可以按名称或按正则表达式。
— PiL 2010年
2

Centreon位于Nagios之上，Nagios与NRPE结合在一起。然后，您可以编写自定义脚本来以NRPE希望的任何格式报告数据。然后，Nagios使用NRPE轮询来自远程服务器的数据，Centreon绘制出漂亮的图形并增加了用户的灵活性。我们在http://beyondhosting.net上使用了 它。如果您愿意的话，我已经有一个带有centeron + nagios设置的VZ容器模板。

图centeron构建hostthenpost.org/tyler/2010-07-23_1719.png

— 视位
source
我希望有一个现成的解决方案来报告我提到的事情，最重要的是消耗最多内存的进程。我也不确定VZ是什么。
— Artem Russakovskii
2

nmon是一款出色的工具，可以满足您的需求。为AIX和Linux开发。产生大量详细的输出，并易于将其放入报告中。如果您使用Google搜索，则有一个IBM Wiki，其中包含大量文档和用于解析数据的其他实用程序。

— 马特卡因
source
2

服务器密度完全符合您的描述。

我在我们的一台生产服务器上使用它，对此感到非常高兴。它的首要功能是查看图表，单击峰值并查看当前时间（包括所有正在运行的进程）的服务器CPU /内存消耗的能力。他们称之为快照。

它在不断改善。最新功能之一是异常检测，它使您可以轻松检测异常。您还可以设置各种门槛

— 阿伦·罗特维（Aron Rotteveel）
source
1
啊，我忘了提到一小部分，我希望它尽可能免费和开源。每台服务器超过100美元并不是我想要花费的东西（我只有1台服务器，而不是5台）。 serverdensity.com/pricing
— Artem Russakovskii 2010年
2

当我问类似问题时，建议的答案是：

伊坎（Icapan） 说：

Munin是在安装和配置上花费最少精力而获得正常运行时间图的最简单方法。在某些过程中，我还使用atop来汇总cpu的使用情况，但这不是您要的。

大卫·斯皮莱特（David Spillet） 说：

我使用collectd记录许多其他参数中的系统负载。它将数据存储在RRD存储中，可以使用许多可用的工具和脚本对其进行图形化和其他分析。我在绘制图形时使用了此脚本的修改版本（示例输出）。

Collected具有用于监视很多东西（通常需要的东西和最上面的东西）的插件，如果您需要专门的东西，创建自己的东西并不难，因此可以使用非常灵活的工具。在rrd.cgi中配置图形是一个非常手动的过程，尽管并不困难，但是您可能会找到一个更方便的工具来处理由collectd维护的RRD文件。

您也可以检查Nagios或OpenNMS。

— 沃伦
source
1

Munin无需Nagios或任何其他工具即可开箱即用地完成您需要的所有操作。OpenSUSE有可用的RPM。

— gareth_bowles
source
它是否通过插件完成。如果是这样，哪一个？我无法找到不需要预先配置的要监视的进程列表的进程。
— Artem Russakovskii
从最初的问题还不清楚您是否不想监视预先配置的流程列表-您能否提供有关需求的更多详细信息？
— gareth_bowles
澄清：流程名称尚不知道，也不应该事先知道-其想法是让它进行监视，然后查看主要的违规者。
— Artem Russakovskii
1

也许旧的OProfile很好，您需要什么？它是基于内核的系统级探查器，仅具有很小的开销（几个百分点）。

然后是一个出色的Perl脚本PSMon，它使您可以设置所有类型的CPU /内存限制。如果超出了这些限制，psmon将记录一个错误和/或终止有问题的进程。

后者不会向您提供任何性能分析报告，但是如果它决定一遍又一遍地杀死相同的进程，则您可能已经找到了您要找的讨厌的混蛋。:-)

— 珍妮·皮卡兰宁
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.