我有一个基本的云服务器，只用于testing。 自从我安装New Relic（昨天）以来，它每8小时报告一次高的光盘I / O和高CPU问题（> 90％），每次总共25分钟（大约）。
New Relic似乎显示了这些问题：
(a) very high CPU issue with "find (root)" (b) high usage of dev/xvda1 我的服务器提供商不知道问题是什么，因为他们看不到他们的最后。
这是什么意思呢？ 我有什么需要做的吗？
（一）非常高的CPU问题与“查找（根）”
这很可能是重build定位数据库的更新脚本，或者是出于某种原因通过磁盘扫描的其他脚本。 如果在问题发生时键入ps auxwwf ，则可以看到进程树; 寻找导致问题的“查找”过程，然后看看它运行的是什么（可能类似于'updatedb'）。
丹（很可能是正确的）。 我用这个post和另一个来解决我的问题，
我有一个类似的问题VMWare Linux薄荷17.1。 开始几分钟后，90-100％的CPU消耗了15分钟左右 – 它有一个相当大的共享目录，其中有大量的遗传数据。
我用top得到查找进程ID（12788）。 由于它消耗了所有的CPU功率，所以它是第一条线。 这里的一个区别是，违规过程是“无人”所有。
然后我运行ps -auxwwf并find了这棵树 – 注意最后一行的find命令。
root 1334 0.0 0.0 12780 960 ? Ss 07:15 0:00 anacron -s root 12676 0.0 0.0 4440 652 ? S 07:20 0:00 \_ /bin/sh -c run-parts --report /etc/cron.daily root 12677 0.0 0.0 4332 648 ? S 07:20 0:00 \_ run-parts --report /etc/cron.daily root 12749 0.0 0.0 4440 652 ? S 07:20 0:00 \_ /bin/sh /etc/cron.daily/locate root 12754 0.0 0.0 4440 744 ? SN 07:20 0:00 \_ /bin/sh /usr/bin/updatedb.findutils root 12762 0.0 0.0 4440 336 ? SN 07:20 0:00 \_ /bin/sh /usr/bin/updatedb.findutils root 12788 0.0 0.0 86152 2384 ? SN 07:20 0:00 | \_ su nobody -s /bin/sh -c /usr/bin/find / -ignore_readdir_race \( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex '\(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\(^/afs$\)\|\(^/amd$\)\|\(^/alex$\)\|\(^/var/spool$\)\|\(^/sfs$\)\|\(^/media$\)\|\(^/var/lib/schroot/mount$\)' \) -prune -o -print0
我没有安装rpm，所以我使用了Synaptic Package Manager GUI，在软件包和名称中search“updatedb”。 与updatedb安装唯一的软件包是“定位”。 然后我删除了定位包。
命令行工具的另一个好的答案是在Unix堆栈交换关于禁用定位/ updatedb