{"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\/da\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod","title":{"rendered":"Operating Systems: Three Easy Pieces. Del 5: Planl\u00e6gning: Multi-Level Feedback Queue (overs\u00e6ttelse)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h1>Introduktion til operativsystemer<\/h1>\n<p>Hej, Habr! Jeg vil gerne pr\u00e6sentere for dig en serie af artikelovers\u00e6ttelser af en interessant litteratur \u2014 OSTEP. Dette materiale unders\u00f8ger grundigt, hvordan unix-lignende operativsystemer fungerer, nemlig hvordan man arbejder med processer, forskellige scheduler, hukommelse og andre lignende komponenter, der udg\u00f8r et moderne OS. Originalen af alt materiale kan du se her <noindex><a rel=\"nofollow\" href=\"http:\/\/pages.cs.wisc.edu\/~remzi\/OSTEP\/\">her<\/a><\/noindex>. V\u00e6r opm\u00e6rksom p\u00e5, at overs\u00e6ttelsen er lavet uprofessionelt (temmelig frit), men jeg h\u00e5ber, at jeg har bevaret den overordnede mening.<\/p>\n<p>Laboratoriearbejder om dette emne kan findes 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 dele:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/446340\/\">Del 1: Introduktion<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/446866\/\">Del 2: Abstraktion: proces<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/447182\/\">Del 3: Introduktion til proces-API<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/449026\/\">Del 4: Introduktion til scheduler<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/450116\/\">Del 5: MLFQ-scheduler<\/a><\/noindex><\/li>\n<\/ul>\n<p>Og du kan ogs\u00e5 tjekke min kanal 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>Planl\u00e6gningsmetode: Multi-Level Feedback Queue<\/h2>\n<p>I denne lektion vil vi diskutere problemerne med at udvikle en af de mest kendte metoder til<br \/>\nplanl\u00e6gning, som kaldes <b>Multi-Level Feedback Queue<\/b> (MLFQ). MLFQ-scheduler blev f\u00f8rste gang beskrevet i 1962 af Fernando J. Corbat\u00f3 i et system kaldet<br \/>\nCompatible Time-Sharing System (CTSS). Disse arbejder (herunder senere arbejder p\u00e5<br \/>\nMultics) blev efterf\u00f8lgende pr\u00e6senteret til Turing Award. Scheduler blev<br \/>\nsenere forbedret og fik et udseende, som man allerede kan finde i<br \/>\nnogle moderne systemer.<\/p>\n<p>MLFQ-algoritmen fors\u00f8ger at l\u00f8se 2 grundl\u00e6ggende overlappende problemer.<br \/>\n<b>For det f\u00f8rste<\/b>, den fors\u00f8ger at optimere oms\u00e6tningshastigheden, som vi har gennemg\u00e5et i den tidligere lektion, og som optimeres ved at k\u00f8re de<br \/>\nkorteste opgaver i starten af k\u00f8en. Desv\u00e6rre ved OS ikke, hvor l\u00e6nge en given proces vil k\u00f8re, hvilket er<br \/>\nn\u00f8dvendig viden for drift af SJF- og STCF-algoritmer. <b>For det andet<\/b>, MLFQ fors\u00f8ger<br \/>\nat g\u00f8re systemet responsivt for brugerne (for eksempel dem, der sidder og<br \/>\nstirrer p\u00e5 sk\u00e6rmen i forventning om at opgaven afsluttes) og dermed minimere<br \/>\nrespons tiden. Desv\u00e6rre reducerer algoritmer som RR respons tiden, men har en meget<br \/>\nnegativ indvirkning p\u00e5 oms\u00e6tningshastighedsmetrikken. Her er vores problem: Hvordan designer man<br \/>\nen scheduler, der opfylder vores krav, uden at vide noget om<br \/>\nprocessens karakter generelt? Hvordan kan en scheduler l\u00e6re opgavens egenskaber,<br \/>\nsom den k\u00f8rer, og dermed tr\u00e6ffe bedre beslutninger om planl\u00e6gning?<\/p>\n<p><u>Essensen af problemet: Hvordan planl\u00e6gger man opgaveplacering uden en perfekt viden?<br \/>\nHvordan udvikler man en scheduler, der samtidig minimerer respons tiden<br \/>\nfor interaktive opgaver og samtidig minimerer oms\u00e6tningstiden uden forudg\u00e5ende<br \/>\nviden om opgavens udf\u00f8relsestid?<\/u><\/p>\n<p>Bem\u00e6rk: L\u00e6rer af tidligere h\u00e6ndelser<\/p>\n<p>MLFQ-k\u00f8 er et glimrende eksempel p\u00e5 et system, der l\u00e6rer af<br \/>\ntidligere h\u00e6ndelser for at forudsige fremtiden. S\u00e5danne metoder ses ofte<br \/>\ni OS (og mange andre omr\u00e5der inden for datalogi, herunder forudsigelser i hardware og caching algoritmer). S\u00e5danne tilgange<br \/>\nfungerer, n\u00e5r opgaver har adf\u00e6rdsm\u00e6ssige faser og dermed er forudsigelige.<br \/>\naktiveres, n\u00e5r opgaver har adf\u00e6rdsm\u00e6ssige faser og dermed er forudsigelige.<br \/>\nMen med s\u00e5dan teknologi skal man v\u00e6re forsigtig, fordi forudsigelser meget let<br \/>\nkan vise sig at v\u00e6re forkerte og f\u00f8re systemet til at tr\u00e6ffe d\u00e5rligere beslutninger end<br \/>\nhvis der slet ikke var nogen viden.<\/p>\n<h3>MLFQ: Grundl\u00e6ggende regler<\/h3>\n<p>Lad os overveje de grundl\u00e6ggende regler for MLFQ-algoritmen. Og selvom der findes flere<br \/>\nimplementeringer af denne algoritme, er de grundl\u00e6ggende tilgange ens.<br \/>\nI den implementering, vi vil se p\u00e5, vil MLFQ have flere<br \/>\nseparat k\u00f8er, hver med en anden prioritet. P\u00e5 ethvert tidspunkt<br \/>\nbefinder en opgave, der er klar til udf\u00f8relse, sig i en af k\u00f8erne. MLFQ anvender prioriteter<br \/>\nfor at afg\u00f8re, hvilken opgave der skal k\u00f8res, dvs. opgaven med h\u00f8jere<br \/>\nprioritet (opgaven fra k\u00f8en med h\u00f8jeste prioritet) vil blive startet f\u00f8rst.<br \/>\nDer kan uden tvivl v\u00e6re mere end \u00e9n opgave i en given k\u00f8, s\u00e5ledes at de<br \/>\nvil have samme prioritet. I dette tilf\u00e6lde vil RR-mekanismen blive anvendt<br \/>\ntil planl\u00e6gning af k\u00f8rsel blandt disse opgaver.<br \/>\nDermed n\u00e5r vi frem til to grundl\u00e6ggende regler for MLFQ:<br \/>\nRegel 1: Hvis Prioritet(A) &gt; Prioritet(B), vil opgave A blive startet (B vil ikke)<\/p>\n<ul>\n<li> Regel 2: Hvis Prioritet(A) = Prioritet(B), vil A og B blive startet ved hj\u00e6lp af RR<\/li>\n<li> I henhold til ovenst\u00e5ende er de vigtigste elementer i MLFQ-planl\u00e6gning<\/li>\n<\/ul>\n<p>prioriteter. I stedet for at tildele en fast prioritet til hver<br \/>\nopgave, \u00e6ndrer MLFQ dens prioritet baseret p\u00e5 observeret adf\u00e6rd.<br \/>\nFor eksempel, hvis en opgave konstant holder CPU'en besk\u5fd9et i ventetid for input fra tastaturet,<br \/>\nvil MLFQ holde prioriteten for processen p\u00e5 et h\u00f8jt niveau, fordi det er s\u00e5dan,<br \/>\nen interaktiv proces skal fungere. Men hvis opgaven derimod konstant og<br \/>\nintensivt bruger CPU'en i l\u00e6ngere tid, vil MLFQ s\u00e6nke dens<br \/>\nprioritet. Dermed vil MLFQ l\u00e6re processernes adf\u00e6rd i l\u00f8bet af deres k\u00f8rsel<br \/>\nog anvende adf\u00e6rden.<br \/>\nLad os skitsere et eksempel p\u00e5, hvordan k\u00f8erne kunne se ud p\u00e5 et givent<br \/>\ntidspunkt, og s\u00e5 ville det se nogenlunde s\u00e5dan ud:<br \/>\nI dette diagram er der 2 processer A og B i k\u00f8en med den h\u00f8jeste prioritet. Processen<br \/>\n<img decoding=\"async\" alt=\"Operating Systems: Three Easy Pieces. Del 5: Planl\u00e6gning: Multi-Level Feedback Queue (overs\u00e6ttelse)\" src=\"\/wp-content\/uploads\/2019\/04\/3598e9ca43a56049625bdcf3074de472.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>C er et sted midt imellem, mens processen D er i bunden af k\u00f8en. I henhold til de ovenst\u00e5ende<br \/>\nbeskrivelser vil MLFQ-planl\u00e6ggeren kun udf\u00f8re opgaver med den h\u00f8jeste prioritet.<br \/>\nbeskrivelserne af MLFQ-algoritmen vil planl\u00e6ggeren kun udf\u00f8re opgaver med den h\u00f8jeste prioritet.<br \/>\nprioritet i henhold til RR, mens opgaverne C og D vil ikke blive forfulgt.<br \/>\nSelvf\u00f8lgelig giver et statisk snapshot ikke det fulde billede af, hvordan MLFQ fungerer.<br \/>\nDet er vigtigt at forst\u00e5, hvordan billedet \u00e6ndrer sig over tid.<\/p>\n<h4>Fors\u00f8g 1: Hvordan \u00e6ndrer man prioritet<\/h4>\n<p>P\u00e5 dette tidspunkt er det n\u00f8dvendigt at beslutte, hvordan MLFQ vil \u00e6ndre prioriteringsniveauet<br \/>\nfor opgaver (og dermed opgavens placering i k\u00f8en) i l\u00f8bet af dens livscyklus. For<br \/>\ndette er det n\u00f8dvendigt at have arbejdsprocessen in mente: et bestemt antal<br \/>\ninteraktive opgaver med kort arbejdstid (og dermed hyppig frigivelse af<br \/>\nCPU) og flere lange opgaver, der bruger CPU i hele deres arbejdstid, mens<br \/>\nrespons tiden for disse opgaver ikke er vigtig. Og s\u00e5ledes kan man g\u00f8re det f\u00f8rste fors\u00f8g<br \/>\np\u00e5 at implementere MLFQ-algoritmen med f\u00f8lgende regler:<\/p>\n<ul>\n<li> Regel 3: N\u00e5r en opgave tilf\u00f8jes systemet, placeres den i k\u00f8en med den h\u00f8jeste<\/li>\n<li>prioritet til Ingester.<\/li>\n<li>Regel 4a: Hvis en opgave bruger hele den tildelte tidsvindue, s\u00e6nkes dens<\/li>\n<li>prioritet.<\/li>\n<li>Regel 4b: Hvis en opgave frigiver CPU f\u00f8r udl\u00f8bet af sit tidsvindue, forbliver den<\/li>\n<li>med den samme prioritet.<\/li>\n<\/ul>\n<p><b>Eksempel 1: En enkelt langvarig opgave<\/b><\/p>\n<p>Som det fremg\u00e5r af dette eksempel, starter opgaven ved at f\u00e5 den h\u00f8jeste<br \/>\nprioritet. Efter et tidsvindue p\u00e5 10 ms s\u00e6nkes prioriteten af planl\u00e6ggeren.<br \/>\nEfter det n\u00e6ste tidsvindue s\u00e6nkes opgaven endelig til<br \/>\nden laveste prioritet i systemet, hvor den forbliver.<br \/>\n<img decoding=\"async\" alt=\"Operating Systems: Three Easy Pieces. Del 5: Planl\u00e6gning: Multi-Level Feedback Queue (overs\u00e6ttelse)\" src=\"\/wp-content\/uploads\/2019\/04\/9b4ee6de03aa92d7957d50b4ffa73949.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p><b>Eksempel 2: En kort opgave introduceres<\/b><\/p>\n<p>Lad os nu se et eksempel p\u00e5, hvordan MLFQ fors\u00f8ger at n\u00e6rme sig SJF. I dette<br \/>\neksempel er der to opgaver: A, som er en langvarig opgave, der konstant<br \/>\nbesk\u00e6ftiger CPU, og B, som er en kort interaktiv opgave. Antag,<br \/>\nat A allerede har k\u00f8rt et stykke tid, da opgave B ankommer.<br \/>\n<img decoding=\"async\" alt=\"Operating Systems: Three Easy Pieces. Del 5: Planl\u00e6gning: Multi-Level Feedback Queue (overs\u00e6ttelse)\" src=\"\/wp-content\/uploads\/2019\/04\/19c299b0519585fd1076a341a71f048b.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>P\u00e5 dette diagram kan resultaterne af scenariet ses. Opgave A, ligesom enhver opgave,<br \/>\nder bruger CPU, befinder sig i bunden. Opgave B vil ankomme p\u00e5 tid T=100 og vil<br \/>\nblive placeret i k\u00f8en med den h\u00f8jeste prioritet. Da dens arbejdstid ikke er lang,<br \/>\nvil den blive afsluttet, f\u00f8r den n\u00e5r den sidste k\u00f8.<\/p>\n<p>Fra dette eksempel skal man forst\u00e5 hovedm\u00e5let med algoritmen: da algoritmen ikke<br \/>\nved, om en opgave er lang eller kort, antager den f\u00f8rst, at opgaven<br \/>\nkort og tildeler den h\u00f8jeste prioritet. Hvis det virkelig er en kort opgave, s\u00e5<br \/>\nvil den blive udf\u00f8rt hurtigt, ellers hvis det er en lang opgave, s\u00e5 vil den bev\u00e6ge sig langsomt<br \/>\nnedad i prioriteten og snart bevise, at det virkelig er en langvarig opgave, der ikke<br \/>\nkr\u00e6ver respons.<\/p>\n<p><b>Eksempel 3: Hvad med ind- og uddata?<\/b><\/p>\n<p>Lad os nu se p\u00e5 et eksempel med ind- og uddata. Som n\u00e6vnt i regel 4b,<br \/>\nhvis en proces frigiver CPU'en uden at have brugt hele sin CPU-tid,<br \/>\nforbliver den p\u00e5 det samme prioriteringsniveau. Hensigten med denne regel er ret enkel<br \/>\n\u2014 hvis en interaktiv opgave udf\u00f8rer mange ind- og uddataoperationer, for eksempel venter<br \/>\np\u00e5 brugerens tastetryk eller mus, vil en s\u00e5dan opgave frigive CPU'en<br \/>\nf\u00f8r det tildelte vindue. Vi \u00f8nsker ikke at s\u00e6nke prioriteten for en s\u00e5dan opgave,<br \/>\nog s\u00e5ledes vil den forblive p\u00e5 det samme niveau.<br \/>\n<img decoding=\"async\" alt=\"Operating Systems: Three Easy Pieces. Del 5: Planl\u00e6gning: Multi-Level Feedback Queue (overs\u00e6ttelse)\" src=\"\/wp-content\/uploads\/2019\/04\/480d33a670fb62a639e5938dd59e30a1.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Dette eksempel viser, hvordan algoritmen vil arbejde med s\u00e5danne processer \u2014 interaktiv opgave B, der kun har brug for CPU i 1 ms f\u00f8r udf\u00f8relsen<br \/>\naf input-output-processen og den langvarige opgave A, der bruger CPU hele sin tid.<br \/>\nMLFQ holder proces B med h\u00f8jeste prioritet, fordi den forts\u00e6tter med<br \/>\nat frigive CPU'en. Hvis B er en interaktiv opgave, har algoritmen i dette tilf\u00e6lde opn\u00e5et<br \/>\nsit m\u00e5l med hurtigt at k\u00f8re interaktive opgaver.<\/p>\n<p><b>Problemer med den nuv\u00e6rende MLFQ-algoritme<\/b><\/p>\n<p>I de tidligere eksempler byggede vi en grundl\u00e6ggende version af MLFQ. Og det ser ud til, at den<br \/>\ng\u00f8r sit arbejde godt og retf\u00e6rdigt, ved rimeligt at fordele CPU-tid mellem<br \/>\nlange opgaver og lader korte opgaver eller opgaver, der intensivt bruger<br \/>\nind- og uddataarbejde hurtigt. Desv\u00e6rre har denne tilgang flere<br \/>\nalvorlige problemer.<br \/>\n<b>For det f\u00f8rste<\/b>, sultproblemet: hvis der er mange interaktive<br \/>\nopgaver i systemet, vil de bruge al CPU-tid, og s\u00e5ledes f\u00e5r ingen lang<br \/>\nopgave mulighed for at blive udf\u00f8rt (de sulter).<\/p>\n<p><b>For det andet<\/b>, smarte brugere kunne skrive deres programmer p\u00e5 en m\u00e5de, der<br \/>\nsnyder planl\u00e6ggeren. Snydet best\u00e5r i at g\u00f8re noget, s\u00e5 planl\u00e6ggeren<br \/>\ngiver processen mere CPU-tid. Algoritmen, der<br \/>\nbeskrevet ovenfor er ganske s\u00e5rbar over for s\u00e5danne angreb: f\u00f8r tidsvinduet n\u00e6sten<br \/>\ner udl\u00f8bet, skal der udf\u00f8res en input-output-operation (til en hvilken som helst, uanset hvilken fil)<br \/>\nog derved frigive CPU'en. En s\u00e5dan adf\u00e6rd vil g\u00f8re det muligt at forblive i den samme<br \/>\nk\u00f8 og igen f\u00e5 en st\u00f8rre procentdel af processortiden. Hvis dette g\u00f8res<br \/>\nkorrekt (for eksempel k\u00f8re 99% af tiden i vinduet f\u00f8r frigivelse af CPU'en),<br \/>\nkan en s\u00e5dan opgave simpelthen monopolisere processoren.<\/p>\n<p>Endelig kan programmet \u00e6ndre sin adf\u00e6rd over tid. De opgaver,<br \/>\nder brugte CPU'en, kan blive interaktive. I vores eksempel vil s\u00e5danne<br \/>\nopgaver ikke f\u00e5 den rette behandling fra planl\u00e6ggeren, da de ville have f\u00e5et andre<br \/>\n(oprindelige) interaktive opgaver.<\/p>\n<p><u>Sp\u00f8rgsm\u00e5l til salen: hvilke angreb p\u00e5 planl\u00e6ggeren kunne der udf\u00f8res i den moderne verden?<br \/>\n<\/u><\/p>\n<h4>Fors\u00f8g 2: Prioritetsfor\u00f8gelse<\/h4>\n<p>Lad os pr\u00f8ve at \u00e6ndre reglerne og se, om vi kan undg\u00e5 problemer med<br \/>\nsult. Hvad kunne vi g\u00f8re for at sikre, at de CPU-relaterede<br \/>\nopgaver f\u00e5r deres tid (selvom det ikke er l\u00e6nge).<br \/>\nSom en simpel l\u00f8sning p\u00e5 problemet kan man foresl\u00e5 at<br \/>\nperiodisk \u00f8ge prioriteten af alle s\u00e5danne opgaver i systemet. Der er mange m\u00e5der<br \/>\nat opn\u00e5 dette, lad os pr\u00f8ve at implementere noget simpelt som eksempel: at \u00e6ndre<br \/>\nalle opgaver til den h\u00f8jeste prioritet, nedenfor er den nye regel:<\/p>\n<ul>\n<li><b>Regel5<\/b>: Efter en vis periode S, \u00e6ndre alle opgaver i systemet til den h\u00f8jeste k\u00f8.<\/li>\n<\/ul>\n<p>Vores nye regel l\u00f8ser to problemer p\u00e5 \u00e9n gang. For det f\u00f8rste<br \/>\ner processerne garanteret ikke sultne: opgaver, der befinder sig i den h\u00f8jeste k\u00f8, vil dele<br \/>\nprocessortid if\u00f8lge RR-algoritmen, og dermed f\u00e5r alle processer<br \/>\nprocessortid. For det andet, hvis en proces, der tidligere kun brugte<br \/>\nprocessoren, bliver interaktiv, vil den forblive i k\u00f8en med h\u00f8jere<br \/>\nprioritet, efter at den engang har f\u00e5et en prioriteringsfor\u00f8gelse til den h\u00f8jeste.<br \/>\nLad os tage et eksempel. I dette scenarie overvejer vi \u00e9n proces, der bruger<br \/>\n<img decoding=\"async\" alt=\"Operating Systems: Three Easy Pieces. Del 5: Planl\u00e6gning: Multi-Level Feedback Queue (overs\u00e6ttelse)\" src=\"\/wp-content\/uploads\/2019\/04\/3b8d879ab4479622684b126ec5af6af3.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>CPU og to interaktive, korte processer. Til venstre viser billedet adf\u00e6rden uden prioriteringsfor\u00f8gelse, hvilket betyder, at de lange opgaver begynder at sulte, efter at der ankommer to interaktive opgaver til systemet. Til h\u00f8jre udf\u00f8res der en prioriteringsfor\u00f8gelse hvert 50 ms, hvilket sikrer, at alle processer f\u00e5r processor tid og periodisk udf\u00f8res. 50 ms er her et eksempel; i virkeligheden er dette tal en smule h\u00f8jere.<br \/>\nDet er tydeligt, at tilf\u00f8jelsen af tid til den periodiske for\u00f8gelse S f\u00f8rer til<br \/>\ndet naturlige sp\u00f8rgsm\u00e5l: hvilken v\u00e6rdi skal fasts\u00e6ttes? En anerkendt<br \/>\nsystemingeni\u00f8r, John Ousterhout, kaldte s\u00e5danne st\u00f8rrelser i systemer for voo-doo<br \/>\nkonstant, da de p\u00e5 en m\u00e5de kr\u00e6vede lidt magi for at blive korrekt<br \/>\nfastsat. Og desv\u00e6rre har S s\u00e5dan en aroma. Hvis v\u00e6rdien s\u00e6ttes for h\u00f8jt,<br \/>\nbegynder de lange opgaver at sulte. Og hvis v\u00e6rdien s\u00e6ttes for lavt,<br \/>\nvil de interaktive opgaver ikke f\u00e5 tilstr\u00e6kkelig processor tid.<\/p>\n<h4>Fors\u00f8g 3: Bedre regnskab<\/h4>\n<p>Nu har vi endnu et problem, vi skal l\u00f8se: hvordan undg\u00e5r vi<br \/>\nat vores planl\u00e6gger bliver snydt? Skyld er reglerne 4a, 4b, som tillader opgaven at bevare prioriteten ved at frigive processoren<br \/>\nindtil den tildelte tid udl\u00f8ber. Hvordan h\u00e5ndterer vi det?<br \/>\nL\u00f8sningen i dette tilf\u00e6lde kan betragtes som en forbedret regnskabsf\u00f8ring af CPU-tid p\u00e5 hvert<br \/>\nniveau af MLFQ. I stedet for at glemme den tid, som programmet har brugt<br \/>\nprocessoren i det tildelte interval, b\u00f8r vi tage h\u00f8jde for og bevare den. Efter at<br \/>\nprocessen har brugt den tildelte tid, b\u00f8r vi s\u00e6nke dens prioritet til den n\u00e6ste<br \/>\nprioritetsniveau. Nu er det ligegyldigt, hvordan processen bruger sin tid \u2014 om<br \/>\nden k\u00f8rer konstant p\u00e5 processoren eller gennem mange opkald. S\u00e5ledes,<br \/>\nb\u00f8r vi omskrive regel 4 til f\u00f8lgende:<br \/>\nRegel 4<\/p>\n<ul>\n<li><b>: N\u00e5r en opgave har brugt sin tildelte tid i den aktuelle k\u00f8 (uanset hvor mange gange den har frigivet CPU'en) s\u00e6nkes prioriteten for denne opgave (den bev\u00e6ger sig ned ad k\u00f8en).<\/b>Lad os se p\u00e5 et eksempel:<\/li>\n<\/ul>\n<p>Billedet viser, hvad der sker, hvis man fors\u00f8ger at snyde planl\u00e6ggeren, ligesom<br \/>\n<img decoding=\"async\" alt=\"Operating Systems: Three Easy Pieces. Del 5: Planl\u00e6gning: Multi-Level Feedback Queue (overs\u00e6ttelse)\" src=\"\/wp-content\/uploads\/2019\/04\/18c53e62b9b342d14a23995bd422ef5e.png\" style=\"display:block;margin: 0 auto;\">&#187;<\/p>\n<p>Billedet viser, hvad der sker, hvis man fors\u00f8ger at narre planl\u00e6ggeren, som<br \/>\nhvis det var med de tidligere regler 4a, 4b ville resultatet til venstre komme ud. Med den nye<br \/>\nregel - resultatet til h\u00f8jre. F\u00f8r beskyttelse kunne enhver proces for\u00e5rsage I\/O indtil afslutningen og<br \/>\ndermed dominere CPU'en, efter aktivering af beskyttelse, uanset adf\u00e6rden af<br \/>\nI\/O, vil det stadig falde ned i k\u00f8erne og s\u00e5ledes ikke v\u00e6re i stand til uretf\u00e6rdigt<br \/>\nat overtage CPU-ressourcer.<\/p>\n<h4>Forbedrer MLFQ og andre problemer<\/h4>\n<p>Med de ovenn\u00e6vnte forbedringer opst\u00e5r nye problemer: et af de vigtigste<br \/>\nsp\u00f8rgsm\u00e5l er - hvordan skal en s\u00e5dan scheduler parametriseres? Dvs. Hvor mange skal der v\u00e6re<br \/>\nk\u00f8er? Hvad skal st\u00f8rrelsen p\u00e5 arbejdsvinduet v\u00e6re inden for k\u00f8en? Hvor<br \/>\nofte skal programmets prioritet h\u00e6ves for at undg\u00e5 sult og<br \/>\ntage hensyn til \u00e6ndringer i programmets adf\u00e6rd? Der er ikke noget simpel<br \/>\nsvar p\u00e5 disse sp\u00f8rgsm\u00e5l, og kun eksperimenter med belastninger og efterf\u00f8lgende konfiguration<br \/>\naf scheduler kan f\u00f8re til en eller anden tilfredsstillende balance.<\/p>\n<p>For eksempel tillader de fleste implementeringer af MLFQ tildeling af forskellige<br \/>\ntidsintervaller til forskellige k\u00f8er. H\u00f8jt prioriterede k\u00f8er tildeles normalt korte intervaller.<br \/>\nDisse k\u00f8er best\u00e5r af interaktive opgaver,<br \/>\nhvor skift mellem dem er ret f\u00f8lsomt og b\u00f8r tage 10 millisekunder eller mindre.<br \/>\nModsat best\u00e5r lavprioriterede k\u00f8er af lange opgaver, der bruger<br \/>\nCPU'en. Og i dette tilf\u00e6lde er lange tidsintervaller meget velegnede (100 ms).<br \/>\n<img decoding=\"async\" alt=\"Operating Systems: Three Easy Pieces. Del 5: Planl\u00e6gning: Multi-Level Feedback Queue (overs\u00e6ttelse)\" src=\"\/wp-content\/uploads\/2019\/04\/4eb6c6669034adeb1615c29454fbb1dc.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>I dette eksempel er der 2 opgaver, der har arbejdet i den h\u00f8jt prioriterede k\u00f8 i 20<br \/>\nms, opdelt i vinduer p\u00e5 10 ms. 40 ms i den mellemste k\u00f8 (vindue p\u00e5 20 ms) og i den lavprioriterede<br \/>\nk\u00f8 blev det tidsvindue 40 ms, hvor opgaverne afsluttede deres arbejde.<\/p>\n<p>Implementeringen af MLFQ i Solaris OS er en klassisk scheduler, der deler tid.<br \/>\nScheduler'en giver et s\u00e6t tabeller, der pr\u00e6cist angiver, hvordan<br \/>\nprioriteten for processen skal \u00e6ndres over tid, hvad st\u00f8rrelse<br \/>\ndet tildelte vindue skal have, og hvor ofte prioriteringer af opgaven skal h\u00e6ves. Systemadministratoren<br \/>\nkan interagere med denne tabel og f\u00e5 scheduler'en til at opf\u00f8re sig<br \/>\nanderledes. Som standard har denne tabel 60 k\u00f8er med gradvist stigende<br \/>\nvinduesst\u00f8rrelser fra 20 ms (h\u00f8j prioritet) op til flere hundrede ms (lav prioritet), og<br \/>\nog med en boost af alle opgaver hver sekund.<\/p>\n<p>Andre MLFQ-planl\u00e6ggere bruger ikke tabeller eller specifikke<br \/>\nregler, som beskrevet i dette foredrag; i stedet beregner de prioriteter ved hj\u00e6lp af<br \/>\nmatematiske formler. For eksempel bruger planl\u00e6ggeren i FreeBSD en formel til<br \/>\nat beregne den aktuelle prioritet for en opgave, baseret p\u00e5 hvor meget processoren<br \/>\nhar brugt CPU. Derudover falder CPU-brug over tid, og dermed sker der en<br \/>\n\u00e6ndring i prioriteten lidt anderledes end beskrevet ovenfor. Dette kaldes<br \/>\ndecay-algoritmer. Fra version 7.1 har FreeBSD ULE-planl\u00e6ggeren.<\/p>\n<p>Endelig har mange planl\u00e6ggere andre funktioner. For eksempel reserverer nogle<br \/>\nplanl\u00e6ggere de h\u00f8jeste niveauer til operationelle systemopgaver, og derfor kan<br \/>\ningen brugerprocesser opn\u00e5 den h\u00f8jeste prioritet i<br \/>\nsystemet. Nogle systemer tillader at give r\u00e5d for at hj\u00e6lpe<br \/>\nplanl\u00e6ggeren med at fasts\u00e6tte prioriteter korrekt. For eksempel kan man med en kommando <b>nice<\/b><br \/>\n\u00f8ge eller reducere prioriteten for en opgave, og dermed \u00f8ge eller<br \/>\nneds\u00e6tte programmets chancer for CPU-tid.<\/p>\n<h3>MLFQ: Konklusioner<\/h3>\n<p>Vi har beskrevet en tilgang til planl\u00e6gning kaldet MLFQ. Navnet<br \/>\nstammer fra princippet om, at den har flere k\u00f8er og bruger feedback<br \/>\ntil at bestemme opgaveprioriteten.<br \/>\nDe endelige regler vil v\u00e6re som f\u00f8lger:<\/p>\n<ul>\n<li><b>Regel 1<\/b>: Hvis prioritet(A) &gt; Prioritet(B), vil opgave A blive startet (B ikke)<\/li>\n<li><b>Regel 2<\/b>: Hvis prioritet(A) = Prioritet(B), startes A og B ved hj\u00e6lp af RR<\/li>\n<li><b>Regel 3<\/b>: N\u00e5r en opgave ankommer til systemet, placeres den i den k\u00f8 med den h\u00f8jeste prioritet.<\/li>\n<li><b>: N\u00e5r en opgave har brugt sin tildelte tid i den aktuelle k\u00f8 (uanset hvor mange gange den har frigivet CPU'en) s\u00e6nkes prioriteten for denne opgave (den bev\u00e6ger sig ned ad k\u00f8en).<\/b>Lad os se p\u00e5 et eksempel:<\/li>\n<li><b>Regel5<\/b>: Efter en vis periode S, \u00e6ndre alle opgaver i systemet til den h\u00f8jeste k\u00f8.<\/li>\n<\/ul>\n<p>MLFQ er interessant af f\u00f8lgende grund - i stedet for at kr\u00e6ve kendskab til<br \/>\nopgavens karakter p\u00e5 forh\u00e5nd, l\u00e6rer algoritmen opgavens tidligere adf\u00e6rd og fasts\u00e6tter<br \/>\nprioriteterne derefter. Dermed fors\u00f8ger den at sidde p\u00e5 to stole - at opn\u00e5 ydeevne for sm\u00e5 opgaver (SJF, STCF) og retf\u00e6rdigt k\u00f8re lange,<br \/>\nCPU-intensive opgaver. Derfor bruger mange systemer, herunder BSD og deres afledte versioner,<br \/>\nSolaris, Windows, Mac som planl\u00e6gger en eller anden form for algoritme<br \/>\nMLFQ som basis.<\/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.3 - 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\/da\/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.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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\udd47Operativsystemer: Tre lette stykker. Del 5: Planl\u00e6gning: Multi-Level Feedback Queue (overs\u00e6ttelse) | ProHoster","description":"Introduktion til operativsystemer Hej, Habr! Jeg vil gerne pr\u00e6sentere en serie af oversatte artikler af en interessant litteratur \u2014 OSTEP.","canonical_url":"https:\/\/prohoster.info\/da\/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":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/32730","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=32730"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/32730\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/24514"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=32730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=32730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=32730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}