Hello, sous Windows c'est une des tâches qu'on entend comme nécessaires
à faire de temps en temps, il en est quoi sous Linux ? C'est nécessaire
de défragmenter ou pas ? Il y a des programmes de défragmentation ?
--
http://zetrader.info & http://zetrader.fr
Forum http://zeforums.com - http://aribaut.com
La curiosité: je voudrais voir le visu. du rapport donnant le bilan de
Lancer e2fsck sur la partition montée en ro (mount -o remount,ro /data) avec l'option -f et en théorie il indique le pourcentage non contigu. Maintenant, si la performance reste acceptable, pourquoi s'en préoccuper? Si la performance n'est pas acceptable, ce n'est pas dit que cela soit un problème de fragmentation, d'ailleurs.
Audacity), couplés à une myriade de petits - relativement aux précédents -
Une myriade de fichiers agencés comment? La méthode `squid' (hâcher le nom de fichier et stocker dans d1/d2/fichier avec d1 et d2 obtenus par la fonction de hâchage de manière à répartir les N fichiers dans 256 répertoires différents (8 x 8) permet d'assurer la performance quand N est très grand même sur des fs de mauvaise qualité. Mais bon, dans mon expérience, si N < 10'00 on ne voit pas trop la différence avec ou sans stockage réparti `squid'. Après, si les données sont de courte taille, pourquoi ne pas réfléchir à un autre système de stockage qu'un filesystem, p.ex. une base de données clé-valeur style dbm 198x ou ce-qui-se-fait-de-mieux-ce-mois- en-big-data.
zeLittle <noreply@noreply.net> wrote:
La curiosité: je voudrais voir le visu. du rapport donnant le bilan de
Lancer e2fsck sur la partition montée en ro (mount -o remount,ro /data)
avec l'option -f et en théorie il indique le pourcentage non
contigu.
Maintenant, si la performance reste acceptable, pourquoi s'en
préoccuper?
Si la performance n'est pas acceptable, ce n'est pas dit que cela
soit un problème de fragmentation, d'ailleurs.
Audacity), couplés à une myriade de petits - relativement aux précédents -
Une myriade de fichiers agencés comment? La méthode `squid' (hâcher le
nom de fichier et stocker dans d1/d2/fichier avec d1 et d2 obtenus par
la fonction de hâchage de manière à répartir les N fichiers dans 256
répertoires différents (8 x 8) permet d'assurer la performance quand N
est très grand même sur des fs de mauvaise qualité.
Mais bon, dans mon expérience, si N < 10'00 on ne voit pas trop la
différence avec ou sans stockage réparti `squid'.
Après, si les données sont de courte taille, pourquoi ne pas réfléchir
à un autre système de stockage qu'un filesystem, p.ex. une base
de données clé-valeur style dbm 198x ou ce-qui-se-fait-de-mieux-ce-mois-
en-big-data.
La curiosité: je voudrais voir le visu. du rapport donnant le bilan de
Lancer e2fsck sur la partition montée en ro (mount -o remount,ro /data) avec l'option -f et en théorie il indique le pourcentage non contigu. Maintenant, si la performance reste acceptable, pourquoi s'en préoccuper? Si la performance n'est pas acceptable, ce n'est pas dit que cela soit un problème de fragmentation, d'ailleurs.
Audacity), couplés à une myriade de petits - relativement aux précédents -
Une myriade de fichiers agencés comment? La méthode `squid' (hâcher le nom de fichier et stocker dans d1/d2/fichier avec d1 et d2 obtenus par la fonction de hâchage de manière à répartir les N fichiers dans 256 répertoires différents (8 x 8) permet d'assurer la performance quand N est très grand même sur des fs de mauvaise qualité. Mais bon, dans mon expérience, si N < 10'00 on ne voit pas trop la différence avec ou sans stockage réparti `squid'. Après, si les données sont de courte taille, pourquoi ne pas réfléchir à un autre système de stockage qu'un filesystem, p.ex. une base de données clé-valeur style dbm 198x ou ce-qui-se-fait-de-mieux-ce-mois- en-big-data.
Nicolas George
Marc SCHAEFER , dans le message <oncbkt$pjp$, a écrit :
Maintenant, si la performance reste acceptable, pourquoi s'en préoccuper?
C'est quoi, une performance acceptable ? Et encore mieux : c'est quoi la différence entre une performance acceptable et une performance inacceptable ? 50% ? 10% ? 5% ? 1% ? N'importe laquelle de ces marges peut représenter la différence entre la réussite et l'échec dans un projet. Tout est une question de compromis, il faut chercher le meilleur possible, sans oublier que la recherche du compromis elle-même est un coût à prendre en considération.
Marc SCHAEFER , dans le message <oncbkt$pjp$1@shakotay.alphanet.ch>, a
écrit :
Maintenant, si la performance reste acceptable, pourquoi s'en
préoccuper?
C'est quoi, une performance acceptable ? Et encore mieux : c'est quoi la
différence entre une performance acceptable et une performance
inacceptable ? 50% ? 10% ? 5% ? 1% ? N'importe laquelle de ces marges
peut représenter la différence entre la réussite et l'échec dans un
projet.
Tout est une question de compromis, il faut chercher le meilleur
possible, sans oublier que la recherche du compromis elle-même est un
coût à prendre en considération.
Marc SCHAEFER , dans le message <oncbkt$pjp$, a écrit :
Maintenant, si la performance reste acceptable, pourquoi s'en préoccuper?
C'est quoi, une performance acceptable ? Et encore mieux : c'est quoi la différence entre une performance acceptable et une performance inacceptable ? 50% ? 10% ? 5% ? 1% ? N'importe laquelle de ces marges peut représenter la différence entre la réussite et l'échec dans un projet. Tout est une question de compromis, il faut chercher le meilleur possible, sans oublier que la recherche du compromis elle-même est un coût à prendre en considération.
Pascal Hambourg
Le 20/08/2017 à 17:59, Marc SCHAEFER a écrit :
Lancer e2fsck sur la partition montée en ro (mount -o remount,ro /data) avec l'option -f et en théorie il indique le pourcentage non contigu.
Pourcentage qui n'apprend pas grand-chose sur la réalité de la fragmentatio et ne permet pas d'estimer son impact, car il n'informe ni sur la taille des fragments ni sur leur nombre. Par exemple si le système de fichiers ne contient que des fichiers de 10 Mo et s'ils sont tous fragmentés en deux, le pourcentage sera de 100% et pourtant l'impact sur la performance sera faible. A mon avis il serait plus utile d'afficher le nombre de fragments, ou le nombre moyen de fragments par fichier.
Le 20/08/2017 à 17:59, Marc SCHAEFER a écrit :
Lancer e2fsck sur la partition montée en ro (mount -o remount,ro /data)
avec l'option -f et en théorie il indique le pourcentage non
contigu.
Pourcentage qui n'apprend pas grand-chose sur la réalité de la
fragmentatio et ne permet pas d'estimer son impact, car il n'informe ni
sur la taille des fragments ni sur leur nombre.
Par exemple si le système de fichiers ne contient que des fichiers de 10
Mo et s'ils sont tous fragmentés en deux, le pourcentage sera de 100% et
pourtant l'impact sur la performance sera faible.
A mon avis il serait plus utile d'afficher le nombre de fragments, ou le
nombre moyen de fragments par fichier.
Lancer e2fsck sur la partition montée en ro (mount -o remount,ro /data) avec l'option -f et en théorie il indique le pourcentage non contigu.
Pourcentage qui n'apprend pas grand-chose sur la réalité de la fragmentatio et ne permet pas d'estimer son impact, car il n'informe ni sur la taille des fragments ni sur leur nombre. Par exemple si le système de fichiers ne contient que des fichiers de 10 Mo et s'ils sont tous fragmentés en deux, le pourcentage sera de 100% et pourtant l'impact sur la performance sera faible. A mon avis il serait plus utile d'afficher le nombre de fragments, ou le nombre moyen de fragments par fichier.
Yliur
Le Sun, 20 Aug 2017 01:24:33 +0200 capfree a écrit :
Le 20/08/2017 à 00:30, Yliur a écrit :
Il est probable que le travail d'ext4 au jour le jour soit déjà très satisfaisant, sans qu'il y ait besoin de repasser derrière (pas de dégradation progressive). Quel est l'intérêt de passer régulièrement des opérations de maintenance si en permanence le système de fichiers est déjà dans un très bon état ? Le fait de le passer dans un état "parfaitement propre" est assez illusoire, à moins que tu aies un besoin très particulier.
Question, si à l'occasion on transfère système et home sur un disque pré-partitionné mais vide, la localisation des fichiers serait-elle idéale?
Suivant ce que tu appelle "idéal". Mais le SF va sans doute éviter de les fragmenter, oui.
Le Sun, 20 Aug 2017 01:24:33 +0200
capfree <caprifermager@libre.invalid> a écrit :
Le 20/08/2017 à 00:30, Yliur a écrit :
> Il est probable que le travail d'ext4 au jour le jour soit déjà
> très satisfaisant, sans qu'il y ait besoin de repasser derrière
> (pas de dégradation progressive). Quel est l'intérêt de passer
> régulièrement des opérations de maintenance si en permanence le
> système de fichiers est déjà dans un très bon état ? Le fait de le
> passer dans un état "parfaitement propre" est assez illusoire, à
> moins que tu aies un besoin très particulier.
Question, si à l'occasion on transfère système et home sur un disque
pré-partitionné mais vide, la localisation des fichiers serait-elle
idéale?
Suivant ce que tu appelle "idéal". Mais le SF va sans doute éviter de
les fragmenter, oui.
Le Sun, 20 Aug 2017 01:24:33 +0200 capfree a écrit :
Le 20/08/2017 à 00:30, Yliur a écrit :
Il est probable que le travail d'ext4 au jour le jour soit déjà très satisfaisant, sans qu'il y ait besoin de repasser derrière (pas de dégradation progressive). Quel est l'intérêt de passer régulièrement des opérations de maintenance si en permanence le système de fichiers est déjà dans un très bon état ? Le fait de le passer dans un état "parfaitement propre" est assez illusoire, à moins que tu aies un besoin très particulier.
Question, si à l'occasion on transfère système et home sur un disque pré-partitionné mais vide, la localisation des fichiers serait-elle idéale?
Suivant ce que tu appelle "idéal". Mais le SF va sans doute éviter de les fragmenter, oui.
Yliur
Le Sun, 20 Aug 2017 21:23:20 +0200 "zeLittle " a écrit :
Le Sun, 20 Aug 2017 17:59:25 +0200, Marc SCHAEFER a écrit:
Lancer e2fsck sur la partition montée en ro (mount -o remount,ro /data) avec l'option -f et en théorie il indique le pourcentage non contigu.
Merci pour l'info. C'est justement plutôt observer cette variation de discontinuité qui m'intéresse, avant même d'entreprendre autre chose.
Maintenant, si la performance reste acceptable, pourquoi s'en préoccuper?
C'est d'abord être sûr que l'espérance de vie de mon disque dur mécanique est optimal, espérance qui est fonction de l'économie de sa mécanique.
Et comment estimes-tu l'impact de telle ou telle organisation sur la mécanique du disque ? Est-ce que les allers-retours de la tête de lecture/écriture diminuent sensiblement sa durée de vie ? Si c'est ce cas, est-ce que le rangement des fichiers sur le disque n'est pas un plus gros problème que de savoir si une poignée d'entre eux sont coupés en plusieurs morceaux ? Et combien coûte la défragmentation dans tout ça (une opération qui consiste à beaucoup accéder au disque pour déplacer des fichiers) ? Si ton problème ce sont des fichiers issus de git, ils sont sans doute très petits (et pas tellement sujets à la fragmentation) et si tu fais des compilations ceux auxquels tu accèdes souvent sont sans doute en mémoire (dans le cache système). À moins que tu aies un cas très particulier, tu ne devrais sans doute pas essayer d'estimer l'impact sur la mécanique du disque parce que ça nécessite beaucoup d'informations sur le fonctionnement de tout ce bazar et que les actions que tu choisirais d'entreprendre après avoir soigneusement étudié la question seraient sans doute obsolètes / contre-productives dans une situation un peu différente (y compris une simple modification du fonctionnement de tel ou tel aspect du noyau Linux). Disons que par curiosité si tu veux t'intéresser à la question libre à toi, mais à moins de faire un travail assez important tu risques assez peu d'arriver à ménager vraiment ton disque ; et "défragmenter" ne fait probablement rien de magique pour toi si tu n'as pas un cas très particulier à exposer.
Le Sun, 20 Aug 2017 21:23:20 +0200
"zeLittle " <noreply@noreply.net> a écrit :
Le Sun, 20 Aug 2017 17:59:25 +0200, Marc SCHAEFER
<schaefer@alphanet.ch> a écrit:
>
> Lancer e2fsck sur la partition montée en ro (mount -o
> remount,ro /data) avec l'option -f et en théorie il indique le
> pourcentage non contigu.
>
Merci pour l'info. C'est justement plutôt observer cette variation
de discontinuité qui m'intéresse, avant même d'entreprendre autre
chose.
>
> Maintenant, si la performance reste acceptable, pourquoi s'en
> préoccuper?
>
C'est d'abord être sûr que l'espérance de vie de mon disque dur
mécanique est optimal, espérance qui est fonction de l'économie de sa
mécanique.
Et comment estimes-tu l'impact de telle ou telle organisation sur la
mécanique du disque ?
Est-ce que les allers-retours de la tête de lecture/écriture diminuent
sensiblement sa durée de vie ? Si c'est ce cas, est-ce que le rangement
des fichiers sur le disque n'est pas un plus gros problème que de
savoir si une poignée d'entre eux sont coupés en plusieurs morceaux ?
Et combien coûte la défragmentation dans tout ça (une opération qui
consiste à beaucoup accéder au disque pour déplacer des fichiers) ? Si
ton problème ce sont des fichiers issus de git, ils sont sans doute
très petits (et pas tellement sujets à la fragmentation) et si tu fais
des compilations ceux auxquels tu accèdes souvent sont sans doute en
mémoire (dans le cache système).
À moins que tu aies un cas très particulier, tu ne devrais sans doute
pas essayer d'estimer l'impact sur la mécanique du disque parce que ça
nécessite beaucoup d'informations sur le fonctionnement de tout ce
bazar et que les actions que tu choisirais d'entreprendre après avoir
soigneusement étudié la question seraient sans doute obsolètes /
contre-productives dans une situation un peu différente (y compris une
simple modification du fonctionnement de tel ou tel aspect du noyau
Linux). Disons que par curiosité si tu veux t'intéresser à la question
libre à toi, mais à moins de faire un travail assez important tu
risques assez peu d'arriver à ménager vraiment ton disque ; et
"défragmenter" ne fait probablement rien de magique pour toi si tu n'as
pas un cas très particulier à exposer.
Le Sun, 20 Aug 2017 21:23:20 +0200 "zeLittle " a écrit :
Le Sun, 20 Aug 2017 17:59:25 +0200, Marc SCHAEFER a écrit:
Lancer e2fsck sur la partition montée en ro (mount -o remount,ro /data) avec l'option -f et en théorie il indique le pourcentage non contigu.
Merci pour l'info. C'est justement plutôt observer cette variation de discontinuité qui m'intéresse, avant même d'entreprendre autre chose.
Maintenant, si la performance reste acceptable, pourquoi s'en préoccuper?
C'est d'abord être sûr que l'espérance de vie de mon disque dur mécanique est optimal, espérance qui est fonction de l'économie de sa mécanique.
Et comment estimes-tu l'impact de telle ou telle organisation sur la mécanique du disque ? Est-ce que les allers-retours de la tête de lecture/écriture diminuent sensiblement sa durée de vie ? Si c'est ce cas, est-ce que le rangement des fichiers sur le disque n'est pas un plus gros problème que de savoir si une poignée d'entre eux sont coupés en plusieurs morceaux ? Et combien coûte la défragmentation dans tout ça (une opération qui consiste à beaucoup accéder au disque pour déplacer des fichiers) ? Si ton problème ce sont des fichiers issus de git, ils sont sans doute très petits (et pas tellement sujets à la fragmentation) et si tu fais des compilations ceux auxquels tu accèdes souvent sont sans doute en mémoire (dans le cache système). À moins que tu aies un cas très particulier, tu ne devrais sans doute pas essayer d'estimer l'impact sur la mécanique du disque parce que ça nécessite beaucoup d'informations sur le fonctionnement de tout ce bazar et que les actions que tu choisirais d'entreprendre après avoir soigneusement étudié la question seraient sans doute obsolètes / contre-productives dans une situation un peu différente (y compris une simple modification du fonctionnement de tel ou tel aspect du noyau Linux). Disons que par curiosité si tu veux t'intéresser à la question libre à toi, mais à moins de faire un travail assez important tu risques assez peu d'arriver à ménager vraiment ton disque ; et "défragmenter" ne fait probablement rien de magique pour toi si tu n'as pas un cas très particulier à exposer.
Marc SCHAEFER
Nicolas George <nicolas$ wrote:
C'est quoi, une performance acceptable ?
Une performance acceptable pour l'application considérée.
Tout est une question de compromis, il faut chercher le meilleur possible, sans oublier que la recherche du compromis elle-même est un coût à prendre en considération.
Euh non. Ici on parle de l'effet de la fragmentation, il s'agit donc de ne pas évaluer celle-ci mais d'évaluer la baisse de performance pour l'application considérée. C'était le sens de mon intervention. Ne pas se focaliser sur la fragmentation en tant que telle alors que ce n'est peut-être pas la cause de la mauvaise performance éventuellement perçue.
Nicolas George <nicolas$george@salle-s.org> wrote:
C'est quoi, une performance acceptable ?
Une performance acceptable pour l'application considérée.
Tout est une question de compromis, il faut chercher le meilleur
possible, sans oublier que la recherche du compromis elle-même est un
coût à prendre en considération.
Euh non. Ici on parle de l'effet de la fragmentation, il s'agit
donc de ne pas évaluer celle-ci mais d'évaluer la baisse
de performance pour l'application considérée.
C'était le sens de mon intervention. Ne pas se focaliser
sur la fragmentation en tant que telle alors que ce n'est
peut-être pas la cause de la mauvaise performance éventuellement
perçue.
Une performance acceptable pour l'application considérée.
Tout est une question de compromis, il faut chercher le meilleur possible, sans oublier que la recherche du compromis elle-même est un coût à prendre en considération.
Euh non. Ici on parle de l'effet de la fragmentation, il s'agit donc de ne pas évaluer celle-ci mais d'évaluer la baisse de performance pour l'application considérée. C'était le sens de mon intervention. Ne pas se focaliser sur la fragmentation en tant que telle alors que ce n'est peut-être pas la cause de la mauvaise performance éventuellement perçue.
Marc SCHAEFER
zeLittle wrote:
Merci, mais ce que tu me dis est complètement hors de mon champ de compétence: je ne comprends rien.
En résumé: si tu as 10'000 fichiers dans un seul répertoire, la performance ne sera pas bonne, l'idée est de répartir ces fichiers dans plusieurs répertoires (par exemple 8 au premier niveau, et 8 au deuxième niveau, soit 256 répertoires), en fonction d'une règle facile (un hâchage). En théorie les fs modernes gère ça bien, mais c'est un vieux réflexe de pas mal de logiciels, p.ex. le proxy squid.
- e4defrag existe, donc "no problemo".
L'idée était de dire que d'autres problèmes de performance peuvent se poser que la fragmentation.
- je peux encore partitionner pour séparer les très gros fichiers des autres.
ça c'est une bonne idée!
zeLittle <noreply@noreply.net> wrote:
Merci, mais ce que tu me dis est complètement hors de mon champ de
compétence: je ne comprends rien.
En résumé: si tu as 10'000 fichiers dans un seul répertoire, la performance
ne sera pas bonne, l'idée est de répartir ces fichiers dans plusieurs
répertoires (par exemple 8 au premier niveau, et 8 au deuxième niveau,
soit 256 répertoires), en fonction d'une règle facile (un hâchage).
En théorie les fs modernes gère ça bien, mais c'est un vieux
réflexe de pas mal de logiciels, p.ex. le proxy squid.
- e4defrag existe, donc "no problemo".
L'idée était de dire que d'autres problèmes de performance
peuvent se poser que la fragmentation.
- je peux encore partitionner pour séparer les très gros fichiers des
autres.
Merci, mais ce que tu me dis est complètement hors de mon champ de compétence: je ne comprends rien.
En résumé: si tu as 10'000 fichiers dans un seul répertoire, la performance ne sera pas bonne, l'idée est de répartir ces fichiers dans plusieurs répertoires (par exemple 8 au premier niveau, et 8 au deuxième niveau, soit 256 répertoires), en fonction d'une règle facile (un hâchage). En théorie les fs modernes gère ça bien, mais c'est un vieux réflexe de pas mal de logiciels, p.ex. le proxy squid.
- e4defrag existe, donc "no problemo".
L'idée était de dire que d'autres problèmes de performance peuvent se poser que la fragmentation.
- je peux encore partitionner pour séparer les très gros fichiers des autres.
ça c'est une bonne idée!
Marc SCHAEFER
Pascal Hambourg wrote:
A mon avis il serait plus utile d'afficher le nombre de fragments, ou le nombre moyen de fragments par fichier.
Ou simplement d'abord remonter à la vérification à la performance de l'application, sans préjuger que la performance est mauvaise ou que ce problème est dû à de la fragmentation.
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
A mon avis il serait plus utile d'afficher le nombre de fragments, ou le
nombre moyen de fragments par fichier.
Ou simplement d'abord remonter à la vérification à la performance
de l'application, sans préjuger que la performance est mauvaise
ou que ce problème est dû à de la fragmentation.
A mon avis il serait plus utile d'afficher le nombre de fragments, ou le nombre moyen de fragments par fichier.
Ou simplement d'abord remonter à la vérification à la performance de l'application, sans préjuger que la performance est mauvaise ou que ce problème est dû à de la fragmentation.
Nicolas George
Marc SCHAEFER , dans le message <ondu8p$b83$, a écrit :
Une performance acceptable pour l'application considérée.
Tu n'as pas répondu à la question, et ce faisant tu renforces l'erreur.
Euh non. Ici on parle de l'effet de la fragmentation, il s'agit donc de ne pas évaluer celle-ci mais d'évaluer la baisse de performance pour l'application considérée. C'était le sens de mon intervention. Ne pas se focaliser sur la fragmentation en tant que telle alors que ce n'est peut-être pas la cause de la mauvaise performance éventuellement perçue.
Je n'ai rien dit qui soit contredit ici. Mais tu fais toujours la double erreur de te concentrer sur une seule application et d'utiliser cette notion d'acceptable. Avec cette mentalité on arrive à des applications lourdingues parce que leurs performances sont « acceptables » sur la bête de course du développeur qui ne sert sur le moment qu'à ça. Ça conduit au gaspillage, par l'obligation d'avoir des machines plus puissantes ou l'impossibilité de faire plusieurs choses sur la même machine. S'il y a moyen d'améliorer les performances, il faut le faire, que ce soit en contrôlant mieux la fragmentation ou par n'importe quelle autre méthode.
Marc SCHAEFER , dans le message <ondu8p$b83$1@shakotay.alphanet.ch>, a
écrit :
Une performance acceptable pour l'application considérée.
Tu n'as pas répondu à la question, et ce faisant tu renforces l'erreur.
Euh non. Ici on parle de l'effet de la fragmentation, il s'agit
donc de ne pas évaluer celle-ci mais d'évaluer la baisse
de performance pour l'application considérée.
C'était le sens de mon intervention. Ne pas se focaliser
sur la fragmentation en tant que telle alors que ce n'est
peut-être pas la cause de la mauvaise performance éventuellement
perçue.
Je n'ai rien dit qui soit contredit ici.
Mais tu fais toujours la double erreur de te concentrer sur une seule
application et d'utiliser cette notion d'acceptable. Avec cette
mentalité on arrive à des applications lourdingues parce que leurs
performances sont « acceptables » sur la bête de course du développeur
qui ne sert sur le moment qu'à ça. Ça conduit au gaspillage, par
l'obligation d'avoir des machines plus puissantes ou l'impossibilité de
faire plusieurs choses sur la même machine.
S'il y a moyen d'améliorer les performances, il faut le faire, que ce
soit en contrôlant mieux la fragmentation ou par n'importe quelle autre
méthode.
Marc SCHAEFER , dans le message <ondu8p$b83$, a écrit :
Une performance acceptable pour l'application considérée.
Tu n'as pas répondu à la question, et ce faisant tu renforces l'erreur.
Euh non. Ici on parle de l'effet de la fragmentation, il s'agit donc de ne pas évaluer celle-ci mais d'évaluer la baisse de performance pour l'application considérée. C'était le sens de mon intervention. Ne pas se focaliser sur la fragmentation en tant que telle alors que ce n'est peut-être pas la cause de la mauvaise performance éventuellement perçue.
Je n'ai rien dit qui soit contredit ici. Mais tu fais toujours la double erreur de te concentrer sur une seule application et d'utiliser cette notion d'acceptable. Avec cette mentalité on arrive à des applications lourdingues parce que leurs performances sont « acceptables » sur la bête de course du développeur qui ne sert sur le moment qu'à ça. Ça conduit au gaspillage, par l'obligation d'avoir des machines plus puissantes ou l'impossibilité de faire plusieurs choses sur la même machine. S'il y a moyen d'améliorer les performances, il faut le faire, que ce soit en contrôlant mieux la fragmentation ou par n'importe quelle autre méthode.
Marc SCHAEFER
Nicolas George <nicolas$ wrote:
Mais tu fais toujours la double erreur de te concentrer sur une seule application et d'utiliser cette notion d'acceptable. Avec cette
Ah, oui, je suis d'accord pour cela: mon terme était imprécis. Je parlais d'application dans le sens d'un projet concret, et non pas d'un seul programme. Je me rends compte que c'était imprécis. Et pour moi, un projet concret ça tourne sur un ensemble de machine (de 1 à N), avec ou sans virtualisation, etc. Une application peut comprendre des dizaines de logiciels. Et en fait je partais dans l'autre sens: SI l'application (le projet) tourne à satisfaction, POURQUOI vouloir se poser des questions bizarres sur une fragmentation théorique, qui en général n'a pas les conséquences sous Linux que sous Microsoft, par exemple (et même, c'est peut-être même plus le cas sous cet environnement depuis NTFS).
qui ne sert sur le moment qu'à ça. Ça conduit au gaspillage, par l'obligation d'avoir des machines plus puissantes ou l'impossibilité de faire plusieurs choses sur la même machine.
Je suis d'accord, ça c'est bien dommage, mais c'est souvent ainsi que les spécialistes font aujourd'hui, vu les ristournes sur le matériel. Quant à moi, j'aime bien conserver du matériel longtemps, pour amortir l'énergie grise. Et la virtualisation légère (les conteneurs) permet de garantir une certaine isolation entre applications (projets) et donc de mutualiser l'infrastructure même pour plusieurs clients.
Nicolas George <nicolas$george@salle-s.org> wrote:
Mais tu fais toujours la double erreur de te concentrer sur une seule
application et d'utiliser cette notion d'acceptable. Avec cette
Ah, oui, je suis d'accord pour cela: mon terme était imprécis. Je parlais
d'application dans le sens d'un projet concret, et non pas d'un seul
programme. Je me rends compte que c'était imprécis.
Et pour moi, un projet concret ça tourne sur un ensemble de machine
(de 1 à N), avec ou sans virtualisation, etc. Une application peut
comprendre des dizaines de logiciels.
Et en fait je partais dans l'autre sens: SI l'application (le projet)
tourne à satisfaction, POURQUOI vouloir se poser des questions bizarres
sur une fragmentation théorique, qui en général n'a pas les
conséquences sous Linux que sous Microsoft, par exemple (et même,
c'est peut-être même plus le cas sous cet environnement depuis NTFS).
qui ne sert sur le moment qu'à ça. Ça conduit au gaspillage, par
l'obligation d'avoir des machines plus puissantes ou l'impossibilité de
faire plusieurs choses sur la même machine.
Je suis d'accord, ça c'est bien dommage, mais c'est souvent ainsi que
les spécialistes font aujourd'hui, vu les ristournes sur le matériel.
Quant à moi, j'aime bien conserver du matériel longtemps, pour amortir
l'énergie grise. Et la virtualisation légère (les conteneurs) permet
de garantir une certaine isolation entre applications (projets) et
donc de mutualiser l'infrastructure même pour plusieurs clients.
Mais tu fais toujours la double erreur de te concentrer sur une seule application et d'utiliser cette notion d'acceptable. Avec cette
Ah, oui, je suis d'accord pour cela: mon terme était imprécis. Je parlais d'application dans le sens d'un projet concret, et non pas d'un seul programme. Je me rends compte que c'était imprécis. Et pour moi, un projet concret ça tourne sur un ensemble de machine (de 1 à N), avec ou sans virtualisation, etc. Une application peut comprendre des dizaines de logiciels. Et en fait je partais dans l'autre sens: SI l'application (le projet) tourne à satisfaction, POURQUOI vouloir se poser des questions bizarres sur une fragmentation théorique, qui en général n'a pas les conséquences sous Linux que sous Microsoft, par exemple (et même, c'est peut-être même plus le cas sous cet environnement depuis NTFS).
qui ne sert sur le moment qu'à ça. Ça conduit au gaspillage, par l'obligation d'avoir des machines plus puissantes ou l'impossibilité de faire plusieurs choses sur la même machine.
Je suis d'accord, ça c'est bien dommage, mais c'est souvent ainsi que les spécialistes font aujourd'hui, vu les ristournes sur le matériel. Quant à moi, j'aime bien conserver du matériel longtemps, pour amortir l'énergie grise. Et la virtualisation légère (les conteneurs) permet de garantir une certaine isolation entre applications (projets) et donc de mutualiser l'infrastructure même pour plusieurs clients.
