Dynamische Thread Prioritäten (Priority Boosts)

hustbaer

Hat jemand von euch eine Liste wo drauf steht wich hoch der Priority-Boost ist der von bestimmten Treibern bzw. IO-Arten vergeben wird? Für Windows 7.

Ich hab' hier nämlich ein komisches Problem, wo der SQL Server dem Vordergrund-Prozess die ganze CPU-Zeit weglutscht, und das sogar denn man den SQL Server mit Priority Class "below normal" laufen lässt (und den Vordergrund-Prozess mit "normal").
Kann ich mir momentan nur so erklären dass die Threads vom SQL Server durch abgeschlossene IOs geboostet werden.

Ich kann mich erinnern mal eine Liste gefunden zu haben, wo die Boosts für die verschiedenen IO Arten aufgelistet waren. Kann die Liste aber gerade nicht finden...

ps: Das komische ist auch, dass wir unter Windows XP noch kein so schlimmes Problem hatte. Dort hat zwar die GUI geruckelt, aber die Sound-Ausgabe war immer OK. Unter Windows 7 fängt jetzt sogar der Sound (DirectShow Video mit Sound das abgespielt wird) zu stottern an. Falls jemand dazu etwas anderes einfällt, wäre ich auch sehr interessiert. Also vielleicht gibt es da ja bekannte Unterschiede bei DirectShow zwischen Windows XP und Windows 7 - etwas in der Art.

Martin Richter

Solch eine Tabelle kenne ich aktuell nichht.

Aber anders: Der SQL Server ist u.U. ein ganz mieses Stück...

Es gibt bestimmte Queries, die der SQL Server versucht zu optimieren und zwar durch Nutzung mehrerer Prozessoren/Threads. Dabei grabbscht er sich evtl. zu 100% die gesamte CPU Leistung. Nach meiner Erfahrung spielt hier die Priorisierung wenig, bis keine Rolle, weil der SQL server das irgendwie selber regelt. Wir haben für bestimmte SQL Queries Optionen eingebaut die den MAXDOP Hint verwenden.
Bei diesen Queries hat er sich "parallel zu Tode optimiert".

Dadurch haben wir das in den Griff bekommen.

Versuch mal zu analysieren, ob es bestimmte SQL Queires sind, und vor allem welche Art von Lock in diesem Moment im SQL Monitor sichtbar wird.

hustbaer

Martin Richter schrieb:

Aber anders: Der SQL Server ist u.U. ein ganz mieses Stück...

Ack

Martin Richter schrieb:

Nach meiner Erfahrung spielt hier die Priorisierung wenig, bis keine Rolle, weil der SQL server das irgendwie selber regelt.

Naja... bin mir ziemlich sicher dass es rein nur die Boosts sind.

Die Vordergrund-Anwendung ist ne D3D9 GUI die mit DirectShow Videos spielt. DirectShow verwendet für den Audio-Pump Thread Priority "above normal" (=base + 1). Was doof ist, ich aber nicht ändern kann.

Wenn ich jetzt die Vordergrund-Anwendung mit Priorität "normal" laufen lasse, und SQL Server auch mit "normal", also alles "ganz normal", dann ruckelt bei bestimmten Sachen die SQL Server verwenden (mehr dazu gleich) sofort die Audio Ausgabe (und das Video sowieso, das wäre aber nicht SO schlimm).
Wenn ich jetzt lediglich die dynamischen Boosts für SQL Server deaktiviere (SetProcessPriorityBoost), dann gibt's keine Audio-Aussetzer mehr. Die Videos und die GUI ruckeln nach wie vor, aber das ist nicht weiter verwunderlich (meine Threads mit "normal" + SQL Server Threads mit "normal" = die streiten sich um die CPU, und SQL Server hat einfach mehr Threads :D).

Daher behaupte ich mal: Das Problem kommt rein durch die dynamischen Boosts zustande. Und da wäre interessant ob sich zwischen Windows XP und Windows 7 'was geändert hat. Bzw. was die Boosts für Disk IO und Netzwerk IO (loopback Device) sind.

Martin Richter schrieb:

Wir haben für bestimmte SQL Queries Optionen eingebaut die den MAXDOP Hint verwenden.
Bei diesen Queries hat er sich "parallel zu Tode optimiert".

Dadurch haben wir das in den Griff bekommen.

Versuch mal zu analysieren, ob es bestimmte SQL Queires sind, und vor allem welche Art von Lock in diesem Moment im SQL Monitor sichtbar wird.

Ich weiss welche Queries betroffen sind. MAXDOP 1 ist da schon drinnen, eben damit die nicht zu wild reinhauen können.

Es scheint auch dass das Problem nicht die Query selbst ist, sondern dass wir sie in ADO als scrollbaren Cursor mit adAsyncFetchNonBlocking aufmachen und dann noch relativ oft den aktuellen "Count" pollen bzw. im Resultset rumscrollen.

Mit einem Testprogramm das die selbe Query über ADO .NET als Firehose Cursor aufmacht ('was anderes gibt's in ADO .NET ja nicht mehr) kann ich das Problem nämlich *nicht* triggern. Selbst wenn ich die Query in 10 Threads (jeder mit eigener Connection) gleichzeitig ausführen lasse.

hustbaer

ps: Daraus ergibt sich für mich jetzt auch die Frage...

Was wäre eher schlau, SQL Server mit Priority Class "below normal" laufen lassen, oder per SetProcessPriorityBoost das dynamische Boosten von Threads in SQL Server ausschalten (und die Priority Class dafür auf "normal" lassen)?

Martin Richter

Kann ich schwer was dazu raten...

Schlau wäre es einen Case by MS aufzumachen und das mit denen zu diskutieren...

In der SQL Produktgruppe hat das meisten funktioniert... ich sage meistens... es dauert leider immer eine bis man einen kompetenten Supporter erwischt. Aber so was ist ja nicht nur bei MS so. SO was haben wir sogar in unserer eigenen Firma

hustbaer

Ui, für sowas ham wir kein Geld zu verschenken...
Und dass MS das gratis macht kann ich mir net vorstellen.

Is aber eh egal, weil so lange kann ich net warten. Ich bau das jetzt mal so ein dass ich die Priorität auf below normal runterschraube. Denke das wird schon passen.

Martin Richter

Habt ihr kein MSDN ABO, oder seid Ihr keine MS-Partner. Selbst mit dem kleinsten Partner Level und MSDN Abo hat man mindestens 2 Anfragen frei!"

hustbaer

Ob wir Partner sind weiss ich nicht.
Bei meiner MSDN Subscription war IIRC allerdings nur 1 Incident dabei, und den hab ich schon weggelutscht

Martin Richter

OK. Früher waren es zwei...
Aber wenn Ihr ein MSDN Abo habt seid ihr vermutlich keine Partner. Das wäre doppelt gemoppelt oder rausgeschmissenes Geld.

Müsst Ihr Euch mal in Zukunft überlegen. Die Partnerschaft kostet zwar was, aber damit ist als ISV ja auch ein MSDN Abo Plus Supportleistungen drin. IMHO könnte das "lohnender" sein... dann spart man sich das MSDN Abo...