Pour évaluer les performances de Linux sous forte charge, le projet Linux Scalability Effort comprend naturellement un volet Test des différents systèmes de fichier, avec notamment des essais à forte charge des principaux systèmes de fichiers journalisés.
Les tests sont effectuées par examen de la tenue en charge, depuis le serveur, via samba.
On y apprend que reiserfs souffrirait d'un bizarre comportement sous forte charge, avec des gels momentanés. Le lien 'graphique qui tue' dévoile une intéressante anomalie de reiserfs sous forte charge.
Voilà un peu de grain à moudre...
Merci LWN pour avoir laissé trainer le mail du Linux Scalability Effort.
- Linux Scalability Effort (8 clics)
- Un graphique qui tue (27 clics)
- Le mail d'IBM à lwn.net (3 clics)
- Comparaison entre reiserfs et reiserfs'notail' (5 clics)
- Article original sur Bulma (3 clics)
# un petit lien qui manquait
Posté par Anonyme . Évalué à 3.
http://www.acnc.com/benchmarks.html(...)
http://hpwww.epfl.ch/bench/bench.html(...)
rafa_at_home pas authentifié because refus
--
Preums
[^] # Re: un petit lien qui manquait
Posté par Jiquem . Évalué à 1.
# gel momentane
Posté par jpph (page perso) . Évalué à 1.
It was interesting to see Reiserfs write at 800 blocks/sec, then nothing for 30 seconds, then again at ~800 blocks/sec. No other journal filesystem experienced that pattern of journal activity.
pour moi y a pas d'anomalie, reiserfs est juste moins performant dans les conditions du test.
[^] # hum, gel momentané de l'activité I/O disque
Posté par Anonyme . Évalué à 0.
write at 800 blocks/sec, then nothing for 30 seconds, then again at ~800 blocks/sec j'y comprends que le système écrit, pause 30'', puis écrit à nouveau, et ainsi de suite.
Il précise qu'aucun autre système de fichier journalisé ne se comporte ainsi.
Il n'a jamais été dit que le noyal freezait, juste l'activité disque (contre toute attente).
Je crois qu'on peut appeller cela une anomalie.
Je précise que j'utilise reiserfs sur mon portable (sujet à de rares plantages par excès de demande de resource de ma part) et que tout fonctionne nickel. Vite et bien.
Rafa
[^] # Re: hum, gel momentané de l'activité I/O disque
Posté par jpph (page perso) . Évalué à 1.
le jfs a 10000blocks/s ext 4000 block/s
[^] # Re: gel momentane
Posté par Manu (page perso) . Évalué à 1.
De plus un profiling semble montrer qu'une des fonctions qui est très souvent appelée soit particulièrement mal écrite.
Affaire à suivre.
-Manu
[^] # Re: gel momentane
Posté par Manu (page perso) . Évalué à 1.
L'option en question est l'option 'notail'
Mais le gars de chez IBM va refaire les tests quand même.
-Manu
[^] # Re: gel momentane
Posté par matiasf . Évalué à 1.
[^] # Re: gel momentane
Posté par Moule Atarte (page perso) . Évalué à -1.
[^] # Re: gel momentane
Posté par Anonyme . Évalué à 0.
interessant de reiserfs: la possiblité de stocker
plusieurs fichiers dans un seul block.
Sur mon disque qui contient pas mal de petits fichiers (code source), en passant de ext2 à reiserfs, j'ai gagné 30% de place disque !!!!!!
Avec 'notail', reiserfs bosse un peu comme ext2, et un fichier de 4 octets occupe 4Ko.
[^] # Re: gel momentane
Posté par Ramón Perez (page perso) . Évalué à 2.
C'est utile à savoit quand on veut faire des toutes petites partitions (genre moins de 100 Mo)....
[^] # Re: gel momentane
Posté par Anonyme . Évalué à 0.
est plus efficace que ext2. Et ca devient 'rentable'
a partir de 200 Mo.
Sinon sur le site de reiserfs, y'a tout ce qui faut
pour patcher, et avoir un journal de 2MB. Utile pour
des Flash.
# Tres objectif comme méthode.
Posté par core . Évalué à 1.
[^] # Re: Tres objectif comme méthode.
Posté par Pierre Tramo (page perso) . Évalué à 1.
De toutes facons, les benchs tout le monde sait ce que ca vaut.
[^] # Re: Tres objectif comme méthode.
Posté par psc . Évalué à 1.
dans les premiers, en tout cas
je ne regrette pas de l'avoir installer sur ma becane.
[^] # Re: Tres objectif comme méthode.
Posté par Manu (page perso) . Évalué à 2.
Voilà un autre lien (qui confirme les précédents tests) :
http://www.pingouin.org/linux/fsbench/(...)
-Manu
# un autre lien interressant
Posté par Réfa Touffu . Évalué à 1.
http://www.mandrakeforum.com/article.php?sid=1124&lang=en(...)
[^] # Re: un autre lien interressant
Posté par matiasf . Évalué à 1.
Quoique en général un poil moins bon en performance.
Mais es-ce très important ?
Ext3 est au point (nfs, quota (je crois qu'il reste un bug)).
Sa compatibilité avec ext2 en fait mon "chouchou".
Quelqu'un a-t-il testé ext3? quelles sont ces impressions?
[^] # Re: un autre lien interressant
Posté par matiasf . Évalué à 1.
http://linuxtoday.com/news_story.php3?ltsn=2001-08-22-004-20-NW-RH(...)
[^] # Re: un autre lien interressant
Posté par Anonyme . Évalué à 0.
http://aurora.zemris.fer.hr/filesystems/(...)
# Français quand tu nous tiens
Posté par Anonyme . Évalué à 0.
Dites, ça ne vous ferait rien d'employer le terme "tenue en charge" au lieu du bâtard "scalabilité" ?
Restons français, quoi...
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.