[F] informatique et high-tech (les meilleures news) : ah bah swap alors ! - Page 1

Ce sujet est issu d'une discussion ayant dérivé sur deux thèmes distincts. Pour vous rendre sur le sujet d'origine, merci de cliquer sur ce lien

http://www.presence-pc.com/tests/RAM-quantite-23328/
Petit article intéressant. J'avoue que créer un ramdisk pour le swap et les fichiers temporaires ne me serait pas venu à l'esprit.

l'article est très intéressant.

Pour revenir sur le ./11209 : le fait d'utiliser l'"excédent" de RAM comme disque virtuel pour les OS 32 bits est original en effet, je ne savais même pas que c'était possible ; en tout cas, c'est ingénieux, mais vu que les OS 32 bits vont probablement disparaître à plus ou moins court terme... (à moins qu'ils s'amusent encore à vendre des PC avec plus de 4 Go de RAM mais un Windows 7 32 bits ?)

Par contre, les progs/l'OS qui crashe en l'absence de fichier d'échange, c'est quand même qu'ils sont codés salement... merde quoi, 12 Go de RAM ça leur suffit pas ?

J'ai jamais eu le cas, effectivement. Soit on demande s'il reste assez de mémoire, soit si on alloue et qu'on se prend un pointeur à 0, on le signale, on s'amuse pas à foutre des données à partir de l'adresse 0 :/

Kochise

Zerosquare (./11217) :
Par contre, les progs/l'OS qui crashe en l'absence de fichier d'échange, c'est quand même qu'ils sont codés salement... merde quoi, 12 Go de RAM ça leur suffit pas ?

C'est 8 Go qui fait crasher, 12 Go va bien sans swap (même si ce n'est pas recommandé).

[Edit]

Kochise (./11218) :
J'ai jamais eu le cas, effectivement. Soit on demande s'il reste assez de mémoire, soit si on alloue et qu'on se prend un pointeur à 0, on le signale, on s'amuse pas à foutre des données à partir de l'adresse 0 :/

-> Exception.
Ou alors tu fais comme chez Apple, "il ne se passe rien" quand un pointeur est nul. Mine de rien ça sauve la situation plus souvent qu'on ne pense; imagine par exemple que tu affiches une liste de miniatures et que tu n'as pas assez de mémoire pour les dernières, alors elles apparaîtront simplement sans image, pas de plantage.

non, je pense que la plupart des OS ont une adresse virtuelle minimale non nulle.

Sous windows mobile c'est 0x10000, sous linux c'est variable, j'imagine que la même chose existe sous windows normal.

(cross)

Kochise (./11218) :

J'ai jamais eu le cas, effectivement. Soit on demande s'il reste assez de mémoire, soit si on alloue et qu'on se prend un pointeur à 0, on le signale, on s'amuse pas à foutre des données à partir de l'adresse 0 :/
Kochise

Oui, enfin, on ne sait pas ce qu'ils appellent crasher... si c'est juste que le rendering a été arrêté avec un message d'erreur "Pas assez de mémoire, opération annulée", c'est pas un crash d'application, mais le rendering a crashé...

Kochise (./11218) :
soit si on alloue et qu'on se prend un pointeur à 0,

Sauf que dans la réalité, se prendre un NULL suite a un malloc n'arrive jamais

Va chercher les termes Memory Overcommit pour comprendre

Kochise (./11218) :
J'ai jamais eu le cas, effectivement. Soit on demande s'il reste assez de mémoire, soit si on alloue et qu'on se prend un pointeur à 0, on le signale, on s'amuse pas à foutre des données à partir de l'adresse 0

J'ai lu beaucoup d'exemples de programme qui ne vérifie pas leurs allocations (les petites en général), leurs redimensionnement, leurs push_back sur des tableaux etc...
Je trouve ça crade.

Les petites, sur Atari, je les faisaient en zone BSS (grosso-merdo juste derrière la pile, zone réservée et initialisée à zéro par l'OS au démarrage du programme) Nan mais bon bordel, quand tu demandes de la mémoire, tu vérifies un minimum qu'on t'en donne effectivement, c'est pas la mort !

Pour Apple, ouais, je connais, c'est ce qui fait dire à FLC qu'Apple (ou Atari puisque l'exception div/0 est vide) sont des systèmes plus performants puisqu'ils ne plantent pas, alors que Windows (le vilain) te renvoie une exception dans les gencives. C'est manifestement mieux d'avoir un fonctionnement non prédictible...

Kochise

Kochise (./11226) :
grosso-merdo

Je fais partie du klan exécutif terminal des tueurs de grossomerdophones

Folco (./11224) :

Kochise (./11218) :
J'ai jamais eu le cas, effectivement. Soit on demande s'il reste assez de mémoire, soit si on alloue et qu'on se prend un pointeur à 0, on le signale, on s'amuse pas à foutre des données à partir de l'adresse 0

J'ai lu beaucoup d'exemples de programme qui ne vérifie pas leurs allocations (les petites en général), leurs redimensionnement, leurs push_back sur des tableaux etc...
Je trouve ça crade.

-> set_new_handler et consorts
Noter qu'en temps normal un programme a peu de chances de se prendre un malloc() == 0. Sous Linux il sera nettoyé par l'OOM killer bien avant, et sous Windows ça ne peut arriver virtuellement que si l'utilisateur a désactivé la swap (mais là c'est lui qui est con, il mérite le plantage le plus destructif possible ).
Gérer les conditions d'erreur c'est beaucoup de travail pour pas grand chose, car il ne suffit pas de faire if (!pointeur) return, il faut toujours s'assurer que le programme retombe ensuite dans un état stable, que les pointeurs temporaires sont libérés, etc. et faire cette vérification prend du temps, et complique la maintenance.

Brunni (./11227) :
par l'OOM killer bien avant

Non la machine va s'effondrer bien avant

Si (je vois pas à quoi servirait l'OOM killer sinon...)

+1

Brunni (./11227) :
Gérer les conditions d'erreur c'est beaucoup de travail pour pas grand chose, car il ne suffit pas de faire if (!pointeur) return, il faut toujours s'assurer que le programme retombe ensuite dans un état stable, que les pointeurs temporaires sont libérés, etc. et faire cette vérification prend du temps, et complique la maintenance.

C'est pour ça qu'on a inventé les exceptions
Tu es toujours certain que ton application retombe dans un état stable comme ça… L'état stable ultime étant l'application qui se termine. (Si tu as choisi de ne pas gérer l'exception ^^)

iwannabeamaki (./11229) :
Si (je vois pas à quoi servirait l'OOM killer sinon...)

Pas a grand chose malheureusement, l'OOM est interessant que si l'overcommit n'est pas actif.

Pourquoi je dit ça ?

Parce que pour que l'OOM Killer se déclanche, il faut remplir la RAM et le SWAP, autant dire que ta machine va etre inutilisable un moment a swaper avant que l'OOMK se déclanche.

Non, j'ai un exemple récent : les indisponibilités de Mirari étaient liées à un module Apache qui leakait, et l'OOM s'est correctement déclenché à chaque fois, bien avant que le serveur ne plante complètement (ça a sauvé quelques jours d'uptime d'ailleurs).

pour info, c'est quel module qui plante? ça pourrait résoudre certains trucs sur ma propre bécane

L'empilement d'heuristiques ajoutées au cours du temps que constitue l'OOM killer de Linux <= 2.6.35.x, est loin de donner de bons résultats dans toutes les circonstances...
L'OOM killer finit normalement par réussir à tuer la tâche qui consomme trop de RAM, mais il y a en général des victimes innocentes, choisies sur des critères incompréhensibles des utilisateurs (tuer Thunderbird, ou même parfois Xorg et donc toute la session graphique, même s'ils consomment moins de RAM que par exemple Firefox, est une des grandes manies de l'OOM killer sur mes machines).

A priori, la réécriture mergée dans 2.6.36 devrait améliorer les choses, car elle part sur d'autres bases a priori plus simples et plus saines. Espérons que cette nouvelle version va y rester... elle est très fortement combattue par un développeur important du memory management, qui a déjà essayé plusieurs fois sans succès de faire passer des patches pour annuler complètement la réécriture: http://lkml.org/lkml/2010/11/14/5 .

./11234 : c'était apache2-mpm-prefork, peut-être à cause d'une mauvaise configuration, mais en tout cas le remplacer par apache2-mpm-worker semble avoir corrigé le problème.

squalyl@dedibox:~$ sudo apt-get install apache2-mpm-worker
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets suivants seront ENLEVÉS :
  apache2-mpm-prefork libapache2-mod-php5
Les NOUVEAUX paquets suivants seront installés :
  apache2-mpm-worker
0 mis à jour, 1 nouvellement installés, 2 à enlever et 2 non mis à jour.
Il est nécessaire de prendre 0o/242ko dans les archives.
Après cette opération, 5550ko d'espace disque seront libérés.
Souhaitez-vous continuer [O/n] ?

gni? virer php5?

edit: http://ubuntuforums.org/showthread.php?t=1038416

ahwé trop bien. La performance gagnée en virant prefork, tu la reperds en passant en CGI? t'as fait comment?

O\n

Avec prefork, tu perds aussi en isolation des requêtes les unes par rapport aux autres.

ça pourrait être ce qui nous fait planter le serveur.

Je suis obligé de passer absolument TOUTES les racines de vhosts en +ExecCGI si je passe par mpm-worker?

Brunni (./11227) :
sous Windows ça ne peut arriver virtuellement que si l'utilisateur a désactivé la swap (mais là c'est lui qui est con, il mérite le plantage le plus destructif possible ).

Hein ?

Ben pour qu'un malloc soit refusé il faut avoir désactivé la swap, sinon il ne sera refusé que si la RAM + swap est pleine, et ça ce n'est pas prêt d'arriver, surtout avec l'expansion automatique du pagefile que fait Windows
Sijnon d'accord avec GC, une allocation refusée c'est exceptionnel -> plus agréable à traiter comme tel (un ou deux close à faire dans le finally au pire, et c'en est fini pour le processus - récupérer d'une erreur c'est trop complexe pour ce que ça apporte).

Je vois pas ce qu'il y a de con à désactiver le swap... ce qui est plutôt con, c'est qu'il y a des cas où ça apporte un gain de performance de le faire !

Et pour le malloc(), je te croyais plus rigoureux que ça quand même
Perso au minimum c'est assert(ptr != NULL), sachant qu'effectivement ça va planter brutalement s'il n'y a pas assez de mémoire, mais au moins ce sera un plantage traçable. Entre ça et un comportement indéterminé, franchement, le choix est vite fait...

C'est si beau de gérer les cas d'erreurs au lieu de coder comme un porc

au moins un
if(!machin) return SOME_ERROR_CODE;

c'est une question de qualité minimale.