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 Thu, 22 Nov 2012 12:40:05 +0100, Philippe Weill a écrit:
Je l'ai pas dit mais sur les serveurs NFS je fais de l'xfs ;-)
Et tu as grandement raison :) N'oublions pas: les réglages par défaut de linux (io scheduler, io queueing, ext3/4) sont optimisés pour des PC desktop et mal adaptés pour des serveurs performants.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Le Thu, 22 Nov 2012 12:40:05 +0100, Philippe Weill a écrit:
Je l'ai pas dit mais sur les serveurs NFS je fais de l'xfs ;-)
Et tu as grandement raison :) N'oublions pas: les réglages par défaut de
linux (io scheduler, io queueing, ext3/4) sont optimisés pour des PC
desktop et mal adaptés pour des serveurs performants.
--
A thing of beauty is a joy forever.
J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert!
Marcel Bénabou.
Le Thu, 22 Nov 2012 12:40:05 +0100, Philippe Weill a écrit:
Je l'ai pas dit mais sur les serveurs NFS je fais de l'xfs ;-)
Et tu as grandement raison :) N'oublions pas: les réglages par défaut de linux (io scheduler, io queueing, ext3/4) sont optimisés pour des PC desktop et mal adaptés pour des serveurs performants.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Emmanuel Florac
Le Thu, 29 Nov 2012 03:33:28 +0100, Francois Lafont a écrit:
Du coup, est-ce que ça vous semble, cette fois-ci, correct au niveau perfs au vu des caractéristiques du serveur ou bien il y a quelque chose qui cloche encore ?
Tout ça paraît correct pour un contrôleur RAID PCI-X.
Si ça vous semble bon, alors je m'orienterai peut-être vers l'installation d'une Debian Wheezy (pour avoir le noyau 3.2) avec 2 grappes RAID.
Il n'y a pas d'inconvénient à utiliser un noyau 3.2 sur une squeeze, c'est ce que je fais toujours depuis des mois et des mois.
Systématiquement, sur le serveur 2, la commande dd ci-dessus met entre 6 à 10 secondes de plus que sur le serveur 1 (parfois l'écart est même plus grand encore) alors qu'ils sont censés être identiques. En plus, sauf erreur de ma part, avec la commande ci-dessus les disques ne rentrent absolument pas en ligne de compte, n'est-ce pas ?
Du coup, comment expliquer cette différence ? Ou bien, pour commencer, où faut-il chercher pour avoir un début de piste ?
Je pense que dans ce test tu testes la bande passante mémoire. Il y a le même nombre de barrettes, et du même type sur les deux machines?
-- I am not a vegetarian because I love animals; I am a vegetarian because I hate plants. A. Whitney Brown
Le Thu, 29 Nov 2012 03:33:28 +0100, Francois Lafont a écrit:
Du coup, est-ce que ça vous semble, cette fois-ci, correct au niveau
perfs au vu des caractéristiques du serveur ou bien il y a quelque chose
qui cloche encore ?
Tout ça paraît correct pour un contrôleur RAID PCI-X.
Si ça vous semble bon, alors je m'orienterai peut-être vers
l'installation d'une Debian Wheezy (pour avoir le noyau 3.2) avec 2
grappes RAID.
Il n'y a pas d'inconvénient à utiliser un noyau 3.2 sur une squeeze,
c'est ce que je fais toujours depuis des mois et des mois.
Systématiquement, sur le serveur 2, la commande dd ci-dessus met entre 6
à 10 secondes de plus que sur le serveur 1 (parfois l'écart est même
plus grand encore) alors qu'ils sont censés être identiques. En plus,
sauf erreur de ma part, avec la commande ci-dessus les disques ne
rentrent absolument pas en ligne de compte, n'est-ce pas ?
Du coup, comment expliquer cette différence ? Ou bien, pour commencer,
où faut-il chercher pour avoir un début de piste ?
Je pense que dans ce test tu testes la bande passante mémoire. Il y a le
même nombre de barrettes, et du même type sur les deux machines?
--
I am not a vegetarian because I love animals; I am a vegetarian
because I hate plants.
A. Whitney Brown
Le Thu, 29 Nov 2012 03:33:28 +0100, Francois Lafont a écrit:
Du coup, est-ce que ça vous semble, cette fois-ci, correct au niveau perfs au vu des caractéristiques du serveur ou bien il y a quelque chose qui cloche encore ?
Tout ça paraît correct pour un contrôleur RAID PCI-X.
Si ça vous semble bon, alors je m'orienterai peut-être vers l'installation d'une Debian Wheezy (pour avoir le noyau 3.2) avec 2 grappes RAID.
Il n'y a pas d'inconvénient à utiliser un noyau 3.2 sur une squeeze, c'est ce que je fais toujours depuis des mois et des mois.
Systématiquement, sur le serveur 2, la commande dd ci-dessus met entre 6 à 10 secondes de plus que sur le serveur 1 (parfois l'écart est même plus grand encore) alors qu'ils sont censés être identiques. En plus, sauf erreur de ma part, avec la commande ci-dessus les disques ne rentrent absolument pas en ligne de compte, n'est-ce pas ?
Du coup, comment expliquer cette différence ? Ou bien, pour commencer, où faut-il chercher pour avoir un début de piste ?
Je pense que dans ce test tu testes la bande passante mémoire. Il y a le même nombre de barrettes, et du même type sur les deux machines?
-- I am not a vegetarian because I love animals; I am a vegetarian because I hate plants. A. Whitney Brown
Emmanuel Florac
Le Fri, 30 Nov 2012 01:20:54 +0100, Francois Lafont a écrit:
Du coup, pas de noyau 3.2 possible avec Xen sur ce type de serveur et donc retour au noyau 2.6 qui semble avoir du mal à gérer le RAID matériel de ce type de serveur. Du coup, reste l'option RAID logiciel.
Non, tu peux tenter un kernel supérieur plutôt. Le 3.5 ou le 3.6, par exemple. Ou bien un noyau "vanilla" compilé maison, c'est ce que je fais toujours :)
-- a script is what you give the actors, a program is what you give the audience. Ada Lovelace according to Larry Wall
Le Fri, 30 Nov 2012 01:20:54 +0100, Francois Lafont a écrit:
Du coup, pas de noyau 3.2 possible avec Xen sur ce type de serveur et
donc retour au noyau 2.6 qui semble avoir du mal à gérer le RAID
matériel de ce type de serveur. Du coup, reste l'option RAID logiciel.
Non, tu peux tenter un kernel supérieur plutôt. Le 3.5 ou le 3.6, par
exemple. Ou bien un noyau "vanilla" compilé maison, c'est ce que je fais
toujours :)
--
a script is what you give the actors, a program is what you give the
audience.
Ada Lovelace according to Larry Wall
Le Fri, 30 Nov 2012 01:20:54 +0100, Francois Lafont a écrit:
Du coup, pas de noyau 3.2 possible avec Xen sur ce type de serveur et donc retour au noyau 2.6 qui semble avoir du mal à gérer le RAID matériel de ce type de serveur. Du coup, reste l'option RAID logiciel.
Non, tu peux tenter un kernel supérieur plutôt. Le 3.5 ou le 3.6, par exemple. Ou bien un noyau "vanilla" compilé maison, c'est ce que je fais toujours :)
-- a script is what you give the actors, a program is what you give the audience. Ada Lovelace according to Larry Wall
Emmanuel Florac
Le Fri, 30 Nov 2012 11:24:44 +0100, Francois Lafont a écrit:
Là, tu parles de quel noyau ? Le noyau Linux ou le noyau Xen ? Parce que si c'est le noyau Linux qui je change, il faut bien modifier aussi le noyau Xen en conséquence, non ?
Non, si tu utilises la virtualisation le noyau qui tourne dans Xen peut être complètement différent du noyau de l'hôte je pense. Bon je dis ça je n'en sais rien, je n'utilise pas Xen mais KVM et je n'ai pas ce genre de problèmes.
-- If atheism is a religion, then baldness is a hair color. And not collecting stamps is a hobby. mahade on reddit.com
Le Fri, 30 Nov 2012 11:24:44 +0100, Francois Lafont a écrit:
Là, tu parles de quel noyau ? Le noyau Linux ou le noyau Xen ? Parce que
si c'est le noyau Linux qui je change, il faut bien modifier aussi le
noyau Xen en conséquence, non ?
Non, si tu utilises la virtualisation le noyau qui tourne dans Xen peut
être complètement différent du noyau de l'hôte je pense. Bon je dis ça je
n'en sais rien, je n'utilise pas Xen mais KVM et je n'ai pas ce genre de
problèmes.
--
If atheism is a religion, then baldness is a hair color.
And not collecting stamps is a hobby.
mahade on reddit.com
Le Fri, 30 Nov 2012 11:24:44 +0100, Francois Lafont a écrit:
Là, tu parles de quel noyau ? Le noyau Linux ou le noyau Xen ? Parce que si c'est le noyau Linux qui je change, il faut bien modifier aussi le noyau Xen en conséquence, non ?
Non, si tu utilises la virtualisation le noyau qui tourne dans Xen peut être complètement différent du noyau de l'hôte je pense. Bon je dis ça je n'en sais rien, je n'utilise pas Xen mais KVM et je n'ai pas ce genre de problèmes.
-- 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 Wed, 05 Dec 2012 01:14:17 +0100, Francois Lafont a écrit:
Non, tu peux tenter un kernel supérieur plutôt. Le 3.5 ou le 3.6, par exemple.
Mais on est bien d'accord que pour avoir un noyau 3.5 ou 3.6 sur une Squeeze ou une Wheezy, tu dois d'abord compiler les sources du noyau, non ?
Mais oui, c'est comme ça que font les vrais hommes avec du poil sur la poitrine :)
Sinon, sur les 4 disques du serveur, j'ai finalement opté pour du RAID 1+0 car lorsque je faisais du RAID 5 sur 3 disques (avec en plus un spare), j'obtenais vraiment des perfs pourries, indépendamment du noyau. Avec du RAID 1+0, j'obtiens ça :
fdisk visiblement compte en gigaoctets ( 1 giga = 1 000 000 000 d'octets) alors que le contrôleur compte en gibioctets ( 1 gibi = 2^30 = 1073741824 octets).
Qui dit la vérité ? (j'espère que c'est fdisk ;-))
Les deux :)
Enfin, on m'a expliqué sur ce fil de discussion qu'il fallait aligner le système de fichiers avec le RAID matériel, par exemple avec des formatages comme celui-ci :
mkfs.ext3 -b 4096 -E stride,stripe-width2
Oui, sauf qu'il ne faut pas utiliser cette sombre brousse d'ext3 bien sûr; les vrais hommes utilisent xfs, et les mangeurs de quiche ext4.
Et sur du RAID 1+0, y a-t-il un alignement particulier à faire ? Autant avec le RAID 5, je visualise bien la bande de donnée divisée en autant de blocs de données que j'ai de disques physiques, autant avec le RAID 1+0, je ne crois pas qu'on puisse parler de bande de données, non?
Non ce n'est pas important (il n'y a pas d'effet lecture-modification- écriture comme en RAID-5 ou RAID-6).
Je ferais bien un topo sur l'effet lecture-modification-écriture mais il doit bien y avoir des trucs là dessus sur le ouèbe :)
Boarf, il y a le truc que j'ai écrit il y a 15 ans, mais c'est toujours valable: http://membres.multimania.fr/eflorac/Technologie/le_RAID/le_raid.html
-- A travers l'audimat, c'est la logique du commercial qui s'impose aux productions culturelles. Or, il est important de savoir que, historiquement, toutes les productions culturelles que je considère, - et je ne suis pas le seul, j'espère -, qu'un certain nombre de gens considèrent comme les productions les plus hautes de l'humanité, les mathématiques, la poésie, la littérature, la philosophie, toutes ces choses ont été produites contre l'équivalent de l'audimat, contre la logique du commerce. Pierre Bourdieu, "Sur la télévision". Raison d'Agir Editions, décembre 1996
Le Wed, 05 Dec 2012 01:14:17 +0100, Francois Lafont a écrit:
Non, tu peux tenter un kernel supérieur plutôt. Le 3.5 ou le 3.6, par
exemple.
Mais on est bien d'accord que pour avoir un noyau 3.5 ou 3.6 sur une
Squeeze ou une Wheezy, tu dois d'abord compiler les sources du noyau,
non ?
Mais oui, c'est comme ça que font les vrais hommes avec du poil sur la
poitrine :)
Sinon, sur les 4 disques du serveur, j'ai finalement opté pour du RAID
1+0 car lorsque je faisais du RAID 5 sur 3 disques (avec en plus un
spare), j'obtenais vraiment des perfs pourries, indépendamment du noyau.
Avec du RAID 1+0, j'obtiens ça :
fdisk visiblement compte en gigaoctets ( 1 giga = 1 000 000 000 d'octets)
alors que le contrôleur compte en gibioctets ( 1 gibi = 2^30 = 1073741824
octets).
Qui dit la vérité ? (j'espère que c'est fdisk ;-))
Les deux :)
Enfin, on m'a expliqué sur ce fil de discussion qu'il fallait aligner le
système de fichiers avec le RAID matériel, par exemple avec des
formatages comme celui-ci :
mkfs.ext3 -b 4096 -E stride,stripe-width2
Oui, sauf qu'il ne faut pas utiliser cette sombre brousse d'ext3 bien
sûr; les vrais hommes utilisent xfs, et les mangeurs de quiche ext4.
Et sur du RAID 1+0, y a-t-il un alignement particulier à faire ? Autant
avec le RAID 5, je visualise bien la bande de donnée divisée en autant
de blocs de données que j'ai de disques physiques, autant avec le RAID
1+0, je ne crois pas qu'on puisse parler de bande de données, non?
Non ce n'est pas important (il n'y a pas d'effet lecture-modification-
écriture comme en RAID-5 ou RAID-6).
Je ferais bien un topo sur l'effet lecture-modification-écriture mais il
doit bien y avoir des trucs là dessus sur le ouèbe :)
Boarf, il y a le truc que j'ai écrit il y a 15 ans, mais c'est toujours
valable:
http://membres.multimania.fr/eflorac/Technologie/le_RAID/le_raid.html
--
A travers l'audimat, c'est la logique du commercial qui s'impose aux
productions culturelles. Or, il est important de savoir que,
historiquement, toutes les productions culturelles que je considère, -
et je ne suis pas le seul, j'espère -, qu'un certain nombre de gens
considèrent comme les productions les plus hautes de l'humanité, les
mathématiques, la poésie, la littérature, la philosophie, toutes ces
choses ont été produites contre l'équivalent de l'audimat, contre la
logique du commerce.
Pierre Bourdieu, "Sur la télévision". Raison d'Agir Editions, décembre
1996
Le Wed, 05 Dec 2012 01:14:17 +0100, Francois Lafont a écrit:
Non, tu peux tenter un kernel supérieur plutôt. Le 3.5 ou le 3.6, par exemple.
Mais on est bien d'accord que pour avoir un noyau 3.5 ou 3.6 sur une Squeeze ou une Wheezy, tu dois d'abord compiler les sources du noyau, non ?
Mais oui, c'est comme ça que font les vrais hommes avec du poil sur la poitrine :)
Sinon, sur les 4 disques du serveur, j'ai finalement opté pour du RAID 1+0 car lorsque je faisais du RAID 5 sur 3 disques (avec en plus un spare), j'obtenais vraiment des perfs pourries, indépendamment du noyau. Avec du RAID 1+0, j'obtiens ça :
fdisk visiblement compte en gigaoctets ( 1 giga = 1 000 000 000 d'octets) alors que le contrôleur compte en gibioctets ( 1 gibi = 2^30 = 1073741824 octets).
Qui dit la vérité ? (j'espère que c'est fdisk ;-))
Les deux :)
Enfin, on m'a expliqué sur ce fil de discussion qu'il fallait aligner le système de fichiers avec le RAID matériel, par exemple avec des formatages comme celui-ci :
mkfs.ext3 -b 4096 -E stride,stripe-width2
Oui, sauf qu'il ne faut pas utiliser cette sombre brousse d'ext3 bien sûr; les vrais hommes utilisent xfs, et les mangeurs de quiche ext4.
Et sur du RAID 1+0, y a-t-il un alignement particulier à faire ? Autant avec le RAID 5, je visualise bien la bande de donnée divisée en autant de blocs de données que j'ai de disques physiques, autant avec le RAID 1+0, je ne crois pas qu'on puisse parler de bande de données, non?
Non ce n'est pas important (il n'y a pas d'effet lecture-modification- écriture comme en RAID-5 ou RAID-6).
Je ferais bien un topo sur l'effet lecture-modification-écriture mais il doit bien y avoir des trucs là dessus sur le ouèbe :)
Boarf, il y a le truc que j'ai écrit il y a 15 ans, mais c'est toujours valable: http://membres.multimania.fr/eflorac/Technologie/le_RAID/le_raid.html
-- A travers l'audimat, c'est la logique du commercial qui s'impose aux productions culturelles. Or, il est important de savoir que, historiquement, toutes les productions culturelles que je considère, - et je ne suis pas le seul, j'espère -, qu'un certain nombre de gens considèrent comme les productions les plus hautes de l'humanité, les mathématiques, la poésie, la littérature, la philosophie, toutes ces choses ont été produites contre l'équivalent de l'audimat, contre la logique du commerce. Pierre Bourdieu, "Sur la télévision". Raison d'Agir Editions, décembre 1996
Emmanuel Florac
Le Wed, 05 Dec 2012 22:47:22 +0100, Francois Lafont a écrit:
Oui, sauf qu'il ne faut pas utiliser cette sombre brousse d'ext3 bien sûr; les vrais hommes utilisent xfs, et les mangeurs de quiche ext4.
J'aime bien les quiches mais je prends bonne note de ta remarque. J'avais entendu dire que xfs était performant mais plus fragile que ext4 notamment lorsqu'il y a coupure de courant le xfs le supporterait mal. Ceci étant, ici le serveur est sur 2 alim redondante, alors...
Oui, xfs est fait pour les serveurs. ext4 est générique, "bon à rien, mauvais à tout" :)
On est d'accord que les tests avec hdparm sont indépendants du système de fichiers, n'est-ce pas ?
En effet.
Si je veux tester les perfs d'un xfs par rapport à un ext4, il faudra que je passe par des commandes comme « dd ... » ou bien d'autres outils de benchmark de disques comme il doit en exister plein j'imagine.
Oui, bonnie++, iozone...
Globalement, je crois que j'y vois un peu plus clair. Il me reste simplement cette histoire d'option --dataalignement de la commande pvcreate qui je ne comprends pas trop encore. J'ai bien saisi qu'en pratique sur mon RAID 5 il fallait que je fasse :
pvcreate --dataalignment 64K /dev/cciss/c0d1p1
parce que 64K est la taille d'un petit bloc de données du RAID 5. Mais la page man n'est pas claire pour moi :
« --dataalignment alignment Align the start of the data to a multiple of this number. »
Je ne vois pas trop ce que j'aligne et avec quoi ?
C'est peut-être plus clair ici: http://wiki.tldp.org/LVM-on-RAID
-- Désormais, pour les nations et pour les peuples, une goutte de pétrole a la valeur d'une goutte de sang. Georges Clémenceau.
Le Wed, 05 Dec 2012 22:47:22 +0100, Francois Lafont a écrit:
Oui, sauf qu'il ne faut pas utiliser cette sombre brousse d'ext3 bien
sûr; les vrais hommes utilisent xfs, et les mangeurs de quiche ext4.
J'aime bien les quiches mais je prends bonne note de ta remarque.
J'avais entendu dire que xfs était performant mais plus fragile que ext4
notamment lorsqu'il y a coupure de courant le xfs le supporterait mal.
Ceci étant, ici le serveur est sur 2 alim redondante, alors...
Oui, xfs est fait pour les serveurs. ext4 est générique, "bon à rien,
mauvais à tout" :)
On est d'accord que les tests avec hdparm sont indépendants du système
de fichiers, n'est-ce pas ?
En effet.
Si je veux tester les perfs d'un xfs par rapport à un ext4, il faudra
que je passe par des commandes comme « dd ... » ou bien d'autres outils
de benchmark de disques comme il doit en exister plein j'imagine.
Oui, bonnie++, iozone...
Globalement, je crois que j'y vois un peu plus clair. Il me reste
simplement cette histoire d'option --dataalignement de la commande
pvcreate qui je ne comprends pas trop encore. J'ai bien saisi qu'en
pratique sur mon RAID 5 il fallait que je fasse :
pvcreate --dataalignment 64K /dev/cciss/c0d1p1
parce que 64K est la taille d'un petit bloc de données du RAID 5. Mais
la page man n'est pas claire pour moi :
« --dataalignment alignment
Align the start of the data to a multiple of this number. »
Je ne vois pas trop ce que j'aligne et avec quoi ?
C'est peut-être plus clair ici:
http://wiki.tldp.org/LVM-on-RAID
--
Désormais, pour les nations et pour les peuples, une goutte de pétrole
a la valeur d'une goutte de sang.
Georges Clémenceau.
Le Wed, 05 Dec 2012 22:47:22 +0100, Francois Lafont a écrit:
Oui, sauf qu'il ne faut pas utiliser cette sombre brousse d'ext3 bien sûr; les vrais hommes utilisent xfs, et les mangeurs de quiche ext4.
J'aime bien les quiches mais je prends bonne note de ta remarque. J'avais entendu dire que xfs était performant mais plus fragile que ext4 notamment lorsqu'il y a coupure de courant le xfs le supporterait mal. Ceci étant, ici le serveur est sur 2 alim redondante, alors...
Oui, xfs est fait pour les serveurs. ext4 est générique, "bon à rien, mauvais à tout" :)
On est d'accord que les tests avec hdparm sont indépendants du système de fichiers, n'est-ce pas ?
En effet.
Si je veux tester les perfs d'un xfs par rapport à un ext4, il faudra que je passe par des commandes comme « dd ... » ou bien d'autres outils de benchmark de disques comme il doit en exister plein j'imagine.
Oui, bonnie++, iozone...
Globalement, je crois que j'y vois un peu plus clair. Il me reste simplement cette histoire d'option --dataalignement de la commande pvcreate qui je ne comprends pas trop encore. J'ai bien saisi qu'en pratique sur mon RAID 5 il fallait que je fasse :
pvcreate --dataalignment 64K /dev/cciss/c0d1p1
parce que 64K est la taille d'un petit bloc de données du RAID 5. Mais la page man n'est pas claire pour moi :
« --dataalignment alignment Align the start of the data to a multiple of this number. »
Je ne vois pas trop ce que j'aligne et avec quoi ?
C'est peut-être plus clair ici: http://wiki.tldp.org/LVM-on-RAID
-- Désormais, pour les nations et pour les peuples, une goutte de pétrole a la valeur d'une goutte de sang. Georges Clémenceau.
Emmanuel Florac
Le Fri, 07 Dec 2012 03:26:19 +0100, Francois Lafont a écrit:
À la prochaine sur f.c.o.l.c. ;-)
Avec plaisir :)
-- I love deadlines, I love the whooshing noise they make as they go by. Douglas Adams
Le Fri, 07 Dec 2012 03:26:19 +0100, Francois Lafont a écrit:
À la prochaine sur f.c.o.l.c. ;-)
Avec plaisir :)
--
I love deadlines, I love the whooshing noise they make as they go by.
Douglas Adams
