Aujourd'hui, disposant d'un peu de temps libre, j'ai eu l'idée de tester les performances de quelques systèmes d'exploitation.
Comme j'avais entendu dire tant de bien du libre et de sa stabilité, je me suis dit qu'un court comparatif pour appuyer cette affirmation ne pourrait qu'être utile.
J'ai donc choisi un unique test, portant sur la gestion de la mémoire, et j'y ai soumis les systèmes suivants :
1) Systèmes libres :
Linux Mandrake Cooker avec noyau 2.6.3-7mdk, installée par les soins du club Linux de mon établissement, sur x86 monoprocesseur.
Je n'ai volontairement pas testé de noyau de série 2.4, car je sais que l'allocateur de mémoire y est défaillant (rappel : en 2.4, un simple ls /*/../*/../*/../*/../*/../*/../* >/dev/null 2>/dev/null suffit à déclencher l'élimination de toute une foule de processus, y compris de processus root, en plus du bash qui ose essayer de lancer cette commande).
Evidemment, vous allez me dire "oui, mais MandrakeSoft patche le noyau, alors bon...", je réponds tout de suite, mon test utilise seulement deux appels-système, qui n'ont aucune raison d'être patchés (MandrakeSoft patche surtout pour des raisons de compatibilité du matériel, je crois).
2) Systèmes propriétaires :
- AIX 4.3 sur BULL PPC,
- AIX 5.2 sur IBM PPC,
- Solaris 8 sur Sun Sparc (sun4).
Le code du test est constitué du programme suivant (sans les "#include") :
int main(void){ while(malloc(1000000)!=NULL) fork();}
Tous ces programmes étaient compilés avec gcc, sans option particulière, puis lancés par un utilisateur non-root.
De plus, pour diverses raisons, j'avais tapé un "echo "kill -9 -1" | at now + 1 min" sur le Linux, chose que je n'ai pas refait sur les autres machines, toutefois, j'ai de bonnes raisons de penser que cette commande n'a guère eu d'effet.
Résultats :
l'AIX 4.3 a réagi tellement vite que je n'ai même pas eu le temps de voir ce qui se passait. Sa charge est montée un instant à 8, puis plus rien. Le résultat est tellement bon que je le trouve suspect, je me demande s'il n'a pas des limitations un peu fortes en matière de gestion de la mémoire.
Il a fallu attendre environ une minute sur l'AIX 5.2 pour qu'il revienne à une charge normale. Ni le service aux autres utilisateurs, ni le fonctionnement de mes processus n'ont été perturbés.
Il a fallu environ quatre minutes pour que le solaris se débarasse de ces processus et revienne à une charge plus normale. Ni le service aux autres utilisateurs, ni le fonctionnement de mes processus, n'ont été perturbés.
Il a fallu quatre heures pour que la machine Linux se débarrasse de ces processus et revienne à un état normal. Sa charge a dépassé les 800, elle a été à de nombreuse reprise signalée "down" (elle ne répondait plus au démon d'uptime), et tous mes processus ont freeze pendant cette durée (il n'y avait pas d'autre utilisateur).
La machine Linux partait pourtant avec cinq avantages : une architecture 32-bits (moins de mémoire adressable), un noyau plus récent, une machine monoprocesseur récente (pas de concurrence critique possible pour une puissance de calcul honorable), une RAM très nettement inférieure, une commande "kill -9 -1" qui devait se déclencher au bout d'une minute.
J'avoue que je suis assez embarrassé par le résultat de ce test. Les systèmes propriétaires ont battu à plate couture mon OS libre favori, alors que le test est franchement très simple. Pour être franc, ça m'inquiète sérieusement, car un serveur Linux doit justement entrer en production dans peu de temps à côté de ces serveurs propriétaires...
Enfin bref, j'ai pensé que, même s'il n'allait pas dans le sens souhaité par les utilisateurs de Linux (dont je fais partie), ces résultats pourraient vous intéresser.
Journal Comparatif entre systèmes d'exploitation
22
oct.
2004
# Ca donne quoi si tu fais...
Posté par jmf . Évalué à 5.
?
[^] # Re: Ca donne quoi si tu fais...
Posté par Pinaraf . Évalué à 1.
Ceci aiderait d'improbable googlistes qui tomberaient sur la page (et moi par la même occasion :)
[^] # Re: Ca donne quoi si tu fais...
Posté par jmf . Évalué à 1.
AMHA ce comportement different (stupide ?) de Linux fausse completement le test.
[^] # Re: Ca donne quoi si tu fais...
Posté par CoinKoin . Évalué à 4.
Le développement de /*/../ [...] /* prend trop de mémoire, donc le bash en demande plus qu'il n'y en a, et l'exterminateur de gestion mémoire tue des processus au hasard parmi ceux qui s'exécutent.
[^] # Re: Ca donne quoi si tu fais...
Posté par durandal . Évalué à 3.
D'ailleurs je me demande à quoi ça sert : il doit pas y avoir beaucoup de programmes qui allouent de la mémoire mais qui ne s'en servent pas. C'est une histoire d'optimisation peut-être...
On peut tester ça avec ce programme :
Chez moi, avec 256 Mo de RAM et 512 Mo de swap, ça me donne 2933 Mo, et 348 Mo avec l'overcommit_memory à 2 (pratique ce truc, je connaissais pas :).
[^] # Re: Ca donne quoi si tu fais...
Posté par CoinKoin . Évalué à 2.
Oui, ça, je le savais, mais je croyais que ce problème avait été résolu en 2.6. C'est justement pour ça que je n'avais pas testé de 2.4.
Cela dit, le coup de l'overcommit_memory a l'air très intéressant.
[^] # Re: Ca donne quoi si tu fais...
Posté par fasthm . Évalué à 5.
existe aussi dans certains unix commerciaux (je connais ça sous
Tru64, eager vs lazy swap modes).
on conseille de ne pas utiliser le lazy mode sur un système
multi utilisateur (au risque de voir les process d'utilisateurs innocents
se faire flinguer en cas de problème sur les processes de quelqu'un
d'autre).
par contre, sur une workstation mono utilisateur, le lazy mode
permet de gagner de la perf (on ne s'assure pas de pouvoir swapper
tous les processes à chaque allocation).
bref, tout ça pour dire que ce n'est pas un problème mais un choix
de fonctionnement : tu mets le doigts sur un truc intéressant, c'est
*pourquoi* les distrib ne désactivent pas le overcommit par défaut,
quitte à le documenter plus précisément si on cherche la perf...
et dès lundi je vais regarder sur mes machines, je connaissais mais
j'ai jamais regardé chez moi :)
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: Ca donne quoi si tu fais...
Posté par Lureau Marc-André . Évalué à 4.
(taille adressage utilisateur - taille adressage noyau)...
ton petit test ne sert pas a grand chose selon moi, car tu n'ecris pas en memoire !, essaie un peu d'ecrire la dedans (remplaces malloc par calloc par exemple)
Et si tu rajoutes un mmap au milieu, il y a des chances que cela ne fasse plus que 2G (attention, ca risque de changer avec le 2.6.9)
--
marco
# as-tu essayé ulimit ?
Posté par Olivier Jeannet . Évalué à 3.
[^] # Re: as-tu essayé ulimit ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Je serais curieux de voir le résultat sur les unix proprio avec :
int main(void){ while(malloc(10)!=NULL) fork();}
avec un beaucoup plus petit malloc...
"La première sécurité est la liberté"
[^] # Re: as-tu essayé ulimit ?
Posté par CoinKoin . Évalué à 4.
Donc c'est avant tout un problème de configuration, et non de système.
(En fait, la valeur du malloc était même doublement mal choisie, puisque cette valeur était trop petite pour permettre, comme je le comptais, une régulation rapide du nombre de processus par l'intermédiaire d'un échec du malloc() (car plus de place en mémoire centrale), mais tout de même assez grande pour favoriser un système avec quotas.)
O.K., je le reconnais, le comparatif était mauvais. CoinKoin, attention, tu vas te faire voler dans les plumes...
[^] # Re: as-tu essayé ulimit ?
Posté par ナイコ (site web personnel) . Évalué à 3.
...D'autant plus qu'il me semble avoir lu dans un LinuxMag que Malloc réserve de la mémoire, mais ne la consomme pas: Tu peux donc allouer beaucoup plus de mémoire que tu n'en a réellement. Mais dans ta boucle, essaye juste de toucher à quelques octets de cette mémoire allouée, et...
/me apporte les oranges.
# Pk pas ca :
Posté par Guillaume Knispel . Évalué à 8.
Ou alors :
J'ai voulu tester la fiabilité du LL alors j'ai fait cat /dev/zero > gngngn et je me suis rendu compte que sans quota le disque c'est rempli et mon système est tombé.
Ou encore :
Euh le LL ca pue dans certains 2.4 yavait un OOM killer qui faisait nawak et pouvait aller jusqu'à tuer des processus indispensable si un soft utilisateur allouait trop de mémoire.
Et ptet meme :
Fiabilité des portables contre un serveur redondant : euh le serveur il pue en débranchant sa prise de l'onduleur il s'eteind alors que mon portable il reste allumé ! Je crois que je vais foutre le serveur de fichiers pour 500 users sur mon portable !
De toute facon ton "La machine Linux partait pourtant avec cinq avantages : une architecture 32-bits (moins de mémoire adressable), un noyau plus récent, une machine monoprocesseur récente (pas de concurrence critique possible pour une puissance de calcul honorable), une RAM très nettement inférieure, une commande "kill -9 -1" qui devait se déclencher au bout d'une minute." m'indique que tu ne sais pas trop de quoi tu parles...
[^] # Re: Pk pas ca :
Posté par CoinKoin . Évalué à 4.
Arf... :-)
Je ne dis pas que mon test était significatif d'une mauvaise qualité intrinsèque des OS libres.
Je n'ai jamais dit que Linux était mauvais non plus, j'ai dit qu'il avait franchement raté mon unique test. Je n'ai fait qu'un seul test, parce que je n'avais pas énormément de temps, et autre chose à faire.
Un test seul, il est clair que ça n'est pas représentatif, cela dit, si n'importe qui peut faire ce coup-là, il est tout aussi clair qu'il y a un gros problème.
De toute facon ton "La machine Linux partait pourtant avec cinq avantages : une architecture 32-bits (moins de mémoire adressable), un noyau plus récent, une machine monoprocesseur récente (pas de concurrence critique possible pour une puissance de calcul honorable), une RAM très nettement inférieure, une commande "kill -9 -1" qui devait se déclencher au bout d'une minute." m'indique que tu ne sais pas trop de quoi tu parles...
Tu peux développer? Il est fort possible que j'ai estimé comme étant des avantages des points qui ne l'étaient pas vraiment. Explique-moi, je ne demande qu'à apprendre!
[^] # Re: Pk pas ca :
Posté par chl (site web personnel) . Évalué à 4.
Tu peux développer? Il est fort possible que j'ai estimé comme étant des avantages des points qui ne l'étaient pas vraiment. Explique-moi, je ne demande qu'à apprendre!
Bon ben je suis pas specialiste mais :
- "une architecture 32-bits (moins de mémoire adressable)"
Il est possible d'adresser plus de 4Go sur une archi 32 bits, grace a la memoire virtuelle.
- "un noyau plus récent"
comparer le noyau linux, avec celui des systemes proprios ne rime a rien. Il faut comparer ce qui est comparable.
- "kill -9 -1" qui devait se déclencher au bout d'une minute."
Si tu surcharges ton systeme, tout est ralenti (normal tu me diras). Donc ta commande censée s'executer dans une minute, ben elle le fera bien apres, lorsqu'elle le pourra. En plus, a cause du fait que certains processus peuvent etre tués au hazard, tu ne peux pas savoir si cette commande sera vraiment executée ou non...
Pour les autres points, j'ai pas compris ce que tu voulais dire (machine mono proc, et RAM inferieure).
[^] # Re: Pk pas ca :
Posté par CoinKoin . Évalué à 2.
Non, justement pas. la mémoire virtuelle permet d'atteindre ces 4Go (enfin, pas toujours, il faut compter l'existence d'adresses réservées et autres...), mais jamais de les dépasser.
comparer le noyau linux, avec celui des systemes proprios ne rime a rien. Il faut comparer ce qui est comparable.
Je pensais que le noyau Linux aurait éventuellement bénéficié de progrès récents dans la technologie. Si on découvre un nouvel algorithme dans 6 mois, il ne pourra pas être disponible sur une machine actuelle.
Si tu surcharges ton systeme, tout est ralenti (normal tu me diras). Donc ta commande censée s'executer dans une minute, ben elle le fera bien apres, lorsqu'elle le pourra
Je n'en suis pas à mon coup d'essai avec ce genre de commandes. L'an dernier, j'avais lancé cette commande juste avant un while(1) fork(); sur une machine Linux sans quotas, et la commande s'exécutait systématiquement au bout de quelques minutes seulement.
D'après mes constats, atd n'a pas été tué par ma manip', donc la commande aurait du être exéctuée au bout de quelques minutes, comme la dernière fois. Manifestement, ça n'a pas été le cas.
Pour la machine monoproc, c'est vrai que ce n'est pas un avantage net (cela évite tout risque de concurrence critique lors de l'accès à la RAM, mais le risque était assez improbable).
Pour ce qui est de la RAM inférieure, ben, moins tu as de RAM, plus vite tu devrais renvoyer NULL à une demande de malloc(), non?
[^] # Re: Pk pas ca :
Posté par Ramso . Évalué à 3.
> (enfin, pas toujours, il faut compter l'existence d'adresses réservées
> et autres...), mais jamais de les dépasser.
'Tain ! je me demande à quoi sert l'option du noyau pour adresser 16 Go de RAM alors !
Puis aussi pourquoi j'ai besoin de mémoire virtuelle alors que mon compatible 386 en mode protéger peut adresser 2^32 = 4 Go !
[^] # Re: Pk pas ca :
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En mode PTE (?), l'os peut gérer qq bits de plus pour gérer jusqu'à 64 Go de RAM avec une sorte de pagination au niveau OS. Donc un seul process ne verra jamais plus de 4 Go.
"La première sécurité est la liberté"
[^] # Re: Pk pas ca :
Posté par CoinKoin . Évalué à 2.
A permettre au noyau de gérer plus de 4Go de RAM, pas à un processus non protégé d'en utiliser plus.
>Puis aussi pourquoi j'ai besoin de mémoire virtuelle alors que mon compatible 386 en mode protéger peut adresser 2^32 = 4 Go !
Oui, mais seul le kernel s'exécute en mode protégé. De plus, il serait inacceptable (et interdit par l'architecture x86, de toutes façons), qu'un processus en userspace adresse une zone mémoire quelconque sans s'appuyer sur le contenu d'un registre de segment (comment tu vérifies qu'il adresse une zone qui lui appartient?).
Comme la pagination offre autrement plus de souplesse que la segmentation, la mémoire virtuelle utilise la pagination, mais on pourrait s'en tenir là (avec une grosse GDT).
Pour plus de détails à ce sujet, je te renvoie à ladocumentation intel.
[^] # Re: Pk pas ca :
Posté par ckyl . Évalué à 3.
Des progres... oui que la machine devienne intelligente; d'apres [1] ca serait pas possible :-)
Quand tu es a cours de memoire
1/ tu ne fais rien, la charge va s'envoler, la machine va partir au tas
2/ tuer la tache qui a le plus de memoire alloue : merde tu viens de tuer la BDD qui bouffait 8Go de RAM c'est con !
3/ tuer la tache qui a le debit d'allocation memoire le plus eleve, c'est pas dit que tu tue la bonne tache
4/ tuer une tache au hasard c'est pas mieux.
5/ tuer la tache qui vient de faire la demande d'allocation memoire, c'est pas dit que ce soit la bonne
6/ pouvoir proteger certains process de l'OOM killer c'est mieux
7/ indiquer les taches a tuer a l'OOM killer c'est lourd a gerer
8/ tu as une proposition ?
Le choix de l'action a prendre est SUBJECTIF. Il n'y a pas d'algorithme satisfaisant pour ce problème. C'est a l'administrateur de savoir administrer et aux developpeurs de fournir ce dont l'admin a besoin.
http://lwn.net/Articles/104185/(...)
Linux te permet deja de faire pas mal de chose et autrement c'est pas enorme a coder.
solution : mettre des restrictions sur les utilisateurs et attendre les plaintes par ce que c'est trop restrictif. Apres si quelqu'un a un compte local c'est qu'il est digne de confiance et mettre une limit raisonable pour eviter les erreurs suffit en general.
[1] :
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about as
relevant as the question of whether submarines can swim.
-- Dijkstra
[^] # Re: Pk pas ca :
Posté par Ramso . Évalué à 4.
[^] # Re: Pk pas ca :
Posté par ckyl . Évalué à 3.
[^] # Re: Pk pas ca :
Posté par CoinKoin . Évalué à 3.
Parce que, chez toi, ton système tombe quand il a son /home (ou son /tmp) plein ?
(Pas de chance, j'ai déjà tenté cette manipulation :-) .)
[^] # Re: Pk pas ca :
Posté par ナイコ (site web personnel) . Évalué à 7.
Anecdote: Un serveur de fichiers Samba, chez nous, faisait aussi serveur DHCP pour les workstations des utilisateurs.
Coup de fil d'une secrétaire, un matin: "Ouééé, ma machine marche pas, elle prend mon mot de passe mais je ne peux aller lire mes fichiers sur le réseau" (Windows garde les mots de passe en mémoire un certain temps entre deux connexions...).
Bon, nous pensons tout de suite à un problème de câble réseau ou ce genre de chose, et un collègue part dépanner. Pendant ce temps, je reçois un autre coup de fil: "J'peux pas rentrer sur ma session" !!! Puis un autre, puis encore un... Les machines se mettaient toutes à déconner l'une après l'autre :o !
Obligé d'arrêter mes tests sur le serveur samba/dhcp (cité plus haut) pour aller chercher la panne :(... Tiens, d'ailleur, merde, j'avais oublié d'enlever "loglevel = 10" dens le smb.conf, moi... Tiens, ce con m'a rempli la partition /var/ ! Tiens, ça a fait planter dhcp qui ne peut plus écrire dans /var/.../dhcpd.leases !
Les stations ne pouvant plus renouveler leur bail, elle perdaient leur IP une par une... Se coupant du réseau.
Moralité en forme de proverbe chinois:
Si tes stations une par une planter,
Regarde ton humble dhcp !
[^] # Re: Pk pas ca :
Posté par Sébastien Munch . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.