这个问题让我很困惑。我使用的是 Ubuntu 14.04，3 天前（2014-20-10）它开始变慢了。
我通过打开 gedit 然后关闭 gedit 来重现它，当问题出现时，它大约需要 2 秒钟来关闭一个空文件，而如果没有这个问题，这总是立即发生的 - 以类似的方式影响其他所有内容。
当冻结发生时，top 报告没有异常活动，htop 也是一样，iotop 也一样。
该问题仅在正常运行 30 分钟后出现，我可以保证在正常运行 29 分钟时我无法重现该问题，在正常运行 31 分钟时我可以始终如一地重现该问题（使用上述方法，除终端和 htop 之外没有启动任何应用程序）并设法重复该问题 4 或 5 次（通过关机、启动并等待半小时 - 这很令人愉快）。
即使重新启动后问题仍然存在，但可以通过关机并重新启动来重置，Ubuntu 的哪个部分在重新启动后保持状态但在关机后不会保持状态？
此期间的相关日志是 syslog、auth.log 和 Xorg.0.log（通过检查 /var/log 中指定范围内修改的时间的内容）
系统日志：
Oct 22 17:21:36 raiden NetworkManager[1102]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Oct 22 17:39:01 raiden CRON[3284]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Oct 22 18:09:01 raiden CRON[3370]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
授权日志：
Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session closed for user root
Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session closed for user root
Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session closed for user root
Xorg.0.log：（可能是我刚刚唤醒了电脑）
[ 3466.727] (II) intel(0): switch to mode [email protected] on LVDS1 using pipe 0, position (0, 900), rotation normal, reflection none
[ 3466.880] (II) intel(0): switch to mode [email protected] on VGA1 using pipe 1, position (0, 0), rotation normal, reflection none
这些都没有表明有任何不好的情况，并且重现该问题的后续步骤表明日志没有任何变化，所以这些很可能只是无辜的日志。
我推测这个问题可能有三个根源：
软件安装：我安装了一些可疑的东西
我做到了：
- 历史 | grep apt-get'-该时间段内没有安装
- 查看了突触包管理器的历史记录 - 这段时间内没有任何内容
- 软件中心历史记录 - 上次更新是在几周前（存在依赖性问题，所以我有一段时间没有做任何更新）
- 我在那段时间安装了适用于 Ubuntu 的 Skype，但没有迹象表明这是由 Skype 引起的（无论如何我还是删除了它）
Cron 任务出错
检查了 crontab、/etc/cron.d /etc/cron.daily 和 hourly 中的 cronjobs，没有任何迹象表明其中有某项工作，只有一个 PHP cron 作业每 30 分钟发生一次，但如果是 cron，它会在时钟的某些时间点执行该作业，而不是在启动后 30 分钟。
分析非减速状态和减速状态之间启动的新进程，表明没有启动新进程（第一次测试显示有一个 kworker 线程，但这可能只是巧合）。我推测这肯定意味着要么是现有进程触发了它，要么是其他原因。
恶意软件
由于它的难以捉摸以及问题神秘地消失了 30 分钟（30 分钟似乎是人为选择的时间），我开始认为它可能是某种恶意软件，尽管可能性不大（很长时间没有更新，并且有几个开放端口）。因此运行了 rkhunter（rootkit 查找器），但没有发现任何异常。
我还尝试过其他方法：
- 取消勾选某些 compiz 组件 - 没有变化
- 重新启动 compiz-没有变化
- 取消勾选所有 compiz 组件 - 没有变化（除了我费力让电脑再次可用）
- 在等待正常运行时间达到 30 分钟的同时演奏各种乐器，然后观察 top 和 htop 的结果是否有任何可疑的变化 - 没有什么奇怪的
有没有人遇到过类似的事情，或者可以给我指出正确的方向，如果有的话，我会反复点击你答案的赞成按钮（我会确保它是一个奇数）
答案1
有一些方法可以配置 cron 在启动后 30 分钟运行作业。H/30 * * * *例如，Jenkins 通过散列函数并使用来实现这一点。它也可以是一个线程休眠 30 分钟并生成一个静默的 CPU 杀手进程。
这里有一些想法：
您是否尝试过以 root 身份使用 htop？某些进程可能不可见，我在 Debian 上尤其见过这种情况。
问题发生时，您是否尝试过注销/重新登录？可能是窗口管理器或会话问题。
如果注销/登录不起作用，您可以尝试重新启动会话管理器。我认为默认情况下是 lightdm，所以sudo service lightdm restart应该这样做。
答案2
这是由于智能数据针对相关驱动器启用。
禁用SMART数据解决了这个问题：
sudo smartctl --smart=off /dev/sda
据推测，在磁盘旋转 30 分钟后，它会不断重新运行某种内部自检并进入循环；因为这是在硬件层，所以计算机的其余部分并不知道它的发生，因此我看不到任何特别负责 IO 阻塞的进程，也看不到任何占用资源的进程。