CPU Management - og hvorfor skal du ikke

[professor green]

Der er kun to Windows-kontroller til rådighed for brugeren, der påvirker applikations-CPU-ydeevne, basisprioritet og CPU-affinitet, og ved at bruge en af dem er det mere sandsynligt, at resultaterne bliver værre snarere end bedre. Det er overraskende let med disse kontroller for at gøre hele dit system trægt og endda hænge og tvinger en genstart. Hvor disse kontroller er moderat nyttige, er der fejlfinding i CPU-ydeevnen, hvor de kan hjælpe med at identificere, hvilken applikation der forårsager CPU-ydeevneproblemer. Af denne grund alene er det værd at forstå, hvad disse kontroller gør, og hvordan de bedst kan bruges.





Processer og tråde



Vi tror, når det gælder applikationer, starter vi Chrome-browseren for eksempel og tænker på det som en applikation, men internt er det lidt mere komplekst end det. Applikationer administreres i Windows som en eller flere processer, og inden for hver proces styres den udførende kode af en eller flere tråde.



Den grundlæggende arbejdsgruppe i Windows kaldes en proces. En proces indeholder alle de ressourcer, der er nødvendige for, at en applikation kan fungere, hver proces får sit eget virtuelle adresserum til f.eks. Hvis du åbner Task Manager og klikker på fanen Detaljer, vil hver indgang du ser, der er en individuel proces. Nogle applikationer (Notesblok for eksempel) kører som en enkelt proces, men andre programmer (f.eks. Chrome) kører som flere processer.



Inden for hver proces kaldes de enkelte arbejdsgrupper tråde. På skærmen Opgavemanagerdetaljer skal du højreklikke overalt på overskriftsrækken og klikke på 'Vælg kolonner'. I den dialog, der åbnes, rul ned og markér afkrydsningsfeltet Tråde, og klik derefter på OK. I denne kolonne kan du se antallet af tråde inden for hver proces. Et par processer har kun én tråd - hvis du har Java installeret på din pc, så har du Java Update Scheduler-processen kørende, den hedder jusched.exe, den har kun en enkelt tråd (den hedder en enkelt-trådet proces). Start nu Notepad (siden Opgavemanagerdetaljer opdateres selv om et par sekunder) og ser på trådtællingen for notepad.exe, der er mange tråde i notepad.exe (dette kaldes en multi-threaded-proces).



Hvad der udføres på en CPU er tråde, så en multi-threaded proces kunne have flere af dens tråde udfører på samme tid på forskellige CPU'er.



Du kan finde ud af, hvor mange CPU'er du har ved at indtaste 'msinfo32' i kommandoen Kør, dette viser panelet System Information. Sørg for, at systemoversigten er valgt (det er standard). Kig ned kolonnen Vare i højre rude, indtil du finder Processor-indtastningen. Det fortæller dig, hvilken CPU chip du har, og hvor mange kerner det har, hver kerne er en separat CPU. Hvis din processor understøtter hyperthreading, som internt ser ud til at køre to tråde på hver kerne på samme tid, er der to logiske processorer pr. Kerne, så en fire-core processor har otte logiske processorer. Windows bruger logiske processorer, så på en fire core hyperthreading processor Windows vil se otte separate CPU'er og vil køre otte tråde samtidigt, en på hver logisk processor. Hvis din processor ikke understøtter hyperthreading, er antallet af kerner antallet af CPU'er, som Windows vil se.



På fanen Opgavemanager Detaljer kigger du på Status kolonnen, tæller op, hvor mange processer der har status. Kører på dit system, der er sandsynligvis godt over 100. Selvom vi antager, at hver proces kun har én aktiv tråd (og de fleste processer vil har mere end det) Det er klart, at vi har langt mere aktive tråde end vi har CPU'er. Hvordan kan de alle løbe?

Dispatching threads

 

[professor green]

A thread exists in one of three states (there are others but they're not important here.



1. Executing - the thread is executing instructions on a CPU right now

2. Ready - the thread can execute when a CPU becomes available, but it is currently in a queue

3. Waiting - the thread is waiting for some external event to complete



På siden Opgavehåndtering Detaljer, som vi nævnte ovenfor, har alle de processer med status Running mindst en tråd, der er i en af disse stater. Det betyder, at processen gør arbejde, men ikke nødvendigvis udfører på en CPU lige nu.



Windows-komponenten, der bestemmer hvilken tråd der skal køre, hvilken CPU (og hvornår) kaldes Dispatcher. Dispatcheren er kun interesseret i tråde, der udfører eller Klar, en tråd, der venter, er usynlig for Dispatcheren.



Når en tråd bevæger sig fra Ventertilstand til Klar tilstand, placeres den i en kø kaldet Klar køen, der er en Klar Kø per logisk processor (eller pr. Kerne, hvis din processor ikke understøtter hyperthreading). Dispatcheren vil normalt vælge tråden øverst i Klar køen for at køre på den næste processor, så en tråds position på Klar køen er kritisk for dens ydeevne. Tråd er køet baseret på deres prioritet.





Tråd prioritet



Hver tråd har en prioritet fra 0 til 31 (hvor 31 er højest), den består af to komponenter; baseprioriteten og den relative prioritet.



En tråds basisprioritet er arvet fra processen; Hver proces har en basisprioritet, som kaldes Real-Time, High, Over Normal, Normal, Under Normal eller Low - disse navne svarer til et tal (højere tal betyder højere prioritet). Hver tråd i en proces bruger således samme basisprioritet, dette tildeles af udvikleren baseret på den relative betydning af denne proces i hele systemet.



Hver tråd har også en relativ prioritet inden for sin proces. Disse tildeles af bygherren for at fastlægge de relative prioriteter for de forskellige tråde i processen, hvilket er afgørende for korrekt drift af processen, så kun udvikleren kan ændre disse. Disse har lignende navne til basisprioriteten, men de svarer til forskellige tal, nogle af dem negative tal.

Den relative prioritet tilføjes til (eller trækkes fra) basisprioriteten og derefter afkortes for at give den faktiske trådprioritet, der bruges til at bestille tråde på de færdige køer. For at give dig en fornemmelse for, hvordan baseprioriteten og den relative prioritet kombineres for at producere den aktuelle prioritet for en tråd, skaber de forskellige basisprioriteter de egentlige prioriteter i disse intervaller.



Lavt - 1 til 15 men skævt i den lave ende, for det meste omkring 1 til 6.

Under Normal - 1 til 15 men skævt tæt på den nedre ende, for det meste omkring 4 til 8.

Normal - 1 til 15 men skævt i midten, for det meste omkring 6 til 10.

Over Normal - 1 til 15 men skævt tæt på den øvre ende, for det meste omkring 8 til 12.

Høj - 1 til 15 men skævt i øverste ende, for det meste 11 til 15.

Real-Time - 16 til 31, men skævt i midten, for det meste 22 til 26.



Herfra kan du se, at det er helt muligt for en tråd i en proces med Normal basisprioritet for at ende med en faktisk prioritet, der er højere end en tråd i en proces med prioritet for ovenstående Normal. Du kan også se, at realtidsbaseprioriteten altid producerer en faktisk prioritet, som er højere end nogen af de andre basisprioritet



Du kan ændre basisprioriteten i en proces, men i den forbindelse ændrer du prioriteten for hver tråd i den proces. Ud fra ovenstående kan du se, at dette kan give nogle utilsigtede konsekvenser for andre tråde i andre processer. Forhøjelse af en proces til realtidsbaseprioriteten vil højst sandsynligt få meget alvorlige (og sandsynligvis dødelige) konsekvenser for andre processer i systemet, især systemprocesser. Glem ikke, at du ikke har nogen ide om den relative prioritet af tråde inden for en proces, så du har ingen anelse om den aktuelle prioritet, som hver tråd i en proces vil få, når du ændrer procesens basisprioritet.



Åbn task manager og klik på fanen Detaljer, hvis kolonnen der er mærket Baseprioritet, ikke er synlig, skal du højreklikke overalt på overskriftslinjen, klikke på 'Vælg kolonner', rul ned og markere feltet, der er mærket Baseprioritet. I denne kolonne kan du se Baseprioritet tildelt til de fleste (nogle Systemprocesser kører med en fast prioritet på 31 og vises som Ikke tilgængelig i denne kolonne). Klik på kolonneoverskrift for basisprioritet for at sortere processerne baseret på denne kolonne, og du vil se, at du sandsynligvis har et par højprioriteringsprocesser, en stor masse normale prioriteringsprocesser og muligvis et par nedenfor under normale og måske en eller to små prioriteter processer.



Ændring af basisprioritet



For at se, hvordan baseprioriteten i en proces kan ændres, start Notepad og vente på siden Opgavemanagerdetaljer for at opdatere. Basisprioritet for notesblok er Normal, for at ændre det højreklik på notepad.exe og vælg Sæt prioritet, fra flyt-ud-listen vælg Under Normal og bekræft ændringen i advarselsdialogboksen, der vises. På siden Opgavestyringsdetaljer kan du se, at grundprioriteten for notepad.exe er ændret til Under Normal, så alle trådene i Notesblok nu køer ned på Klar køer på alle CPU'er, fordi deres aktuelle prioritet nu er lavere. De vil således få udført på CPU'er meget mindre ofte.



Du kan prøve at bruge Notesblok nu med dens under normale baseprioritet, men hvis du har ledige logiske processorer i dit system, kan du ikke se nogen forskel. Trådprioritet bliver kun vigtig, når der er mere arbejde end CPU'erne kan klare. Vi opretter senere en demonstration, der giver dig mulighed for at se trådprioritet i aktion.



Bemærk, at denne basisprioritetsændring kun varer, mens processen er aktiv. Hvis du lukker Notesblok og derefter starter det igen, vil du se det begynder med den normale basisprioritet (fordi den oprindelige basisprioritet er angivet af udvikleren i programmet

 

[professor green]

Skal du ændre basisprioriteten i en proces? Jeg håber dit svar er nok ikke. Du bør helt sikkert aldrig ændre basisprioriteten opad uden omhyggelig overvejelse af de mulige konsekvenser og være forberedt på nogle uventede konsekvenser også. Aldrig nogensinde overveje at hæve en basisprioritet til Real-Time, det vil påvirke systemprocesserne, i bedste fald vil du gøre dit system meget trægt, i værste fald vil det hænge.

Ændring af basisprioriteten nedad kan imidlertid nogle gange være et nyttigt ydelseshjælpemiddel. Antag at du har en multi-threaded CPU hog applikation kører for eksempel, en der bruger masser af CPU cykler på alle dine CPU'er, det vil gøre resten af dit system meget træg. Hvis du ændrer baseprioriteten til CPU hog-processen nedad med et niveau (så fra Normal til Under Normal for eksempel), fortsætter programmet, men det vil nu gå på alle CPU Ready Queues under dine andre processer, hvilket vil genoprette lydhørhed i dit system. Selvfølgelig vil CPU hog ansøgningen nu tage meget længere tid at fuldføre.



Ovennævnte teknik kan også bruges til fejlfinding af CPU-ydeevne ved at reducere basisprioriteten i processer (ikke-system), hvor du hurtigt kan finde ud af, hvilken proces der bidrager til dit CPU-problem uden at skulle dræbe processer.



Lad dig ikke fristes til at øge basisprioriteten i en proces for at forbedre dens ydeevne, selvom CPU'en er flaskehalsen. De utilsigtede konsekvenser kan være dystre. Enten overveje at reducere baseprioriteten i konkurrerende processer eller, endnu bedre, reducere arbejdsmængden i systemet ved at lukke unødvendige applikationer.

Før vi ser på, hvordan vi gør det, lad os tale om hvorfor du vil gerne gøre det. Dispatcheren er langt bedre at vælge, hvilken processor der skal bruges, end du er, så selv om der er en lille ydelsesfordel ved at bruge samme processor til en tråd, er det ikke en god grund til at bruge CPU Affinity. En multi-threaded proces med tråde, som udvikleren forventer at køre samtidigt på mange processorer, kan muligvis ikke køre meget godt, hvis du begrænser det til en eller to.



Den eneste gyldige præstationsårsag til indstilling af CPU Affinity er i det usandsynlige tilfælde, at du har en applikation, der ikke er multiprocessorbevidst og skal køre alle dens tråde på en enkelt CPU. I dag er disse former for anvendelse så sjældne som høns tænder.



En anden potentiel grund til at indstille CPU Affinity kan være i et CPU fejlfinding scenario. Antag at du har en proces, der synes at løbe væk med CPU-cyklusser på tværs af alle logiske processorer, og begrænser det til en enkelt processor med CPU Affinity vil isolere problemet til den CPU, så resten af systemet kan køre på de andre processorer. Du kan derefter beslutte, om du vil sænke de processer, som er basisprioritet, og fjerne CPU Affinity eller lade det fuldføre på den ene processor.



Bemærk, at når du indstiller CPU Affinity til en proces, kan tråden i den proces kun køre på denne processor (eller processorer), men det betyder ikke, at det er den eneste proces, der kører på den eller de pågældende processorer. Dispatcheren planlægger stadig andre tråde til at køre på samme processor (r). Der er ingen mekanisme, der giver dig mulighed for at angive eksklusiv CPU Affinity.



For at ændre CPU Affinity skal du åbne task manager på fanen Detaljer, højreklikke på processen og vælge Set Affinity. I dialogboksen, der åbner fjerner du markeringen af CPU'er for at forlade kun den ønskede CPU (er), og klik på OK.

Bemærk, at CPU Affinity varer kun, mens processen er aktiv. Hvis du stopper og genstarter processen, vil CPU Affinity gå tabt.



For at se dette i aktion har vi brug for en temmelig CPU-intensiv applikation. De fleste af os kører Malwarebyte's on-demand anti-virus scanner, og dette er en stor CPU-bruger. Hvis du ikke har Malwarebytes scanner, er det måske en god tid at downloade det?



Start Malwarebytes scanner og konfigurer den for at scanne alle dine diske. Når det først er startet, åbnes siden Opgavemanagerdetaljer, vil du se, at processen MBAMService.exe bruger mange CPU-cyklusser. Klik nu på fanen Ydeevne, CPU-sektion, og vis graferne for hver logisk processor (hvis du har en enkelt samlet graf, højreklik på enkeltgrafen og vælg Skift graf til og vælg logiske processorer). Du kan se høj CPU-brug på tværs af alle CPU'er.



Gå nu tilbage til fanen Detaljer, højreklik på MBAMService.exe-processen og indstil CPU Affinity til en enkelt logisk processor - det er klogt at ikke vælge CPU 0, fordi nogle systemtråde foretrækker CPU 0, så vælg en enkelt CPU-enhed end 0.



Hvis du nu går tilbage til fanen Processor, kan du se, at kun den logiske processor, du valgte, nu bruger mange CPU-cyklusser, de andre er relativt inaktiv. Dette skyldes, at MBAMService.exe kører kun på den proces



Demonstrere virkningen af ændringer i baseprioritet



Vi kan bruge Malwarebytes scanner og CPU Affinity til at demonstrere, hvordan baseprioriteten påvirker applikationsydelsen. Hvis du har færre end fire logiske processorer i dit system (eller fire fysiske kerner, hvis din processor ikke understøtter hyperthreading), foreslår jeg, at du ikke forsøger denne demonstration, det kan have alvorlig indvirkning på din generelle systemydelse.



Med Malwarebyte scanneren kører på kun en enkelt CPU, skal du starte Notepad. På fanen Opgavehåndtering Detaljer indstiller CPU Affinity for notepad.exe til den samme processor som MBAMService.exe. Prøv nu at åbne et eksisterende tekstdokument med Notesblok, du kan måske finde det lidt mindre responsivt end normalt, men sandsynligvis ikke så meget. Dette skyldes, at både MBAMService.exe og notepad.exe deler samme basisprioritet (Normal), så den aktuelle prioritet for deres respektive tråde er sandsynligvis meget ens (vi kan ikke vide det sikkert), så de køer tæt sammen på Ready Queue.



Nu ændrer du grundprioritering for notepad.exe til Under Normal, og prøv derefter at åbne et eksisterende tekstdokument med Notesblok igen. Du vil opdage, at Notesblok nu er meget træg og ret vanskeligt at bruge. Dette skyldes, at de fleste MBAMService.exe-tråde køber sig over notepad.exe, hvilket resulterer i meget ringe Notepad-ydeevne.



Prøv nu at bytte basisprioriteterne over, lav notepad.exe Normal og MBAMService.exe under Normal. Du bør opdage, at Notesblok opfører sig ganske normalt nu, det skyldes, at MBAMService.exe tråde bliver køet bag notepad.exe tråde.



Fordi både baseprioritet og CPU-affinitet varer kun for procesens levetid, er der ikke behov for at ændre dem tilbage (medmindre du vil). Du skal blot lukke Malwarebytes ansøgning (via ikonet i systembakken) og lukke Notesblok og de ændringer, du lige har foretaget, vil gå tabt.