Je ne vais pas rentrer dans le détail du matériel mais juste en ayant la vision boîte noire : j'ai un point de montage sur lequel j'ai de la place et je désire connaître ses performances.
Comme cela a déjà été indiqué dans les posts précédents, ces résultats dépendent de beaucoup de paramètres (cache, taille de l'I/O).
Pour ma part, j'utilise Iozone un petit utilitaire en C qui fonctionne sur systèmes POSIX (testé sur HP-UX, AIX et Linux) et qui permet de simuler des I/O en faisant varier les paramètres :
+ lecture/écriture
+ taille de l'I/O
+ cache/pas cache
+ synchrone/asynchrone (pour les écritures)
Iozone est un vrai couteau suisse mais
+ Il n'est plus maintenu (date de 1998 - 2002)
+ Les tableurs excel pour avoir de zolis graphes sont payants . C'est uniquement pour le rendu, les matrices de résultats sont exploitables avec un peu d'habitude.
En particulier, il est indispensable de connaître la taille des I/O qui vont être faits.
Par exemple,
* sur un serveurs de fichiers, on aura de longues I/O séquentielles : Plusieurs centaines de ko en 1 I/O
* sur une base de données : on pourra avoir différents types d'I/O
+ sur un Scan complet des Tables, on aura tendances à avoir des "grosses I/O" (prefetch des valeurs suivantes) (dizaines voire centaine de ko l'I/O)
+ sur une requête simple ou sur un jointure sur index on pourra avoir des petites I/O (4ko,8ko qui sont des multiples de la taille du bloc)
(Sur la base de données, je me base sur des mécanismes de type 'Oracle')
Et c'est pourquoi si on joint sur 90% de la table, il est peut être préférable de faire un Full Table Scan que de mettre des Index.
Et c'est la raison pour laquelle il me semble primordial de d'abord s'attacher au besoin du stockage (I/O, débit, latence) avant de tenter un test brut.
# IOzone
Posté par Etienne Carrière . En réponse au journal Linux Centos et disque SSD. Évalué à 2.
Je ne vais pas rentrer dans le détail du matériel mais juste en ayant la vision boîte noire : j'ai un point de montage sur lequel j'ai de la place et je désire connaître ses performances.
Comme cela a déjà été indiqué dans les posts précédents, ces résultats dépendent de beaucoup de paramètres (cache, taille de l'I/O).
Pour ma part, j'utilise Iozone un petit utilitaire en C qui fonctionne sur systèmes POSIX (testé sur HP-UX, AIX et Linux) et qui permet de simuler des I/O en faisant varier les paramètres :
+ lecture/écriture
+ taille de l'I/O
+ cache/pas cache
+ synchrone/asynchrone (pour les écritures)
Iozone est un vrai couteau suisse mais
+ Il n'est plus maintenu (date de 1998 - 2002)
+ Les tableurs excel pour avoir de zolis graphes sont payants . C'est uniquement pour le rendu, les matrices de résultats sont exploitables avec un peu d'habitude.
En particulier, il est indispensable de connaître la taille des I/O qui vont être faits.
Par exemple,
* sur un serveurs de fichiers, on aura de longues I/O séquentielles : Plusieurs centaines de ko en 1 I/O
* sur une base de données : on pourra avoir différents types d'I/O
+ sur un Scan complet des Tables, on aura tendances à avoir des "grosses I/O" (prefetch des valeurs suivantes) (dizaines voire centaine de ko l'I/O)
+ sur une requête simple ou sur un jointure sur index on pourra avoir des petites I/O (4ko,8ko qui sont des multiples de la taille du bloc)
(Sur la base de données, je me base sur des mécanismes de type 'Oracle')
Et c'est pourquoi si on joint sur 90% de la table, il est peut être préférable de faire un Full Table Scan que de mettre des Index.
Et c'est la raison pour laquelle il me semble primordial de d'abord s'attacher au besoin du stockage (I/O, débit, latence) avant de tenter un test brut.