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 Mon, 19 Nov 2012 10:06:23 +0100, Francois Lafont a écrit:
Il y a un petit truc qui m'échappe.
Si l'application ouvre un fichier pour la première fois, il faudra bien un accès disque quand même, pour certes ensuite placer le fichier dans le cache du système Linux (dans la RAM) et le lire ensuite sur ce cache, mais c'est donc bien l'accès au disque lui-même qui sera le goulet d'étranglement (celui qu'on mesure avec hdparm -t), non ?
Oui effectivement. De toute façon pour bien mesurer les performances d'un système disque, il vaut mieux tester avec au moins 2 fois la RAM pour minimiser l'efficacité du cache.
On peut aussi purger les caches avant de tester:
echo 3 > /proc/sys/vm/drop_caches
-- If atheism is a religion, then baldness is a hair color. And not collecting stamps is a hobby. mahade on reddit.com
Le Mon, 19 Nov 2012 10:06:23 +0100, Francois Lafont a écrit:
Il y a un petit truc qui m'échappe.
Si l'application ouvre un fichier pour la première fois, il faudra bien
un accès disque quand même, pour certes ensuite placer le fichier dans
le cache du système Linux (dans la RAM) et le lire ensuite sur ce cache,
mais c'est donc bien l'accès au disque lui-même qui sera le goulet
d'étranglement (celui qu'on mesure avec hdparm -t), non ?
Oui effectivement. De toute façon pour bien mesurer les performances d'un
système disque, il vaut mieux tester avec au moins 2 fois la RAM pour
minimiser l'efficacité du cache.
On peut aussi purger les caches avant de tester:
echo 3 > /proc/sys/vm/drop_caches
--
If atheism is a religion, then baldness is a hair color.
And not collecting stamps is a hobby.
mahade on reddit.com
Le Mon, 19 Nov 2012 10:06:23 +0100, Francois Lafont a écrit:
Il y a un petit truc qui m'échappe.
Si l'application ouvre un fichier pour la première fois, il faudra bien un accès disque quand même, pour certes ensuite placer le fichier dans le cache du système Linux (dans la RAM) et le lire ensuite sur ce cache, mais c'est donc bien l'accès au disque lui-même qui sera le goulet d'étranglement (celui qu'on mesure avec hdparm -t), non ?
Oui effectivement. De toute façon pour bien mesurer les performances d'un système disque, il vaut mieux tester avec au moins 2 fois la RAM pour minimiser l'efficacité du cache.
On peut aussi purger les caches avant de tester:
echo 3 > /proc/sys/vm/drop_caches
-- If atheism is a religion, then baldness is a hair color. And not collecting stamps is a hobby. mahade on reddit.com
Emmanuel Florac
Le Mon, 19 Nov 2012 10:29:07 +0100, Francois Lafont a écrit:
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.
Oui mais normalement ce type de serveur devrait dépoter en IO. Regarde, j'ai un vieux bipro opteron dual core de 2007 sous Squeeze 64 avec 3 pauvres disques SATA:
[~]# hdparm -tT /dev/sda
/dev/sda: Timing cached reads: 1690 MB in 2.00 seconds = 845.28 MB/sec Timing buffered disk reads: 546 MB in 3.00 seconds = 181.88 MB/sec
Sur une autre machine de même style avec un contrôleur RAID ancien aussi (3Ware 9650 8 disques SATA en RAID 10):
[~]# hdparm -tT /dev/sda
/dev/sda: Timing cached reads: 1782 MB in 2.00 seconds = 891.59 MB/sec Timing buffered disk reads: 714 MB in 3.00 seconds = 237.85 MB/sec
On parle bien de machines avec des processeurs qui sont sortis en 2005 (Opteron 22xx ), équivalent à du DL380G4 je pense.
-- Never ascribe to malice that which is adequately explained by incompetence. Hanlon's Razor.
Le Mon, 19 Nov 2012 10:29:07 +0100, Francois Lafont a écrit:
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.
Oui mais normalement ce type de serveur devrait dépoter en IO. Regarde,
j'ai un vieux bipro opteron dual core de 2007 sous Squeeze 64 avec 3
pauvres disques SATA:
root@0[~]# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 1690 MB in 2.00 seconds = 845.28 MB/sec
Timing buffered disk reads: 546 MB in 3.00 seconds = 181.88 MB/sec
Sur une autre machine de même style avec un contrôleur RAID ancien aussi
(3Ware 9650 8 disques SATA en RAID 10):
root@0[~]# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 1782 MB in 2.00 seconds = 891.59 MB/sec
Timing buffered disk reads: 714 MB in 3.00 seconds = 237.85 MB/sec
On parle bien de machines avec des processeurs qui sont sortis en 2005
(Opteron 22xx ), équivalent à du DL380G4 je pense.
--
Never ascribe to malice that which is adequately explained by
incompetence.
Hanlon's Razor.
Le Mon, 19 Nov 2012 10:29:07 +0100, Francois Lafont a écrit:
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.
Oui mais normalement ce type de serveur devrait dépoter en IO. Regarde, j'ai un vieux bipro opteron dual core de 2007 sous Squeeze 64 avec 3 pauvres disques SATA:
[~]# hdparm -tT /dev/sda
/dev/sda: Timing cached reads: 1690 MB in 2.00 seconds = 845.28 MB/sec Timing buffered disk reads: 546 MB in 3.00 seconds = 181.88 MB/sec
Sur une autre machine de même style avec un contrôleur RAID ancien aussi (3Ware 9650 8 disques SATA en RAID 10):
[~]# hdparm -tT /dev/sda
/dev/sda: Timing cached reads: 1782 MB in 2.00 seconds = 891.59 MB/sec Timing buffered disk reads: 714 MB in 3.00 seconds = 237.85 MB/sec
On parle bien de machines avec des processeurs qui sont sortis en 2005 (Opteron 22xx ), équivalent à du DL380G4 je pense.
-- Never ascribe to malice that which is adequately explained by incompetence. Hanlon's Razor.
Ascadix
Emmanuel Florac a émis l'idée suivante :
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.
RAM max 512 Mo, pas d'option FBWC, seulement un BBWC, et en port PCIX pas PCIe, c'est une carte de milieu de gamme de qq années.
Si je me souviens bien des réf, j'en ai eu une il ya 4-5 ans, pour un p'tit serveur à vocation principale de NAS (acheté sur des queues de budget), P600 dans un Proliant DL entrée de gamme avec du DD SATA pour remplir une MSA60, RAID5 + spare, c'est très bien, aucun pb pour tourner deriere un simple réseau GB, débit correct et pas de pb de stabilité. Par contre, en RAID6, ça plombait un peu les perfs.
Pour un server applicatif, ça peut effectivement être un peu court sur patte et surtout facilement "incohérent" face à un serveur avec CPU/RAM taillé comme une bête de course.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Emmanuel Florac a émis l'idée suivante :
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.
RAM max 512 Mo, pas d'option FBWC, seulement un BBWC, et en port PCIX
pas PCIe, c'est une carte de milieu de gamme de qq années.
Si je me souviens bien des réf, j'en ai eu une il ya 4-5 ans, pour un
p'tit serveur à vocation principale de NAS (acheté sur des queues de
budget), P600 dans un Proliant DL entrée de gamme avec du DD SATA pour
remplir une MSA60, RAID5 + spare, c'est très bien, aucun pb pour
tourner deriere un simple réseau GB, débit correct et pas de pb de
stabilité.
Par contre, en RAID6, ça plombait un peu les perfs.
Pour un server applicatif, ça peut effectivement être un peu court sur
patte et surtout facilement "incohérent" face à un serveur avec CPU/RAM
taillé comme une bête de course.
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
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.
RAM max 512 Mo, pas d'option FBWC, seulement un BBWC, et en port PCIX pas PCIe, c'est une carte de milieu de gamme de qq années.
Si je me souviens bien des réf, j'en ai eu une il ya 4-5 ans, pour un p'tit serveur à vocation principale de NAS (acheté sur des queues de budget), P600 dans un Proliant DL entrée de gamme avec du DD SATA pour remplir une MSA60, RAID5 + spare, c'est très bien, aucun pb pour tourner deriere un simple réseau GB, débit correct et pas de pb de stabilité. Par contre, en RAID6, ça plombait un peu les perfs.
Pour un server applicatif, ça peut effectivement être un peu court sur patte et surtout facilement "incohérent" face à un serveur avec CPU/RAM taillé comme une bête de course.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Pascal Hambourg
Francois Lafont a écrit :
Le 19/11/2012 10:22, Pascal Hambourg a écrit :
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.
Effectivement je viens de regarder ses caractéristiques et c'est aussi de la RAM de type DDR-1, donc le résultat est cohérent.
Francois Lafont a écrit :
Le 19/11/2012 10:22, Pascal Hambourg a écrit :
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.
Effectivement je viens de regarder ses caractéristiques et c'est aussi
de la RAM de type DDR-1, donc le résultat est cohérent.
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.
Effectivement je viens de regarder ses caractéristiques et c'est aussi de la RAM de type DDR-1, donc le résultat est cohérent.
Emmanuel Florac
Le Tue, 20 Nov 2012 01:31:53 +0100, Francois Lafont a écrit:
J'en suis pas rendu à des perfs comme celles que tu donnes plus-haut mais je n'en suis pas si loin que ça non plus, non ? Pour toi les valeurs ci-dessus (196 MB/s et 784 MB/s) restent « anormales » ?
Non, ça paraît plutôt correct. Ensuite il faudrait voir avec un test un peu plus poussé.
Je pose la question car mon _premier_ problème si j'ose dire est que, du fait de mon ignorance crasse en matière de RAID, je n'ai absolument aucune idée des valeurs qui je suis censé espérer par rapport aux caractéristiques du serveur.
Si comme l'a dit Pascal c'est de la DDR1, ça paraît déjà bien.
-- Never ascribe to malice that which is adequately explained by incompetence. Hanlon's Razor.
Le Tue, 20 Nov 2012 01:31:53 +0100, Francois Lafont a écrit:
J'en suis pas rendu à des perfs comme celles que tu donnes plus-haut
mais je n'en suis pas si loin que ça non plus, non ? Pour toi les
valeurs ci-dessus (196 MB/s et 784 MB/s) restent « anormales » ?
Non, ça paraît plutôt correct. Ensuite il faudrait voir avec un test un
peu plus poussé.
Je pose la question car mon _premier_ problème si j'ose dire est que, du
fait de mon ignorance crasse en matière de RAID, je n'ai absolument
aucune idée des valeurs qui je suis censé espérer par rapport aux
caractéristiques du serveur.
Si comme l'a dit Pascal c'est de la DDR1, ça paraît déjà bien.
--
Never ascribe to malice that which is adequately explained by
incompetence.
Hanlon's Razor.
Le Tue, 20 Nov 2012 01:31:53 +0100, Francois Lafont a écrit:
J'en suis pas rendu à des perfs comme celles que tu donnes plus-haut mais je n'en suis pas si loin que ça non plus, non ? Pour toi les valeurs ci-dessus (196 MB/s et 784 MB/s) restent « anormales » ?
Non, ça paraît plutôt correct. Ensuite il faudrait voir avec un test un peu plus poussé.
Je pose la question car mon _premier_ problème si j'ose dire est que, du fait de mon ignorance crasse en matière de RAID, je n'ai absolument aucune idée des valeurs qui je suis censé espérer par rapport aux caractéristiques du serveur.
Si comme l'a dit Pascal c'est de la DDR1, ça paraît déjà bien.
-- Never ascribe to malice that which is adequately explained by incompetence. Hanlon's Razor.
Emmanuel Florac
Le Tue, 20 Nov 2012 09:20:50 +0100, Pascal Hambourg a écrit:
Attention, là on ne teste pas seulement les performances brutes du disque (ou du RAID) en écriture ou lecture séquentielle, mais on fait intervenir un système de fichiers (allocation, journalisation...). Pour se rapprocher de ce que fait hdparm -t, il vaudrait mieux spécifier of=/dev/<device>.
Oui, enfin en général on utilise un filesystem aussi :)
-- It always takes longer than you expect, even when you take into account Hofstadter's Law. Hofstadter's Law
Le Tue, 20 Nov 2012 09:20:50 +0100, Pascal Hambourg a écrit:
Attention, là on ne teste pas seulement les performances brutes du
disque (ou du RAID) en écriture ou lecture séquentielle, mais on fait
intervenir un système de fichiers (allocation, journalisation...). Pour
se rapprocher de ce que fait hdparm -t, il vaudrait mieux spécifier
of=/dev/<device>.
Oui, enfin en général on utilise un filesystem aussi :)
--
It always takes longer than you expect, even when you take into account
Hofstadter's Law.
Hofstadter's Law
Le Tue, 20 Nov 2012 09:20:50 +0100, Pascal Hambourg a écrit:
Attention, là on ne teste pas seulement les performances brutes du disque (ou du RAID) en écriture ou lecture séquentielle, mais on fait intervenir un système de fichiers (allocation, journalisation...). Pour se rapprocher de ce que fait hdparm -t, il vaudrait mieux spécifier of=/dev/<device>.
Oui, enfin en général on utilise un filesystem aussi :)
-- It always takes longer than you expect, even when you take into account Hofstadter's Law. Hofstadter's Law
Emmanuel Florac
Le Wed, 21 Nov 2012 00:10:53 +0100, Francois Lafont a écrit:
Mais ce paramètre représente quoi ? D'après mes recherches, je suis arrivé à ça comme « définition » :
« 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 Linux (la RAM) 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 Linux) 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). »
Est-ce (à peu près) correct ?
C'est ça. En pratique, le RAID-5 est un mode de RAID "en bandes" (striped) donc ne donne des performances correctes que si on lit la bande en entier (tous les disques sont accédés). Si ton RAID a une largeur de bande de 64 Ko et 14 disques, il faut lire au minimum 13 * 64Ko soit 832 Ko pour de bons résultats, soit "setra 1664".
Quelle valeur raisonnable dois-je donner à ce paramètre ? Pour avoir un changement pérenne (valable à chaque démarrage), il faut que je passe par le fichier rc.local ?
Oui, rc.local. et n'oublie pas de tester aussi la longueur de file d'attente:
echo 512 > /proc/sys/sda/queue/nr_requests
Tu peux aussi essayer avec d'autres valeurs que 512, par exemple 1024; mais pour ce type de contrôleur je pense que 512 est bien.
je ne vois pas d'autres tests.
Si tu comptes faire tourner des applications, ça peut être utile de faire un benchmark utilisant l'application.
Mais j'ai une confiance aveugle en Pascal ;-). C'est vraisemblablement de la DDR1, non ?
Mais quand je teste avec dmidecode, il me dit bien que c'est de la DDR2 400 Mhz. Je pense que lshw n'est pas très fiable sur ce coup... Regarde ce que dit dmidecode.
-- "Dope will get you through times of no money better than money will get you through times of no dope." Freewheelin' Franklin.
Le Wed, 21 Nov 2012 00:10:53 +0100, Francois Lafont a écrit:
Mais ce paramètre représente quoi ? D'après mes recherches, je suis
arrivé à ça comme « définition » :
« 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 Linux (la RAM) 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 Linux) 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). »
Est-ce (à peu près) correct ?
C'est ça. En pratique, le RAID-5 est un mode de RAID "en
bandes" (striped) donc ne donne des performances correctes que si on lit
la bande en entier (tous les disques sont accédés). Si ton RAID a une
largeur de bande de 64 Ko et 14 disques, il faut lire au minimum 13 * 64Ko
soit 832 Ko pour de bons résultats, soit "setra 1664".
Quelle valeur raisonnable dois-je donner à ce paramètre ? Pour avoir un
changement pérenne (valable à chaque démarrage), il faut que je passe
par le fichier rc.local ?
Oui, rc.local. et n'oublie pas de tester aussi la longueur de file
d'attente:
echo 512 > /proc/sys/sda/queue/nr_requests
Tu peux aussi essayer avec d'autres valeurs que 512, par exemple 1024;
mais pour ce type de contrôleur je pense que 512 est bien.
je ne vois pas d'autres tests.
Si tu comptes faire tourner des applications, ça peut être utile de faire
un benchmark utilisant l'application.
Mais j'ai une confiance aveugle en Pascal ;-). C'est vraisemblablement
de la DDR1, non ?
Mais quand je teste avec dmidecode, il me dit bien que c'est de la DDR2
400 Mhz. Je pense que lshw n'est pas très fiable sur ce coup...
Regarde ce que dit dmidecode.
--
"Dope will get you through times of no money better
than money will get you through times of no dope."
Freewheelin' Franklin.
Le Wed, 21 Nov 2012 00:10:53 +0100, Francois Lafont a écrit:
Mais ce paramètre représente quoi ? D'après mes recherches, je suis arrivé à ça comme « définition » :
« 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 Linux (la RAM) 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 Linux) 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). »
Est-ce (à peu près) correct ?
C'est ça. En pratique, le RAID-5 est un mode de RAID "en bandes" (striped) donc ne donne des performances correctes que si on lit la bande en entier (tous les disques sont accédés). Si ton RAID a une largeur de bande de 64 Ko et 14 disques, il faut lire au minimum 13 * 64Ko soit 832 Ko pour de bons résultats, soit "setra 1664".
Quelle valeur raisonnable dois-je donner à ce paramètre ? Pour avoir un changement pérenne (valable à chaque démarrage), il faut que je passe par le fichier rc.local ?
Oui, rc.local. et n'oublie pas de tester aussi la longueur de file d'attente:
echo 512 > /proc/sys/sda/queue/nr_requests
Tu peux aussi essayer avec d'autres valeurs que 512, par exemple 1024; mais pour ce type de contrôleur je pense que 512 est bien.
je ne vois pas d'autres tests.
Si tu comptes faire tourner des applications, ça peut être utile de faire un benchmark utilisant l'application.
Mais j'ai une confiance aveugle en Pascal ;-). C'est vraisemblablement de la DDR1, non ?
Mais quand je teste avec dmidecode, il me dit bien que c'est de la DDR2 400 Mhz. Je pense que lshw n'est pas très fiable sur ce coup... Regarde ce que dit dmidecode.
-- "Dope will get you through times of no money better than money will get you through times of no dope." Freewheelin' Franklin.
Emmanuel Florac
Le Thu, 22 Nov 2012 00:38:26 +0100, Francois Lafont a écrit:
Pourquoi le 14 (disques) devient 13 (13*64 Ko) ? - parce que j'ai 14 disques dont un en spare (14-1) ? - ou bien parce qu'une bande contient 13 blocs de données et 1 bloc de parité qu'on ne compte pas ?
Oui, on ne compte pas la parité. Et s'il y a un spare, on ne le compte pas non plus, donc c'est 12 disques de données qu'il faut considérer.
/dev/cciss/c0d0: Timing buffered disk reads: 418 MB in 3.00 seconds = 139.26 MB/sec
Désolé, bug mémoire, c'est /sys/block/sda/queue/nr_requests :)
Ça quoi « la longueur de la file d'attente » ?
Le nombre de commande SCSI qui sont envoyée au périphérique sans attendre l'éxécution de la suivante. Typiquement, il ne faut pas utiliser le scheduler du noyau (cfq), donc passer le scheduler à noop, et envoyer les commandes en nombre au contrôleur qui se chargera lui-même de les mettre en bon ordre (Command Tag Queueing et compagnie).
Handle 0x1100, DMI type 17, 23 bytes Memory Device Array Handle: 0x1000 Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: 1 Locator: DIMM 01 Bank Locator: Not Specified Type: DDR Type Detail: Synchronous Speed: 400 MHz (2.5 ns)
Ça veut dire que c'est de la DDR2 ? On le voit à quoi ? À la fréquence ? Si c'est >= 400 MHz c'est de la DDR2 ?
Bizarre, chez moi j'ai les mêmes valeurs mais bien la mention "DDR2". Logiquement il me semble que la DDR1 est à 200 Mhz et la DDR2 à 400, mais il faudrait vérifier. Où alors tu as de la super DDR1 et moi de la DDR2 bas de gamme, je ne sais pas :)
-- La propriété c'est le vol. Pierre-Joseph Proudhon.
La propriété c'est le meurtre. Marcel Camus.
Le Thu, 22 Nov 2012 00:38:26 +0100, Francois Lafont a écrit:
Pourquoi le 14 (disques) devient 13 (13*64 Ko) ? - parce que j'ai 14
disques dont un en spare (14-1) ? - ou bien parce qu'une bande
contient 13 blocs de données et 1 bloc de parité qu'on ne compte pas ?
Oui, on ne compte pas la parité. Et s'il y a un spare, on ne le compte
pas non plus, donc c'est 12 disques de données qu'il faut considérer.
/dev/cciss/c0d0:
Timing buffered disk reads: 418 MB in 3.00 seconds = 139.26 MB/sec
Désolé, bug mémoire, c'est /sys/block/sda/queue/nr_requests :)
Ça quoi « la longueur de la file d'attente » ?
Le nombre de commande SCSI qui sont envoyée au périphérique sans attendre
l'éxécution de la suivante. Typiquement, il ne faut pas utiliser le
scheduler du noyau (cfq), donc passer le scheduler à noop, et envoyer les
commandes en nombre au contrôleur qui se chargera lui-même de les mettre
en bon ordre (Command Tag Queueing et compagnie).
Handle 0x1100, DMI type 17, 23 bytes
Memory Device
Array Handle: 0x1000
Error Information Handle: Not Provided Total Width: 72 bits
Data Width: 64 bits
Size: 2048 MB
Form Factor: DIMM
Set: 1
Locator: DIMM 01
Bank Locator: Not Specified
Type: DDR
Type Detail: Synchronous
Speed: 400 MHz (2.5 ns)
Ça veut dire que c'est de la DDR2 ? On le voit à quoi ? À la fréquence ?
Si c'est >= 400 MHz c'est de la DDR2 ?
Bizarre, chez moi j'ai les mêmes valeurs mais bien la mention "DDR2".
Logiquement il me semble que la DDR1 est à 200 Mhz et la DDR2 à 400, mais
il faudrait vérifier. Où alors tu as de la super DDR1 et moi de la DDR2
bas de gamme, je ne sais pas :)
--
La propriété c'est le vol.
Pierre-Joseph Proudhon.
Le Thu, 22 Nov 2012 00:38:26 +0100, Francois Lafont a écrit:
Pourquoi le 14 (disques) devient 13 (13*64 Ko) ? - parce que j'ai 14 disques dont un en spare (14-1) ? - ou bien parce qu'une bande contient 13 blocs de données et 1 bloc de parité qu'on ne compte pas ?
Oui, on ne compte pas la parité. Et s'il y a un spare, on ne le compte pas non plus, donc c'est 12 disques de données qu'il faut considérer.
/dev/cciss/c0d0: Timing buffered disk reads: 418 MB in 3.00 seconds = 139.26 MB/sec
Désolé, bug mémoire, c'est /sys/block/sda/queue/nr_requests :)
Ça quoi « la longueur de la file d'attente » ?
Le nombre de commande SCSI qui sont envoyée au périphérique sans attendre l'éxécution de la suivante. Typiquement, il ne faut pas utiliser le scheduler du noyau (cfq), donc passer le scheduler à noop, et envoyer les commandes en nombre au contrôleur qui se chargera lui-même de les mettre en bon ordre (Command Tag Queueing et compagnie).
Handle 0x1100, DMI type 17, 23 bytes Memory Device Array Handle: 0x1000 Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: 1 Locator: DIMM 01 Bank Locator: Not Specified Type: DDR Type Detail: Synchronous Speed: 400 MHz (2.5 ns)
Ça veut dire que c'est de la DDR2 ? On le voit à quoi ? À la fréquence ? Si c'est >= 400 MHz c'est de la DDR2 ?
Bizarre, chez moi j'ai les mêmes valeurs mais bien la mention "DDR2". Logiquement il me semble que la DDR1 est à 200 Mhz et la DDR2 à 400, mais il faudrait vérifier. Où alors tu as de la super DDR1 et moi de la DDR2 bas de gamme, je ne sais pas :)
-- La propriété c'est le vol. Pierre-Joseph Proudhon.
La propriété c'est le meurtre. Marcel Camus.
Emmanuel Florac
Le Thu, 22 Nov 2012 06:20:29 +0100, Philippe Weill a écrit:
en suite si tu fais de l'EXT(3/4)
au formatage tu à interet à utiliser
mkfs.ext3 -b 4096 -E stride,stripe-width2
de facon à t'aligner sur les blocs physiques du RAID
cf http://busybox.net/~aldot/mkfs_stride.html
Et bien entendu si on veut la performance séquentielle maximale on utilisera xfs et surtout pas ext4 (encore moins ext3 dont les performances sont totalement dépassées):
mkfs.xfs -i lazy-count=1 -d sudk,sw /dev/XXX
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Kaid Ahmed.
Le Thu, 22 Nov 2012 06:20:29 +0100, Philippe Weill a écrit:
en suite si tu fais de l'EXT(3/4)
au formatage tu à interet à utiliser
mkfs.ext3 -b 4096 -E stride,stripe-width2
de facon à t'aligner sur les blocs physiques du RAID
cf http://busybox.net/~aldot/mkfs_stride.html
Et bien entendu si on veut la performance séquentielle maximale on
utilisera xfs et surtout pas ext4 (encore moins ext3 dont les
performances sont totalement dépassées):
mkfs.xfs -i lazy-count=1 -d sudk,sw /dev/XXX
--
L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas
en avant.
Kaid Ahmed.
Le Thu, 22 Nov 2012 06:20:29 +0100, Philippe Weill a écrit:
en suite si tu fais de l'EXT(3/4)
au formatage tu à interet à utiliser
mkfs.ext3 -b 4096 -E stride,stripe-width2
de facon à t'aligner sur les blocs physiques du RAID
cf http://busybox.net/~aldot/mkfs_stride.html
Et bien entendu si on veut la performance séquentielle maximale on utilisera xfs et surtout pas ext4 (encore moins ext3 dont les performances sont totalement dépassées):
mkfs.xfs -i lazy-count=1 -d sudk,sw /dev/XXX
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Kaid Ahmed.
Philippe Weill
Le 22/11/2012 08:41, Emmanuel Florac a écrit :
Le Thu, 22 Nov 2012 06:20:29 +0100, Philippe Weill a écrit:
en suite si tu fais de l'EXT(3/4)
au formatage tu à interet à utiliser
mkfs.ext3 -b 4096 -E stride,stripe-width2
de facon à t'aligner sur les blocs physiques du RAID
cf http://busybox.net/~aldot/mkfs_stride.html
Et bien entendu si on veut la performance séquentielle maximale on utilisera xfs et surtout pas ext4 (encore moins ext3 dont les performances sont totalement dépassées):
mkfs.xfs -i lazy-count=1 -d sudk,sw /dev/XXX
Je l'ai pas dit mais sur les serveurs NFS je fais de l'xfs ;-)
l'ext me sert en HPC pour lustre
Le 22/11/2012 08:41, Emmanuel Florac a écrit :
Le Thu, 22 Nov 2012 06:20:29 +0100, Philippe Weill a écrit:
en suite si tu fais de l'EXT(3/4)
au formatage tu à interet à utiliser
mkfs.ext3 -b 4096 -E stride,stripe-width2
de facon à t'aligner sur les blocs physiques du RAID
cf http://busybox.net/~aldot/mkfs_stride.html
Et bien entendu si on veut la performance séquentielle maximale on
utilisera xfs et surtout pas ext4 (encore moins ext3 dont les
performances sont totalement dépassées):
mkfs.xfs -i lazy-count=1 -d sudk,sw /dev/XXX
Je l'ai pas dit mais sur les serveurs NFS je fais de l'xfs ;-)
Le Thu, 22 Nov 2012 06:20:29 +0100, Philippe Weill a écrit:
en suite si tu fais de l'EXT(3/4)
au formatage tu à interet à utiliser
mkfs.ext3 -b 4096 -E stride,stripe-width2
de facon à t'aligner sur les blocs physiques du RAID
cf http://busybox.net/~aldot/mkfs_stride.html
Et bien entendu si on veut la performance séquentielle maximale on utilisera xfs et surtout pas ext4 (encore moins ext3 dont les performances sont totalement dépassées):
mkfs.xfs -i lazy-count=1 -d sudk,sw /dev/XXX
Je l'ai pas dit mais sur les serveurs NFS je fais de l'xfs ;-)
