我试图找到在开发运行嵌入式 Linux 的机器时使用“top”作为半永久性工具的最佳方法。(仪器将从最终测试和生产版本中删除。)
我的第一遍是简单地将其添加到 init.d:
top -b -d 15 >/tmp/toploop.out &
这每 15 秒以“批处理”模式运行一次。假设 /tmp 有足够的空间……</p>
问题:
- 15 秒是通用监控的好选择吗?
- 除了磁盘空间,这对系统状态的干扰有多严重?
- 像这样可以使用哪些其他(也许更好的)工具?
我试图找到在开发运行嵌入式 Linux 的机器时使用“top”作为半永久性工具的最佳方法。(仪器将从最终测试和生产版本中删除。)
我的第一遍是简单地将其添加到 init.d:
top -b -d 15 >/tmp/toploop.out &
这每 15 秒以“批处理”模式运行一次。假设 /tmp 有足够的空间……</p>
问题:
看看collectd。这是一个为性能而编码的非常轻量级的系统监控框架。
我们使用sysstat来监控这样的事情。
可惜你没有说你在监视什么。
您可能会发现带有延迟且没有重复计数器的 vmstat 和 iostat 是更好的选择。
我怀疑 15 秒会绰绰有余,除非你真的想实时观看正在发生的事情,但这里似乎并非如此。
就负载而言,在运行 Ubuntu 的空闲 PIII 900Mhz w/768MB RAM(不确定哪个版本,但不超过一年)上,我每 0.5 秒进行一次最高更新,CPU 利用率约为 2%。在 15 秒更新时,我看到 CPU 利用率为 0.1%。
根据您的具体需求,您可以使用 uptime、free 和 ps 的输出来获取 top 的大部分信息(如果不是全部的话)。
如果您正在寻找整体负载,正常运行时间可能就足够了。但是,如果您想了解有关进程的特定信息、喜欢冒险并且启用了 /proc 文件系统,则可能需要编写自己的工具。这种环境的主要好处是您可以准确地专注于您想要的内容,并将引入系统的负载降至最低。
proc 文件系统为您的应用程序提供对跟踪许多有趣变量的内核内存的读取访问权限。从 /proc 读取是获取此信息的最简单的方法之一。此外,您可能会获得比 top 提供的更多信息。我过去这样做是为了获得此过程在用户和系统上花费的时间。此外,您可以使用它来获取有关进程打开的文件描述符数量的信息。您也可以使用它来获取有关网络系统如何工作的详细信息。
这些信息中的大部分都由其他应用程序进行了预处理,如果您获得所需的信息,可以使用这些应用程序。但是,阅读原始信息相当简单。做一个man proc
以获取更多信息。
在压力测试期间的系统监控工作中,我们使用了一个名为nmon的工具。
我喜欢 nmon 的地方在于它能够导出到 XLS 并为您生成漂亮的图表。
它生成以下统计信息:
祝你好运 :)