Performance de lecture et/ou écriture faible sur un disque logique RAID 5 (RAID matériel) sur une Debian Squeeze 64 bit
37 réponses
Francois Lafont
Bonjour à tous,
J'ai un serveur dont voici les caractéristiques :
- C'est un HP Proliant DL385 avec 16 Go de RAM, 2 processeurs
Opteron(tm) 265 1.80 GHz (1MBL2), 4 disques durs (2.5") de 72 Go et un
contrôleur RAID Smart Array P600.
- Ce serveur est relié à une baie SAS HP Storage Works MSA50 avec 10
disques durs (2.5") de 72 Go.
- Il y a donc en tout 14 disques durs et 13 sont montés en RAID 5 et 1
disque est en spare (via le contrôleur RAID Smart Array P600). J'ai donc
un unique disque logique sur lequel est installé Debian Squeeze 64 bit.
- Tous les disques physiques (14 au total) sont identiques et vous avez
leurs caractéristiques ici :
http://www.harddrivesdirect.com/product_info.php?cPath=130&products_id=144366
- Plus bas dans le message, je vous ai copié-collé plein d'informations
sur le contrôleur RAID.
Mon souci est que le tout semble être un peu lent en lecture et/ou
écriture (encore qu'en écriture j'ai un petit doute) par rapport aux
caractéristiques ci-dessus. Je vous mets ci-dessous les tests effectués
(avec leur résultat) ainsi que les questions que j'ai car certaines
notions ne sont pas forcément très claires dans mon esprit (je ne suis
pas un spécialiste du RAID). Mon souhait serait simplement d'arriver à
obtenir des performances de lecture/écriture qui correspondent aux
caractéristiques du serveur.
Déjà en lecture j'ai ceci qui est assez représentatif des valeurs que
j'obtiens :
Déjà, j'aimerais être sûr de comprendre de quoi il s'agit :
- « Timing buffered disk reads » c'est le temps de lecture du disque
sachant que le buffer du disque a été vidé au préalable et que la
lecture se fait sans la couche "système de fichiers".
- « Timing cached reads » c'est le temps de lecture du buffer du disque,
sachant que le buffer est une mémoire volatile qui se trouve dans le
disque lui-même qui est beaucoup plus rapide à lire (et à écrire) que le
disque lui-même.
Q1 : déjà, est-ce que j'ai bon jusque là ?
Q2 : les performances ci-dessous sont bien faibles au regard des
caractéristiques annoncées, on est d'accord ? Rien que sur sur mon
modeste pc perso (sans RAID) j'ai du « Timing buffered disk reads » égal
à 121.98 MB/sec les doigts dans pif.
Du coup, j'ai fait quelques recherches sur le Web et il est question ici
ou là paramètre "readahead". Alors, celui-là j'ai un peu de mal à le
comprendre : apparemment ça serait, au moment de la lecture du disque,
la taille des « paquets » (exprimée en nombre de secteurs consécutifs de
512 bytes) que le disque enverrait dans son buffer afin que le système
d'exploitation lise les données demandées. Du coup, pour une lecture
séquentielle de pas mal de données, ça fait gagner du temps d'avoir un
"readahead" élevé (car il y a moins de « paquets » à envoyer dans le
buffer) mais pour des lectures de petits fichiers un peu dispersés sur
le disque on y perd (car beaucoup de données sont envoyées dans le
buffer inutilement).
Q3 : est-ce correct ?
Du coup, voici une tentative de changement de ce paramètre et voici un
nouveau test :
Q4 : est-ce que cela vous semble correct (= en phase avec le matériel)
comme perfs cette fois ? Quelle bonne valeur faut-il donner à ce
paramètre "readahead" ? Comment faire pour que le paramètre soit
conservé après redémarrage ? Via une commande dans rc.local ? Y a-t-il
d'autres moyens que la modification de ce paramètre pour améliorer les
performances en lecture ?
Q5 : est-ce que cela vous paraît correct ? Personnellement je n'ai rien
trouvé qui améliore sensiblement la vitesse d'écriture (mais peut-être
c'est déjà en phase avec les caractéristiques du serveur). Peut-être
ai-je des choses à modifier au niveau du contrôleur RAID. Je vous donne
des infos ci-dessous :
---------------------------------------------------------
~# hpacucli controller all show config detail
Smart Array P600 in Slot 3
Bus Interface: PCI
Slot: 3
Serial Number: P92B30F9SSZ05U
Cache Serial Number: P67570H9SSY0A5
RAID 6 (ADG) Status: Enabled
Controller Status: OK
Hardware Revision: A
Firmware Version: 2.04
Rebuild Priority: Medium
Expand Priority: Medium
Surface Scan Delay: 15 secs
Surface Scan Mode: Idle
Post Prompt Timeout: 0 secs
Cache Board Present: True
Cache Status: OK
Cache Ratio: 50% Read / 50% Write
Drive Write Cache: Enabled
Total Cache Size: 256 MB
Total Cache Memory Available: 224 MB
No-Battery Write Cache: Disabled
Cache Backup Power Source: Batteries
Battery/Capacitor Count: 2
Battery/Capacitor Status: OK
SATA NCQ Supported: False
Array: A
Interface Type: SAS
Unused Space: 0 MB
Status: OK
Array Type: Data
Logical Drive: 1
Size: 820.0 GB
Fault Tolerance: RAID 5
Heads: 255
Sectors Per Track: 32
Cylinders: 65535
Strip Size: 64 KB
Full Stripe Size: 768 KB
Status: OK
Caching: Enabled
Parity Initialization Status: Initialization Completed
Unique Identifier: 600508B10010463953535A303555000C
Disk Name: /dev/cciss/c0d0
Mount Points: /boot 285 MB, / 18.6 GB
OS Status: LOCKED
Logical Drive Label: A021A069P92B30F9SSZ05UB273
Drive Type: Data
physicaldrive 1E:1:1
Port: 1E
Box: 1
Bay: 1
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 72 GB
Rotational Speed: 10000
Firmware Revision: HPD4
Serial Number: 6SD24N6W0000B123M7FT
Model: HP DG0072BALVL
PHY Count: 2
PHY Transfer Rate: 3.0Gbps, Unknown
physicaldrive 1E:1:2
Port: 1E
Box: 1
Bay: 2
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 72 GB
Rotational Speed: 10000
Firmware Revision: HPD7
Serial Number: 3LB07GA7000076139ZSM
Model: HP DG072A8B54
PHY Count: 1
PHY Transfer Rate: 3.0Gbps
physicaldrive 1E:1:3
Port: 1E
Box: 1
Bay: 3
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 72 GB
Rotational Speed: 10000
Firmware Revision: HPD7
Serial Number: 3LB07GPJ0000761393MC
Model: HP DG072A8B54
PHY Count: 1
PHY Transfer Rate: 3.0Gbps
physicaldrive 1E:1:4
Port: 1E
Box: 1
Bay: 4
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 72 GB
Rotational Speed: 10000
Firmware Revision: HPD7
Serial Number: 3LB07G65000076139Z01
Model: HP DG072A8B54
PHY Count: 1
PHY Transfer Rate: 3.0Gbps
physicaldrive 1E:1:5
Port: 1E
Box: 1
Bay: 5
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 72 GB
Rotational Speed: 10000
Firmware Revision: HPD7
Serial Number: 3LB07G9Q00007613SML0
Model: HP DG072A8B54
PHY Count: 1
PHY Transfer Rate: 3.0Gbps
physicaldrive 1E:1:6
Port: 1E
Box: 1
Bay: 6
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 72 GB
Rotational Speed: 10000
Firmware Revision: HPD7
Serial Number: 3LB07GPW0000761392XX
Model: HP DG072A8B54
PHY Count: 1
PHY Transfer Rate: 3.0Gbps
physicaldrive 1E:1:7
Port: 1E
Box: 1
Bay: 7
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 72 GB
Rotational Speed: 10000
Firmware Revision: HPD7
Serial Number: 3LB07G6Q000076139Z15
Model: HP DG072A8B54
PHY Count: 1
PHY Transfer Rate: 3.0Gbps
physicaldrive 1E:1:8
Port: 1E
Box: 1
Bay: 8
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 72 GB
Rotational Speed: 10000
Firmware Revision: HPD7
Serial Number: 3LB07G3000007613A0AG
Model: HP DG072A8B54
PHY Count: 1
PHY Transfer Rate: 3.0Gbps
physicaldrive 1E:1:9
Port: 1E
Box: 1
Bay: 9
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 72 GB
Rotational Speed: 10000
Firmware Revision: HPD7
Serial Number: 3LB07HAX0000761393YP
Model: HP DG072A8B54
PHY Count: 1
PHY Transfer Rate: 3.0Gbps
physicaldrive 2I:1:1
Port: 2I
Box: 1
Bay: 1
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 72 GB
Rotational Speed: 10000
Firmware Revision: HPD7
Serial Number: 3LB0FYTG000076362WBD
Model: HP DG072A8B54
PHY Count: 1
PHY Transfer Rate: 3.0Gbps
physicaldrive 2I:1:2
Port: 2I
Box: 1
Bay: 2
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 72 GB
Rotational Speed: 10000
Firmware Revision: HPD7
Serial Number: 3LB0G0L700007636KFHL
Model: HP DG072A8B54
PHY Count: 1
PHY Transfer Rate: 3.0Gbps
physicaldrive 2I:1:3
Port: 2I
Box: 1
Bay: 3
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 72 GB
Rotational Speed: 10000
Firmware Revision: HPD7
Serial Number: 3LB0FYW600007636KFQL
Model: HP DG072A8B54
PHY Count: 1
PHY Transfer Rate: 3.0Gbps
physicaldrive 2I:1:4
Port: 2I
Box: 1
Bay: 4
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 72 GB
Rotational Speed: 10000
Firmware Revision: HPD7
Serial Number: 3LB0FZX300007636XVA1
Model: HP DG072A8B54
PHY Count: 1
PHY Transfer Rate: 3.0Gbps
physicaldrive 1E:1:10
Port: 1E
Box: 1
Bay: 10
Status: OK
Drive Type: Spare Drive
Interface Type: SAS
Size: 72 GB
Rotational Speed: 10000
Firmware Revision: HPD7
Serial Number: 3LB07H0Q00007613A01J
Model: HP DG072A8B54
PHY Count: 1
PHY Transfer Rate: 3.0Gbps
Expander 122
Device Number: 122
Firmware Version: A
WWID: 500508B300A2093F
Port: 1E
Box: 1
Vendor ID: HP
Model: MSA 50-10D25G1
Expander 123
Device Number: 123
Firmware Version: A
WWID: 500508B300A2092F
Port: 1E
Box: 1
Vendor ID: HP
Model: MSA 50-10D25G1
Enclosure SEP (Vendor ID HP, Model MSA50 -10D25G1) 121
Device Number: 121
Firmware Version: 1.20
WWID: 500508B300A2092C
Port: 1E
Box: 1
Vendor ID: HP
Model: MSA50 -10D25G1
---------------------------------------------------------
Voici les paramètres qui ont retenu mon attention :
Smart Array P600 in Slot 3
Cache Ratio: 50% Read / 50% Write
Total Cache Size: 256 MB
Le « cache ratio », celui-là je peux le changer sans problème avec la
commande "hpacucli" mais je n'ai pas noté ensuite de changement sensible
au niveau des performances.
Un paramètre que j'aurais bien aimé changer c'est le « Total Cache Size
» qui me semble bien petit. Mais celui-là, je n'ai pas trouvé le moyen
de le changer, peut-être est-ce un paramètre purement matériel
impossible à changer...
Q6 : enfin il y a les paramètres « Strip Size » et « Full Strip Size ».
Savez-vous ce qu'ils signifient ? Apparemment, ça peut avoir une
incidence sur les performances. Mais je n'ai pas tellement de choix pour
cette valeur :
Le Sun, 18 Nov 2012 23:28:27 +0100, Francois Lafont a écrit:
Bon, je vais peut-être m'orienter vers 2 grappe alors.
Je te conseille sérieusement d'essayer aussi avec une grappe en RAID logiciel md; vu les performances du contrôleur, tu as tout à y gagner, il est probable que ce sera 5 à 10 fois plus performant.
-- The bearing of a child takes 9 months, no matter how many women are assigned. Fred Brooks
Le Sun, 18 Nov 2012 23:28:27 +0100, Francois Lafont a écrit:
Bon, je vais peut-être m'orienter vers 2 grappe alors.
Je te conseille sérieusement d'essayer aussi avec une grappe en RAID
logiciel md; vu les performances du contrôleur, tu as tout à y gagner, il
est probable que ce sera 5 à 10 fois plus performant.
--
The bearing of a child takes 9 months, no matter how many women are
assigned.
Fred Brooks
Le Sun, 18 Nov 2012 23:28:27 +0100, Francois Lafont a écrit:
Bon, je vais peut-être m'orienter vers 2 grappe alors.
Je te conseille sérieusement d'essayer aussi avec une grappe en RAID logiciel md; vu les performances du contrôleur, tu as tout à y gagner, il est probable que ce sera 5 à 10 fois plus performant.
-- The bearing of a child takes 9 months, no matter how many women are assigned. Fred Brooks
Francois Lafont
Le 18/11/2012 16:58, Emmanuel Florac a écrit :
Q4 : est-ce que cela vous semble correct (= en phase avec le matériel) comme perfs cette fois ?
Clairement, non. Sur les machines avec une 15aine de disques 7200 tours (donc deux fois plus lents) que j'assemble, la performance est très, très supérieure (pour 15 disques en RAID-6, j'ai au moins 800 Mo/s soutenus en écriture et 1200 Mo/s en lecture sur les derniers systèmes). D'un autre côté, d'après ce que j'ai vu avec les P400 et P450 HP,
Dans mon cas c'est un contrôleur Smart Array P600.
Apparemment tout est bien configuré: le cache est activé, en lecture comme en écriture, etc. À ce stade je me demande s'il ne serait pas plus intéressant de mettre les disques en JBOD et de faire du RAID-5 logiciel; la performance serait certainement meilleure parce que 225 Mo/s en écriture avec 13 disques 15k, c'est vraiment pathétique (tu devrais avoir un bon 1 Go/s ou même plus).
Alors effectivement je suis bien loin du compte...
Je viens de voir que tu as assemblé dans la même grappe les disques internes au serveur et la baie externe.
Oui, mais le problème est qu'il n'y a pas pléthore d'espace disque...
Je ne pense pas non plus que ce soit une bonne idée; les disques internes devraient plutôt être configurés en RAID-10 dans une grappe pour héberger le système et les applis, et les disques dans le châssis externe en RAID-5.
Tu es le deuxième à dire cela. Il faudra vraiment que je tente le coup pour en avoir le cœur net. :-)
Je ne pense pas cependant que ça joue sur les performance globales, mais sait-on jamais, ces contrôleurs sont si mal foutus...
Je vous tiendrai au courant. Merci pour ton aide.
-- François Lafont
Le 18/11/2012 16:58, Emmanuel Florac a écrit :
Q4 : est-ce que cela vous semble correct (= en phase avec le matériel)
comme perfs cette fois ?
Clairement, non. Sur les machines avec une 15aine de disques 7200 tours
(donc deux fois plus lents) que j'assemble, la performance est très, très
supérieure (pour 15 disques en RAID-6, j'ai au moins 800 Mo/s soutenus en
écriture et 1200 Mo/s en lecture sur les derniers systèmes). D'un autre
côté, d'après ce que j'ai vu avec les P400 et P450 HP,
Dans mon cas c'est un contrôleur Smart Array P600.
Apparemment tout est bien configuré: le cache est activé, en lecture
comme en écriture, etc. À ce stade je me demande s'il ne serait pas plus
intéressant de mettre les disques en JBOD et de faire du RAID-5 logiciel;
la performance serait certainement meilleure parce que 225 Mo/s en
écriture avec 13 disques 15k, c'est vraiment pathétique (tu devrais avoir
un bon 1 Go/s ou même plus).
Alors effectivement je suis bien loin du compte...
Je viens de voir que tu as assemblé dans la même grappe les disques
internes au serveur et la baie externe.
Oui, mais le problème est qu'il n'y a pas pléthore d'espace disque...
Je ne pense pas non plus que ce
soit une bonne idée; les disques internes devraient plutôt être
configurés en RAID-10 dans une grappe pour héberger le système et les
applis, et les disques dans le châssis externe en RAID-5.
Tu es le deuxième à dire cela. Il faudra vraiment que je tente le coup
pour en avoir le cœur net. :-)
Je ne pense pas
cependant que ça joue sur les performance globales, mais sait-on jamais,
ces contrôleurs sont si mal foutus...
Q4 : est-ce que cela vous semble correct (= en phase avec le matériel) comme perfs cette fois ?
Clairement, non. Sur les machines avec une 15aine de disques 7200 tours (donc deux fois plus lents) que j'assemble, la performance est très, très supérieure (pour 15 disques en RAID-6, j'ai au moins 800 Mo/s soutenus en écriture et 1200 Mo/s en lecture sur les derniers systèmes). D'un autre côté, d'après ce que j'ai vu avec les P400 et P450 HP,
Dans mon cas c'est un contrôleur Smart Array P600.
Apparemment tout est bien configuré: le cache est activé, en lecture comme en écriture, etc. À ce stade je me demande s'il ne serait pas plus intéressant de mettre les disques en JBOD et de faire du RAID-5 logiciel; la performance serait certainement meilleure parce que 225 Mo/s en écriture avec 13 disques 15k, c'est vraiment pathétique (tu devrais avoir un bon 1 Go/s ou même plus).
Alors effectivement je suis bien loin du compte...
Je viens de voir que tu as assemblé dans la même grappe les disques internes au serveur et la baie externe.
Oui, mais le problème est qu'il n'y a pas pléthore d'espace disque...
Je ne pense pas non plus que ce soit une bonne idée; les disques internes devraient plutôt être configurés en RAID-10 dans une grappe pour héberger le système et les applis, et les disques dans le châssis externe en RAID-5.
Tu es le deuxième à dire cela. Il faudra vraiment que je tente le coup pour en avoir le cœur net. :-)
Je ne pense pas cependant que ça joue sur les performance globales, mais sait-on jamais, ces contrôleurs sont si mal foutus...
Je vous tiendrai au courant. Merci pour ton aide.
-- François Lafont
Ascadix
Francois Lafont a émis l'idée suivante :
Le 18/11/2012 01:45, Ascadix a écrit :
Une seule grappe RAID avec les DD de la baie interne et ceux de la baie externe ... c'est pas trop courrant comme config. Généralement, on utilise plutot une grappe RAID par baie.
Ah, ok. Du coup, j'essayerai sans doute de faire ainsi.
Si ton OS gére correctement un cache lecture,
L'OS est Debian Squeeze 64 bit, c'est quand même pas de la gnognote, non ? :-)
Je sais pas, je l'utilise pas assez pour juger ça, donc je me prononce pas. Comme tu as p'tet pu le voir, je suis nettement plus "windows" que "Linux", donc pour ta question, j'peux participer sur le plan matos, mais pas trop OS.
tu pourais affecter ton cache controleur en majorité à l'écriture, ça améliorera les perf en écriture sans dégrader la lecture.
Ok.
Par contre, si ton OS sait pas gérer correctement un cache systeme en lecture ou est à cours de RAM pour faire du cache-disque, faut mieux mettre du genre 75 R / 25 W (à ajuster suivant le type d'I/O majoritaire sur ton serveur)
Il y a 16 Go de RAM quand même.
Ok pour la quantité, mais regarde quand même si l'OS est réglé pour privilégier l'usage en cache ou pas.
Du coup, je vais peut-être m'orienter vers un ratio en faveur de l'écriture je pense.
Un paramètre que j'aurais bien aimé changer c'est le « Total Cache Size » qui me semble bien petit. Mais celui-là, je n'ai pas trouvé le moyen de le changer, peut-être est-ce un paramètre purement matériel impossible à changer...
C'est la taille de RAM embarqué sur ton controleur, si tu veux augmenter, faut rajouter/changer la barette de cache (et oubli pas la batterie qui va avec)
Ok. Et bien le contrôleur RAID ne possède que 256 Mo de cache. C'est pas énorme je trouve.
ça dépend de l'époque :-)
C'est pas gigantesque, mais faut voir si c'est adapté à l'usage de ton serveur, tu peut p'tet mettre plus (ça dépend du controleur) mais ça coute plus cher ...
Par ex, si le serveur sert de controleur (LDAP) +DNS + DHCP, ça suffit. par contre, pour un serveur de fichier / SGBD, on peut mettre plus.
Q6 : enfin il y a les paramètres « Strip Size » et « Full Strip Size ». Savez-vous ce qu'ils signifient ? Apparemment, ça peut avoir une incidence sur les performances. Mais je n'ai pas tellement de choix pour cette valeur :
"Full Strip Size" t'en préoccupe pas, c'est une info calculé à partir du "strip size" et du nombre de DD utiles.
"Strip Size" c'est la taille de découpe des blocs de donnée RAID (en gros, la taille d'un "secteur" du volume logique RAID)
D'accord. Merci bien pour cette info.
Pour trouver la valeur optimale, faut mixer divers facteurs:
l'idée de base c'est : - si tes I/O sont fortement aléatoires -> petit strip - si tes I/O sont fortement séquentiels -> grand strip
En admettant que sur le serveur sera installé un Xen4 et des machines virtuelles (les disques des VM seront dans une partition LVM), je suis plus dans quelle catégorie ? Des I/O plutôt séquentiels, non ?
Non, pas forcement, t'aura les I/O de tes VM.
Déjà, plusieures VM ça oriente plus vers des I/O dispersées que séquentielles, ensuite voir dans tes VM comment elles bossent.
NB: pense à l'alignement des partitions dans les VM, comme pour un SSD ou un DD 4k, là le motif c'est de pas avoir de cluster dans la VM qui soit à cheval sur 2 strip de ton RAID.
Mais faut moduler avec la doc de ton controleur, avec certains controleurs la taille "optimale" dépend aussi du niveau de RAID choisi, et la répartition R/W à aussi son importance.
Si tu sais pas, prend la valeur par défaut, c'est censé être celle ou le controleur donnera le meilleur de ses capacité indépandament de ton schéma d'I/O.
Ok.
Q7 : voyez-vous des choses à améliorer pour optimiser les performances en lecture/écritures au niveau du contrôleur RAID ?
Faudrais savoir la config de ton serveur, mais en général, on sépare les grappes RAID.
- 1 grappe pour l'OS (taille ..juste ce qu'il faut, plutot RAID10) - 1 grappe swap (éventuellement, taille ..juste ce qu'il faut, plutot RAID10) - X grappes pour les data, suivant le nb de service qui accédent au DD, la répartition des données, etc ... plutot RAID5 ou 6
Par ex, si ton serveur fourni une DB et un serveur Web, tu met la DB sur une grappe et le contenu statique du site sur une autre grappe.
Les binaires sur une grappe isolé si possible, sinon sur la grappe de l'OS.
évidement, ça coute des DD tout ça, donc parfois/souvent, on fait des compromis.
Et oui.
Le compromis plus courrant à bas cout c'est 2 grappes: - 1 grappe OS/ SWAP / applis - 1 grappe data
Bon, je vais peut-être m'orienter vers 2 grappe alors.
Merci pour tes précieux conseils Ascadix. :-)
Bah, c'est juste mes 2 cts :-)
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Francois Lafont a émis l'idée suivante :
Le 18/11/2012 01:45, Ascadix a écrit :
Une seule grappe RAID avec les DD de la baie interne et ceux de la baie
externe ... c'est pas trop courrant comme config.
Généralement, on utilise plutot une grappe RAID par baie.
Ah, ok. Du coup, j'essayerai sans doute de faire ainsi.
Si ton OS gére correctement un cache lecture,
L'OS est Debian Squeeze 64 bit, c'est quand même pas de la gnognote, non
? :-)
Je sais pas, je l'utilise pas assez pour juger ça, donc je me prononce
pas.
Comme tu as p'tet pu le voir, je suis nettement plus "windows" que
"Linux", donc pour ta question, j'peux participer sur le plan matos,
mais pas trop OS.
tu pourais affecter ton
cache controleur en majorité à l'écriture, ça améliorera les perf en
écriture sans dégrader la lecture.
Ok.
Par contre, si ton OS sait pas gérer correctement un cache systeme en
lecture ou est à cours de RAM pour faire du cache-disque, faut mieux
mettre du genre 75 R / 25 W (à ajuster suivant le type d'I/O
majoritaire sur ton serveur)
Il y a 16 Go de RAM quand même.
Ok pour la quantité, mais regarde quand même si l'OS est réglé pour
privilégier l'usage en cache ou pas.
Du coup, je vais peut-être m'orienter
vers un ratio en faveur de l'écriture je pense.
Un paramètre que j'aurais bien aimé changer c'est le « Total Cache Size
» qui me semble bien petit. Mais celui-là, je n'ai pas trouvé le moyen
de le changer, peut-être est-ce un paramètre purement matériel
impossible à changer...
C'est la taille de RAM embarqué sur ton controleur, si tu veux
augmenter, faut rajouter/changer la barette de cache (et oubli pas la
batterie qui va avec)
Ok. Et bien le contrôleur RAID ne possède que 256 Mo de cache. C'est pas
énorme je trouve.
ça dépend de l'époque :-)
C'est pas gigantesque, mais faut voir si c'est adapté à l'usage de ton
serveur, tu peut p'tet mettre plus (ça dépend du controleur) mais ça
coute plus cher ...
Par ex, si le serveur sert de controleur (LDAP) +DNS + DHCP, ça suffit.
par contre, pour un serveur de fichier / SGBD, on peut mettre plus.
Q6 : enfin il y a les paramètres « Strip Size » et « Full Strip Size ».
Savez-vous ce qu'ils signifient ? Apparemment, ça peut avoir une
incidence sur les performances. Mais je n'ai pas tellement de choix pour
cette valeur :
"Full Strip Size" t'en préoccupe pas, c'est une info calculé à partir du
"strip size" et du nombre de DD utiles.
"Strip Size" c'est la taille de découpe des blocs de donnée RAID (en
gros, la taille d'un "secteur" du volume logique RAID)
D'accord. Merci bien pour cette info.
Pour trouver la valeur optimale, faut mixer divers facteurs:
l'idée de base c'est :
- si tes I/O sont fortement aléatoires -> petit strip
- si tes I/O sont fortement séquentiels -> grand strip
En admettant que sur le serveur sera installé un Xen4 et des machines
virtuelles (les disques des VM seront dans une partition LVM), je suis
plus dans quelle catégorie ? Des I/O plutôt séquentiels, non ?
Non, pas forcement, t'aura les I/O de tes VM.
Déjà, plusieures VM ça oriente plus vers des I/O dispersées que
séquentielles, ensuite voir dans tes VM comment elles bossent.
NB: pense à l'alignement des partitions dans les VM, comme pour un SSD
ou un DD 4k, là le motif c'est de pas avoir de cluster dans la VM qui
soit à cheval sur 2 strip de ton RAID.
Mais faut moduler avec la doc de ton controleur, avec certains
controleurs la taille "optimale" dépend aussi du niveau de RAID choisi,
et la répartition R/W à aussi son importance.
Si tu sais pas, prend la valeur par défaut, c'est censé être celle ou le
controleur donnera le meilleur de ses capacité indépandament de ton
schéma d'I/O.
Ok.
Q7 : voyez-vous des choses à améliorer pour optimiser les performances
en lecture/écritures au niveau du contrôleur RAID ?
Faudrais savoir la config de ton serveur, mais en général, on sépare les
grappes RAID.
- 1 grappe pour l'OS (taille ..juste ce qu'il faut, plutot RAID10)
- 1 grappe swap (éventuellement, taille ..juste ce qu'il faut, plutot
RAID10)
- X grappes pour les data, suivant le nb de service qui accédent au DD,
la répartition des données, etc ... plutot RAID5 ou 6
Par ex, si ton serveur fourni une DB et un serveur Web, tu met la DB sur
une grappe et le contenu statique du site sur une autre grappe.
Les binaires sur une grappe isolé si possible, sinon sur la grappe de l'OS.
évidement, ça coute des DD tout ça, donc parfois/souvent, on fait des
compromis.
Et oui.
Le compromis plus courrant à bas cout c'est 2 grappes:
- 1 grappe OS/ SWAP / applis
- 1 grappe data
Bon, je vais peut-être m'orienter vers 2 grappe alors.
Merci pour tes précieux conseils Ascadix. :-)
Bah, c'est juste mes 2 cts :-)
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
Une seule grappe RAID avec les DD de la baie interne et ceux de la baie externe ... c'est pas trop courrant comme config. Généralement, on utilise plutot une grappe RAID par baie.
Ah, ok. Du coup, j'essayerai sans doute de faire ainsi.
Si ton OS gére correctement un cache lecture,
L'OS est Debian Squeeze 64 bit, c'est quand même pas de la gnognote, non ? :-)
Je sais pas, je l'utilise pas assez pour juger ça, donc je me prononce pas. Comme tu as p'tet pu le voir, je suis nettement plus "windows" que "Linux", donc pour ta question, j'peux participer sur le plan matos, mais pas trop OS.
tu pourais affecter ton cache controleur en majorité à l'écriture, ça améliorera les perf en écriture sans dégrader la lecture.
Ok.
Par contre, si ton OS sait pas gérer correctement un cache systeme en lecture ou est à cours de RAM pour faire du cache-disque, faut mieux mettre du genre 75 R / 25 W (à ajuster suivant le type d'I/O majoritaire sur ton serveur)
Il y a 16 Go de RAM quand même.
Ok pour la quantité, mais regarde quand même si l'OS est réglé pour privilégier l'usage en cache ou pas.
Du coup, je vais peut-être m'orienter vers un ratio en faveur de l'écriture je pense.
Un paramètre que j'aurais bien aimé changer c'est le « Total Cache Size » qui me semble bien petit. Mais celui-là, je n'ai pas trouvé le moyen de le changer, peut-être est-ce un paramètre purement matériel impossible à changer...
C'est la taille de RAM embarqué sur ton controleur, si tu veux augmenter, faut rajouter/changer la barette de cache (et oubli pas la batterie qui va avec)
Ok. Et bien le contrôleur RAID ne possède que 256 Mo de cache. C'est pas énorme je trouve.
ça dépend de l'époque :-)
C'est pas gigantesque, mais faut voir si c'est adapté à l'usage de ton serveur, tu peut p'tet mettre plus (ça dépend du controleur) mais ça coute plus cher ...
Par ex, si le serveur sert de controleur (LDAP) +DNS + DHCP, ça suffit. par contre, pour un serveur de fichier / SGBD, on peut mettre plus.
Q6 : enfin il y a les paramètres « Strip Size » et « Full Strip Size ». Savez-vous ce qu'ils signifient ? Apparemment, ça peut avoir une incidence sur les performances. Mais je n'ai pas tellement de choix pour cette valeur :
"Full Strip Size" t'en préoccupe pas, c'est une info calculé à partir du "strip size" et du nombre de DD utiles.
"Strip Size" c'est la taille de découpe des blocs de donnée RAID (en gros, la taille d'un "secteur" du volume logique RAID)
D'accord. Merci bien pour cette info.
Pour trouver la valeur optimale, faut mixer divers facteurs:
l'idée de base c'est : - si tes I/O sont fortement aléatoires -> petit strip - si tes I/O sont fortement séquentiels -> grand strip
En admettant que sur le serveur sera installé un Xen4 et des machines virtuelles (les disques des VM seront dans une partition LVM), je suis plus dans quelle catégorie ? Des I/O plutôt séquentiels, non ?
Non, pas forcement, t'aura les I/O de tes VM.
Déjà, plusieures VM ça oriente plus vers des I/O dispersées que séquentielles, ensuite voir dans tes VM comment elles bossent.
NB: pense à l'alignement des partitions dans les VM, comme pour un SSD ou un DD 4k, là le motif c'est de pas avoir de cluster dans la VM qui soit à cheval sur 2 strip de ton RAID.
Mais faut moduler avec la doc de ton controleur, avec certains controleurs la taille "optimale" dépend aussi du niveau de RAID choisi, et la répartition R/W à aussi son importance.
Si tu sais pas, prend la valeur par défaut, c'est censé être celle ou le controleur donnera le meilleur de ses capacité indépandament de ton schéma d'I/O.
Ok.
Q7 : voyez-vous des choses à améliorer pour optimiser les performances en lecture/écritures au niveau du contrôleur RAID ?
Faudrais savoir la config de ton serveur, mais en général, on sépare les grappes RAID.
- 1 grappe pour l'OS (taille ..juste ce qu'il faut, plutot RAID10) - 1 grappe swap (éventuellement, taille ..juste ce qu'il faut, plutot RAID10) - X grappes pour les data, suivant le nb de service qui accédent au DD, la répartition des données, etc ... plutot RAID5 ou 6
Par ex, si ton serveur fourni une DB et un serveur Web, tu met la DB sur une grappe et le contenu statique du site sur une autre grappe.
Les binaires sur une grappe isolé si possible, sinon sur la grappe de l'OS.
évidement, ça coute des DD tout ça, donc parfois/souvent, on fait des compromis.
Et oui.
Le compromis plus courrant à bas cout c'est 2 grappes: - 1 grappe OS/ SWAP / applis - 1 grappe data
Bon, je vais peut-être m'orienter vers 2 grappe alors.
Merci pour tes précieux conseils Ascadix. :-)
Bah, c'est juste mes 2 cts :-)
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Francois Lafont
Le 19/11/2012 00:03, Francois Lafont a écrit :
Apparemment tout est bien configuré: le cache est activé, en lecture comme en écriture, etc. À ce stade je me demande s'il ne serait pas plus intéressant de mettre les disques en JBOD et de faire du RAID-5 logiciel; la performance serait certainement meilleure parce que 225 Mo/s en écriture avec 13 disques 15k, c'est vraiment pathétique (tu devrais avoir un bon 1 Go/s ou même plus).
Alors effectivement je suis bien loin du compte...
Quand tu parles de 1 Go/s, tu parles bien du test de hdparm avec l'option -t (en minuscules) ?
-- François Lafont
Le 19/11/2012 00:03, Francois Lafont a écrit :
Apparemment tout est bien configuré: le cache est activé, en lecture
comme en écriture, etc. À ce stade je me demande s'il ne serait pas plus
intéressant de mettre les disques en JBOD et de faire du RAID-5 logiciel;
la performance serait certainement meilleure parce que 225 Mo/s en
écriture avec 13 disques 15k, c'est vraiment pathétique (tu devrais avoir
un bon 1 Go/s ou même plus).
Alors effectivement je suis bien loin du compte...
Quand tu parles de 1 Go/s, tu parles bien du test de hdparm avec
l'option -t (en minuscules) ?
Apparemment tout est bien configuré: le cache est activé, en lecture comme en écriture, etc. À ce stade je me demande s'il ne serait pas plus intéressant de mettre les disques en JBOD et de faire du RAID-5 logiciel; la performance serait certainement meilleure parce que 225 Mo/s en écriture avec 13 disques 15k, c'est vraiment pathétique (tu devrais avoir un bon 1 Go/s ou même plus).
Alors effectivement je suis bien loin du compte...
Quand tu parles de 1 Go/s, tu parles bien du test de hdparm avec l'option -t (en minuscules) ?
-- François Lafont
Emmanuel Florac
Le Mon, 19 Nov 2012 00:10:23 +0100, Francois Lafont a écrit:
Oui, qui peut être activé ou désactivé. Il est apparemment actif d'après l'outil cciss.
Oui effet, l'outil cciss me signale que le cache est activé au niveau du disque logique. Mais le cache existe aussi au niveau d'un disque physique, non ?
Malheureusement l'utilisation du cache des disques est liée au type de contrôleur dont il faut étudier la doc attentivement pour savoir ce qu'il en fait.
J'en conclus que c'est tout de même le test avec l'option -t qui est le plus représentatif d'une lecture sur le disque.
Oui mais c'est le -T qui est représentatif des usages habituels, où une grande partie de la RAM de la machine est utilisée comme cache disque.
Ok mais la première fois où on veut lire telles ou telles donnée j'imagine qu'on se trouve plutôt dans le cas du « -t ».
Non, ça dépend surtout de la façon dont on y accède: si on ouvre un fichier pour le lire avec une application ordinaire, on est toujours dans le cas "avec buffers". Par contre si on ouvre en accès direct c'est dans certains cas précis, base de données par exemple.
-- I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. Bjarne Stroustrup
Le Mon, 19 Nov 2012 00:10:23 +0100, Francois Lafont a écrit:
Oui, qui peut être activé ou désactivé. Il est apparemment actif
d'après l'outil cciss.
Oui effet, l'outil cciss me signale que le cache est activé au niveau du
disque logique. Mais le cache existe aussi au niveau d'un disque
physique, non ?
Malheureusement l'utilisation du cache des disques est liée au type de
contrôleur dont il faut étudier la doc attentivement pour savoir ce qu'il
en fait.
J'en conclus que c'est tout de même le test avec l'option -t qui est
le plus représentatif d'une lecture sur le disque.
Oui mais c'est le -T qui est représentatif des usages habituels, où une
grande partie de la RAM de la machine est utilisée comme cache disque.
Ok mais la première fois où on veut lire telles ou telles donnée
j'imagine qu'on se trouve plutôt dans le cas du « -t ».
Non, ça dépend surtout de la façon dont on y accède: si on ouvre un
fichier pour le lire avec une application ordinaire, on est toujours dans
le cas "avec buffers". Par contre si on ouvre en accès direct c'est dans
certains cas précis, base de données par exemple.
--
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
Bjarne Stroustrup
Le Mon, 19 Nov 2012 00:10:23 +0100, Francois Lafont a écrit:
Oui, qui peut être activé ou désactivé. Il est apparemment actif d'après l'outil cciss.
Oui effet, l'outil cciss me signale que le cache est activé au niveau du disque logique. Mais le cache existe aussi au niveau d'un disque physique, non ?
Malheureusement l'utilisation du cache des disques est liée au type de contrôleur dont il faut étudier la doc attentivement pour savoir ce qu'il en fait.
J'en conclus que c'est tout de même le test avec l'option -t qui est le plus représentatif d'une lecture sur le disque.
Oui mais c'est le -T qui est représentatif des usages habituels, où une grande partie de la RAM de la machine est utilisée comme cache disque.
Ok mais la première fois où on veut lire telles ou telles donnée j'imagine qu'on se trouve plutôt dans le cas du « -t ».
Non, ça dépend surtout de la façon dont on y accède: si on ouvre un fichier pour le lire avec une application ordinaire, on est toujours dans le cas "avec buffers". Par contre si on ouvre en accès direct c'est dans certains cas précis, base de données par exemple.
-- I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. Bjarne Stroustrup
Emmanuel Florac
Le Mon, 19 Nov 2012 00:12:39 +0100, Francois Lafont a écrit:
Dans le cas d'un RAID logiciel, faut-il aussi que je respecte aussi une séparation avec d'un côté une grappe pour les 4 disques du serveur et de l'autre une grappe pour les 10 disques de la baie SAS, ou bien on s'en fiche ?
Dans l'absolu, il est préférable d'avoir deux volumes parce que la connexion entre le serveur et la baie peut toujours être interrompue, mais si ça te pose vraiment problème tu peux toujours regrouper tout ensemble.
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Le Mon, 19 Nov 2012 00:12:39 +0100, Francois Lafont a écrit:
Dans le cas d'un RAID logiciel, faut-il aussi que je respecte aussi une
séparation avec d'un côté une grappe pour les 4 disques du serveur et de
l'autre une grappe pour les 10 disques de la baie SAS, ou bien on s'en
fiche ?
Dans l'absolu, il est préférable d'avoir deux volumes parce que la
connexion entre le serveur et la baie peut toujours être interrompue,
mais si ça te pose vraiment problème tu peux toujours regrouper tout
ensemble.
--
Ne pas savoir de quoi on parle est un avantage dont il ne faut pas
abuser.
R.Debray
Le Mon, 19 Nov 2012 00:12:39 +0100, Francois Lafont a écrit:
Dans le cas d'un RAID logiciel, faut-il aussi que je respecte aussi une séparation avec d'un côté une grappe pour les 4 disques du serveur et de l'autre une grappe pour les 10 disques de la baie SAS, ou bien on s'en fiche ?
Dans l'absolu, il est préférable d'avoir deux volumes parce que la connexion entre le serveur et la baie peut toujours être interrompue, mais si ça te pose vraiment problème tu peux toujours regrouper tout ensemble.
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Emmanuel Florac
Le Mon, 19 Nov 2012 00:08:02 +0100, Ascadix a écrit:
Il y a 16 Go de RAM quand même.
Ok pour la quantité, mais regarde quand même si l'OS est réglé pour privilégier l'usage en cache ou pas.
Linux utilise toujours la RAM comme cache si elle n'a rien de mieux à faire.
Ok. Et bien le contrôleur RAID ne possède que 256 Mo de cache. C'est pas énorme je trouve.
ça dépend de l'époque
Oui c'est sans doute un peu trop mesquin pour faire un RAID-5 efficace, je pense que ce type de contrôleur est plutôt conçu pour du RAID-10.
-- Je suis riche des biens dont je sais me passer. Louis-Jean-Baptiste Etienne Vigée.
Le Mon, 19 Nov 2012 00:08:02 +0100, Ascadix a écrit:
Il y a 16 Go de RAM quand même.
Ok pour la quantité, mais regarde quand même si l'OS est réglé pour
privilégier l'usage en cache ou pas.
Linux utilise toujours la RAM comme cache si elle n'a rien de mieux à
faire.
Ok. Et bien le contrôleur RAID ne possède que 256 Mo de cache. C'est
pas énorme je trouve.
ça dépend de l'époque
Oui c'est sans doute un peu trop mesquin pour faire un RAID-5 efficace,
je pense que ce type de contrôleur est plutôt conçu pour du RAID-10.
--
Je suis riche des biens dont je sais me passer.
Louis-Jean-Baptiste Etienne Vigée.
Où on écrit en vrai 100 Go sur le disque le plus vite possible. hdparm teste sur une toute petite taille et uniquement en lecture.
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Pascal Hambourg
Francois Lafont a écrit :
Donc si je comprends bien dans la page man :
-------------------------------------------------------------- -t --> This displays the speed of reading through the buffer cache to the disk without any prior caching of data.
-T --> This displays the speed of reading directly from the Linux buffer cache without disk access. --------------------------------------------------------------
Dans les deux cas, le « buffer cache » est la mémoire cache de l'OS qui se trouve sur la RAM.
Est-ce correct ?
Oui.
Mais on est d'accord que le disque possède lui aussi en interne un cache, non ?
Oui, mais sa taille est très inférieure au cache de l'OS, de l'ordre de quelque méga-octets à quelques dizaines de méga-octets.
J'en conclus que c'est tout de même le test avec l'option -t qui est le plus représentatif d'une lecture sur le disque.
Oui. L'option -T mesure la performance du processeur et de la mémoire, indépendamment du disque testé. C'est d'ailleurs ce qui m'étionne dans tes chiffres : C'est proche de ce que m'indique hdparm sur un PC de bureau de 2004 ou 2005 équipé d'un Pentium 4 et de 512 Mio de mémoire DDR-1. Je m'attendrais à ce qu'une serveur récent avec 8 Gio de RAM devrait ait une valeur beaucoup plus élevée.
Francois Lafont a écrit :
Donc si je comprends bien dans la page man :
--------------------------------------------------------------
-t --> This displays the speed of reading through the buffer cache to
the disk without any prior caching of data.
-T --> This displays the speed of reading directly from the Linux buffer
cache without disk access.
--------------------------------------------------------------
Dans les deux cas, le « buffer cache » est la mémoire cache de l'OS qui
se trouve sur la RAM.
Est-ce correct ?
Oui.
Mais on est d'accord que le disque possède lui aussi en interne un
cache, non ?
Oui, mais sa taille est très inférieure au cache de l'OS, de l'ordre de
quelque méga-octets à quelques dizaines de méga-octets.
J'en conclus que c'est tout de même le test avec l'option -t qui est le
plus représentatif d'une lecture sur le disque.
Oui. L'option -T mesure la performance du processeur et de la mémoire,
indépendamment du disque testé. C'est d'ailleurs ce qui m'étionne dans
tes chiffres : C'est proche de ce que m'indique hdparm sur un PC de
bureau de 2004 ou 2005 équipé d'un Pentium 4 et de 512 Mio de mémoire
DDR-1. Je m'attendrais à ce qu'une serveur récent avec 8 Gio de RAM
devrait ait une valeur beaucoup plus élevée.
-------------------------------------------------------------- -t --> This displays the speed of reading through the buffer cache to the disk without any prior caching of data.
-T --> This displays the speed of reading directly from the Linux buffer cache without disk access. --------------------------------------------------------------
Dans les deux cas, le « buffer cache » est la mémoire cache de l'OS qui se trouve sur la RAM.
Est-ce correct ?
Oui.
Mais on est d'accord que le disque possède lui aussi en interne un cache, non ?
Oui, mais sa taille est très inférieure au cache de l'OS, de l'ordre de quelque méga-octets à quelques dizaines de méga-octets.
J'en conclus que c'est tout de même le test avec l'option -t qui est le plus représentatif d'une lecture sur le disque.
Oui. L'option -T mesure la performance du processeur et de la mémoire, indépendamment du disque testé. C'est d'ailleurs ce qui m'étionne dans tes chiffres : C'est proche de ce que m'indique hdparm sur un PC de bureau de 2004 ou 2005 équipé d'un Pentium 4 et de 512 Mio de mémoire DDR-1. Je m'attendrais à ce qu'une serveur récent avec 8 Gio de RAM devrait ait une valeur beaucoup plus élevée.
Francois Lafont
Le 19/11/2012 10:22, Pascal Hambourg a écrit :
Donc si je comprends bien dans la page man :
-------------------------------------------------------------- -t --> This displays the speed of reading through the buffer cache to the disk without any prior caching of data.
-T --> This displays the speed of reading directly from the Linux buffer cache without disk access. --------------------------------------------------------------
Dans les deux cas, le « buffer cache » est la mémoire cache de l'OS qui se trouve sur la RAM.
Est-ce correct ?
Oui.
Mais on est d'accord que le disque possède lui aussi en interne un cache, non ?
Oui, mais sa taille est très inférieure au cache de l'OS, de l'ordre de quelque méga-octets à quelques dizaines de méga-octets.
Ok, merci pour les explications.
J'en conclus que c'est tout de même le test avec l'option -t qui est le plus représentatif d'une lecture sur le disque.
Oui. L'option -T mesure la performance du processeur et de la mémoire, indépendamment du disque testé. C'est d'ailleurs ce qui m'étionne dans tes chiffres : C'est proche de ce que m'indique hdparm sur un PC de bureau de 2004 ou 2005 équipé d'un Pentium 4 et de 512 Mio de mémoire DDR-1. Je m'attendrais à ce qu'une serveur récent avec 8 Gio de RAM devrait ait une valeur beaucoup plus élevée.
Attention, j'ai donné les caractéristiques du serveurs dans mon premier message (16 Go de RAM). Ce n'est pas un serveur neuf, c'est même un ancien serveur qui nous a été gracieusement donné par une société privée (en septembre). Je ne sais pas de quand date le serveur mais ce n'est pas du matériel récent.
-- François Lafont
Le 19/11/2012 10:22, Pascal Hambourg a écrit :
Donc si je comprends bien dans la page man :
--------------------------------------------------------------
-t --> This displays the speed of reading through the buffer cache to
the disk without any prior caching of data.
-T --> This displays the speed of reading directly from the Linux buffer
cache without disk access.
--------------------------------------------------------------
Dans les deux cas, le « buffer cache » est la mémoire cache de l'OS qui
se trouve sur la RAM.
Est-ce correct ?
Oui.
Mais on est d'accord que le disque possède lui aussi en interne un
cache, non ?
Oui, mais sa taille est très inférieure au cache de l'OS, de l'ordre de
quelque méga-octets à quelques dizaines de méga-octets.
Ok, merci pour les explications.
J'en conclus que c'est tout de même le test avec l'option -t qui est le
plus représentatif d'une lecture sur le disque.
Oui. L'option -T mesure la performance du processeur et de la mémoire,
indépendamment du disque testé. C'est d'ailleurs ce qui m'étionne dans
tes chiffres : C'est proche de ce que m'indique hdparm sur un PC de
bureau de 2004 ou 2005 équipé d'un Pentium 4 et de 512 Mio de mémoire
DDR-1. Je m'attendrais à ce qu'une serveur récent avec 8 Gio de RAM
devrait ait une valeur beaucoup plus élevée.
Attention, j'ai donné les caractéristiques du serveurs dans mon premier
message (16 Go de RAM). Ce n'est pas un serveur neuf, c'est même un
ancien serveur qui nous a été gracieusement donné par une société privée
(en septembre). Je ne sais pas de quand date le serveur mais ce n'est
pas du matériel récent.
-------------------------------------------------------------- -t --> This displays the speed of reading through the buffer cache to the disk without any prior caching of data.
-T --> This displays the speed of reading directly from the Linux buffer cache without disk access. --------------------------------------------------------------
Dans les deux cas, le « buffer cache » est la mémoire cache de l'OS qui se trouve sur la RAM.
Est-ce correct ?
Oui.
Mais on est d'accord que le disque possède lui aussi en interne un cache, non ?
Oui, mais sa taille est très inférieure au cache de l'OS, de l'ordre de quelque méga-octets à quelques dizaines de méga-octets.
Ok, merci pour les explications.
J'en conclus que c'est tout de même le test avec l'option -t qui est le plus représentatif d'une lecture sur le disque.
Oui. L'option -T mesure la performance du processeur et de la mémoire, indépendamment du disque testé. C'est d'ailleurs ce qui m'étionne dans tes chiffres : C'est proche de ce que m'indique hdparm sur un PC de bureau de 2004 ou 2005 équipé d'un Pentium 4 et de 512 Mio de mémoire DDR-1. Je m'attendrais à ce qu'une serveur récent avec 8 Gio de RAM devrait ait une valeur beaucoup plus élevée.
Attention, j'ai donné les caractéristiques du serveurs dans mon premier message (16 Go de RAM). Ce n'est pas un serveur neuf, c'est même un ancien serveur qui nous a été gracieusement donné par une société privée (en septembre). Je ne sais pas de quand date le serveur mais ce n'est pas du matériel récent.
