Bonjour à tous,
je fais appel à votre esprit critique sur le point suivant :
On nous a prêtée une machine avec 128 Go de RAM / plein de disque SSD et de gros CPU
But de la manœuvre : évaluer la différence avec un baie SAN plus classique.
Après installation de Centos on est allé dans "Utilitaire de disque"
qui propose un test de lecture écriture
Et la on tombe sur ceci :
Vitesse de lecture minimum : 2,4 Go/s
Vitesse de lecture maximum : 2,7 Go/s
Vitesse d'écriture minimum : 1,3 Go/s
Vitesse d'écriture maximum : 1,7 Go/s
Impressionnant quand même
Mais bon que peu tu penser de ce type de test ?
Merci pour votre avis éclairé
# Merci pour votre avis éclairé
Posté par Laurent Cligny (site web personnel) . Évalué à 3.
C'est lumineux !
[^] # Re: Merci pour votre avis éclairé
Posté par ChickenKiller . Évalué à 5.
C'est vrai que c'est difficile de répondre, ne sachant pas la configuration de tes disques, comme tu y accèdes, etc…. Pour le coup je dirait donc plutôt :
C'est bien obscure !!! :-P
# Et les détails ?
Posté par benoar . Évalué à 4.
Que sans détails ni sur le hard, ni sur la conf soft, ça ne sert pas à grand chose à ceux qui s'intéressent à la technique, à part pour montrer que tu as la plus grosse…
[^] # Re: Et les détails ?
Posté par ChickenKiller . Évalué à 2.
Nous allons jouer au qui perd, perd:
le Russe Ichlakoff a sauté 2,31 mètres… Pouvez-vous dire mieux ?
[^] # Re: Et les détails ?
Posté par Christophe B. (site web personnel) . Évalué à -4. Dernière modification le 18 mars 2014 à 18:08.
Vous êtes caustique … :)
C'est la qualité du test de "UTILITAIRE DISQUE REDHAT" qui m'interpellent
peu t on se fier a cet utilitaire ?
donc oui la patte gauche du pigeon est plus ressemblante :)
bien fait pour moi, réfléchir … réfléchir … écrire le journal …
mais c'est pas mon jour …
un switch flingué … un reboot qui se passe mal car un vg pas fini
vivement ce soir
[^] # Re: Et les détails ?
Posté par Maclag . Évalué à 8.
C'est plus qu'un peu plus, mais quand même moins que beaucoup plus, du coup c'est assez plus mieux que moins pire.
[^] # Re: Et les détails ?
Posté par undeuxtroisout . Évalué à 5.
Mieux!
# Ok voici plus de précisions
Posté par Christophe B. (site web personnel) . Évalué à 2.
Bonjour,
Les disques sont en RAID10 matériel avec stripping
Il s'agit d'une centos 6.5 avec un max de paquets (machine de dev)
en se connectant sur une session graphique
on va dans Application / Outils Système / Utilitaire de disques
et on lance le test en écriture, faut que le disque soit pas formaté
la question que je me posais … ce type de test est il valable ?
Les valeurs retournées sont elles significatives ?
Quelqu'un en saurait t il un peu plus sur cet utilitaire Redhat ?
Après sur cette bécane qui a 3 contrôleurs de disques et plein de disques SSD
j'ai fait d'autres tests (plus parlant pour moi)
dd if=/dev/zero of=toto bs=1G count=30 => 32 secondes
sur une VM accroché à une baie SAN classique (SATA 6Gb/s) cela prend 8 minutes
Avec une base oracle (1G de SGA) création de 100 millions de lignes (soit environ 20 Go de données)
=> 13 minutes sur SSD / 38 minutes sur la même VM + baie SATA
3 fois plus rapide
bref, les disques SSD bousculent les reflexes que l'ont a avec les disques classiques
Ainsi certains contrôleurs "ralentissent" les I/O car sle cache est moins rapide que le disque …
Les I/O sont tellement rapides que même des test avec 100 millions de lignes et 20 go de données
ne sont peut être pas assez significatifs
[^] # Re: Ok voici plus de précisions
Posté par ChickenKiller . Évalué à 4. Dernière modification le 18 mars 2014 à 18:17.
Maintenant qu'on a plus de détails, je vais te répondre plus sérieusement :-)
Pour des test assez complets j'ai plutôt tendance à utiliser:
- dans un premier temps hdparm avec les option "-Tt" qui permet de se faire une idée de la vitesse séquentielle
- tout comme toi dd dans certaines conditions
- bonnie++ pour avoir une idée plus précise des io/s qui sont le nerf de la guerre pour de nombreuses applications (c'est souvent ce que j'ai tendance à vouloir optimiser en général). Dans le cas des bases de données en général, c'est là que tout se joue.
Maintenant de manière plus général, oui les SSDs changent complètement la donne et nécessitent bien souvent de désactiver toutes les astuces utilisées jusqu'à maintenant pour contourner la lenteur des disques mécaniques (virer les caches, changer l'ordonnanceur, etc.).
Par contre la différence sur les insert dans ta base oracle ne me semble pas spécialement spectaculaire. Tu ne serais pas limité au niveau du CPU de ta VM ? Ton hyperviseur accède de quel manière au stockage ?
[^] # Re: Ok voici plus de précisions
Posté par Marotte ⛧ . Évalué à 3.
Ça fait donc un peu plus de 1GB/s c'est un peu moins que ce que le test de CentOS te donne mais c'est quand même assez proche.
Je dirais donc que le test en question à l'air assez fiable :)
[^] # Re: Ok voici plus de précisions
Posté par Zenitram (site web personnel) . Évalué à 2.
Je ne sais pas combien de temps tu as hiberné, mais ça a dû être long.
Ca fait des années que les SSD existent, et qu'on parle de reflexes bousculés qui en 2014 sont des réflexes devenus normaux.
Et un SSD fait 500 Mo/s en séquentiel. donc tu en mets 4 en ligne, et 2 Go/s est normal.
Super, il manque encore plein d'infos, genre le nombre de disques : si 4 disques RAID10 font ces perfs, pas mal, si tu en a 32 c'est bof. La marque de la carte RAID impacte beaucoup aussi.
Question idiote : tu comptes avoir une machine avec 128 Go de RAM pour faire de la bête lecture de fichier?
Non, normal de nos jours en RAID 10 et quelques SSD (ces perfs peuvent être vues aussi par une seule carte SSD PCI-E, même sans aller dans des solutions pro de chez pro). Mais en fait, on s'en fout dans 99% des cas.
Je dois pouvoir monter ce genre de perfomance avec moins de 1000€ (carte 8 ports internes + 8 SSD de base), rien de problèmatique pour une entreprise.
rien de nouveau, je suis même plutôt étonné que ce soit que 3x, tu dois être limité par ailleurs (CPU?)
Que c'est un test sequentiel et qu'on s'en fout un peu pour des SSD sauf pour le fun, car on mesure les SSD en IOPS.
Et que, sans vouloir remettre en cause tes compétances par ailleurs, tu n'es pas la bonne personne pour la tâche assignée : la première chose à faire quand on se lance dans une évaluation, c'est de spécifier les scénarios de tests, pas de lancer n'importe quel bench qu'on ne connait pas (à part pour le fun en extra, évidement).
En fait, je me pose de mon côté ces questions :
- Un journal est fait pour apporter des informations, alors qu'un forum est pour poser des question, donc qu'apporte le journal pour nous?
- qu'est-ce que tu veux comme esprit critique sur ce que tu as donné qui est hyper générique ("eh les gars, j'ai balancé un test de lecture séquentielle sur une machine dont je ne dirai pas le nom, ça donne 4 Go/s, vous en pensez quoi")? quel est le but? cherches-tu une prestation de bench?
Oui, je sais, c'est un peu brutal, mais le journal l'est aussi (en plus de ne rien apporter pour un journal).
[^] # Re: Ok voici plus de précisions
Posté par Marotte ⛧ . Évalué à 8.
Zenitram, mode œil pour œil, dent pour dent :)
[^] # Re: Ok voici plus de précisions
Posté par Christophe B. (site web personnel) . Évalué à 2.
Sincèrement, Merci pour la qualité de ta réponse.
Non c'est normal pour nous, on est un peu comme les ents on évoluent doucement.
Cela vient du produit que l'on met en oeuvre, une ERP cela engagent tout le monde pour au moins 5 ans, donc on préfère les choses connues et maitrisées.
Il y a 2 ans, des collègues plus aventureux, avaient bataillés avec un serveur contenant des disques SSD.
Maintenant on étudie c'est tout … En plus on nous prête une machine pour tester :)
Et tu as raison, en fait on est arrivé à la conclusion que sur ce genre de machine, c'est le CPU qui saturent AVANT les I/Os (ce qui est nouveau pour nous)
Ainsi tests sur 250 millions de lignes écrites, le rapport 3x restent (30 mn vs 90 mn)
Pas de problème, je suis désolé d'avoir pollué les journaux avec un sujet qui aurait du être dans un forum.
Sinon j'ai eu les réponses et les confirmations que j'attendais … et même plus vu que je suis passé pour une andouille :)
Dans tout les cas … Merci
[^] # Re: Ok voici plus de précisions
Posté par Marotte ⛧ . Évalué à 2.
Afin de te donner un avis plus technique sur ce test.
Comme cela a été fait remarquer, avec dd l'écriture est principalement séquentielle mais pas forcément…
De plus, il faut faire le test avec des block_size différents. Selon le système de fichier, le firmware du disque et tout à tas d'autres paramètres les résultats varient. Il faut évidemment s'assurer que pendant toute la durée des test aucune tâche consommatrice d'IO (rotation de log, indexation de fichier, snapshot de vm…) ne va se lancer :)
[^] # Re: Ok voici plus de précisions
Posté par Zenitram (site web personnel) . Évalué à 7.
Tu veux jouer? ;-)
Tu oublies :
- le QDx (le nombre de commandes simultanées) à tester, exemple tu peux passer de 100 Mo/s à 300 Mo/s (ou l'inverse), ou autre exemple de 10 000 IOPS à 100 000 IOPS, rien qu'en jouant sur le nombre de commandes simultanées (qui dépendent de ton usage)
- Qu'en entreprise, il faut savoir ce qu'on veut : perfs et coût à fond, ou faible utilisation pas cher, guerre SLC vs MLC, pour "bencher" il faut regarder le modèle par rapport au besoin et ce dire "trop cher" ou "pas adapté à long terme".
- Zut, je n'arrive pas à trouver des liens rapidos de si bon matin, mais des SSD on une partie "rapide" (SLC chère) et une partie "lente" (MLC moins chère), et le contrôleur joue avec les deux, du coup si tu ne touche pas la limite de la SLC (si tu fais des perfs que de manière ponctuelle) les perfs sont bonnes et sinon au bout de quelques secondes les perfs peuvent tomber.
- Le coût! A moins que ça soit offert, les SSD coûtent, et donc il faut regarder si du full SSD est interessant, de nos jours ZFS par exemple peut se servir des SSD comme "tampon" avant de mettre sur HDD, comparer que du full HDD contre du full SSD est se limiter en choix financier.
Au final, on revient toujours au même : quand une entreprise demande d'évaluer une machine, on ne lance pas un bench trouvé au hasard puis demander un avis sur des nombres comme ça, on met en place son cas d'utilisation (logiciel, charge demandée, CPU, RAM…) qui va donner des tests et des résultats très différents. Si on veut tester les SSD on ne change pas la machine complète, on change juste la partie stockage de la machine etc. HDD ou SSD d'ailleurs.
D'ailleurs, il faut aussi se demande jusqu'où on veut aller dans le besoin (car ce qui est oublié dans l'histoire est la définition du besoin), des "disque SSD" c'est un peu la mode d'avant, maintenant la mode c'est des SSD sur PCI-E a 2 Go/s tranquille, et les modèles 3 Go/s (je vous invite à bien lire cet article et l'ensemble du site si les perfs SSD vous interessent) sont en train d'arriver sur le marché (un petit RAID0 sur 4 cartes PCI-E, et hop plus de 10 Go/s à faire pleurer la petite machine de l'auteur du journal, si on veut des nombres bruts à balancer :) )
[^] # Re: Ok voici plus de précisions
Posté par benoar . Évalué à 1.
Ça n'est pas qu'il y a une « partie » SLC, c'est que tant que ton disque n'est qu'à moitié utilisé, le SSD utilise seulement 2 niveaux par cellule, pour coder un bit, alors que quand tu dépasses cette limite, il se met à utiliser 4 niveaux par cellule, pour pouvoir coder 2 bits (le « Multi » de MLC c'est pour dire que tu codes plus d'un bit par cellule ; en général 2 bits, mais aujourd'hui on a aussi de la TLC qui est de la MLC à 3 bits/cellule). Le truc, c'est que pour écrire/lire une cellule à deux niveaux, tu mets moins de temps car tu peux y aller plus « à l'arrache » en ayant que deux « zones » de reconnaissance de l'état de charge de ta cellule. Quand tu passe à quatre niveaux, il faut être plus fin, alors ça met plus de temps, et tes perfs tombent.
Je n'ai pas de lien précis mais ça se trouve sur le très bon http://www.hardware.fr/.
[^] # Re: Ok voici plus de précisions
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 19 mars 2014 à 20:00.
Il y a ça aussi, mais je ne pensais pas à ça (j'avais complètement oublié cette astuce, tout comme j'ai oublié les bidouilles limites comme la compression à la volé qui fait que tu benches suivant la compressabilité des données écrites).
Non, je parle bien d'une partie du SSD (quelques Go) qui sert à aller très très vite, et il y a une copie en arrière plan vers la partie "lente", et du coup si par exemple si la partie rapide est de 1 Go tu fais une écriture de 900 Mo et tu trouves que ça déchires, tu fais une écriture de 2 Go les perfs tombent.
Mais la, je n'arrive pas à retrouver les tests sur le sujet, zut!
Bref, ce qu'il faut retenir est les constructeurs ont des tonnes d'idées pour avoir un bon rapport perfs/coût, et que quand on benche il faut de nos jours avec les SSD le faire en conditions réelles de chez réelles tellement le moindre petit paramètre qui change peut changer le résultat d'une compétition de SSD, et qu'un Bench synthétique ne peut donner qu'une idée partielle de la partie la plus rapide du SSD, bref juste donner une direction.
[^] # Re: Ok voici plus de précisions
Posté par benoar . Évalué à 2.
Ah, étrange, je me renseigne pas mal sur les SSD mais je n'ai jamais entendu parler de ça. Les SSD ont un cache sous forme de RAM, mais qui n'atteint pas le Go, mais plutôt la centaine de Mo, et qui sert à « aller vite » pendant que l'écriture se fait sur la Flash… mais je suppose que tu ne parles pas de ça.
Tout à fait.
[^] # Re: Ok voici plus de précisions
Posté par Zenitram (site web personnel) . Évalué à 3.
Je cherche, mais je ne retrouve pas, donc soit cette idée n'est plus en place en 2014 et remplacée par celle que tu décris, soit… Elle n'a jamais existé ;-).
Bon, un lien pour les curieux sur le fonctionnement décrit par benoar (et on peut voir les différences de perfs…)
Indilinx Everest 2 et débits : attention !
[^] # Re: Ok voici plus de précisions
Posté par Christophe B. (site web personnel) . Évalué à 1.
Juste pour infos :
Le coût est à peu de choses prés identiques ( diff < 500 euros )
sur 2 configurations "utilisables" dans le cas qui intéressait
Par contre la GROSSE différence viendrait des performances.
[^] # Re: Ok voici plus de précisions
Posté par Prosper . Évalué à 4.
Si tu veux faire un "bête" dd , sans passer par le cache ram , il vaut mieux faire
dd if=/dev/zero of=plop bs=1G count=30 conv=fsyncCela dit ça ne te donnera que des perfs séquentielles de ta baie , ce qui n'est pas le plus pertinent d'autant que ta baie peux aussi faire de la compression bête et méchante sur des datas composés de zéro ( en utilisant un algo de compression de type zle )
Si tu veux avoir un bench un peu plus poussé tu peux jouer avec bonnie++ et ses 40000 paramètres
Cela dit ce genre de résultat n' a rien d'extraordinaire , une carte type fusion-IO tape dans ce genre de débit aussi.
# --
Posté par WhiteCat . Évalué à 2.
Je n'avais pas connaissance de cet utilitaire Red Hat, je regarderais demain au boulot.
Tu peux aussi utiliser hdparm pour un "benchmark" :
# hdparm -Tt /dev/sda
Sinon, assures toi que le TRIM est bien activé (option discard dans le fstab), et à mon avis mettre le IO-scheduler "deadline" aussi (d'ailleurs également recommandé pour les bases de données). Tu trouveras des infos pour activer ça ici par exemple :
https://wiki.archlinux.org/index.php/Solid_State_Drives
Les disques sont en RAID matériel ? Je prend le pari que tu aurais des perfs meilleures encore avec du soft-raid Linux.
[^] # Re: --
Posté par ChickenKiller . Évalué à 2.
Deadline ? j'ai plutot pour habitude de mettre noop … Je n'ai jamais bencher avec deadline, tu as de meilleurs résultats?
[^] # Re: --
Posté par WhiteCat . Évalué à 2.
Oui je me suis gouré.
noop c'est mieux pour les SSD.
Et deadline est bien pour les SGBD qui tournent sur HDD.
[^] # Re: --
Posté par Christophe B. (site web personnel) . Évalué à 1.
C'est que l'on nous a dit mais je ne penses pas avoir le temps de le tester.
Et c'est bien dommage
# Attention au cache filesystem
Posté par Gilles Mocellin . Évalué à 4.
Bonjour,
Je connais très bien cette baie puisque je travaille dessus avec la société qui vous l'a prêté. Enfin, je suppose vu que l'on m'a montré aujourd'hui une copie d'écran d'un test de perfs disque sous CentOS avec les mêmes valeurs…
Je dirais d’emblée de faire attention à tout outil graphique accessible rapidement, sans paramétrage…
Ce que je pense, c'est que ces valeurs sont avec le cache du filesystem. Comme hdparm -T.
Sur le graph, tu remarqueras en dessous vers les 120Mo/s, une ligne verte.
Je pense qu'ici, l'outil affiche les valeurs sans le cache. Comme un hdparm -t.
Là, ça me parait peu comme valeur. Il faudrait vérifier l'alignement des partitions si le RAID logiciel a été fait sur des partitions.
Ou sinon, si c'est du RAID matériel, c'est clairement moins performant.
Le bench que j'avais eu le temps de faire avec fio, blocks de 4k sur un RAID10 logiciel de 6 SSD :
En ko/s :
Lecture seq 309 429
Lecture aléa 218 181
Écriture seq 240 678
Écriture aléa 350 958
En comparaison, le même test avec la carte LSI configurée en RAID matériel :
Lecture seq 203 508
Lecture aléa 137 046
Écriture seq 232 565
Écriture aléa 287 439
J'avais fait d'autres tests en iSCSI avec différentes tailles de bloc, mais je saturait le lien gigabit, donc pas représentatif.
[^] # Re: Attention au cache filesystem
Posté par Gilles Mocellin . Évalué à 1.
Pour ceux qui voudrais des IOPS, ben il suffi t de diviser par 4, puisque ce sont des blocs de 4ko.
[^] # Re: Attention au cache filesystem
Posté par Zenitram (site web personnel) . Évalué à 2.
Quelle modèle de "carte LSI"?
Car c'est un peu méchant de balancer comme ça une mauvaises perfs du RAID matériel, la perf dépendant fortement du modèle surtout depuis l'arrivée des SSD (comme si je prenais un Intel Atom et que je disais de ne pas prendre Intel sur les serveurs car j'ai testé l'Atom et pas le Xeon)
[^] # Re: Attention au cache filesystem
Posté par Gilles Mocellin . Évalué à 2.
C'est clair que c'est une carte "basique", sans cache. Par contre, SAS3 (12Gb/s).
LSI 3008 je crois, mais c'est un chipset intégré à la carte mère.
lspci donne :
Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)
[^] # Re: Attention au cache filesystem
Posté par KiKouN . Évalué à 2. Dernière modification le 20 mars 2014 à 10:44.
Je remarque les même différences de perf avec d'autres cartes LSI ou Areca et différents disques SSD. En HDD, la différence est moins marqué.
Bon après, tout dépend de ce que l'on veut. Dans notre cas, c'est de la simplicité, de la sécurité, de homogénéité dans le matos et des temps d'accès faibles. Les backups, on a toute la journée pour les faire.
Je rajouterai que l'on peut obtenir mieux en mettant un contrôleur par disque ( ou deux disques ). Mais il faut de la place pour mettre pour les mettre, donc autant prendre un SSD en PCI-Express.
[^] # Re: Attention au cache filesystem
Posté par Christophe B. (site web personnel) . Évalué à 1.
haha le monde est petit, c'est moi qui ai fait la copie d'écran, les infos circulent vite :)
François nous avait parlé de tes tests :)
Pour infos … On est dans la même zone à Bron. A quelques centaines de mètres de chez eux.
Toi tu satures les liens Gigabits, nous on sature les CPUs (c'est déjà plus facile)… pas facile à agacer ces disques SLC :)
C'est d'ailleurs à cause de ce "réflexe" que j'ai ouvert ce journal (qui aurait être dans un forum)
Le RAID matériel à l'air moins performant que le LVM de linux, en fait le RAID matériel ne dispose que peu de cache ou de cache moins rapide que les disques et donc est contre performant.
Mais c'est dommage on risque de manquer de temps pour tester tout ça.
# IOzone
Posté par Etienne Carrière . É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.
# 128Go de ram, et test de 30Go de data => tout en ram
Posté par NeoX . Évalué à 3.
forcement ca va vite,
ensuite la machine ecrit reellement sur les SSD
cela s'appelle le cache.
il faudrait le desactiver, ou dire à tes outils de test d'ignorer le cache, pour tester effectivement le materiel.
[^] # Re: 128Go de ram, et test de 30Go de data => tout en ram
Posté par M.Poil (site web personnel) . Évalué à 0.
J'avais la flemme de tout lire mais tu as tout dit :)
Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.