Re: pregunta sobre el nucli Linux
Hola,
Potser no ha quedat clar com ho he explicat, intento fer-ho millor. Al
que m'estava referint és que el oom-killer està protegint el sistema
contra la denegació de servei que provocaria que no hi hagi memòria
disponible per un procés (d'usuari). En el cas d'esgotar tota la
memòria i solicitar-ne més el oom-killer s'invocaria alliberant
memòria a base de matar un algún procés (segons unes regles
predefinides). És a dir, contesta la pregunta que ha formulat l'Alex:
(3) Per què un sistema operatiu multiusuari no ve de sortida més
protegit per que el procés d'un usuari no es mengi tota la ram causan
una denegació de servei a la resta ?
Sobre l'enunciat de la pregunta hauriem d'aclarir també que el fet que
un procés consumeixi tota la memòria del sistema no es intrínsecament
dolent, per tant prohibir-ho per tots els casos no té sentit. Un
usuari podria tenir una màquina que executa un sol procés que utilitza
exactament tota la memoria però sense passar-se. Creieu que s'ha de
denegar aquest comportament unilateralment??
Interpreto que quan et refereixes al "problema del company" vols dir
que el Firefox (o qualsevol altre procés d'usuari de la máquina)
tingui la possibilitat d'utilitzar tota la RAM del sistema. Això seria
una cosa diferent a la denegació de servei per quedar-te sense RAM (i
swap en cas d'haver-hi) i per gestionar-ho hi ha altres eines com
ulimit, cgroups, ... En la majoria de distribucions (incloses Debian i
Ubuntu) els límits per defecte són molt laxos però, no és
responsabilitat de l'usuari (administrador) de la máquina configurar
aquesta com desitgi??
Si estàs pensant que el oom-killer hauria d'haver matat el Firefox,
segons el que ens expliquen probablement hauria d'haver passat, però
també és possible que no s'hagués exhaurit tota la memòria sinó que
s'ha quedat a prop del límit però sense arribar-hi i per tant no s'ha
arribat a cridar el oom-killer. En aquest escenari el Firefox
intentava funcionar amb la RAM+swap, lo qual és molt lent però es algo
que ha decidit l'usuari de la màquina.
T'encaixa ara??
Contestant a les teves preguntes sobre el codi del OOM:
El significat que has suposat de les abreviacions és correcte.
En quan al trosset de codi [2], l'objectiu de la funció on està escrit
això és donar una puntuació pel procés sobre el que li han preguntat.
Aquesta puntuació és una funció (en el sentit matemàtic) que utiliza
diferents paràmetres sobre l'espai de memòria del procés (rss, swap,
taula de pàgines,...). Per poder consultar aquestes dades necessita el
punter a l'esctructura mm_struct i per trobar aquest punter crida a la
funció "find_lock_task_mm()".
Salutacions,
Jordi
--
--
Para ser realmente grande, hay que estar con la gente, no por encima de ella.
El sáb, 2 oct 2021 a las 20:14, pedeb (<pedeb@cas.cat>) escribió:
>
> Hola Jordi,
>
> sembla que això de oom_killer és una cosa que té múltiples
> configuracions i que s'ha d'ajustar, però que té uns ajustos genèrics i
> no veig gaire raonable per evitar el problema que comenta el company
> [0], o estic equivocat.
>
> també he trobat [1] (això ho trobo molt interessant Alex)
>
> i independentment d'això, ja que has apuntat el codi font, si em pots
> ajudar a entendre:
>
> què vol dir literalment la variable adj: adjustment?
>
> què vol dir literalment la mm: memory management?, ien aquest context [2] ?
>
> Gràcies!
> Pedro
>
> [0]
> https://www.percona.com/blog/2019/08/02/out-of-memory-killer-or-savior/
> https://www.oracle.com/technical-resources/articles/it-infrastructure/dev-oom-killer.html
> que ve de
> https://juantrucupei.wordpress.com/2017/04/03/desactivar-oom-killer-out-of-memory-killer/
>
> [1]
> https://dev.to/msugakov/taking-firefox-memory-usage-under-control-on-linux-4b02
>
> [2]
> p = find_lock_task_mm(p);
> if (!p)
> return LONG_MIN;
>
> On 10/2/21 3:02 PM, Jordi Miguel wrote:
> > Hola,
> >
> > Sobre el tema del límit d'usuaris per les aplicacions de Google Drive
> > (Docs, Sheets, Slides), Google diu el següent:
> >
> > Share & collaborate on a file with more than 100 people
> > Up to 100 people with view, edit, or comment permissions can work on a
> > Google Docs, Sheets, or Slides file at the same time. When more than
> > 100 people are accessing a file, only the owner and some users with
> > editing permissions can edit the file.
> >
> > Podeu veure la informació completa aquí[1] amb les solucions que
> > proposen per compartir amb més de 100 persones. Potser seria
> > interessant que ens comentessis com vas compartir aquesta presentació:
> > quins permisos tenies tu sobre la presentació? els alumnes tenien el
> > mateix enllaç i, per tant, permisos que tu? o l'enllaç dels alumnes
> > només tenia permisos com a lector ?? Pots reproduir el problema si
> > comparteixes la presentació de la manera que es proposa a la
> > documentació de Google ??
> >
> > Sobre el motiu pel qual Firefox consumeix tota la memòria RAM, imagino
> > que tindràs extensions i/o temes carregats. El primer pas seria
> > intentar reproduir el mateix problema utilitzant el safe mode (e.g. #
> > firefox --safe-mode ) ??
> > Si en safe mode el Firefox es comporta correctament hauries d'anar
> > activant/desactivant extensions fins que trobis quina provoca que el
> > consum es dispari.
> >
> > En quant el tema de control de memòria per part del kernel ja has vist
> > en la teva cerca per Internet que tens diverses opcions disponibles
> > (ulimit, cgroups, ...). La funció de protecció que busques opino que
> > la compleix el OOM-killer (out-of-memory killer). Podeu veure com
> > funciona mirant el codi font [2]. Quan aquest procés s'activa registra
> > el que ha fet al dmesg. Si realment es va consumir tota la memòria
> > pots revisar quin o quins processos va matar el OOM-killer mirant els
> > logs.
> >
> >
> > [1] https://support.google.com/drive/answer/2494822?hl=en
> > [2] https://github.com/torvalds/linux/blob/master/mm/oom_kill.c#L195
> >
> > Salutacions,
> > Jordi
> > --
> >
> > El sáb, 2 oct 2021 a las 13:28, Àlex (<alex@probeta.net>) escribió:
> >>
> >>> Em crida molt l'atenció que Google Slides faci petar el navegador quan
> >>> es comparteix una presentació amb 100 persones.
> >>
> >> No és tant quan 100 persones obren el document, com quan un d'ells fa
> >> clic al botó d'iniciar reproducció.
> >>
> >> Quan moltes persones tenen el document obert el sistema no tenía més que
> >> 1 Gb de RAM ocupada entre escriptori i navegador. És quan faig clic al
> >> botó d'iniciar presentació qué de sobte demana tota la RAM i peta. Per
> >> què? No ho sé.
> >>
> >> Només ho he reproduit un parell de cops amb Ubuntu 18.04 + Firefox 92.0
> >>
> >> No ho he provat amb Chromium . Tampoc ho he provat a Windows ni MacOS.
> >>
> >> Fa uns dies que veig que els llocs de Google funcionen millor amb
> >> Chromium que amb Firefox. Potser només passa amb Firefox.
> >>
> >> Però de les tres preguntes que sorgeixen ...
> >>
> >> (1) Per què passa això a Google Slides ?
> >>
> >> (2) Per què els navegadors no controlen quan una pestanya es menja tota
> >> la RAM del sistema per avisar l'usuari si la vol bloquejar ?
> >>
> >> (3) Per què un sistema operatiu multiusuari no ve de sortida més
> >> protegit per que el procés d'un usuari no es mengi tota la ram causan
> >> una denegació de servei a la resta ?
> >>
> >> ... a llarg termini m'interessen més la pregunta (3) ó la (2) que la (1)
> >>
>
>
Reply to: