☰

Leistungsverlust nach 30 Minuten

tag-icon • tag-icon 14.04 performance cron
Leistungsverlust nach 30 Minuten

Das hier hat mich verblüfft. Ich habe Ubuntu 14.04, vor 3 Tagen (20.10.2014) begann es langsamer zu werden.

Ich habe es reproduziert, indem ich gedit geöffnet und dann geschlossen habe. Wenn das Problem aktiv ist, dauert das Schließen einer leeren Datei etwa 2 Sekunden, während dies ohne das Problem immer sofort geschieht – es wirkt sich auf alles andere auf ähnliche Weise aus.

top meldet keine ungewöhnliche Aktivität, wenn das Einfrieren auftritt, htop das Gleiche, iotop ebenfalls.

Das Problem tritt erst nach 30 Minuten Betriebszeit auf. Ich kann garantieren, dass ich es nach 29 Minuten Betriebszeit nicht reproduzieren konnte. Nach 31 Minuten Betriebszeit konnte ich es durchgängig reproduzieren (mit der obigen Methode, keine anderen Apps als Terminal und htop gestartet) und es 4 oder 5 Mal wiederholen (durch Herunterfahren, Hochfahren und eine halbe Stunde Warten – was Spaß machte).

Das Problem besteht auch nach einem Neustart weiterhin, kann aber durch Herunterfahren und erneutes Einschalten zurückgesetzt werden. Welcher Teil von Ubuntu behält seinen Zustand nach einem Neustart, aber nicht nach einem Herunterfahren?

Relevante Protokolle für diesen Zeitraum sind syslog, auth.log und Xorg.0.log (durch Prüfung des Inhalts von /var/log auf Änderungszeit im angegebenen Bereich).

Syslog:

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))

Authlog:

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: (wahrscheinlich wecke ich den Computer gerade wieder auf)

[  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

Nichts davon weist auf etwas Schlimmes hin und die nachfolgenden Schritte zur Reproduktion des Problems zeigen, dass sich die Protokolle nicht geändert haben. Es handelte sich also höchstwahrscheinlich nur um harmlose Protokolle.

Ich gehe davon aus, dass dieses Problem drei mögliche Ursachen hat:

Softwareinstallation: Ich habe etwas Fragwürdiges installiert

Ich tat:

  • Verlauf | grep apt-get' - keine Installationen in diesem Zeitraum
  • Habe mir den Verlauf des Synaptic-Paketmanagers angesehen – in diesem Zeitraum nichts
  • Verlauf des Softwarecenters – das letzte Update war mehrere Wochen her (es gab ein Abhängigkeitsproblem, deshalb hatte ich eine Zeit lang keine Updates durchgeführt)
  • Ich habe Skype für Ubuntu etwa zu diesem Zeitpunkt installiert, aber es gibt keinen Hinweis darauf, dass es durch Skype verursacht wurde (habe es trotzdem entfernt)

Cron-Job läuft schief

Habe die Cronjobs in Crontab, /etc/cron.d /etc/cron.daily und hourly geprüft, nichts deutet darauf hin, dass da etwas ist, es wird nur alle 30 Minuten ein PHP-Cronjob ausgeführt, aber wenn es ein Cron wäre, würde er ihn zu bestimmten Zeitpunkten rund um die Uhr ausführen, nicht 30 Minuten nach dem Start.

Die Analyse neuer Prozesse, die zwischen dem Nicht-Verlangsamungszustand und dem Verlangsamungszustand gestartet wurden, lässt darauf schließen, dass keine neuen Prozesse gestartet wurden (beim ersten Test wurde ein Kworker-Thread angezeigt, aber das ist wahrscheinlich nur ein Zufall). Ich nehme an, das muss bedeuten, dass es entweder ein bestehender Prozess war, der es ausgelöst hat, oder etwas anderes.

Malware

Aufgrund seiner Unauffindbarkeit und der mysteriösen 30-minütigen Abwesenheit des Problems (30 Minuten scheinen eine von Menschen gewählte Zeitspanne zu sein) begann ich zu glauben, dass es sich um eine Art Malware handeln könnte, so unwahrscheinlich das auch sein mag (ich hatte eine Weile kein Update durchgeführt und hatte ein paar offene Ports). Also habe ich rkhunter (Rootkit-Finder) ausgeführt, aber nichts Ungewöhnliches gefunden.

Andere Dinge, die ich versucht habe:

  • Deaktivieren bestimmter Compiz-Komponenten – keine Änderung
  • Compiz neu starten - keine Änderung
  • Deaktivieren aller Compiz-Komponenten – keine Änderung (außer dass ich damit kämpfe, den Computer wieder nutzbar zu machen)
  • Ich spiele verschiedene Musikinstrumente, während ich warte, bis die Betriebszeit 30 Minuten erreicht hat, und beobachte dann die Ergebnisse von top und htop auf verdächtige Änderungen – nichts Ungewöhnliches

Ist irgendjemandem etwas Ähnliches passiert oder könnte mir jemand weiterhelfen? Wenn ja, drücke ich für Ihre Antwort wiederholt die Schaltfläche „Hochstimmen“ (ich achte darauf, dass es eine ungerade Zahl ist).

Antwort1

Es gibt einige Möglichkeiten, Cron so zu konfigurieren, dass ein Job 30 Minuten nach dem Start ausgeführt wird. Jenkins tut dies, indem es die Funktion hasht und H/30 * * * *beispielsweise verwendet. Es könnte auch ein Thread sein, der 30 Minuten lang schläft und einen stillen CPU-Killerprozess erzeugt.

Einige Ideen dazu:

Haben Sie htop als Root ausprobiert? Einige Prozesse sind möglicherweise unsichtbar, das habe ich insbesondere bei Debian gesehen.

Haben Sie versucht, sich abzumelden und erneut anzumelden, als das Problem auftrat? Es könnte am Fenstermanager oder an einem Sitzungsproblem liegen.

Wenn das Abmelden/Anmelden nicht funktioniert, können Sie versuchen, Ihren Sitzungsmanager neu zu starten. Ich glaube, standardmäßig ist lightdm aktiv, also sudo service lightdm restartsollten Sie das tun.

Antwort2

Ursache hierfür warSMART-Datenfür das betreffende Laufwerk aktiviert sein.

Das Deaktivieren der SMART-Daten hat dieses Problem gelöst:

sudo smartctl --smart=off /dev/sda

Vermutlich führte es 30 Minuten nach dem Hochfahren der Festplatte immer wieder eine Art internen Selbsttest aus und geriet in eine Schleife. Da dies auf der Hardwareebene geschah, bemerkte der Rest des Computers nichts davon. Daher konnte ich keinen bestimmten Prozess erkennen, der für die E/A-Blockierung verantwortlich war, und auch keine Prozesse, die Ressourcen beanspruchten.

verwandte Informationen