Laden...

Prozesse starten mit limitierter maximaler CPU-Last

Erstellt von xingelxangel vor 14 Jahren Letzter Beitrag vor 14 Jahren 1.932 Views
X
xingelxangel Themenstarter:in
58 Beiträge seit 2009
vor 14 Jahren
Prozesse starten mit limitierter maximaler CPU-Last

Hallo,

der Titel sagt denke ich mal schon recht viel. Ich starte einen Prozess (in diesem Fall einen Dienst) so:

 Process startService = new Process();
            startService.StartInfo.FileName = "net.exe";
            startService.StartInfo.Arguments = serviceArguments;
            startService.StartInfo.UseShellExecute = false;
            startService.StartInfo.CreateNoWindow = true;
            startService.Start();

Nun ist das Problem, dass dieser Service, obwohl er nicht so viel macht, recht häufig 99% CPU-Last erzeugt. Ist es möglich, dass programmtechnisch irgendwie auf einen Maximalwert (kleiner 99) zu limitieren? Ich hab schon ein bissl geschaut. Ich vermute, dass geht irgendwie über die Prioritäten, bin mir aber absolut nicht sicher! Bin für Ideen oder Ratschläge sehr dankbar.

MfG
xixa

Gelöschter Account
vor 14 Jahren

prinzipiell geht es nciht. das macht alles der sheduler von windows. über prioritäten kannst du nur festlegen, das er bei gleichzeitigen anfragen von anderen prozessen, weniger oft zeitscheiben erhält als die anderen prozesse aber du kannst nciht die cpu-last festlegen. es gibt aber ein kostenpflichtiges tool, das das kann ... link habe ich jedoch nicht mehr.

C
401 Beiträge seit 2007
vor 14 Jahren

Also wenn dein Service nicht viel machen soll, dann solltest du eventuell als erstes überprüfen, ob vielleicht dein Code Fehler enthält, bzw. du die Aufgaben nicht optimal gelöst hast. eine hohe CPU-Last entsteht ja nicht aus heiterem Himmel 😉

3.971 Beiträge seit 2006
vor 14 Jahren

Wie Jack schon geschrieben hat geht das nur über Prioritäten. Du kannst allerdings auch zusätzlich zur Prozess-Priorität auch die Thread(s)-Prioriotät(en) herunter setzen.

Grund, ein Prozess selbst bekommt keine Zeitscheibe zugewiesen, sondern nur derren Threads - somit bezieht sich die Priorität immer auf Threads. Die Prozesspriorität gibt lediglich die Wertigkeit der Threadpriorität an. So bekommt beispielsweise ein Thread(Niedrig) im Prozess(Normal) weniger Zeit zugewiesen, als ein Thread(Normal) im Prozess(Niedrig). Weiterhin ist es wichtig, ob es sich dabei um einen Vorder- oder Hintergrundprozess handelt (Ausnahme Server). Eine im Vordergrund befindliche _Anwendung _bekommt immer mehr von der Zeitscheibe als eine die sich im Hintergrund befindet, bzw. gar keine Anwendung mit GUI ist.

Auch bewusst sollte man sich sein, dass wenn es einen Thread gibt, der 100% der CPU beansprucht, die CPU auch immer zu 100% ausgelastet ist, egal welche Priorität. Die Priorität gibt jedeglich an, wer wieviel vom Kuchen abkriegt.
Entweder ist es zu 100% der eine Thread, oder 100% ein andere Thread mit höhere Priorität (können natürlich auch mehrere sein!) oder aber irgendwas zwischen 0 und 100, wenn es sich um gleiche Prioritäten der Arbeitsthreads handelt oder aber einer der Threads mit höherer Priorität schlafen gelegt wurde.

Ein genaues Festsetzen der Auslastung auf 50% ist nur mit einer Mehrkern CPU möglich und mit nur einem Thread. Alles andere ist in meinen Augen pfutsch und nicht wirklich zu gebrauchen.

Nicht verwendete CPU-zeit wird dem Prozess 0 (Leerlaufprozess) zugewiesen, der auch ein ganz "normaler" Prozess ist - dieser führt dann für Windows irgendwelche Verwaltungsaufgaben durch.

Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...

X
xingelxangel Themenstarter:in
58 Beiträge seit 2009
vor 14 Jahren

Also wenn dein Service nicht viel machen soll, dann solltest du eventuell als erstes überprüfen, ob vielleicht dein Code Fehler enthält, bzw. du die Aufgaben nicht optimal gelöst hast. eine hohe CPU-Last entsteht ja nicht aus heiterem Himmel 😉

Das hatte ich natürlich gemacht bzw. das war mein erster Gedanke. Aber selbst wenn ich sämtlich Funktionalität aus dem Dienst nehme, ihn also wirklich nur starte, dann tritt dasselbe Phänomen auf.

Noch Ideen?

Gelöschter Account
vor 14 Jahren

ich würde sagen, das du eine endlosschleife in deinem dienst hast. die solltest du wirklich entfernen.. bzw wegoptimieren.

3.971 Beiträge seit 2006
vor 14 Jahren

Hol dir den Process Explorer von Sysinternals, dort kannst du sehen, welcher Thread welche CPU-Last erzeugt. Du kannst dir sogar den aktuellen Stack(Aufrufliste) des jeweiligen Threads anzeigen lassen. Damit sollte der Fehler schnell gefunden sein.

Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...

B
193 Beiträge seit 2009
vor 14 Jahren

Gleiches Problem hier. Ich hab allerdings eine Endloßschleife in meinem Code. dachte also das es daher kommt. Wenn es nicht so ist und eine Lösung gefunden wird wäre ich natürlich dankbar wenn du Sie hier hinein schreibst.

Gelöschter Account
vor 14 Jahren

@bl4ckY:

die lösung ist bereits genannt.... das wegoptimieren der endlosschleife.

B
193 Beiträge seit 2009
vor 14 Jahren

Das hatte ich natürlich gemacht bzw. das war mein erster Gedanke. Aber selbst wenn ich sämtlich Funktionalität aus dem Dienst nehme, ihn also wirklich nur starte, dann tritt dasselbe Phänomen auf.

Anscheinend gibt es aber noch eine weitere Quelle des Übels. Es sei denn ich verstehe "selbst wenn ich sämtlich Funktionalität aus dem Dienst nehme" falsch.

Gelöschter Account
vor 14 Jahren

@bl4ckY:

ja, das verstehts du falsch. offensichtlich ist eine leere endlosschleife geblieben.

X
xingelxangel Themenstarter:in
58 Beiträge seit 2009
vor 14 Jahren

Das könnte sein, mit der While-Schleife. Allerdings läßt sich diese kaum bis gar nicht vermeiden. Würde eine "While-Schleife" mit Abbruchbedingung anstatt einer "While(true)-Break-Schleife" das Problem eindämmen? Prinzipiell ist eine Umstellung möglich, aber nur mit großem Aufwand, daher frage ich hier lieber mal vorher nach.

Wie auch immer. Ich habe den Dienst nochmal neu installiert (mit aller Funktionalität) und gestartet. Ab in den Taskmanager: Gleiches Problem wie immer. Nun habe ich mir mit Hilfe des "ProcessExplorers" den Prozess(meinen Dienst) angeschaut bzw. die dazugehörigen Threads + Stacktrace. Der CPU-Fresser ist dabei offentsichtlich die "mscorwks.dll". Diese ist laut google Teil des .Net-Framework. Der dazugehörige Stacktrace ist der folgende:

ntkrnlpa.exe!NtBuildNumber+0x73
ntkrnlpa.exe!MmIsDriverVerifying+0xbb2
hal.dll!HalClearSoftwareInterrupt+0x342
mscorlib.ni.dll+0x738ca4
mscorlib.ni.dll+0x9388d8
mscorlib.ni.dll+0x206b7c
mscorlib.ni.dll+0x205f0c
mscorlib.ni.dll+0x2047c8
mscorlib.ni.dll+0x2044c9
mscorlib.ni.dll+0x2042cc
mscorlib.ni.dll+0x690389
mscorlib.ni.dll+0x216d66
mscorlib.ni.dll+0x2201ef
mscorlib.ni.dll+0x216ce4
mscorwks.dll+0x1b4c
mscorwks.dll!DllUnregisterServerInternal+0x619d
mscorwks.dll!CoUninitializeEE+0x2ead
mscorwks.dll!CoUninitializeEE+0x2ee0
mscorwks.dll!CoUninitializeEE+0x2efe
mscorwks.dll!CorExitProcess+0x1e4d
mscorwks.dll!CoUninitializeEE+0x4e0b
mscorwks.dll!CoUninitializeEE+0x4da7
mscorwks.dll!CoUninitializeEE+0x4ccd
mscorwks.dll!CoUninitializeEE+0x4e59
mscorwks.dll!CorExitProcess+0x1c1e
mscorwks.dll!CorExitProcess+0x1cf8
mscorwks.dll!CorExitProcess+0x21f3f
KERNEL32.dll!GetModuleFileNameA+0x1ba


Keine Ahnung, ob da mit jemand was anfangen kann. Aber versuchen kann ich es ja mal.

MfG
xixa

Gelöschter Account
vor 14 Jahren

Würde eine "While-Schleife" mit Abbruchbedingung anstatt einer "While(true)-Break-Schleife" das Problem eindämmen?

ich sehe in den beiden versionen keinerlei unterschied.

prinzipiell bleibe ich bei mier kernaussage... die schleife muss weg. entweder du nimmst einen timer oder machst es komplett eventbasiert aber busy-waiting ist wie du selber sehen kannst schlecht.

49.485 Beiträge seit 2005
vor 14 Jahren

Hallo xingelxangel,

Allerdings läßt sich diese kaum bis gar nicht vermeiden.

wenn der "Service, obwohl er nicht so viel macht, recht häufig 99% CPU-Last erzeugt" ist die Schleife sicher vermeidbar. Allerdings hat die Frage, wie man die Schleife vermeiden kann, nichts mehr mit dem Thema im Titel zu tun. Du hast jetzt ohnehin alle Hinweise, die du brauchst. Den Rest solltest du also alleine hinbekommen.

herbivore