Différences

Ci-dessous, les différences entre deux révisions de la page.

--- wiki:divers:coin_geek:benchmark_nfs [2018/09/18 01:37]
shatoon [Pertinence de l'outil de mesure]
+++ wiki:divers:coin_geek:benchmark_nfs [2020/06/27 18:16] (Version actuelle)
@@ Ligne 156: / Ligne 156: @@
 Nous avons réalisé des tests de performances pour deux algorithmes de compressions utilisés potentiellement par **ZFS** : **lz4** et **lzjb**.
-Les performances sont équivalentes avec celles obtenues synchronisation désactivée ( je vous laisse regarder les tableaux excel des annexes pour vous en persuader ).
+Les performances sont équivalentes avec celles obtenues synchronisation désactivée (je vous laisse regarder les tableaux Excel en annexe pour vous en persuader).
 Voici les taux de compressions obtenus :
@@ Ligne 164: / Ligne 164: @@
 | **lzjb** | 2.46 | 1.10 |
-Le fait que la compression ne fasse pas perdre de performance viens du fait que nos processeurs sont clairement "over-kills". On n'observe néanmoins pas de réelles améliorations de stats comme on peut le lire par endroit.
+Le fait que la compression ne fasse pas perdre de performance vient du fait que nos processeurs sont clairement "over-kills". On n'observe néanmoins pas de réelles améliorations de stats comme on peut le lire par endroit.
 ==== Un mot sur la synchronisation? ====
 La synchronisation du dataset s'avère fatale pour les petits fichiers (opérations synchrones sur un système de fichier gérant les opérations synchrones). En effet, les pertes en écriture pure sont énormes :
-les latences sont entre 10 fois (pour les gros fichiers) et 20 fois (pour les petits) plus élevées que pour des opération asynchrones sur un système de fichier asynchrone. Les performances en écriture sont encore plus dégradées (facteur 100 par endroit) Les performances en lecture ne sont pas affectées.
+les latences sont entre 10 fois (pour les gros fichiers) et 20 fois (pour les petits) plus élevées que pour des opérations asynchrones sur un système de fichier asynchrone. Les performances en écriture sont encore plus dégradées (facteur 100 par endroit) Les performances en lecture ne sont pas affectées.
-Quelques graphes illustrerons mon propos. Je vous laisse chercher les autres dans les annexes.
+Quelques graphes illustreront mon propos. Je vous laisse chercher les autres dans les annexes.
 {{:wiki:divers:019.jpg?500|}}
@@ Ligne 262: / Ligne 262: @@
 ===== Et en cas de soucis ? =====
-J'ai comparé les débits en scrub (annalyse des pools) et en resilvering (réparation des pools ).
+J'ai comparé les débits en scrub (annalyse des pools) et en resilvering (réparation des pools).
 En scrub, OpenIndiana est à 25 Mo/s et FreeNas 30 Mo/s... Si notre pool est plein ça prend un peu plus de 12 h  dans les deux cas.
@@ Ligne 268: / Ligne 268: @@
 En resilvering les débits sont équivalents.
-Les performances demandées par un resilvering "à pleine vitesse" sous OpenIndiana sont de 15% de CPU et 700 Mo de Ram. Les disques sont néanmoins pas mal solicités. Du genre 12 Mo/s de lecture sur chaque disque du pool en lecture et 12Mo/s en écriture sur le disque resilveré. Prévoir des pertes de performances...
+Les performances demandées par un resilvering "à pleine vitesse" sous OpenIndiana sont de 15% de CPU et 700 Mo de Ram. Les disques sont néanmoins pas mal sollicités. Du genre 12 Mo/s de lecture sur chaque disque du pool en lecture et 12Mo/s en écriture sur le disque resilveré. Prévoir des pertes de performances...
 ===== Conclusion =====
@@ Ligne 274: / Ligne 274: @@
 En conclusion :
-  * OpenIndiana permettra de meilleurs résultats que FreeNas en terme d'écritures, même si il y a un prix à payer sur les grosses écritures séquentielles. Nous privilégierons donc cette solution.
+  * OpenIndiana permettra de meilleurs résultats que FreeNas en terme d'écriture, même si il y a un prix à payer sur les grosses écritures séquentielles. Nous privilégierons donc cette solution.
   * La dedup ne sera pas activée pour cause de manque de RAM
   * La compression peut être activée sans soucis, et peut permettre de gagner un bon facteur de compression
@@ Ligne 299: / Ligne 299: @@
   * Le [[https://imagine.minet.net/pad/p/benchmark-nas|PAD]] comportant l'ensemble des commandes saisies lors des tests (accessible seulement par les membres de MiNET...).
   * Un [[https://calomel.org/zfs_raid_speed_capacity.html|autre]] test très intéressant, notamment sur la compression.
-  * Si vous lisez des benchmarks extérieures, faites attention à la date du test. FreeNas s'est clairement amélioré entre 2010 et 2012...
+  * Si vous lisez des benchmarks extérieurs, faites attention à la date du test. FreeNas s'est clairement amélioré entre 2010 et 2012...
   * Un des [[http://www.zfsbuild.com/2013/01/25/zfsbuild2012-nexenta-vs-freenas-vs-zfsguru|tests]] qui nous a poussé à tester FreeNAS
  --- //[[benwa@minet.net|Benoit Tellier]] 2014/01/25 17:02//

WikiMiNET

Outils pour utilisateurs

Outils du site

Différences

Outils de la page