Allouer plus de mémoire que disponible

"Rémi Moyen" <rmoyen@gmail.com> writes:

D'accord. Donc, si je demande plus de mémoire que disponible, suivant
le comportement de 'new', il va se passer:
- soit 'new' n'écrit pas dans les pages réservées, l'appel est donc
très rapide, mais peut retourner sans échec et ça se passera mal quand
j'essaierais ensuite d'accéder pour de vrai à la mémoire (comment se
manifeste ce 'mal' ? Le noyau tuera des processus au hasard pour cause
de OOM ? Ou quelque chose de plus subtil et de récupérable ?) ;

Je ne sais pas. Peut être peut il envoyer un SIGSEGV, tant que la
mémoire ne lui est pas absolument nécessaire, mais dès qu'il en aura
besoin, il tuera des processus sans prévenir. De toutes façon quand
on est dans cette situation, les choses vont déjà assez mal: on swap à
mort, les temps de réponse des processus interactifs sont de l'ordre
de la minute ou de la dizaine de minute plutôt que de la seconde, etc.
Sur un ordinateur personnel, on n'a pas la patience d'attendre, on
reboote. Sur un serveur, si on a la chance d'avoir un terminal root
ouvert, on peut essayer de taper deux commandes pour ajouter du swap:

dd if=/dev/zero of=/tmp/swap bs=1M count=1K ; swapon /tmp/swap

mais c'est surement déjà trop tard...

- soit 'new' écrit dans chaque page pour vérifier sa disponibilité,
l'appel est donc potentiellement lent (parce qu'il faut aller dans
chaque page, potentiellement swapper, etc.), mais si il retourne sans
échec je suis certain que ma mémoire est dispo (bien que peut-être
partiellement sur le swap et donc lente à accéder, mais c'est un peu
un autre problème).

C'est correct ?

Oui. Il faut voir comment est implémenté new(), mais il me semble
qu'en général (et surtout pour les petits blocs) il écrit dans toutes
les pages.

Dans ce cas, j'ai l'impression que ça veut dire qu'il faut plus ou
moins que j'implémente un micro-garbage collector pour savoir combien
de mémoire j'utilise ?? Ça me semble bizarre, j'ai dû mal
comprendre...

Oui. Tu peux avoir une enveloppe fixe, ou évaluer la mémoire
nécessaire en fonction de la taille des données.

Pffou... ça ne m'arrange pas du tout, ça. Y'a des fonctions classiques
pour faire ça facilement (en C++, toujours) ? Genre un appel système
qui fixerait la taille maxi que je veux et qui ferait en sorte que
n'importe quel 'new' allouant au-dessus de cette limite lance une
exception ? Ça devrait être le comportement par défaut, me semble-t-
il...

Il y a ulimit, qui permet de mettre une limite (fixe ou variable) sur
la consomation de ressources d'un processus (et fils).

[pjb@thalassa pjb]$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 8191
virtual memory (kbytes, -v) unlimited

Et il y a deux signaux sur Linux:

SIGXCPU 24,24,30 Core CPU time limit exceeded (4.2 BSD)
SIGXFSZ 25,25,31 Core File size limit exceeded (4.2 BSD)

mais je n'en trouve pas concernant la mémoire. Peut être SIGSEGV ?


--
__Pascal Bourguignon__ http://www.informatimago.com/

"This statement is false." In Lisp: (defun Q () (eq nil (Q)))

C'est
quand on essaye d'écrire dans cette page que le système va essayer
d'allouer effectivement une page de mémoire et s'il n'en reste plus de
libre en RAM, il va swapper, et s'il n'en reste plus de libre en swap
il va envoyer des signaux (ce qui peut tuer des processus).

Tiens, à ce sujet, pour un léger topic drift..

Avec une FreeBSD ici, j'ai récemment légèrement bourdé un script, qui a
gonflé en mémoire, et le système m'a gentiment tué le serveur DHCP du
domaine avant que je ne m'en rende compte...

Est-ce que la mécanique selon laquelle le système choisit les processus
à signaler est standard, et est-il possible d'influer dessus ? Par
exemple signaler qu'un ou deux démons (ou utilisateurs ?) devaient être
laissés en paix à part extrême nécessité ?

Fred
--
Our chief weapons are 'who', 'ps -aux', 'kill -9', and a fanatical
devotion to 'fastboot'.
(Sun User Group)

On Feb 16, 2:13 pm, Pascal Bourguignon <p...@informatimago.com> wrote:

- soit 'new' écrit dans chaque page pour vérifier sa disponibilit é,
l'appel est donc potentiellement lent (parce qu'il faut aller dans
chaque page, potentiellement swapper, etc.), mais si il retourne sans
échec je suis certain que ma mémoire est dispo (bien que peut-être
partiellement sur le swap et donc lente à accéder, mais c'est un peu
un autre problème).

C'est correct ?

Oui. Il faut voir comment est implémenté new(), mais il me semble
qu'en général (et surtout pour les petits blocs) il écrit dans tout es
les pages.

OK. Je vais essayer de creuser ça du côté de new.

Pffou... ça ne m'arrange pas du tout, ça. Y'a des fonctions classiq ues
pour faire ça facilement (en C++, toujours) ? Genre un appel système
qui fixerait la taille maxi que je veux et qui ferait en sorte que
n'importe quel 'new' allouant au-dessus de cette limite lance une
exception ? Ça devrait être le comportement par défaut, me semble -t-
il...

Il y a ulimit, qui permet de mettre une limite (fixe ou variable) sur
la consomation de ressources d'un processus (et fils).

Ah oui, je n'y pensais plus. Donc si je dépasse la taille fixée par
ulimit, mon appel à 'new' devrait immédiatement échouer, sans essayer
de marquer toutes les pages une par une, c'est ça ? Dans ce cas, ça
va, ça ne complique pas trop mon travail. Ouf.

Merci !
--
Rémi Moyen

"F. Senault" <fred@lacave.net> writes:

C'est
quand on essaye d'écrire dans cette page que le système va essayer
d'allouer effectivement une page de mémoire et s'il n'en reste plus de
libre en RAM, il va swapper, et s'il n'en reste plus de libre en swap
il va envoyer des signaux (ce qui peut tuer des processus).

Tiens, à ce sujet, pour un léger topic drift..

Avec une FreeBSD ici, j'ai récemment légèrement bourdé un script, qui a
gonflé en mémoire, et le système m'a gentiment tué le serveur DHCP du
domaine avant que je ne m'en rende compte...

Est-ce que la mécanique selon laquelle le système choisit les processus
à signaler est standard, et est-il possible d'influer dessus ? Par
exemple signaler qu'un ou deux démons (ou utilisateurs ?) devaient être
laissés en paix à part extrême nécessité ?

Bonne question. Pour ce que j'en sais, il y a une heuristique
implémentée dans le noyau. Il faudrait lire les sources. Il doit
choisir des processus "qui ne servent à rien", et dhcpd, à part le
matin, quand les utilisateurs allument leurs postes, il ne fait pas
grand chose dans la journée...


--
__Pascal Bourguignon__ http://www.informatimago.com/

HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.

"Rémi Moyen" <rmoyen@gmail.com> writes:

On Feb 16, 2:13 pm, Pascal Bourguignon <p...@informatimago.com> wrote:

- soit 'new' écrit dans chaque page pour vérifier sa disponibilité,
l'appel est donc potentiellement lent (parce qu'il faut aller dans
chaque page, potentiellement swapper, etc.), mais si il retourne sans
échec je suis certain que ma mémoire est dispo (bien que peut-être
partiellement sur le swap et donc lente à accéder, mais c'est un peu
un autre problème).

C'est correct ?

Oui. Il faut voir comment est implémenté new(), mais il me semble
qu'en général (et surtout pour les petits blocs) il écrit dans toutes
les pages.

OK. Je vais essayer de creuser ça du côté de new.

Pffou... ça ne m'arrange pas du tout, ça. Y'a des fonctions classiques
pour faire ça facilement (en C++, toujours) ? Genre un appel système
qui fixerait la taille maxi que je veux et qui ferait en sorte que
n'importe quel 'new' allouant au-dessus de cette limite lance une
exception ? Ça devrait être le comportement par défaut, me semble-t-
il...

Il y a ulimit, qui permet de mettre une limite (fixe ou variable) sur
la consomation de ressources d'un processus (et fils).

Ah oui, je n'y pensais plus. Donc si je dépasse la taille fixée par
ulimit, mon appel à 'new' devrait immédiatement échouer, sans essayer
de marquer toutes les pages une par une, c'est ça ? Dans ce cas, ça
va, ça ne complique pas trop mon travail. Ouf.

Non.

Enfin, le problème c'est qu'il y a plusieurs couches!
Tu nous parles de new(), mais le système n'a rien à voir avec new().

En particulier, quand tu appelle new() tu peux obtenir comme résultat
un pointeur sur un bloc de mémoire qui a été delete()'d précédement.

Ou possiblement, si tu fais un new pour obtenir 100 Ko, new ne va
faire un syscall pour obtenir que 50 Ko, parce qu'il a déjà 50 Ko
disponibles.


Ce qui est sur, c'est que quand on demande des pages de mémoire au
système, celui ci alloue dans la MMU des pointeurs mappant ces pages
virtuellement toute sur une seule page qu'il garde à zéro et qui est
en lecture seule.

Quand le processus essaye d'écrire sur une de ces pages, une exception
de MMU se produit, le système prend la main, et cherche alors une page
en RAM qui soit libre pour l'allouer. S'il y a des pages libres ok.
Sinon, s'il y a des pages utilisée par le cache disque, il peut en
reprendre une, l'effacer et la mapper à la place de la page à zéro.
Sinon, il va chercher une page d'un processus inactif et la copier sur
le swap, et quelques dixièmes de seconde plus tard, la démapper de
l'autre processus, la remettre à zéro et la mapper sur ton processus.
Si le swap est plein, alors il choisi un processus à tuer, le tue et
récupère de la place dans le swap et/ou la RAM et recommence.

Tout ceci ne se produit que quand on essaye d'écrire dans un page
allouée.


La question, c'est comment se comporte new()? Comment est elle
implémentée?

Une implémentation simple d'un gestionnaire de mémoire pourrait
allouer un mot en plus de l'espace demandé, pour écrire la taille du
bloc alloué, ce qui permet à free ou delete de savoir quelle est la
taille libérée, avec une simple liste de bloc libres. Quand il n'y a
pas de bloc libre assez grand, il peut demander au système de mapper
une grande zone, en faire un bloc libre (écrire donc une taille et un
pointeur au début, sur la première page), et puis le couper en petit
blocs au fur et à mesure de l'allocation. Dans ce cas, chaque fois
que tu appelle malloc ou new, au plus DEUX pages sont allouées, celles
où la taille du bloc alloué est écrite, et celle où le pointeur de la
liste de bloc libre est mis à jour.

Avec un tel gestionnaire de mémoire, seul la première page est allouée
avant d'en retourner un pointeur. Si tu fais un new pour 64 Ko, il est
possible que le système n'ait alloué effectivement que 4 Ko.


--
__Pascal_Bourguignon__
http://www.informatimago.com/

Rémi Moyen <rmoyen@gmail.com> wrote:

Hmmm... Je crois que je me suis mal exprimé, ou alors que je ne
comprends pas exactement ta réponse. Si je te comprends bien, tu dis
que dans certains cas, 'new' pourrait réussir alors qu'en réalité, le
jour où j'essaierais d'écrire dans ma mémoire, ça ne marchera pas
parce qu'en réalité le noyau m'a alloué des pages qui ne sont pas
vraiment disponibles ? Si c'est le cas, c'est en effet plutôt (!)

C'est exactement ça.

Mais ma question était plutôt de savoir si le noyau allait passer du
temps à essayer d'allouer avant de me dire qu'il ne peut pas ou si il
était capable de me dire 'non' avant d'avoir tout essayé ? Ta réponse
me laisse supposer que c'est plutôt la première alternative que la
deuxième, c'est bien ça ?

Non le noyau ne va rien essayer du tout, il va allouer de la mémoire en
espérant qu'elle sera libre au moment où tu en auras besoin. Le problème
est que les allocations se font page par page, il y a constamment des
pages allouéee et libérées et en pratique ça ne pose pas de problème
tant que le programme ne grossit pas démesurément. Dans le cas contraire
il est tué, mais avec l'overcommit tu ne peux pas savoir quand ça va
arriver ni te prémunir contre. Si tu risques de te trouver dans ce cas
il faut prévoir beaucoup d'espace de swap, le disque ne coute pas cher.

Tu peux lire l'avis d'experts ici:
http://leaf.dragonflybsd.org/mailarchive/kernel/2005-02/msg00239.html

J'ai lu rapidement et j'avoue ne pas avoir tout compris, mais il me
semble qu'une des conclusions, ça serait que c'est à mon programme de
ne pas demander plus de mémoire que ce qui est raisonnable (et qu'un
des problèmes est de définir ce "raisonnable" proprement), et que je
ne devrais jamais me reposer sur le noyau pour me dire si oui ou non
j'ai assez de mémoire. Ai-je bien compris ?

Oui.

Dans ce cas, j'ai l'impression que ça veut dire qu'il faut plus ou
moins que j'implémente un micro-garbage collector pour savoir combien
de mémoire j'utilise ?? Ça me semble bizarre, j'ai dû mal
comprendre...

Non, ça veut dire qu'il faut te dépêcher de remplir toutes les pages
que tu as demandées, une à une, si tu veux être sur de les avoir pour
toi, et tu risques de te faire tuer s'il n'y a plus de place.

Merci pour ta réponse, en tout cas !
--
Rémi Moyen

--

Michel TALON

Rémi Moyen <rmoyen@gmail.com> wrote:

Ben c'est aussi ce que je me disais au début, mais par exemple, je ne
connais pas de fonction pour accéder facilement à la quantité de
mémoire utilisable. Je peux connaître la mémoire libre, mais ce
chiffre ne tient pas compte de la mémoire utilisé pour servir de cache

Contrairement à ce qui a été dit, quand on parle de mémoire il s'agit
toujours de mémoire totale, mémoire + swap, pour tous les Unix, y
compris Linux. Donc tant qu'il reste du swap il y a de l'espoir.

et qui est disponible si nécessaire. Donc je me dis que le système n'a
pas toujours l'air de pouvoir dire clairement ce qui est réellement
dispo ou pas -- et les commentaires de Michel Talon sur l'overcommit
semblent confirmer cela. D'où ma perplexité.

Tout simplement l'allocation de mémoire est un problème dynamique et qui
fluctue au cours du temps. Ton programme n'est pas le seul à réclamer de
la mémoire, les copains aussi en réclament et en rendent. Donc il est
impossible au temps t de savoir si dans 10 minutes il sera possible
d'allouer une page supplémentaire à ton programme, à moins que tu ais
bloqué toutes tes pages en mémoire dés le départ. Ca suppose non
seulement de faire le malloc, mais encore d'aller écrire sur les pages
pour qu'elle deviennent effectivement résidentes, et en plus d'appliquer
mlock() pour empêcher qu'elles soient virées. Comme tu t'en doutes c'est
un sabotage total pour l'exécution des autres programmes, voilà pourquoi
aucun système raisonnable n'utilise cette stratégie. La bonne stratégie
c'est d'avoir une partition de swap suffisamment gigantesque pour que le
problème ne se pose pas. En effet si l'OS est de suffisamment bonne
qualité, et c'est le cas de FreeBSD et des versions récentes de Linux,
il saura gérer la mémoire physique au mieux pour minimiserl'usage du
swap sans que tu ais à te poser la question que tu te poses. Les new()
marcheront toujours, et les programmes ne seront jamais tués.

Il est aussi possible de redéfinir l'opérateur "new" si on pense pouvoir
gérer la mémoire mieux que le système (ou la "libc").

Oui ben non, ça m'étonnerait beaucoup que je sois capable de gérer la
mémoire mieux.

Tu peux compter sur le fait que la fontion new de C++ ne gère pas la
mémoire du tout, au delà de l'appel nécessaire à malloc() et des bidules
nécessaires pour gérer les objets. Si tu imagines qu'il fait des appels
à madvise(), mlock() ou autres appels systèmes nécessaires pour que ça
se passe comme tu le souhaites, je pense que tu crois au père Noel.

--
Rémi Moyen

--

Michel TALON

Marc <marc.glisse@gmail.com> wrote:

Michel Talon wrote:

C'est le fameux problème de l'"overcommit". Probablement tous les
systèmes Unix modernes, et certainement Linux et FreeBSD font comme les
banquiers qui prêtent de l'argent qu'ils n'ont pas, ils allouent de la
mémoire qui n'est pas disponible, et on voit *aprés* si dès fois il y a
un problème. Il paraît que faire comme ça est indispensable pour
préserver les performances.

Tu oublies solaris qui ne fait pas d'overcommit (il n'y a aucune option
pour le permettre) et s'en sort bien quand même.

Oui ça leur permet de vendre des machines avec beaucoup de gigaoctets de
mémoire et de téraoctets de disque. J'ai trouvé une discussion de la
question ici:
http://developers.sun.com/solaris/articles/subprocess/subprocess.html
On y apprend que sous Linux, même quand l'overcommit est désactivé, il y
est quand même (!), et que sous Solaris il existe un appel système pour
permettre l'overcommit de certains buffers mmap(MAP_NORESERVE)



--

Michel TALON

On Feb 16, 4:05 pm, t...@lpthe.jussieu.fr (Michel Talon) wrote:

Mais ma question était plutôt de savoir si le noyau allait passer du
temps à essayer d'allouer avant de me dire qu'il ne peut pas ou si il
était capable de me dire 'non' avant d'avoir tout essayé ? Ta rép onse
me laisse supposer que c'est plutôt la première alternative que la
deuxième, c'est bien ça ?

Non le noyau ne va rien essayer du tout, il va allouer de la mémoire en
espérant qu'elle sera libre au moment où tu en auras besoin. Le probl ème
est que les allocations se font page par page, il y a constamment des
pages allouéee et libérées et en pratique ça ne pose pas de probl ème
tant que le programme ne grossit pas démesurément. Dans le cas contra ire
il est tué, mais avec l'overcommit tu ne peux pas savoir quand ça va
arriver ni te prémunir contre. Si tu risques de te trouver dans ce cas
il faut prévoir beaucoup d'espace de swap, le disque ne coute pas cher.

Oui enfin le problème du swap, c'est que je peux allouer la mémoire
par blocs de 1 Go ou 2. Dans ce cas, le temps de swapper assez pour me
faire de la place dans la RAM n'est pas négligeable et si je fais
cette opération pour rien (i.e. qu'à la fin de mon allocation de 1 Go
je me rends compte que je ne peux récupérer que 900 Mo et que mon truc
échoue), j'ai un peu gâché plein de temps.

D'où ma question initiale. Je voudrais juste être sûr que quand le
noyau commence à swapper des trucs, il ne le fait pas pour rien. Donc
que si il commence à swapper pour me donner mon Go, c'est que je
l'aurais au final. Je crois comprendre de tes explications qu'en fait,
ce que je demande est impossible, que le seul et unique moyen de
vérifier que mon bloc de mémoire est vraiment disponible, c'est
d'écrire dedans et donc potentiellement de swapper si il faut.

Ça ne m'arrange pas, mais si c'est comme ça, tant pis, les
utilisateurs devront s'y faire...

Dans ce cas, j'ai l'impression que ça veut dire qu'il faut plus ou
moins que j'implémente un micro-garbage collector pour savoir combien
de mémoire j'utilise ?? Ça me semble bizarre, j'ai dû mal
comprendre...

Non, ça veut dire qu'il faut te dépêcher de remplir toutes les pages
que tu as demandées, une à une, si tu veux être sur de les avoir po ur
toi, et tu risques de te faire tuer s'il n'y a plus de place.

Mais tant que je n'ai pas rempli la dernière page, je ne sais pas si
elle sera disponible quand j'écrirais dedans ? Et donc si elle n'est
pas disponible, j'aurais passé du temps pour rien à écrire toutes les
autres pages (et potentiellement à envoyer plein d'autres trucs sur le
swap pour me donner ces pages-là en RAM) ?
--
Rémi Moyen

On Feb 16, 4:22 pm, t...@lpthe.jussieu.fr (Michel Talon) wrote:

Rémi Moyen <rmo...@gmail.com> wrote:

Ben c'est aussi ce que je me disais au début, mais par exemple, je ne
connais pas de fonction pour accéder facilement à la quantité de
mémoire utilisable. Je peux connaître la mémoire libre, mais ce
chiffre ne tient pas compte de la mémoire utilisé pour servir de ca che

Contrairement à ce qui a été dit, quand on parle de mémoire il s' agit
toujours de mémoire totale, mémoire + swap, pour tous les Unix, y
compris Linux. Donc tant qu'il reste du swap il y a de l'espoir.

Oui, j'entends bien, c'est avec le swap. Mais c'est un peu un problème
pour moi, parce que si je demande 1 Go, que l'OS swappe 900 Mo
d'autres données avant de se rendre compte qu'il ne peut pas me
fournir mon Go complet, j'ai quand même passé un moment à attendre que
mes 900 Mo soient swappés pour rien du tout (et c'est même pire parce
qu'il va falloir que je relise ces 900 Mo dans la RAM au moment où
y'en aura besoin, alors qu'ils auraient pu rester dans la RAM tout le
temps).

Tout simplement l'allocation de mémoire est un problème dynamique et qui
fluctue au cours du temps. Ton programme n'est pas le seul à réclamer de
la mémoire, les copains aussi en réclament et en rendent. Donc il est
impossible au temps t de savoir si dans 10 minutes il sera possible
d'allouer une page supplémentaire à ton programme, à moins que tu a is
bloqué toutes tes pages en mémoire dés le départ.

En même temps, quand dans mon code je fais un float* toto = new
float[1000000000], je m'attends à ce que, si new() n'échoue pas, j'ai
un tableau de 1 milliard de cases et où je puisse écrire n'importe où.

Tu vas me dire, la solution est, comme tu le dis, d'aller écrire sur
toutes les pages. Mais dans ce cas, je tombe dans le problème décrit
plus haut de faire swapper 900 Mo avant de me rendre compte que j'ai
pas assez de place. D'où ma question initiale, est-ce qu'il y a un
moyen de faire ça proprement et sans que ça prenne trop de temps ?

La bonne stratégie
c'est d'avoir une partition de swap suffisamment gigantesque pour que le
problème ne se pose pas.

(et d'avoir un système capable d'addresser toute cette mémoire, aussi,
ce qui n'est pas le cas par défaut de mon RedHat 3, mais c'est un
détail, ça)
En effet, dans ce cas je n'aurais jamais de problème pour allouer la
place que je veux. En fait mon problème se pose dans un cas où y'a pas
assez de swap et où donc des allocations peuvent échouer.

Tu peux compter sur le fait que la fontion new de C++ ne gère pas la
mémoire du tout, au delà de l'appel nécessaire à malloc() et des bidules
nécessaires pour gérer les objets. Si tu imagines qu'il fait des appe ls
à madvise(), mlock() ou autres appels systèmes nécessaires pour que ça
se passe comme tu le souhaites, je pense que tu crois au père Noel.

Ah, c'est pas lui qui m'a donné mon train électrique à Noël ?

Mais ça veut aussi dire que je prends le risque que mon 'new' marche
sans problèmes mais qu'après, à un moment quelconque et aléatoire, mon
appli crash (ou qu'un process se fasse tuer) sans que je puisse rien y
faire. Je suis censé hausser des épaules et dire "c'est normal", ou
y'a une stratégie propre pour éviter ça ???
--
Rémi Moyen