Prozesspriorität auf Hoch setzen: Gefährlich?


8

Ich habe gelesen, dass das Einstellen von etwas in Echtzeit ein großes Nein-Nein ist, also werde ich das nicht tun. Ich habe jedoch eine Anwendung, mit der ich sicherstellen muss, dass mein System immer die höchste Priorität hat, da dies für den Rest der von mir ausgeführten Anwendungen von entscheidender Bedeutung ist. Besteht die Gefahr, die Priorität auf hoch zu setzen, was eine Stufe unter der Echtzeit liegt?

Wie könnte ich dies auch tun, indem ich das Verknüpfungsziel ändere? Was ist der Befehl?


Die Einstellung "Über Normal" (Windows 7) ist sicherer. Einige Diskussionen hier ... stackoverflow.com/questions/1663993/…
Moab

1
Es ist sehr gefährlich. Das Hauptproblem ist die Prioritätsinversion, die dazu führt, dass der Prozess mit höherer Priorität tatsächlich eine effektiv niedrigere Priorität erhält, da er durch einen Prozess mit niedrigerer Priorität auf unbestimmte Zeit blockiert werden kann .
David Schwartz

Wie bereits erwähnt, ist "Echtzeit" nicht unbedingt schlecht, solange sich Ihr Prozess gut verhält und nur ausgeführt wird, wenn er benötigt wird, und wenn er nicht benötigt wird. Andernfalls kann (und wird) er verhindern, dass andere Aufgaben vollständig ausgeführt werden.
Mokubai

2
@ David Schwartz, Cutler hat den Windows-Scheduler so konzipiert, dass Deadlocks aufgrund der Prioritätsumkehr vermieden werden. Unter support.microsoft.com/kb/96418 : "Der Windows NT-Scheduler löst dieses Problem, indem er die Priorität von Threads, die zur Ausführung bereit sind (in diesem Fall die Sperrhalter mit niedriger Priorität), zufällig erhöht. Die Threads mit niedriger Priorität werden lange genug ausgeführt Um die Sperre aufzuheben (den kritischen Abschnitt zu verlassen), erhält der Thread mit hoher Priorität die Sperre zurück. Wenn der Thread mit niedriger Priorität nicht genügend CPU-Zeit erhält, um seine Sperre beim ersten Mal aufzuheben, erhält er eine weitere Chance in der nächsten Planungsrunde. "
Nicole Hamilton

@NicoleHamilton Deshalb öffnet ein Programm manchmal einige Instanzen gleichzeitig, wenn es aufgrund der hohen Auslastung nicht beim ersten Klick geöffnet wurde (und Sie ein paar Mal geklickt haben)?
Simon Verbeke

Antworten:


6

Echtzeit ist nicht unbedingt ein "Nein-Nein". Es könnte andere Prozesse aus CPU-Zyklen heraus hungern lassen. Einige Anwendungen können damit nicht umgehen. Es ist etwas, mit dem man experimentieren müsste.

Hoch sollte weniger ein Problem sein. Sie müssen Ihr System jedoch weiterhin überwachen, um festzustellen, ob sich alle Anwendungen gut verhalten.

So ändern Sie den Prozess über die Befehlszeile, die Sie in eine Verknüpfung einfügen können:

http://support.microsoft.com/kb/191771


1
Unter Windows es tut sehr leicht andere Prozesse hungern (einschließlich Task - Manager selbst).
user1686

3
Es hängt alles von Ihrem System ab. Abhängig davon, wie CPU-intensiv der Prozess ist, ist eine Echtzeit-Affinität in Ordnung. Ich führe gerade einen Prozess in Echtzeit ohne Probleme aus. Es kann auch hilfreich sein, eine Affinität zu einem Prozessor festzulegen, während die Priorität auf Echtzeit gesetzt wird.
Keltari

Wenn ein Prozess auf Echtzeit eingestellt ist, hat er dann absolute Priorität vor allen anderen Prozessen auf dem Kern, auf dem er ausgeführt wird? Ich habe versucht, Wege zu finden, um einen meiner Kerne der Zwergenfestung zu widmen, während sie läuft.
SaintWacko

3

Ich würde sagen, es kommt darauf an. Wenn Sie nur einen Kern / eine CPU auf Ihrem Computer haben und dies eine CPU-intensive Aufgabe ist, würde ich sie nicht auf Echtzeit einstellen. Hoch mag in Ordnung sein, aber das muss experimentiert werden.

Wenn Sie mehrere Kerne haben und der Prozess nur einen Thread hat: Stellen Sie ihn so ein, wie Sie möchten. Ihre anderen Kerne sind weiterhin frei, selbst wenn ein Kern die ganze Zeit zu 100% ausgelastet ist.

Wenn Sie mehrere Kerne haben und der Prozess mehrere Threads umfasst, hängt dies davon ab, ob alle Threads zu 100% ausgelastet sind. Einige Programme haben einen 'Manager'-Thread, der die Arbeit an andere Threads weiterleitet, aber selbst nicht viel verarbeitet. Dies würde einen Kern nahezu frei lassen und somit eine hohe Priorität oder Echtzeitpriorität ermöglichen.

Andere Programme versuchen, alle Kerne aufzunehmen. In diesem Fall mag hoch in Ordnung sein, aber es muss experimentiert werden.

Selbst andere nehmen nur eine bestimmte Anzahl von Kernen und verwenden möglicherweise nicht alle verfügbaren Kerne. In diesem Fall sollte eine hohe Priorität oder Echtzeitpriorität in Ordnung sein.

Experimentieren Sie, es sei denn, Sie befinden sich auf einem einzigen Kern. Meistens tut es nicht weh, es auf Hoch oder sogar in Echtzeit einzustellen. Sie können die Affinität eines Prozesses (wie viele Kerne er verwenden kann) auch im Task-Manager festlegen. Auf diese Weise können Sie die Belastung Ihrer CPU besser ausgleichen. Es kann auch dazu beitragen, die Temperaturen und den Stromverbrauch niedrig zu halten.


+1 Guter Punkt, dass eine Single-Threaded-App auf einem Multi-Core-Computer kein Problem darstellt, egal wie rechengebunden.
Nicole Hamilton

Vergessen Sie jedoch nicht, dass, wie gewarnt, [hauptsächlich] Single-Threaded-Prozesse mit hoher Priorität - selbst wenn sie nur einen einzelnen Kern betreffen - globale Systemsynchronisationssperren für einen abnormalen Zeitraum halten können.
Dyasta

1

Ob dies für Sie funktioniert, hängt ganz davon ab, was Ihre Anwendung tut. Wenn es sich um eine lange, lange Berechnung handelt, bei der nie auf E / A gewartet werden muss, können Sie davon ausgehen, dass das Ausführen mit hoher Priorität Ihre Maschine in die Knie zwingen kann. Wenn das Problem jedoch die Latenz ist und Ihre Anwendung als Reaktion auf einen E / A-Abschluss oder ein ähnliches Ereignis nur sehr schnell aufwachen muss, führen Sie eine schnelle Verarbeitung durch und schlafen Sie dann wieder ein. Dies ist in Ordnung.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.