it-swarm-eu.dev

Unangenehme CPU-Spitzen, die nicht mit sichtbaren Prozessen verbunden sind

Wirklich seltsames Problem hier. Ich bekomme immer wieder unangenehme CPU-Spitzen, bei denen die CPU über alle Kerne hinweg etwa 5 Minuten lang zu 80-90% ausgelastet ist. Wenn ich mir conky in htop oder system monitor anschaue und nach% CPU sortiere, kann ich keinen Prozess erkennen, der für diese CPU-Auslastung verantwortlich ist.

Die einzigen Dinge, die ich seitdem geändert habe, sind:

  • Ich bin auf die Kernel-Version 2.6.35 umgezogen (home compiled, ab 2.6.24-1)
  • Ich habe den Nvidia-Treiber 256.44 (von 256.34) installiert

Jetzt bin ich bereit, einen oder beide Upgrades durchzuführen, um das Problem zu finden, aber ich würde es vorziehen, dies so wissenschaftlich wie möglich zu tun und herauszufinden, was die CPU-Explosion verursacht, bevor ich einen Downgrade durchführe.

Edit: Mein genaues Problem sieht aus wie eine NVIDIA-Regression in ihrem neuesten Treiber. Andere Leute bekommen ähnliche Spitzen .

7
Oli

Es könnte sich um einen Kernel-Thread handeln, der in den meisten Leistungsmonitoren standardmäßig ausgeblendet ist. In htop können Sie Kernel-Threads mit "K" (Umschalt + k) ein- und ausblenden.

1
JanC

"Die CPU ist ca. 5 Minuten lang über alle Kerne hinweg zu 80-90% ausgelastet."

Wenn Sie so viel verwenden, können Sie den Täter möglicherweise mithilfe von pidstat, das im sysstat-Paket enthalten ist, lokalisieren.

Führe einfach pidstat -u | sort -nr -k 7,7 | head -10 und der Prozess, der die meiste CPU verwendete, sollte die oberste Zeile sein.

3
Li Lo

Ich würde versuchen, die Ursache für das Problem mit einem Shell-Skript zu finden:

#!/bin/sh
MAXLOAD=100
CURRLOAD=`uptime | sed '[email protected]*load average: \([^,]*\).*@\[email protected]' | sed '[email protected]\?.0\[email protected]@'`

if [ $CURRLOAD -gt $MAXLOAD ]; then                                             
  ps -eo tid,pcpu,comm | sort -n -k 2 | tail -n 5 | \
    mail -s "High load" -e [email protected]
fi

Das Skript hat zwei Variablen MAXLOAD und CURRLOAD. Die erste sollte eine hohe Last multipliziert mit 100 sein. Wenn Sie also auf eine Spitze stoßen und die Systemlast auf 2 oder 3 steigen sehen, sollten Sie MAXLOAD auf einen Wert um 200 setzen. $CURRLOAD nimmt die Ausgabe von uptime, sucht nach der Last und entfernt den Punkt sowie führende Nullen.

Wenn die Last zu einem bestimmten Zeitpunkt zu hoch ist, werden die fünf Prozesse mit der höchsten CPU-Auslastung gedruckt und an [email protected] Gesendet.

Dieses Skript soll Ihnen helfen, den Grund für einen Spitzenwert zu finden. Wenn Sie ihn kennen, können Sie das Problem möglicherweise beheben.

2
qbi

Es gibt einige kürzlich behobene Fehler, die dieses Problem beheben könnten. Wenn Sie Ubuntu verwenden, würde ich empfehlen, beim Ubuntu-Kernel zu bleiben, um die Patches durch regelmäßige Updates zu erhalten. Ich würde empfehlen, Lucid für die Unterstützung und Stabilität zu installieren. Sie können sich für Maverick entscheiden, wenn es Funktionen gibt, von denen Sie wissen, dass sie nicht in Lucid enthalten sind.

1
Brad Figg

So erhalten Sie die Ausgabe von oben, die Sie speichern können: top -b -n1

Wenn Sie dies in einem Cronjob festhalten, können Sie sich die minutiöse Prozessliste ansehen, auch nachdem das Problem behoben wurde. Beispiel für einen Crontab-Eintrag:

* * * * * top -b -n1 > /tmp/top_output_$(date +%Y-%m-%d_%H:%M:%S)

Dadurch wird es in einer Datei pro Minute in/tmp gespeichert

1

Ich denke, das ist ein Kernel-Problem. Ich würde auf eine offiziell getestete Version zurückgreifen.