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
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. Et j'utilise de l'acquisition de données (metering) pour détecter des problèmes de performance système ou application (quand l'application a été conçue pour), que cela soit au niveau service, application (projet), machine virtuelle ou machine réelle. L'évolution de certains compteurs dans munin (charge CPU, charge disque, délai de réponse, etc) suffit en première approche, mais c'est encore mieux si l'application a été conçue avec des métriques appropriées.
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.
Et j'utilise de l'acquisition de données (metering) pour détecter des
problèmes de performance système ou application (quand l'application
a été conçue pour), que cela soit au niveau service, application (projet),
machine virtuelle ou machine réelle.
L'évolution de certains compteurs dans munin (charge CPU, charge disque,
délai de réponse, etc) suffit en première approche, mais c'est encore
mieux si l'application a été conçue avec des métriques appropriées.
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. Et j'utilise de l'acquisition de données (metering) pour détecter des problèmes de performance système ou application (quand l'application a été conçue pour), que cela soit au niveau service, application (projet), machine virtuelle ou machine réelle. L'évolution de certains compteurs dans munin (charge CPU, charge disque, délai de réponse, etc) suffit en première approche, mais c'est encore mieux si l'application a été conçue avec des métriques appropriées.
Pascal Hambourg
Le 21/08/2017 à 08:28, Marc SCHAEFER a écrit :
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.
On s'éloignerait trop de l'effet de la seule fragmentation, la performance de l'application pouvant dépende de bien d'autres facteurs.
Le 21/08/2017 à 08:28, Marc SCHAEFER a écrit :
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.
On s'éloignerait trop de l'effet de la seule fragmentation, la
performance de l'application pouvant dépende de bien d'autres facteurs.
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.
On s'éloignerait trop de l'effet de la seule fragmentation, la performance de l'application pouvant dépende de bien d'autres facteurs.
