{"id":32730,"date":"2019-10-31T21:48:36","date_gmt":"2019-10-31T18:48:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod\/"},"modified":"2021-02-08T11:40:35","modified_gmt":"2021-02-08T09:40:35","slug":"operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod","title":{"rendered":"Operativsystemer: Tre Enkle Deler. Del 5: Planlegging: Multi-Level Feedback Queue (oversettelse)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h1>Innledning til operativsystemer<\/h1>\n<p>Hei, Habr! Jeg \u00f8nsker \u00e5 presentere for deg en serie med oversatte artikler fra en litteratur som jeg synes er interessant \u2014 OSTEP. I dette materialet blir arbeidet til UNIX-lignende operativsystemer behandlet temmelig grundig, nemlig arbeidet med prosesser, forskjellige planleggere, minne og andre lignende komponenter som utgj\u00f8r et moderne OS. Den originale teksten til alt materialet kan du se her <noindex><a rel=\"nofollow\" href=\"http:\/\/pages.cs.wisc.edu\/~remzi\/OSTEP\/\">here<\/a><\/noindex>. Vennligst merk at oversettelsen er gjort uprofesjonelt (temmelig fritt), men jeg h\u00e5per jeg har bevart den generelle meningen.<\/p>\n<p>Laboratoriearbeid knyttet til emnet kan finnes her:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"http:\/\/pages.cs.wisc.edu\/~remzi\/OSTEP\/Homework\/homework.html\">originalen<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/remzi-arpacidusseau\/ostep-code\">originalen<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/bykvaadm\/OS\/tree\/master\/ostep\">min personlige tilpasning<\/a><\/noindex><\/li>\n<\/ul>\n<p>Andre deler:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/446340\/\">Del 1: Introduksjon<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/446866\/\">Del 2: Abstraksjon: prosess<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/447182\/\">Del 3: Innf\u00f8ring i prosess-API<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/449026\/\">Del 4: Innf\u00f8ring i planlegger<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/450116\/\">Del 5: MLFQ-planleggeren<\/a><\/noindex><\/li>\n<\/ul>\n<p>Og du kan ogs\u00e5 sjekke kanalen min p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/bykvaadm\">telegram<\/a><\/noindex> =)<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Planlegging: Multi-Level Feedback Queue<\/h2>\n<p>I denne forelesningen skal vi snakke om problemene med \u00e5 utvikle en av de mest kjente tiln\u00e6rmingene til<br \/>\nplanlegging, som kalles <b>Multi-Level Feedback Queue<\/b> (MLFQ). Den f\u00f8rste beskrivelsen av MLFQ-planleggeren ble gitt i 1962 av Fernando J. Corbat\u00f3 i et system kalt<br \/>\nCompatible Time-Sharing System (CTSS). Disse arbeidene (inkludert senere arbeider om<br \/>\nMultics) ble senere nominert til Turing Award. Planleggeren ble<br \/>\nsenere forbedret og fikk en form som kan sees i<br \/>\nnoen moderne systemer.<\/p>\n<p>MLFQ-algoritmen pr\u00f8ver \u00e5 l\u00f8se to grunnleggende overlappende problemer.<br \/>\n<b>For det f\u00f8rste<\/b>, den pr\u00f8ver \u00e5 optimalisere omdreiningstiden, som, som vi s\u00e5 i forrige forelesning, optimaliseres ved \u00e5 kj\u00f8re de mest<br \/>\nkorte oppgavene f\u00f8rst i k\u00f8en. Imidlertid vet ikke operativsystemet hvor lenge en bestemt prosess vil kj\u00f8re, og dette<br \/>\ner n\u00f8dvendig kunnskap for SJF- og STCF-algoritmene. <b>For det andre<\/b>, MLFQ pr\u00f8ver<br \/>\n\u00e5 gj\u00f8re systemet responsivt for brukerne (for eksempel de som sitter og<br \/>\nstirrer p\u00e5 skjermen i p\u00e5vente av at oppgaven skal fullf\u00f8res) og dermed minimere tiden<br \/>\nfor respons. Dessverre reduserer algoritmer som RR responstid, men har en sv\u00e6rt<br \/>\nd\u00e5rlig effekt p\u00e5 omdreiningstid-metrikken. Her er v\u00e5rt problem: Hvordan designe<br \/>\nen planlegger som vil m\u00f8te v\u00e5re krav og samtidig ikke vite noe om<br \/>\nkarakteren til prosessen, generelt? Hvordan kan planleggeren l\u00e6re karakteristikkene til oppgavene,<br \/>\nsom den kj\u00f8rer og dermed ta bedre avgj\u00f8relser om planlegging?<\/p>\n<p><u>Essensen av problemet: Hvordan planlegge oppgaveinnsetting uten perfekt kunnskap?<br \/>\nHvordan utvikle en planlegger som b\u00e5de minimerer responstiden<br \/>\nfor interaktive oppgaver og samtidig minimerer omdreiningstiden uten forh\u00e5nds<br \/>\nkunnskap om oppgavens kj\u00f8retid?<\/u><\/p>\n<p>Merk: L\u00e6rer av tidligere hendelser<\/p>\n<p>MLFQ-k\u00f8en er et utmerket eksempel p\u00e5 et system som l\u00e6rer av<br \/>\ntidligere hendelser for \u00e5 forutsi fremtiden. Slike tiln\u00e6rminger finnes ofte<br \/>\ni operativsystemer (og mange andre omr\u00e5der i datavitenskap, inkludert grener av<br \/>\nprediksjon innen maskinvare og cache-algoritmer). Slike tiln\u00e6rminger<br \/>\ner effektive n\u00e5r oppgavene har atferdsfaser og dermed er forutsigbare.<br \/>\nMen med slik teknologi m\u00e5 man v\u00e6re forsiktig, fordi prediksjonene lett<br \/>\nkan vise seg \u00e5 v\u00e6re feil og f\u00f8re systemet til \u00e5 ta d\u00e5rligere beslutninger enn<br \/>\ndet ville v\u00e6rt uten noen kunnskap i det hele tatt.<\/p>\n<h3>MLFQ: Grunnleggende Regler<\/h3>\n<p>La oss se p\u00e5 de grunnleggende reglene for MLFQ-algoritmen. Og selv om det finnes flere<br \/>\nimplementeringer av denne algoritmen, er de grunnleggende tiln\u00e6rmingene like.<br \/>\nI den implementeringen vi skal se p\u00e5, vil MLFQ ha flere<br \/>\nseparate k\u00f8er, hver med ulik prioritet. Til enhver tid,<br \/>\nvil oppgaven som er klar til \u00e5 kj\u00f8re befinne seg i en av k\u00f8ene. MLFQ bruker prioriteringer<br \/>\nfor \u00e5 avgj\u00f8re hvilken oppgave som skal kj\u00f8res, det vil si at oppgaven med h\u00f8yere<br \/>\nprioritet (oppgaven fra k\u00f8en med h\u00f8yest prioritet) vil bli kj\u00f8rt f\u00f8rst.<br \/>\nUten tvil kan det v\u00e6re mer enn \u00e9n oppgave i en bestemt k\u00f8, slik<br \/>\nat de vil ha lik prioritet. I s\u00e5 fall vil RR-mekanismen<br \/>\nbli brukt for \u00e5 planlegge kj\u00f8ring blant disse oppgavene.<br \/>\nDermed kommer vi til to grunnleggende regler for MLFQ:<br \/>\nRegel 1: Hvis prioritet(A) &gt; Prioritet(B), vil oppgave A bli kj\u00f8rt (B vil ikke)<\/p>\n<ul>\n<li> Regel 2: Hvis prioritet(A) = Prioritet(B), A og B kj\u00f8res ved bruk av RR<\/li>\n<li> Basert p\u00e5 det ovenst\u00e5ende, er n\u00f8kkelkomponentene for MLFQ-planlegging<\/li>\n<\/ul>\n<p>prioriteringer. I stedet for \u00e5 gi en fast prioritet til hver<br \/>\noppgave, endrer MLFQ prioriteten avhengig av oppf\u00f8rt atferd.<br \/>\nFor eksempel, hvis en oppgave kontinuerlig gir fra seg arbeid til CPU mens den venter p\u00e5 input fra tastaturet,<br \/>\nvil MLFQ holde prosessens prioritet p\u00e5 et h\u00f8yt niv\u00e5, fordi det er slik<br \/>\nen interaktiv prosess skal fungere. Hvis derimot oppgaven stadig og<br \/>\nintensivt bruker CPU-en over lang tid, vil MLFQ senke dens<br \/>\nprioritet. Dermed vil MLFQ l\u00e6re oppf\u00f8rselen til prosessene mens de arbeider<br \/>\nog bruke denne oppf\u00f8rselen.<br \/>\nLa oss tegne et eksempel p\u00e5 hvordan k\u00f8ene kunne sett ut p\u00e5 et gitt<br \/>\ntidspunkt, og det ville se noe slik ut:<br \/>\nI dette skjemaet er to prosesser A og B i k\u00f8en med h\u00f8yest prioritet. Prosess<br \/>\n<img decoding=\"async\" alt=\"Operativsystemer: Tre Enkle Deler. Del 5: Planlegging: Multi-Level Feedback Queue (oversettelse)\" src=\"\/wp-content\/uploads\/2019\/04\/3598e9ca43a56049625bdcf3074de472.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>C er et sted i midten, og prosess D er p\u00e5 bunnen av k\u00f8en. I henhold til beskrivelsene ovenfor<br \/>\nvil MLFQ-planleggeren bare utf\u00f8re oppgaver med h\u00f8yest prioritet.<br \/>\nmed beskrivingene av MLFQ-algoritmen vil planleggeren utf\u00f8re oppgaver bare med den h\u00f8yeste prioriteten<br \/>\nprioritetet i henhold til RR, mens oppgavene C og D ikke vil bli prioritert.<br \/>\nSelvf\u00f8lgelig vil et statisk \u00f8yeblikksbilde ikke gi et fullstendig bilde av hvordan MLFQ fungerer.<br \/>\nDet er viktig \u00e5 forst\u00e5 hvordan bildet endres over tid.<\/p>\n<h4>Fors\u00f8k 1: Hvordan endre prioritet<\/h4>\n<p>P\u00e5 dette tidspunktet er det n\u00f8dvendig \u00e5 avgj\u00f8re hvordan MLFQ vil endre prioriteringsniv\u00e5et<br \/>\nfor oppgaver (og dermed plasseringen av oppgaven i k\u00f8en) gjennom dens livssyklus. For<br \/>\ndette m\u00e5 man ha arbeidsflyten i bakhodet: et visst antall<br \/>\ninteraktive oppgaver med kort arbeidstid (og dermed hyppig frigj\u00f8ring av<br \/>\nCPU) og noen f\u00e5 lange oppgaver som bruker CPU hele sin arbeidstid, der<br \/>\nrespons tiden for slike oppgaver ikke er viktig. Dermed kan man gj\u00f8re et f\u00f8rste fors\u00f8k p\u00e5<br \/>\n\u00e5 implementere MLFQ-algoritmen med f\u00f8lgende regler:<\/p>\n<ul>\n<li> Rule3: N\u00e5r en oppgave kommer inn i systemet, plasseres den i k\u00f8en med h\u00f8yest<\/li>\n<li>prioritet.<\/li>\n<li>Rule4a: Hvis oppgaven bruker hele sitt tildelte tidsvindu, reduseres dens<\/li>\n<li>prioritet.<\/li>\n<li>Rule4b: Hvis oppgaven frigj\u00f8r CPU f\u00f8r tidsvinduet er utl\u00f8pt,<\/li>\n<li>forblir den med sin opprinnelige prioritet.<\/li>\n<\/ul>\n<p><b>Eksempel 1: En enkelt langvarig oppgave<\/b><\/p>\n<p>Som vist i dette eksempelet, blir oppgaven plassert med h\u00f8yest<br \/>\nprioritet n\u00e5r den kommer inn. Etter et tidsvindu p\u00e5 10 ms reduseres prosessen i prioritet<br \/>\nav planleggeren. Etter det neste tidsvinduet blir oppgaven endelig redusert til<br \/>\nden laveste prioriteten i systemet, der den blir v\u00e6rende.<br \/>\n<img decoding=\"async\" alt=\"Operativsystemer: Tre Enkle Deler. Del 5: Planlegging: Multi-Level Feedback Queue (oversettelse)\" src=\"\/wp-content\/uploads\/2019\/04\/9b4ee6de03aa92d7957d50b4ffa73949.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p><b>Eksempel 2: Ankomst av en kort oppgave<\/b><\/p>\n<p>N\u00e5 skal vi se et eksempel p\u00e5 hvordan MLFQ vil fors\u00f8ke \u00e5 n\u00e6rme seg SJF. I dette<br \/>\neksempelet er det to oppgaver: A, som er en langvarig oppgave som kontinuerlig<br \/>\nopptar CPU, og B, som er en kort interaktiv oppgave. Anta at<br \/>\nA allerede har v\u00e6rt i gang en stund da oppgaven B kommer inn.<br \/>\n<img decoding=\"async\" alt=\"Operativsystemer: Tre Enkle Deler. Del 5: Planlegging: Multi-Level Feedback Queue (oversettelse)\" src=\"\/wp-content\/uploads\/2019\/04\/19c299b0519585fd1076a341a71f048b.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>I denne grafen vises resultatene av scenariet. Oppgave A, som enhver oppgave,<br \/>\nsom bruker CPU, havnet p\u00e5 bunnen. Oppgave B ankommer ved tid T=100 og vil<br \/>\nbli plassert i k\u00f8en med h\u00f8yest prioritet. Siden den bruker mindre tid, vil<br \/>\nden fullf\u00f8re f\u00f8r den n\u00e5r den siste k\u00f8en.<\/p>\n<p>Fra dette eksempelet er hovedm\u00e5let med algoritmen tydelig: siden algoritmen ikke<br \/>\nkan vite om en oppgave er lang eller kort, antar den f\u00f8rst at oppgaven<br \/>\nkort og gir den h\u00f8yeste prioritet. Hvis dette virkelig er en kort oppgave, s\u00e5<br \/>\nvil den bli utf\u00f8rt raskt, ellers, hvis det er en lang oppgave, vil den bevege seg sakte<br \/>\ni prioritet nedover og snart bevise at det faktisk er en lang oppgave som ikke<br \/>\nkrever respons.<\/p>\n<p><b>Eksempel 3: Hva med inngang-og-utgang?<\/b><\/p>\n<p>La oss n\u00e5 se p\u00e5 et eksempel med inngang-og-utgang. Som p\u00e5pekt i regel 4b,<br \/>\nhvis prosessen frigj\u00f8r prosessoren uten \u00e5 bruke hele prosessortiden sin,<br \/>\nvil den forbli p\u00e5 samme priortet niv\u00e5. Intensjonen med denne regelen er ganske enkel<br \/>\n\u2014 hvis en interaktiv oppgave utf\u00f8rer mange inngang-og-utgang operasjoner, for eksempel, venter<br \/>\np\u00e5 brukerens tastetrykk eller museklikk, vil en slik oppgave frigj\u00f8re prosessoren<br \/>\nf\u00f8r den tildelte tidsvinduet. Vi ville ikke \u00f8nske \u00e5 senke prioriteten til en slik oppgave,<br \/>\nog dermed vil den forbli p\u00e5 samme niv\u00e5.<br \/>\n<img decoding=\"async\" alt=\"Operativsystemer: Tre Enkle Deler. Del 5: Planlegging: Multi-Level Feedback Queue (oversettelse)\" src=\"\/wp-content\/uploads\/2019\/04\/480d33a670fb62a639e5938dd59e30a1.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Dette eksemplet viser hvordan algoritmen vil fungere med slike prosesser \u2014 interaktiv oppgave B, som bare trenger CPU i 1 ms f\u00f8r den utf\u00f8rer<br \/>\ninngang-og-utgang prosessen, og den lange oppgaven A, som bruker all sin tid p\u00e5 CPU.<br \/>\nMLFQ holder oppgave B med h\u00f8yest prioritet, siden den stadig frigj\u00f8r<br \/>\nCPU. Hvis B er en interaktiv oppgave, s\u00e5 har algoritmen i s\u00e5 fall oppn\u00e5dd<br \/>\nsitt m\u00e5l om \u00e5 kj\u00f8re interaktive oppgaver raskt.<\/p>\n<p><b>Problemer med den n\u00e5v\u00e6rende MLFQ algoritmen<\/b><\/p>\n<p>I de tidligere eksemplene har vi bygget en grunnleggende variant av MLFQ. Og det ser ut til at den<br \/>\ngj\u00f8r jobben sin godt og rettferdig, fordeler prosessortiden rettferdig mellom<br \/>\nlange oppgaver og lar korte oppgaver eller oppgaver som hyppig bruker<br \/>\ninngang-og-utgang bli behandlet raskt. Dessverre inneholder denne tiln\u00e6rmingen flere<br \/>\nalvorlige problemer.<br \/>\n<b>For det f\u00f8rste<\/b>, sultproblemet: hvis systemet har mange interaktive<br \/>\noppgaver, vil de konsumere all prosessortid, og dermed vil ingen lange<br \/>\noppgaver f\u00e5 muligheten til \u00e5 kj\u00f8re (de sulter).<\/p>\n<p><b>For det andre<\/b>, smarte brukere kan skrive programmene sine slik at de<br \/>\nlurer planleggeren. L\u00f8ven ligger i \u00e5 gj\u00f8re noe som tvinger<br \/>\nplanleggeren til \u00e5 gi prosessen mer prosessortid. Algoritmen som<br \/>\nbeskrevet ovenfor er helt s\u00e5rbar for slike angrep: f\u00f8r tiden nesten<br \/>\ng\u00e5r ut, m\u00e5 en inn- og utgangsoperasjon (til en eller annen, uansett hvilken fil)<br \/>\nutf\u00f8res,<br \/>\nog slik frigj\u00f8r CPU-en. Denne oppf\u00f8rselen vil tillate \u00e5 forbli i den samme<br \/>\nk\u00f8en og igjen f\u00e5 en st\u00f8rre del av prosessorens tid. Hvis man gj\u00f8r<br \/>\ndette riktig (for eksempel, kj\u00f8re 99% av tiden f\u00f8r man frigj\u00f8r CPU-en),<\/p>\n<p>kan en slik oppgave rett og slett monopoliserer prosessoren.<br \/>\nTil slutt kan programmet endre oppf\u00f8rselen sin over tid. De oppgavene,<br \/>\nsom brukte CPU-en, kan bli interaktive. I v\u00e5rt eksempel vil slike<br \/>\noppgaver ikke f\u00e5 tilstrekkelig behandling fra planleggeren, s\u00e5 de ville f\u00e5tt en annen<\/p>\n<p><u>(opprinnelige) interaktive oppgaver.<br \/>\n<\/u><\/p>\n<h4>Sp\u00f8rsm\u00e5l til salen: hvilke angrep p\u00e5 planleggeren kunne v\u00e6rt gjennomf\u00f8rt i dagens verden?<\/h4>\n<p>Fors\u00f8k 2: Heve prioriteten<br \/>\nLa oss pr\u00f8ve \u00e5 endre reglene og se om vi kan unng\u00e5 problemer med<br \/>\nsulting. Hva kan vi gj\u00f8re for \u00e5 garantere at oppgaver relatert til<br \/>\nCPU f\u00e5r sin tid (selv om det ikke er lenge).<br \/>\nSom en enkel l\u00f8sning p\u00e5 problemet kan man foresl\u00e5 \u00e5 periodisk<br \/>\nheve prioriteten for alle slike oppgaver i systemet. Det finnes mange m\u00e5ter<br \/>\n\u00e5 oppn\u00e5 dette, la oss pr\u00f8ve \u00e5 implementere noe enkelt som et eksempel: \u00e5 omgj\u00f8re<\/p>\n<ul>\n<li><b>alle oppgaver til h\u00f8yest prioritert med en gang, her er den nye regelen:<\/b>Rule5<\/li>\n<\/ul>\n<p>: Etter en viss periode S, flytt alle oppgaver i systemet til den h\u00f8yeste k\u00f8en.<br \/>\nV\u00e5r nye regel l\u00f8ser to problemer samtidig. For det f\u00f8rste er prosesser<br \/>\ngarantert ikke sultne: oppgaver som er i den \u00f8verste k\u00f8en vil dele<br \/>\nprosessortid i henhold til RR-algoritmen, og p\u00e5 den m\u00e5ten vil alle prosesser f\u00e5<br \/>\nprosessortid. For det andre, hvis en prosess, som tidligere brukte<br \/>\nbare prosessoren, blir interaktiv, vil den forbli i k\u00f8en med h\u00f8yest<br \/>\nprioritet etter \u00e5 ha f\u00e5tt heve prioriteten til h\u00f8yest.<br \/>\n<img decoding=\"async\" alt=\"Operativsystemer: Tre Enkle Deler. Del 5: Planlegging: Multi-Level Feedback Queue (oversettelse)\" src=\"\/wp-content\/uploads\/2019\/04\/3b8d879ab4479622684b126ec5af6af3.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>CPU og to interaktive, korte prosesser. Til venstre p\u00e5 bildet vises oppf\u00f8rselen uten prioritetsh\u00f8yning, og dermed begynner den lange oppgaven \u00e5 sultne etter at to interaktive oppgaver ankommer systemet. Til h\u00f8yre vises det at hver 50 ms skjer prioritetsh\u00f8yning, og dermed f\u00e5r alle prosesser garantert prosessortid og vil kj\u00f8res periodisk. 50 ms er valgt som et eksempel, i virkeligheten er dette tallet noe h\u00f8yere.<br \/>\nDet er \u00e5penbart at tillegget av periodisk heving S f\u00f8rer til<br \/>\ndet naturlige sp\u00f8rsm\u00e5let: hvilket tall b\u00f8r settes? En av de anerkjente<br \/>\nsystemingeni\u00f8rene John Ousterhout kalte slike st\u00f8rrelser i systemer som voo-doo<br \/>\nkonstanter, ettersom de p\u00e5 en eller annen m\u00e5te krevde svart magi for korrekt<br \/>\ninnstilling. Og dessverre har S en slik lukt. Hvis verdien settes for<br \/>\nh\u00f8y, vil lange oppgaver begynne \u00e5 sultne. Og hvis verdien settes for lav,<br \/>\nvil de interaktive oppgavene ikke f\u00e5 tilstrekkelig prosessortid.<\/p>\n<h4>Fors\u00f8k 3: Bedre regnskap<\/h4>\n<p>N\u00e5 har vi et annet problem som m\u00e5 l\u00f8ses: hvordan ikke<br \/>\nla v\u00e5r planlegger bli lurt? \u00c5rsaken til denne muligheten er<br \/>\nreglene 4a, 4b, som lar oppgaven beholde prioriteten ved \u00e5 la CPU<br \/>\nbli frigjort f\u00f8r tildelt tid er ute. Hvordan takler man dette?<br \/>\nL\u00f8sningen i dette tilfellet kan v\u00e6re bedre regnskap for CPU-tid p\u00e5 hvert<br \/>\nniv\u00e5 i MLFQ. I stedet for \u00e5 glemme tiden programmet brukte<br \/>\nCPU i den tildelte perioden, b\u00f8r man ta hensyn til og lagre den. Etter at<br \/>\nprosessen har forbrukt sin tildelte tid, b\u00f8r den senkes til neste<br \/>\nprioritetsniv\u00e5. N\u00e5 spiller det ingen rolle hvordan prosessen bruker tiden sin \u2014 som<br \/>\nkontinuerlig beregning p\u00e5 CPU eller som mange kall. Dermed<br \/>\nb\u00f8r regel 4 omskrives til f\u00f8lgende:<\/p>\n<ul>\n<li><b>Rule4<\/b>: Etter at en oppgave har brukt sin tildelte tid i den n\u00e5v\u00e6rende k\u00f8en (uavhengig av hvor mange ganger den har frigjort CPU), senkes prioriteten for en slik oppgave (den beveger seg nedover i k\u00f8en).<\/li>\n<\/ul>\n<p>La oss se p\u00e5 et eksempel:<br \/>\n<img decoding=\"async\" alt=\"Operativsystemer: Tre Enkle Deler. Del 5: Planlegging: Multi-Level Feedback Queue (oversettelse)\" src=\"\/wp-content\/uploads\/2019\/04\/18c53e62b9b342d14a23995bd422ef5e.png\" style=\"display:block;margin: 0 auto;\">&gt;<\/p>\n<p>Bildet viser hva som skjer hvis man pr\u00f8ver \u00e5 lure planleggeren, som<br \/>\nhvis det var med de tidligere reglene 4a, 4b ville resultatet til venstre ha blitt. Med den nye<br \/>\nregelen \u2014 resultatet til h\u00f8yre. F\u00f8r beskyttelse kunne enhver prosess for\u00e5rsake I\/O f\u00f8r fullf\u00f8ring og<br \/>\ndominerende CPU-en, etter aktivering av beskyttelsen, uavhengig av I\/O-atferd,<br \/>\nvil han fortsatt bli sendt ned i k\u00f8en og dermed ikke kunne urettferdig<br \/>\ntilgang til CPU-ressursene.<\/p>\n<h4>Forbedrer MLFQ og andre problemer<\/h4>\n<p>Med de ovennevnte forbedringene oppst\u00e5r nye problemer: et av de viktigste<br \/>\nsp\u00f8rsm\u00e5lene er hvordan man skal parametrisere en slik planlegger? Det vil si, hvor mange<br \/>\nk\u00f8er skal det v\u00e6re? Hva skal st\u00f8rrelsen p\u00e5 arbeidsvinduet v\u00e6re innenfor k\u00f8en? Hvor<br \/>\nofte skal man heve prioriteten til programmet for \u00e5 unng\u00e5 sulting og<br \/>\nta hensyn til endringer i programmets atferd? Det finnes ingen enkel<br \/>\nsvar p\u00e5 disse sp\u00f8rsm\u00e5lene, og kun eksperimentering med belastningene og p\u00e5f\u00f8lgende konfigurasjon<br \/>\nav planleggeren kan f\u00f8re til en tiln\u00e6rmet tilfredsstillende balanse.<\/p>\n<p>For eksempel tillater de fleste implementasjoner av MLFQ tildeling av ulike<br \/>\ntidsintervaller til forskjellige k\u00f8er. H\u00f8yt prioriterte k\u00f8er f\u00e5r vanligvis<br \/>\nkorte intervaller. Disse k\u00f8ene best\u00e5r av interaktive oppgaver,<br \/>\nsom bytter ganske f\u00f8lsomt og b\u00f8r ta 10 millisekunder eller mindre.<br \/>\nMotsatt best\u00e5r lavprioriterte k\u00f8er av lange oppgaver som bruker<br \/>\nCPU. I dette tilfellet passer lange tidsintervaller mye godt (100 ms).<br \/>\n<img decoding=\"async\" alt=\"Operativsystemer: Tre Enkle Deler. Del 5: Planlegging: Multi-Level Feedback Queue (oversettelse)\" src=\"\/wp-content\/uploads\/2019\/04\/4eb6c6669034adeb1615c29454fbb1dc.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>I dette eksemplet er det to oppgaver som har jobbet i den h\u00f8yt prioriterte k\u00f8en i 20<br \/>\nms, delt opp i vinduer p\u00e5 10 ms. 40 ms i den middels prioriterte k\u00f8en (vindu p\u00e5 20 ms) og i den lavprioriterte<br \/>\nk\u00f8en ble tidsvinduet 40 ms, hvor oppgavene fullf\u00f8rte arbeidet sitt.<\/p>\n<p>Implementeringen av MLFQ i OS Solaris er en klasse av planleggere som deler opp tiden.<br \/>\nPlanleggeren tilbyr et sett med tabeller som n\u00f8yaktig definerer hvordan<br \/>\nprosessenes prioritet skal endres over levetiden, hva som skal v\u00e6re st\u00f8rrelsen p\u00e5<br \/>\ndet tildelte vinduet og hvor ofte oppgavene skal heve prioritetene. Systemadministratoren<br \/>\nkan interagere med denne tabellen og f\u00e5 planleggeren til \u00e5 oppf\u00f8re seg<br \/>\nannerledes. Som standard har denne tabellen 60 k\u00f8er med gradvis \u00f8kende<br \/>\nvindusst\u00f8rrelse fra 20 ms (h\u00f8y prioritet) til flere hundre ms (lav prioritet), og<br \/>\nog med boost av alle oppgaver hver sekund.<\/p>\n<p>Andre MLFQ-planleggere bruker ikke tabeller eller spesifikke<br \/>\nregler som beskrevet i denne l\u00e6ren; tvert imot beregner de prioriteter ved \u00e5 bruke<br \/>\nmatematisk formel. For eksempel bruker planleggeren i FreeBSD en formel for<br \/>\n\u00e5 beregne gjeldende prioritet for en oppgave, basert p\u00e5 hvor mye prosessor<br \/>\nden har brukt. I tillegg forfaller CPU-bruken over tid, og dermed skjer<br \/>\n\u00f8king av prioritet noe annerledes enn beskrevet ovenfor. Dette er s\u00e5kalt<br \/>\ndecay-algoritmer. Fra versjon 7.1 bruker FreeBSD ULE-planleggeren.<\/p>\n<p>Til slutt har mange planleggere andre egenskaper. For eksempel reserverer noen<br \/>\nplanleggere de h\u00f8yere niv\u00e5ene for operativsystemets arbeid, og slik<br \/>\nkan ingen brukerprosess oppn\u00e5 den h\u00f8yeste prioriteten i<br \/>\nsystemet. Noen systemer tillater \u00e5 gi r\u00e5d for \u00e5 hjelpe<br \/>\nplanleggeren til \u00e5 sette prioriteringer korrekt. For eksempel kan man <b>nice<\/b><br \/>\nbruke kommandoen til \u00e5 \u00f8ke eller senke prioriteten til en oppgave, og dermed<br \/>\n\u00f8ke eller redusere sjansene til programmet for prosessor-tid.<\/p>\n<h3>MLFQ: Oppsummering<\/h3>\n<p>Vi har beskrevet en tiln\u00e6rming til planlegging som kalles MLFQ. Navnet<br \/>\ner basert p\u00e5 prinsippet om hvordan den fungerer \u2014 den har flere k\u00f8er og bruker<br \/>\ntilbakemelding for \u00e5 bestemme prioriteten til oppgaven.<br \/>\nDe endelige reglene vil v\u00e6re som f\u00f8lger:<\/p>\n<ul>\n<li><b>Rule1<\/b>: Hvis prioritet(A) &gt; Prioritet(B), vil oppgave A bli kj\u00f8rt (B vil ikke bli)<\/li>\n<li><b>Rule2<\/b>: Hvis prioritet(A) = Prioritet(B), kj\u00f8res A og B med RR<\/li>\n<li><b>Rule3<\/b>: N\u00e5r en oppgave kommer inn i systemet, plasseres den i k\u00f8en med h\u00f8yest prioritet.<\/li>\n<li><b>Rule4<\/b>: Etter at en oppgave har brukt sin tildelte tid i den n\u00e5v\u00e6rende k\u00f8en (uavhengig av hvor mange ganger den har frigjort CPU), senkes prioriteten for en slik oppgave (den beveger seg nedover i k\u00f8en).<\/li>\n<li><b>alle oppgaver til h\u00f8yest prioritert med en gang, her er den nye regelen:<\/b>Rule5<\/li>\n<\/ul>\n<p>MLFQ er interessant av f\u00f8lgende grunn \u2014 i stedet for \u00e5 kreve forkunnskap om<br \/>\noppgavens natur p\u00e5 forh\u00e5nd, studerer algoritmen oppgavens tidligere atferd og setter<br \/>\nprioriteter deretter. Slik pr\u00f8ver den \u00e5 f\u00e5 til en balanse \u2014 oppn\u00e5 ytelse for sm\u00e5 oppgaver (SJF, STCF) og \u00e6rlig kj\u00f8re lange,<br \/>\nCPU-tunge oppgaver. Derfor bruker mange systemer, inkludert BSD og deres avledninger,<br \/>\nSolaris, Windows, Mac en form for MLFQ-algoritme som grunnleggende<br \/>\nplanlegger.<\/p>\n<h4>Additional materials:<\/h4>\n<ol>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/manpages.debian.org\/stretch\/manpages\/sched.7.en.html\">manpages.debian.org\/stretch\/manpages\/sched.7.en.html<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Scheduling_\">en.wikipedia.org\/wiki\/Scheduling_<\/a><\/noindex>(computing)<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/pages.lip6.fr\/Julia.Lawall\/atc18-bouron.pdf\">pages.lip6.fr\/Julia.Lawall\/atc18-bouron.pdf<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.usenix.org\/legacy\/event\/bsdcon03\/tech\/full_papers\/roberson\/roberson.pdf\">www.usenix.org\/legacy\/event\/bsdcon03\/tech\/full_papers\/roberson\/roberson.pdf<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/chebykin.org\/freebsd-process-scheduling\">chebykin.org\/freebsd-process-scheduling<\/a><\/noindex><\/li>\n<\/ol>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/450116\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0425\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u0441\u0435\u0440\u0438\u044e \u0441\u0442\u0430\u0442\u0435\u0439-\u043f\u0435\u0440\u0435\u0432\u043e\u0434\u043e\u0432 \u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e\u0439 \u043d\u0430 \u043c\u043e\u0439 \u0432\u0437\u0433\u043b\u044f\u0434 \u043b\u0438\u0442\u0435\u0440\u0430\u0442\u0443\u0440\u044b \u2014 OSTEP. \u0412 \u044d\u0442\u043e\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0435 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0433\u043b\u0443\u0431\u043e\u043a\u043e \u0440\u0430\u0431\u043e\u0442\u0430 unix-\u043f\u043e\u0434\u043e\u0431\u043d\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c, \u0430 \u0438\u043c\u0435\u043d\u043d\u043e \u2014 \u0440\u0430\u0431\u043e\u0442\u0430 \u0441 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u043c\u0438, \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u043c\u0438 \u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0449\u0438\u043a\u0430\u043c\u0438, \u043f\u0430\u043c\u044f\u0442\u044c\u044e \u0438 \u043f\u0440\u043e\u0447\u0438\u0438\u043c\u0438 \u043f\u043e\u0434\u043e\u0431\u043d\u044b\u043c\u0438 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044e\u0442 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u0443\u044e \u041e\u0421. \u041e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0432\u0441\u0435\u0445 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u0432 \u0432\u044b \u043c\u043e\u0436\u0435\u0442\u0435 \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0435\u0442\u044c \u0432\u043e\u0442 \u0442\u0443\u0442. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24514,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32730","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.5 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0425\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u0441\u0435\u0440\u0438\u044e \u0441\u0442\u0430\u0442\u0435\u0439-\u043f\u0435\u0440\u0435\u0432\u043e\u0434\u043e\u0432 \u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e\u0439 \u043d\u0430 \u043c\u043e\u0439 \u0432\u0437\u0433\u043b\u044f\u0434 \u043b\u0438\u0442\u0435\u0440\u0430\u0442\u0443\u0440\u044b \u2014 OSTEP.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"nn_NO\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Operating Systems: Three Easy Pieces. Part 5: \u041f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435: Multi-Level Feedback Queue (\u043f\u0435\u0440\u0435\u0432\u043e\u0434) | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0425\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u0441\u0435\u0440\u0438\u044e \u0441\u0442\u0430\u0442\u0435\u0439-\u043f\u0435\u0440\u0435\u0432\u043e\u0434\u043e\u0432 \u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e\u0439 \u043d\u0430 \u043c\u043e\u0439 \u0432\u0437\u0433\u043b\u044f\u0434 \u043b\u0438\u0442\u0435\u0440\u0430\u0442\u0443\u0440\u044b \u2014 OSTEP.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:48:36+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2021-02-08T09:40:35+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Operativsystem: Tre enkle stykker. Del 5: Planlegging: Multi-Level Feedback Queue (oversettelse) | ProHoster","description":"Introduksjon til operativsystemer Hei, Habr! Jeg vil gjerne presentere for deg en serie med oversettelsesartikler av en litteratur jeg synes er interessant - OSTEP.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Operating Systems: Three Easy Pieces. Part 5: \u041f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435: Multi-Level Feedback Queue (\u043f\u0435\u0440\u0435\u0432\u043e\u0434) | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0425\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u0441\u0435\u0440\u0438\u044e \u0441\u0442\u0430\u0442\u0435\u0439-\u043f\u0435\u0440\u0435\u0432\u043e\u0434\u043e\u0432 \u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e\u0439 \u043d\u0430 \u043c\u043e\u0439 \u0432\u0437\u0433\u043b\u044f\u0434 \u043b\u0438\u0442\u0435\u0440\u0430\u0442\u0443\u0440\u044b \u2014 OSTEP.","og:url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:48:36+00:00","article:modified_time":"2021-02-08T09:40:35+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32730","title":null,"description":"","keywords":"","keyphrases":null,"primary_term":null,"canonical_url":"","og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 12:18:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:53:25","updated":"2026-01-21 12:18:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/32730","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=32730"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/32730\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/24514"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=32730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=32730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=32730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}