在下面的屏幕截图中，整体 CPU 被报告为 3%，但 mysqld 进程被报告为使用 57%。这是总 3% 的 57%，因此 mysqld 只使用了大约 1.5% 的 CPU？
顶部截图 http://img.skitch.com/20090620-cih33piwnnrke6aw41y9p1phwr.jpg
更新：下面的评论者要求我按“1”键并发布结果： 1 键 http://img.skitch.com/20090620-gayja43s44qtw2wkw4aq642e8c.jpg
（见底部更新...）
我已经为 Cacti 编写了一个数据输入方法脚本（在 Ruby 中，用于从 beanstalkd 收集统计信息）并且它在作为 cacti 用户帐户运行时从命令行工作（返回一个简单的整数，如文档所述），但是Cacti 工具本身没有收集任何数据，日志中也没有任何内容。
这是数据输入法设置： Cacti 数据输入法 http://img.skitch.com/20091009-gh7g1kukn9yradj6y2iqrd5qm1.jpg
这是生成的图表（在将其添加到主机的图表模板并运行足够长的时间以收集数据之后）： Cacti Graph http://img.skitch.com/20091009-xq1kn3qxkteb5hb11wtx6tbs8m.jpg
更新 #1：看起来 Cacti 可能正在剥离环境：
sudo su - cacti -c 'env -i /script/beanstat --host 10.11.12.13 --port 11300 --stat current-waiting'
/script/beanstat:4:in `require': 没有要加载的文件——rubygems (LoadError)
来自 /script/beanstat:4
如果是这种情况，我该如何解决？
更新 #2：stackoverflow.com 上的这个响应似乎已经解决了环境问题，但图表中仍然没有数据。
更新 #3：感谢@Heath 的建议，我提高了轮询器日志记录级别并发现了这一点：
警告：来自 CMD 的结果无效。部分结果：U
谷歌搜索“部分结果：U”的意思没有任何运气。该脚本只打印一个整数值。
更新 #4：我终于开始工作了。核心问题是shell脚本运行时缺少环境。我必须通过在我的 Ruby 脚本前加上以下几行来解决这个问题：
#!/bin/sh PATH=/usr/local/bin:$PATH exec ruby -x"/full/path/to/script/directory" $0 "$@" #!/usr/bin/env ruby
第二个问题是数据输入方法的正确配置（我想收集的每个单独的指标一个，即使它们都使用相同的脚本），它提供数据模板的数据源（反之亦然，我我仍然不清楚）它提供了需要分配给设备的图形模板，然后添加到图形树中。总而言之，这是一个关于文档废话的重大失败，我希望永远不必再这样做了。
更新 #5 …
我的 .conf 文件中有以下块，但是当我加载适当的 URL（它指向一个只有一个虚拟 .txt 文件的目录）时，我得到了 Apache 2 测试页面而不是目录列表。
<Directory "/var/www/sites/www.some-site.com/public">
Options Indexes
[...other settings that are working fine...]
</Directory>
如果我将 index.html 文件放在那里，它会按预期加载。
我省略的“其他设置”用于 LDAP HTTP 身份验证等，它们也都按预期工作。
目录中没有 .htaccess 文件。
我似乎无法使目录浏览正常工作。
我也尝试过 +Indexes ，但仍然没有运气。
我有一个服务设置为在启动时启动，但它没有这样做，我不知道在哪里查看（例如日志）来解决它。
我已经验证了运行级别：
$ grep default /etc/inittab
id:3:initdefault:
符号链接在那里：
$ find /etc -name *beans*
/etc/rc.d/rc6.d/K47beanstalkd
/etc/rc.d/rc1.d/K47beanstalkd
/etc/rc.d/rc0.d/K47beanstalkd
/etc/rc.d/rc2.d/K47beanstalkd
/etc/rc.d/rc4.d/K47beanstalkd
/etc/rc.d/rc3.d/K47beanstalkd
/etc/rc.d/rc5.d/K47beanstalkd
/etc/rc.d/init.d/beanstalkd
当我手动启动它时（通过“sudo /etc/init.d/beanstalkd start”）它工作正常。
我从哪里开始解决这个问题？在哪里可以记录引导序列以便我可以 grep 查找问题？如果重要的话，这是一个 CentOS 机器。
谢谢。
在我的特殊情况下，它是 mysql 常规日志和慢查询日志；两者都不是操作的关键，只是在需要时进行故障排除，而且 mysql 没有滚动或截断它们中的任何一个的机制。如果被忽视，这些日志会变得大得离谱。是否有一个不错的 cron-job+bash-script hack 来滚动或截断这些文件？谢谢。