Rano dodajte zonu da se uključi u Fedora 32 kako bi se izbjeglo rušenje memorije

rana soba

u Programeri Fedore razgovarali su o zajedničkoj temi što je još uvijek kamen u ciklusu Linuxa i što se već dugo priča o problemima koji dolazi do sadašnjeg Linuxa s malo memorije u sistemu, što dovodi do toga da sistem visi ili pokazuje pad performansi.

Fedora programeri razgovarali su o načinima kako izbjeći prekide pamćenja od ljeta 2019, u cilju poboljšanja korisničkog iskustva u radnom okruženju. Suočeni sa ovom situacijom koja se događa u Fedori, programeri su govorili i odobrili uključivanje Earlyoom-a en sljedeća verzija Fedore koja bi bila verzija Fedora 32.

Radna grupa predložila je nekoliko rješenja da zamrzne radnu površinu tokom rada, što značajno utječe na korisničko iskustvo. Međutim, SIGKIL, koji brzo oporavlja čitav sistem i samo završava procese, bio je predložen i ranije, slanjem SIGTERM-a da daje upute na kraju postupka, može se izabrati u fazama za korisnika.

O EarlyOOM-u

rana soba to je pozadinski proces koji će biti uključeni u Fedoru 32 za rano reagiranje na nedostatak memorije u sistemu.

Ako je količina dostupne memorije manja od navedene vrijednosti, onda ovisno preostala veličina memorije Poslat će se Sigterm (slobodna memorija manja od 10%) ili Sigkill (<5%) to silom proces koji troši najviše memorije će završiti.

Ovdje će se uzeti postupak s najvećom vrijednošću / proc / * / oom_score, bez navođenja stanja sistema na brisanje sistemskih me uspremnika.

S tim Earlyoom će omogućiti sistemu brži odgovor da nedostaje memorije bez pozivanja OOM (Out of Memory) pokretačkog programa u jezgri, što se pokreće kada situacija postane kritična i sistem u pravilu više ne reagira na korisnika.

U drugim verzijama Fedore moguće je omogućiti upravljački program s malo memorije monitor sa malo memorije koji koristi sučelje / proc / pritisak / memorija  koja je uvedena u Linux kernel 4.20 i poboljšana u 5.2.

Da bi procijenili nedostatak memorije u sistemu, Za razliku od earlyoom, on obrađuje i šalje obavijest putem DBusa o potrebi smanjenja potrošnje memorije (ako se nakon toga situacija ne vrati u normalu, moguće je aktivirati OOM Killer kernel).

Monitor sa malo memorije zahtijeva izmjenu aplikacija, tako se vidi kao rješenje za daleku budućnost, koji se može koristiti nakon prenošenja GNOME aplikacija.

Da nadgleda situaciju bez pamćenja, aplikacije u Glib 2.63.3 dodale su GMemoryMonitor API, koji vam omogućuje praćenje signala s monitora s malo memorije i poduzimanje radnji (na primjer, aplikacija može osloboditi memoriju koja se koristi za predmemoriranje, spremiti datoteke, pokrenuti prikupljanje smeća, pokušati smanjiti fragmentaciju memorije ili dovršiti neaktivnu podršku procesa).

Dodata je i podrška za GMemoryMonitor na xdg-desktop-portal za upotrebu u samostalnim aplikacijama isporučenim u flatpak formatu.

Konačno Važno je napomenuti da je zadana EarlyOOM implementacija u Fedori ograničeno samo na verziju za računare tako da ga druge verzije Fedore neće imati.

Kao dodatni podatak, Spominje se da je EarlyOOM razvijen za upotrebu na radnoj površini i čini se malo vjerojatnim da će se vršiti druga uređivanja ukoliko se potražnja ne poveća. Trenutno je paket dostupan za različite distribucije Linuxa, a takođe programeri OpenSUSE-a razgovaraju o njegovom uključivanju u sistem.

Si želite znati više o tome o uključivanju EarlyOOM-a možete se posavjetovati sljedeći linkovi gdje se razvija rasprava. 

Tambien možete pogledati dokumentaciju i instalaciju u starijim verzijama Fedore na sljedeći link. 


Ostavite komentar

Vaša e-mail adresa neće biti objavljena. Obavezna polja su označena sa *

*

*

  1. Za podatke odgovoran: Miguel Ángel Gatón
  2. Svrha podataka: Kontrola neželjene pošte, upravljanje komentarima.
  3. Legitimacija: Vaš pristanak
  4. Komunikacija podataka: Podaci se neće dostavljati trećim stranama, osim po zakonskoj obavezi.
  5. Pohrana podataka: Baza podataka koju hostuje Occentus Networks (EU)
  6. Prava: U bilo kojem trenutku možete ograničiti, oporaviti i izbrisati svoje podatke.

  1.   automatski pilot rekao je

    Vm.swappiness i vm.dirty_bytes nisu bili dovoljni da bi se izbjeglo rušenje radne površine.

    Vrlo dobre vijesti!