這個讓我很困惑我有 Ubuntu 14.04，三天前（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
這些都沒有表明有任何問題，並且重現該問題的後續步驟表明日誌沒有發生任何更改，因此這些很可能只是無辜的日誌。
我認為這個問題有3個可能的來源：
軟體安裝：我安裝了一些狡猾的東西
我做了：
- 歷史| grep apt-get' - 在該時段內沒有安裝
- 查看了突觸套件管理器的歷史記錄 - 在那段時間沒有任何內容
- 軟體中心歷史記錄 - 上次更新是幾週前（存在依賴性問題，所以我有一段時間沒有進行任何更新）
- 我在那段時間安裝了 Skype for Ubuntu，但沒有跡象表明這是由 Skype 引起的（無論如何都將其刪除）
Cron 作業出錯
檢查了crontab、/etc/cron.d /etc/cron.daily 和每小時中的cronjobs，沒有任何跡象表明其中有任何內容，只有PHP cron 作業每30 分鐘發生一次，但如果它是cron，它會在全天候的某些時間點執行而不是啟動後30分鐘。
分析在非減速狀態和減速狀態之間啟動的新進程表明沒有啟動新進程（首先測試顯示了一個 kworker 線程，但這可能只是巧合）。我認為這必定意味著它要么是觸發它的現有流程，要么是其他原因。
惡意軟體
由於它難以捉摸，而且神秘的 30 分鐘沒有出現問題（30 分鐘似乎是人類選擇的時間），我開始認為這可能是某種惡意軟體，無論可能性如何（尚未進行更新）一段時間並有一些開放的連接埠）。於是運行了 rkhunter（rootkit finder），但沒有發現任何異常。
我嘗試過的其他事情：
- 取消選取某些 compiz 元件 - 沒有變化
- 重新啟動 compiz - 沒有變化
- 取消勾選所有 compiz 組件 - 沒有任何變化（除了我努力讓電腦再次可用）
- 演奏各種樂器，同時等待正常運行時間達到 30 分鐘，然後觀察 top 和 htop 的結果是否有任何可疑的變化 - 沒什麼奇怪的
有沒有人遇到過類似的事情，或者如果你這樣做的話，可以給我指出正確的方向，我會在你的答案上反复點擊“向上投票”按鈕（我會確保它是一個奇數）
答案1
有一些方法可以將 cron 配置為在啟動後 30 分鐘執行作業。 Jenkins 透過雜湊函數並使用H/30 * * * *example 來做到這一點。它也可能是一個線程休眠 30 分鐘並產生一個靜默的 cpu 殺手進程。
那裡有一些想法：
你有沒有嘗試過以 root 身分使用 htop ？有些進程可能是看不見的，我在 Debian 上尤其看到過這種情況。
出現問題時您是否嘗試登出/重新登入？可能是視窗管理器或會話問題。
如果登出/登入不起作用，您可以嘗試重新啟動會話管理器。我認為預設是 lightdm，所以sudo service lightdm restart應該這樣做。
答案2
這是由於智慧數據正在為有問題的驅動器啟用。
禁用 SMART 數據解決了這個問題：
sudo smartctl --smart=off /dev/sda
據推測，在磁碟旋轉並進入循環後 30 分鐘，它不斷重新運行某種內部自我檢測；由於這是在硬體層，電腦的其餘部分不知道它正在發生，因此我看不到任何進程專門負責 IO 阻塞，也沒有進程佔用資源。