Re: problème de charge disque
’soir,
Sur ce que j’ai dit avant (fichiers à trous, plein de zéros) :
http://en.wikipedia.org/wiki/Sparse_file
En revanche, le dd tel que proposé n’en crée pas. Mea culpa.
(Mais ça n’empêche pas que c’est un test qui n’indique pas
grand-chose :oP )
Pour ceux que veulent savoir si un fichier occupe réellement
de la place sur le disque, voir l’option -k de ls :
ls -lks indique le nombre de blocs utilisés en première colonne.
Le vendredi 1 mai 2015, 17:57:29 Gaëtan PERRIER a écrit :
>[…]
> en pièce jointe le résultat de bonnie++ mais je ne sais pas
> trop comment ça s'interprète ?
Explication des tests :
→ /usr/share/doc/bonnie++/readme.html
Pour chaque test (man bonnie++) :
For every test two numbers are reported, the amount of
work done (higher numbers are better) and the percentage
of CPU time taken to perform the work (lower numbers are
better). If a test completes in less than 500ms then the
output will be displayed as "++++". This is because
such a test result can't be calculated accurately due to
rounding errors and I would rather display no result than
a wrong result.
Les résultats sont dans un tableau ascii.
Tu peux prendre les lignes pleines de virgules à la fin et les
passer par bon_csv2html pour avoir un tableau un peu plus
lisible en HTML.
Comme pour beaucoup de résultats, ce qui est le plus
intéressant, c’est de comparer avant/après ou deux systèmes
proches.
De ce que j’en peux dire, tes chiffres m’ont l’air corrects
pour les débits (~100 Mio/s en écriture, ~200 Mio/s en lecture
et très peu d’usage du CPU) mais énormes pour les latences (1 à
2 secondes !).
Donc tu aurais un gros problème de latence (temps d’accès). Ce
qui est très très embêtant quand on lit/écrit beaucoup de
fichiers (genre une installation).
Bon, maintenant, il faut trouver d’où ça vient…
--
Sylvain Sauvage
Reply to: