instruyete

Die heute aktuelle KDE 4.7.0 Inkarnation beglückt einem nach dem Starten der KDE Session mit 100% CPU Auslastung durch kded4

kded4 ist der KDE daemon der vorzugsweise via D-Bus Abfragen vornimmt, die Plasma Widgets dann grafisch darstellen (notifier).
Gefüttert wird der daemon durch seine Module, die sofern sie fehlerhaft sind, wie momentan

kded_networkstatus.so (in /usr/lib64/kde auf einem x64_86 System)

dann leicht in einen busy endlos-loop gerät – bei dem erwähnten Modul pollt er sich zu Tode.
Leider ist die Fehlersuche relativ mühselig – anstatt auf der Oberfläche in den KDE Systemsettings rumzuklicken, würde ich alle Verknüpfungsdateien für kded in

/usr/share/kde4/services/kded

zuerst entfernen und dann wieder Stück für Stück hineinkopieren und anschliessend in KDE einloggen um direkt die Auswirkungen des speziellen Moduls zu sehen.

Seit geraumer Zeit werde ich nach jedem Login in einem KDE4.x System zeitverzögert mit folgender Meldung beglückt:

„Nepomuk Indexing agents have been disabled“

Zusätzlich kommt noch einiges an blabla bzgl. akonadi Beschwerden.
Die Sache ist, dass ich in den KDE Systemeinstellungen nepomuk deaktiviert habe und keine KDE PIM Programme verwende. So what?

Nachdem ich mir hier nochmals die Terminologie der KDE Lieblingsprojekte verinnerlicht habe, wurde die Ursache schnell klar, auch wenn die Hintergründe es immer noch nicht sind.

Akonadi als PIM Datenzugriffsframework benötigt unbedingt nepomuk für die Umsetzung der Suche.
Warum aber starten denn überhaupt die akonadi agents? Schon der Versuch die nicht benötigten Softwarekomponenten (alles was mit akonadi und KDEpim zu tun hat) zu löschen, schlug fehl. Sie sind so stark mit dem restlichen KDE System verzahnt, dass man entweder gleich das ganze KDE System löschen oder sie eben behalten muss.
Auch ein löschen der (aus welchem Grund auch immer) schon angelegten akonadi Resourcen in den KDE Sytemeinstellungen brachte akonadi beim KDE Start nicht zum schweigen. Es scheint, dass akonadi von banalsten Programmen wie der Plasma-Uhr, benutzt wird. An dieser Stelle gab ich nach und aktivierte nepomuk (allerdings ohne den Strigi Indexer).

Dies führte dann zu dem dubiosen Fehler, dass sich nepomuk beschwerte nicht starten zu können, da das soprano backend redland fehlt. Tatsächlich waren aber alle redland Komponenten installiert. Da ich aber in den KDE Systemeinstellungen zu nepomuk nur eine Konfigurationseinstellung bzgl. des virtuoso backends gesehen habe, schwante mir wieder eine Inkosistenz – geschuldet mangelhafter Transitionsprozesse während der fortlaufenden KDE updates in der 4.x Reihe. Abhilfe schafft das Löschen folgender nepomuk Dateien:

~/.kde4/share/config/nepomuk*
~/.kde4/share/apps/nepomuk/*

Seitdem läuft nepomuk und akonadi ohne Fehlermeldungen und v.a. ressourcenschonend im Hintergrund. Lediglich nach dem Einloggen erscheinen für wenige Augenblicke die Prozesse

nepomukservicestub
akonadi_maildispatcher_agent

mit CPU Belastung.
Übrigens war dies während der inkonsistenten Phase ganz anders. Dort liefen teilweise akonadi Prozesse, sowie das benutze mysql, wild und CPU-fressend durch die Gegend.

Das nächste Echtzeit Performance Monitoring Tool. Ist aber so kompakt und einfach gehalten, dass es einfach auch hier erwähnt werden muss

AT Computing’s System & Process Monitor

Teilt den Bildschirm wie top in einen oberen Systembereich und unteren Prozessbereich auf.
Positiv fällt sofort auf, dass der Systembereich auch mit RAID/LVM und den physikalischen zugrundeliegenden Datenträgern zurechtkommt und die Last auf den einzelnen OSI Netzwerkschichten darstellen kann.

Die wichtigesten Shortcuts lauten folgendermassen:

Parameter	Bedeutung
G	Allgemeine Ansicht
M	Hauptspeicher Ansicht
D	Massenspeicher Ansicht
S	Scheduler Ansicht
P	Ansicht nach Program
U	Ansicht nach Benutzer
C	Ansicht Befehlszeile
Shift+C	Sortieren nach CPU-Auslastung
Shift+M	Sortieren nach RAM-Auslastung
Shift+D	Sortieren nach Massenspeicher-Auslastung
Shift+A	Sortieren nach meistgenutzer Resource
Shift+P	Filtern nach Prozessname
Shift+U	Filtern nach Benutzername
Z	Pause
T	Auslösen einer manuellen Messung

Nachdem mit Kernel 2.6.39 der Big Kernel Lock (BLK) endgültig entfernt wurde, stellt jeder Vanilla Kernel ein vollständig konfigurierbares RT System dar.

Warum man dennoch mit Speziallösungen wie der Realtime Linux Distribution RedHawk nicht schlecht fährt liegt meist an Frontend Features welche die Wartbarkeit deutlich erhöhen.

Beispiele, gerade aus der Distribution RedHawk sind CPU-set shielding und CPU-set affinity. Beides wird mit Shell Kommandos unterstützt.

• shield kann on-the-fly CPU(s) aus der Verfügbarkeit des Operating Systems herausnehmen und wieder hinzufügen.
• run kann bestimmte Prozesse mit RT-Priorität einem bestimmten CPU-set exklusiv zuweisen (affinity).

Diese Beispiele sowie allgemeine Aktualisierungen sind in der aktuellen Fassung meines Dokumentes über Realtime Linux enthalten.

Mit den Systemaufrufen:

struct sched_param sp;
sched_setscheduler(pid,SCHED_RR,&sp);

lässt sich – sofern man über CAP_SYS_NICE Capabilities verfügt – jederzeit unter Linux der Prozess pid in einen soften Realtime Mode bringen. Hierbei übernimmt das Kernelmodul sched_rt das Prozessscheduling von sched_fair (Complete Fair Scheduler).

Beachtenswert hierbei ist wieder die gewöhnungsbedürftige Invertierung der RT-Prioritäten. Der Aufruf

struct sched_param sp;
sp.sched_priority = 14;

setzt die RT-Priorität auf 14 – welches im Linux Prioritätenarray dann 99-14=85 ergibt. Dies bestätigt die Ausgabe Prio des folgenden Befehls:

cat /proc/<pid>/sched

Die Capability CAP_SYS_NICE muss übrigens nicht zwangsläufig bedeuten, dass nur root den Prozess starten muss. Mittels den libcap-progs kann auch folgender Befehl dem Programm auf Filesystemebene diese Capability zugestehen.

setcap cap_sys_nice=ep /pfad/zu/meinem/programm

Erforderlich dazu ist, dass der Kernel mit CONFIG_SECURITY_FILE_CAPABILITIES=y kompiliert wurde. Die Linux Kernel welche von Novell gebaut wurden (SLES,openSUSE) müssen noch mit dem Bootparameter file_caps=1 gestartet werden, da diese die Fähigkeit zwar auch einkompiliert haben, aber standardmässig deaktiviert ist.
Der Bootparameter ist übrigens exklusiv nur auf Novell Systemen vorhanden – der offizielle Vanilla Kernel Bootparameter bzgl. Capabilities lautet no_file_caps ,um die Fähigkeit beim Start zu deaktivieren.