je cherche a mesurer le temps que prend une application a se lancer.
Je vais modifier des parametres, puis la relancer, remesurer, etc..
L'ennui, c'est qu'immanquablement un moment ou un autre le cache disque
de linux va se mettre en oeuvre. Et la, mes mesures seront faussees.
Y'a t'il un moyen simple de forcer le cache disque a se vider afin de
faire un test "reel" ?
Le but:
je trouve que firefox met longtemps a se charger (beaucoup trop).
Je veux essayer d'installer entierement firefox dans un fichier loop
(binaires + conf +cache). Ce fichier loop sera lu en une seule fois (a
la vitesse du debit du disque), et charge en RAM. Les acces multiples
aux nombreux fichiers differents seront rapides:
Dans le cas normal, la tete de lecture du disque doit se deplacer entre
chaque fichier lu. Et a 10ms, de temps d'acces, ca prend deja 1s par
centaine de fichiers lu en dehors de la duree de lecture des dits
fichiers.. Si on supprime toutes ces attentes, ca devrait aller plus
vite.
Si ca marche pour firefox, ca devrait marcher pour d'autres applis
comme OpenOffice, etc..
Mais pour bencher cette idee et affirmer une vitesse d'execution plus
grande, il faut que je sois sur que le cache de linux n'entre pas en
jeu, d'ou ma question.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Vincent Bernat
OoO En cette fin de matinée radieuse du jeudi 24 août 2006, vers 11:59, disait:
Bonjour, je cherche a mesurer le temps que prend une application a se lancer. Je vais modifier des parametres, puis la relancer, remesurer, etc..
L'ennui, c'est qu'immanquablement un moment ou un autre le cache disque de linux va se mettre en oeuvre. Et la, mes mesures seront faussees. Y'a t'il un moyen simple de forcer le cache disque a se vider afin de faire un test "reel" ?
sync effectue un flush du cache disque en écriture. Pour le cache en lecture, généralement, on fait quelque chose du genre :
for i in /bin/* /usr/bin/* ; cat $i > /dev/null ; done
Il existe peut-être des moyens plus propres, mais c'est une première piste. -- panic("Oh boy, that early out of memory?"); 2.2.16 /usr/src/linux/arch/mips/mm/init.c
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
OoO En cette fin de matinée radieuse du jeudi 24 août 2006, vers
11:59, octane@alinto.com disait:
Bonjour,
je cherche a mesurer le temps que prend une application a se lancer.
Je vais modifier des parametres, puis la relancer, remesurer, etc..
L'ennui, c'est qu'immanquablement un moment ou un autre le cache disque
de linux va se mettre en oeuvre. Et la, mes mesures seront faussees.
Y'a t'il un moyen simple de forcer le cache disque a se vider afin de
faire un test "reel" ?
sync effectue un flush du cache disque en écriture. Pour le cache en
lecture, généralement, on fait quelque chose du genre :
for i in /bin/* /usr/bin/* ; cat $i > /dev/null ; done
Il existe peut-être des moyens plus propres, mais c'est une première
piste.
--
panic("Oh boy, that early out of memory?");
2.2.16 /usr/src/linux/arch/mips/mm/init.c
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
OoO En cette fin de matinée radieuse du jeudi 24 août 2006, vers 11:59, disait:
Bonjour, je cherche a mesurer le temps que prend une application a se lancer. Je vais modifier des parametres, puis la relancer, remesurer, etc..
L'ennui, c'est qu'immanquablement un moment ou un autre le cache disque de linux va se mettre en oeuvre. Et la, mes mesures seront faussees. Y'a t'il un moyen simple de forcer le cache disque a se vider afin de faire un test "reel" ?
sync effectue un flush du cache disque en écriture. Pour le cache en lecture, généralement, on fait quelque chose du genre :
for i in /bin/* /usr/bin/* ; cat $i > /dev/null ; done
Il existe peut-être des moyens plus propres, mais c'est une première piste. -- panic("Oh boy, that early out of memory?"); 2.2.16 /usr/src/linux/arch/mips/mm/init.c
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Manu
wrote:
L'ennui, c'est qu'immanquablement un moment ou un autre le cache disque de linux va se mettre en oeuvre. Et la, mes mesures seront faussees. Y'a t'il un moyen simple de forcer le cache disque a se vider afin de faire un test "reel" ?
En lisant plein d'autre "trucs" afin de lui faire oublier Firefox ? En démontant une partition on peut supposer que les entrées associées dans le cache seront supprimer...
Le but: je trouve que firefox met longtemps a se charger (beaucoup trop). Je veux essayer d'installer entierement firefox dans un fichier loop (binaires + conf +cache). Ce fichier loop sera lu en une seule fois (a la vitesse du debit du disque), et charge en RAM. Les acces multiples aux nombreux fichiers differents seront rapides:
Tu peux aussi essayer avec un fichier en loopback compressé avec cloop. En fois compressée l'ensemble de mon Firefox fait pèse presque 5 fois moins.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
octane@alinto.com wrote:
L'ennui, c'est qu'immanquablement un moment ou un autre le cache disque
de linux va se mettre en oeuvre. Et la, mes mesures seront faussees.
Y'a t'il un moyen simple de forcer le cache disque a se vider afin de
faire un test "reel" ?
En lisant plein d'autre "trucs" afin de lui faire oublier Firefox ?
En démontant une partition on peut supposer que les entrées associées
dans le cache seront supprimer...
Le but:
je trouve que firefox met longtemps a se charger (beaucoup trop).
Je veux essayer d'installer entierement firefox dans un fichier loop
(binaires + conf +cache). Ce fichier loop sera lu en une seule fois (a
la vitesse du debit du disque), et charge en RAM. Les acces multiples
aux nombreux fichiers differents seront rapides:
Tu peux aussi essayer avec un fichier en loopback compressé avec cloop.
En fois compressée l'ensemble de mon Firefox fait pèse presque 5 fois moins.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
L'ennui, c'est qu'immanquablement un moment ou un autre le cache disque de linux va se mettre en oeuvre. Et la, mes mesures seront faussees. Y'a t'il un moyen simple de forcer le cache disque a se vider afin de faire un test "reel" ?
En lisant plein d'autre "trucs" afin de lui faire oublier Firefox ? En démontant une partition on peut supposer que les entrées associées dans le cache seront supprimer...
Le but: je trouve que firefox met longtemps a se charger (beaucoup trop). Je veux essayer d'installer entierement firefox dans un fichier loop (binaires + conf +cache). Ce fichier loop sera lu en une seule fois (a la vitesse du debit du disque), et charge en RAM. Les acces multiples aux nombreux fichiers differents seront rapides:
Tu peux aussi essayer avec un fichier en loopback compressé avec cloop. En fois compressée l'ensemble de mon Firefox fait pèse presque 5 fois moins.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Manu
Manu wrote:
Tu peux aussi essayer avec un fichier en loopback compressé avec cloop. En fois compressée l'ensemble de mon Firefox fait pèse presque 5 fois moins.
Tu peux aussi essayé e2compr qui (dé)compresse les fichiers à la volée. Sinon il y a cramfs et squashfs qui sont des systèmes de fichiers avec compression mais en lecture seule.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Manu wrote:
Tu peux aussi essayer avec un fichier en loopback compressé avec cloop.
En fois compressée l'ensemble de mon Firefox fait pèse presque 5 fois moins.
Tu peux aussi essayé e2compr qui (dé)compresse les fichiers à la volée.
Sinon il y a cramfs et squashfs qui sont des systèmes de fichiers avec
compression mais en lecture seule.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Tu peux aussi essayer avec un fichier en loopback compressé avec cloop. En fois compressée l'ensemble de mon Firefox fait pèse presque 5 fois moins.
Tu peux aussi essayé e2compr qui (dé)compresse les fichiers à la volée. Sinon il y a cramfs et squashfs qui sont des systèmes de fichiers avec compression mais en lecture seule.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
octane
Manu a écrit :
> Le but: > je trouve que firefox met longtemps a se charger (beaucoup trop). > Je veux essayer d'installer entierement firefox dans un fichier loop > (binaires + conf +cache). Ce fichier loop sera lu en une seule fois (a > la vitesse du debit du disque), et charge en RAM. Les acces multiples > aux nombreux fichiers differents seront rapides:
Tu peux aussi essayer avec un fichier en loopback compressé avec cloop. En fois compressée l'ensemble de mon Firefox fait pèse presque 5 fois moins.
Et non, rien a voir.. Le probleme ne vient pas de la quantite en taille des donnees a lire, mais du nombre de fichiers a lire et des acces disque. Soit un fichier de 100Mo non fragmente sur un disque recent. A 50Mo/s il est lu en 2 secondes, plus le temps que met la tete de lecture du disque a se positionner en debut de fichier (mettons 10ms). Soit maintenant 1000 fichier de 1 ko (donc 1Mo, cent fois moins!), eparpilles sur le disque. Je neglige la duree de lecture du fichier, mais la tete de lecture fera 1000 temps d'acces de 10ms, soit 10s de lecture au total!!
Donc pour lire 100Mo, on met 2s, et pour lire 1Mo, on met 10s!!
Si je prends le cas de firefox: $ find /usr/lib/mozilla-firefox/ | wc -l 393 $ du -h /usr/lib/mozilla-firefox/ | tail -1 25M /usr/lib/mozilla-firefox/ $ find .mozilla/firefox/ | wc -l 149 $ du -h .mozilla/firefox/ | tail -1 23M .mozilla/firefox/
48Mo au total et 550 fichers. Si j'ai un gros fichier unique, il est lu en 1s. les 550 fichiers prendront 5.5s pour etre accedes.
C'est un calcul grossier et a la louche, mais j'aimerai justement affiner ce calcul grossier pour voir quel est l'impact réel du grand nombre d'acces a de petits fichiers.
Je ne cherche pas a diminuer la taille de firefox, mais a diminuer le nombre de deplacements de la tete de lecture de mon disque dur!
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Manu a écrit :
> Le but:
> je trouve que firefox met longtemps a se charger (beaucoup trop).
> Je veux essayer d'installer entierement firefox dans un fichier loop
> (binaires + conf +cache). Ce fichier loop sera lu en une seule fois (a
> la vitesse du debit du disque), et charge en RAM. Les acces multiples
> aux nombreux fichiers differents seront rapides:
Tu peux aussi essayer avec un fichier en loopback compressé avec cloop.
En fois compressée l'ensemble de mon Firefox fait pèse presque 5 fois moins.
Et non, rien a voir..
Le probleme ne vient pas de la quantite en taille des donnees a lire,
mais du nombre de fichiers a lire et des acces disque.
Soit un fichier de 100Mo non fragmente sur un disque recent. A 50Mo/s
il est lu en 2 secondes, plus le temps que met la tete de lecture du
disque a se positionner en debut de fichier (mettons 10ms).
Soit maintenant 1000 fichier de 1 ko (donc 1Mo, cent fois moins!),
eparpilles sur le disque. Je neglige la duree de lecture du fichier,
mais la tete de lecture fera 1000 temps d'acces de 10ms, soit 10s de
lecture au total!!
Donc pour lire 100Mo, on met 2s, et pour lire 1Mo, on met 10s!!
Si je prends le cas de firefox:
$ find /usr/lib/mozilla-firefox/ | wc -l
393
$ du -h /usr/lib/mozilla-firefox/ | tail -1
25M /usr/lib/mozilla-firefox/
$ find .mozilla/firefox/ | wc -l
149
$ du -h .mozilla/firefox/ | tail -1
23M .mozilla/firefox/
48Mo au total et 550 fichers.
Si j'ai un gros fichier unique, il est lu en 1s.
les 550 fichiers prendront 5.5s pour etre accedes.
C'est un calcul grossier et a la louche, mais j'aimerai justement
affiner ce calcul grossier pour voir quel est l'impact réel du grand
nombre d'acces a de petits fichiers.
Je ne cherche pas a diminuer la taille de firefox, mais a diminuer le
nombre de deplacements de la tete de lecture de mon disque dur!
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
> Le but: > je trouve que firefox met longtemps a se charger (beaucoup trop). > Je veux essayer d'installer entierement firefox dans un fichier loop > (binaires + conf +cache). Ce fichier loop sera lu en une seule fois (a > la vitesse du debit du disque), et charge en RAM. Les acces multiples > aux nombreux fichiers differents seront rapides:
Tu peux aussi essayer avec un fichier en loopback compressé avec cloop. En fois compressée l'ensemble de mon Firefox fait pèse presque 5 fois moins.
Et non, rien a voir.. Le probleme ne vient pas de la quantite en taille des donnees a lire, mais du nombre de fichiers a lire et des acces disque. Soit un fichier de 100Mo non fragmente sur un disque recent. A 50Mo/s il est lu en 2 secondes, plus le temps que met la tete de lecture du disque a se positionner en debut de fichier (mettons 10ms). Soit maintenant 1000 fichier de 1 ko (donc 1Mo, cent fois moins!), eparpilles sur le disque. Je neglige la duree de lecture du fichier, mais la tete de lecture fera 1000 temps d'acces de 10ms, soit 10s de lecture au total!!
Donc pour lire 100Mo, on met 2s, et pour lire 1Mo, on met 10s!!
Si je prends le cas de firefox: $ find /usr/lib/mozilla-firefox/ | wc -l 393 $ du -h /usr/lib/mozilla-firefox/ | tail -1 25M /usr/lib/mozilla-firefox/ $ find .mozilla/firefox/ | wc -l 149 $ du -h .mozilla/firefox/ | tail -1 23M .mozilla/firefox/
48Mo au total et 550 fichers. Si j'ai un gros fichier unique, il est lu en 1s. les 550 fichiers prendront 5.5s pour etre accedes.
C'est un calcul grossier et a la louche, mais j'aimerai justement affiner ce calcul grossier pour voir quel est l'impact réel du grand nombre d'acces a de petits fichiers.
Je ne cherche pas a diminuer la taille de firefox, mais a diminuer le nombre de deplacements de la tete de lecture de mon disque dur!
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Loki Harfagr
Le Thu, 24 Aug 2006 14:40:28 +0000, Vincent Bernat a écrit :
OoO En cette fin de matinée radieuse du jeudi 24 août 2006, vers 11:59, disait:
Bonjour, je cherche a mesurer le temps que prend une application a se lancer. Je vais modifier des parametres, puis la relancer, remesurer, etc..
L'ennui, c'est qu'immanquablement un moment ou un autre le cache disque de linux va se mettre en oeuvre. Et la, mes mesures seront faussees. Y'a t'il un moyen simple de forcer le cache disque a se vider afin de faire un test "reel" ?
sync effectue un flush du cache disque en écriture. Pour le cache en lecture, généralement, on fait quelque chose du genre :
for i in /bin/* /usr/bin/* ; cat $i > /dev/null ; done
Il existe peut-être des moyens plus propres, mais c'est une première piste.
Peut-être un truc de ce genre ? (en choisissant la taille, ici 128 Mo) # dd if=/dev/zero of=/dev/null bs=1M count8
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le Thu, 24 Aug 2006 14:40:28 +0000, Vincent Bernat a écrit :
OoO En cette fin de matinée radieuse du jeudi 24 août 2006, vers
11:59, octane@alinto.com disait:
Bonjour,
je cherche a mesurer le temps que prend une application a se lancer.
Je vais modifier des parametres, puis la relancer, remesurer, etc..
L'ennui, c'est qu'immanquablement un moment ou un autre le cache disque
de linux va se mettre en oeuvre. Et la, mes mesures seront faussees.
Y'a t'il un moyen simple de forcer le cache disque a se vider afin de
faire un test "reel" ?
sync effectue un flush du cache disque en écriture. Pour le cache en
lecture, généralement, on fait quelque chose du genre :
for i in /bin/* /usr/bin/* ; cat $i > /dev/null ; done
Il existe peut-être des moyens plus propres, mais c'est une première
piste.
Peut-être un truc de ce genre ? (en choisissant la taille, ici 128 Mo)
# dd if=/dev/zero of=/dev/null bs=1M count8
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le Thu, 24 Aug 2006 14:40:28 +0000, Vincent Bernat a écrit :
OoO En cette fin de matinée radieuse du jeudi 24 août 2006, vers 11:59, disait:
Bonjour, je cherche a mesurer le temps que prend une application a se lancer. Je vais modifier des parametres, puis la relancer, remesurer, etc..
L'ennui, c'est qu'immanquablement un moment ou un autre le cache disque de linux va se mettre en oeuvre. Et la, mes mesures seront faussees. Y'a t'il un moyen simple de forcer le cache disque a se vider afin de faire un test "reel" ?
sync effectue un flush du cache disque en écriture. Pour le cache en lecture, généralement, on fait quelque chose du genre :
for i in /bin/* /usr/bin/* ; cat $i > /dev/null ; done
Il existe peut-être des moyens plus propres, mais c'est une première piste.
Peut-être un truc de ce genre ? (en choisissant la taille, ici 128 Mo) # dd if=/dev/zero of=/dev/null bs=1M count8
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Vincent Bernat
OoO Pendant le temps de midi du lundi 28 août 2006, vers 12:09, Loki Harfagr disait:
for i in /bin/* /usr/bin/* ; cat $i > /dev/null ; done
Il existe peut-être des moyens plus propres, mais c'est une première piste.
Peut-être un truc de ce genre ? (en choisissant la taille, ici 128 Mo) # dd if=/dev/zero of=/dev/null bs=1M count8
/dev/zero étant un pseudo device, ça va pas provoquer beaucoup de lectures sur le disque, donc cela n'aura aucun effet sur le cache. -- BOFH excuse #447: According to Microsoft, it's by design
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
OoO Pendant le temps de midi du lundi 28 août 2006, vers 12:09, Loki
Harfagr <l0k1@free.fr> disait:
for i in /bin/* /usr/bin/* ; cat $i > /dev/null ; done
Il existe peut-être des moyens plus propres, mais c'est une première
piste.
Peut-être un truc de ce genre ? (en choisissant la taille, ici 128 Mo)
# dd if=/dev/zero of=/dev/null bs=1M count8
/dev/zero étant un pseudo device, ça va pas provoquer beaucoup de
lectures sur le disque, donc cela n'aura aucun effet sur le cache.
--
BOFH excuse #447:
According to Microsoft, it's by design
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
OoO Pendant le temps de midi du lundi 28 août 2006, vers 12:09, Loki Harfagr disait:
for i in /bin/* /usr/bin/* ; cat $i > /dev/null ; done
Il existe peut-être des moyens plus propres, mais c'est une première piste.
Peut-être un truc de ce genre ? (en choisissant la taille, ici 128 Mo) # dd if=/dev/zero of=/dev/null bs=1M count8
/dev/zero étant un pseudo device, ça va pas provoquer beaucoup de lectures sur le disque, donc cela n'aura aucun effet sur le cache. -- BOFH excuse #447: According to Microsoft, it's by design
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Manu
wrote:
Et non, rien a voir.. Le probleme ne vient pas de la quantite en taille des donnees a lire, mais du nombre de fichiers a lire et des acces disque.
Ok donc cramfs et sqaushfs ne pourront rien pour toi mais je reste persuadé qu'un fichier faisant office de loopback compressé (pour peu que le fichier en question ne soit pas trop fragmenté sur le disque) ira plus vite. Le mieux est d'essayer.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
octane@alinto.com wrote:
Et non, rien a voir..
Le probleme ne vient pas de la quantite en taille des donnees a lire,
mais du nombre de fichiers a lire et des acces disque.
Ok donc cramfs et sqaushfs ne pourront rien pour toi mais je reste
persuadé qu'un fichier faisant office de loopback compressé (pour peu
que le fichier en question ne soit pas trop fragmenté sur le disque) ira
plus vite.
Le mieux est d'essayer.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Et non, rien a voir.. Le probleme ne vient pas de la quantite en taille des donnees a lire, mais du nombre de fichiers a lire et des acces disque.
Ok donc cramfs et sqaushfs ne pourront rien pour toi mais je reste persuadé qu'un fichier faisant office de loopback compressé (pour peu que le fichier en question ne soit pas trop fragmenté sur le disque) ira plus vite. Le mieux est d'essayer.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Damien Wyart
* in fr.comp.os.linux.moderated:
Y'a t'il un moyen simple de forcer le cache disque a se vider afin de faire un test "reel" ?
On peut regarder du côté de /proc/sys/vm/drop_caches, plus précisément : echo 3 > /proc/sys/vm/drop_caches (cf Documentation/filesystems/proc.txt).
-- DW
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
* octane@alinto.com in fr.comp.os.linux.moderated:
Y'a t'il un moyen simple de forcer le cache disque a se vider afin de
faire un test "reel" ?
On peut regarder du côté de /proc/sys/vm/drop_caches, plus précisément :
echo 3 > /proc/sys/vm/drop_caches
(cf Documentation/filesystems/proc.txt).
--
DW
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Y'a t'il un moyen simple de forcer le cache disque a se vider afin de faire un test "reel" ?
On peut regarder du côté de /proc/sys/vm/drop_caches, plus précisément : echo 3 > /proc/sys/vm/drop_caches (cf Documentation/filesystems/proc.txt).
-- DW
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Olivier Croquette
wrote:
$ du -h /usr/lib/mozilla-firefox/ | tail -1 25M /usr/lib/mozilla-firefox/
Juste pour info, "du -hs" fait la même chose.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
octane@alinto.com wrote:
$ du -h /usr/lib/mozilla-firefox/ | tail -1
25M /usr/lib/mozilla-firefox/
Juste pour info, "du -hs" fait la même chose.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
$ du -h /usr/lib/mozilla-firefox/ | tail -1 25M /usr/lib/mozilla-firefox/
Juste pour info, "du -hs" fait la même chose.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Pierre Salagnac
Manu wrote:
Manu wrote:
Tu peux aussi essayé e2compr qui (dé)compresse les fichiers à la volée. Sinon il y a cramfs et squashfs qui sont des systèmes de fichiers avec compression mais en lecture seule.
J'aurai plutôt pensé à utiliser tmpfs. Avec ça, tu travaille entièrement en mémoire et donc plus d'accès au disque. Mais attention il ne faut pas être trop gourmand car si tu utilise trop de mémoire de système la passera en swap donc les mesures seront complètement fausses.
Pierre
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Manu wrote:
Manu wrote:
Tu peux aussi essayé e2compr qui (dé)compresse les fichiers à la volée.
Sinon il y a cramfs et squashfs qui sont des systèmes de fichiers avec
compression mais en lecture seule.
J'aurai plutôt pensé à utiliser tmpfs. Avec ça, tu travaille entièrement en
mémoire et donc plus d'accès au disque. Mais attention il ne faut pas être
trop gourmand car si tu utilise trop de mémoire de système la passera en
swap donc les mesures seront complètement fausses.
Pierre
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Tu peux aussi essayé e2compr qui (dé)compresse les fichiers à la volée. Sinon il y a cramfs et squashfs qui sont des systèmes de fichiers avec compression mais en lecture seule.
J'aurai plutôt pensé à utiliser tmpfs. Avec ça, tu travaille entièrement en mémoire et donc plus d'accès au disque. Mais attention il ne faut pas être trop gourmand car si tu utilise trop de mémoire de système la passera en swap donc les mesures seront complètement fausses.
Pierre
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
