Bonjour,

Le RAID0 logiciel, est-ce qu'en pratique ça apporte des performances
palpables?
Moi j'ai une grosse (qui occupe beaucoup de place sur le disque) base MySQL
à faire mouliner plus vite rapidement (pas le temps de revoir la structure
des données).
Ce que je remarque, avec entre autre gkrellm, c'est que sur les requetes qui
nous paraissent lentes, la quantité d'I/O monte pendant la requete. On est
pour le moement avec un seul disque SATA.
Si on doit optimiser au niveau du matériel, je pense donc qu'il faut donner
un peu plus de punch aux I/O. D'ou l'orientation vers un RAID0.

La machine tournera sous Linux.

Mais ceux qui ont essayé ont-ils eu de nettes améliorations?

Merci.

Le Sun, 20 May 2007 19:47:40 +0200, Mihamina (R12y) Rakotomandimby a
écrit:

>
> Le RAID0 logiciel, est-ce qu'en pratique ça apporte des performances
> palpables?

Oui, c'est net. Par contre si tu recherches un gain sur de petites IO
(base de données), le gain sera limité. Mieux vaut passer aux disques
plus rapides, 10000 t/mn en SATA ou bien mieux, 15000 t/mn en SAS. Et
aussi maximiser le cache en lecture/écriture, donc la RAM.

--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando

Emmanuel Florac - <pan.2007.05.20.20.10.10.370562@imaginet.fr> :

> Oui, c'est net. Par contre si tu recherches un gain sur de petites IO
> (base de données), le gain sera limité.

Ah? Il existe des petites et des grandes I/O?
Juste pour me faire une idée du principe: tu me dis que les bases de données
font des petites I/O. Quelles applications (dans le sens large) en font des
grandes?

"Mihamina (R12y) Rakotomandimby" <infogerance@asso-polyvalente.fr>
writes:

> Emmanuel Florac - <pan.2007.05.20.20.10.10.370562@imaginet.fr> :
>
>> Oui, c'est net. Par contre si tu recherches un gain sur de petites IO
>> (base de données), le gain sera limité.
>
> Ah? Il existe des petites et des grandes I/O?

Bah oui, lire un petit bout de donnée ou en lire un gros, ça ne se
passe pas du tout pareil au niveau perfs. Dans le premier cas, le
facteur limitant est le temps d'accès, auquel le RAID ne peut pas
grand chose, et dans le second, c'est le débit, et là, le RAID peut
aider.

--
Matthieu

"Mihamina (R12y) Rakotomandimby" a écrit dans le message de news:
> Le RAID0 logiciel, est-ce qu'en pratique ça apporte des performances
> palpables?

Elle fait combien ta base ?
Il y a pas moyen de la mettre entièrement en ram ?

Le Sun, 20 May 2007 22:31:26 +0200, Mihamina (R12y) Rakotomandimby a
écrit:

>
> Ah? Il existe des petites et des grandes I/O? Juste pour me faire une
> idée du principe: tu me dis que les bases de données font des petites
> I/O. Quelles applications (dans le sens large) en font des grandes?

Pour être spécifique, les longues lectures séquentielles sont une
chose, les lectures de petites quantités dispersées de façon aléatoire
sur le disque une autre. Par exemple lire de l'audio ou de la vidéo, des
gros fichiers de manière générale, c'est de la lecture séquentielle et
de la grosse I/O. La base de données multi-utilisateurs, c'est
typiquement de la petite I/O à accès aléatoire.
Les écarts de performances sont de plusieurs ordres de grandeurs entre
les deux types d'accès : dans la lecture séquentielle, le facteur
limitant c'est le débit du disque (plusieurs dizaines de mo/s sur
n'importe quel disque récent). Dans la lecture aléatoire de petites
quantités (inférieures au cache du disque, typiquement 8Mo) le facteur
limitant c'est le temps d'accès du disque, égal au moins à une
demi-rotation+le temps de lecture.

--
Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est
carrément impossible. Si ça a l'air impossible, c'est un compilateur
Ada.
Théorème de Stockmayer.

Emmanuel Florac a écrit :
> [...] Dans la lecture aléatoire de petites
> quantités (inférieures au cache du disque, typiquement 8Mo) le facteur
> limitant c'est le temps d'accès du disque, égal au moins à une
> demi-rotation

En moyenne. Le temps de latence (latency time) varie entre 0 et le temps
d'un tour complet.

> +le temps de lecture.

+ le temps de déplacement du bras de têtes (seek time).

Pensée :
Si la taille moyenne des accès aléatoires est petite devant la taille
des bandes (c'est comme ça qu'on dit ?) du RAID0, ne peut-on pas espérer
un gain de temps d'accès moyen en tablant sur le fait que
statistiquement on va chercher sur chaque disque des données à des
emplacements non corrélés et donc que les déplacements des têtes sont
indépendants ?

On Sun, 20 May 2007 19:47:40 +0200, "Mihamina (R12y) Rakotomandimby" :

>Moi j'ai une grosse (qui occupe beaucoup de place sur le disque) base MySQL

Qu'entends-tu par "grosse" ? Plusieurs Go ? Dizaines de Go ?

>à faire mouliner plus vite rapidement (pas le temps de revoir la structure
>des données).

Sans changer la structure en elle-même, rajouter quelques index bien
placés aiderait peut-être ?

On Wed, 23 May 2007 22:08:47 +0200, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org>:

>Si la taille moyenne des accès aléatoires est petite devant la taille
>des bandes [...] du RAID0,

Ou tout simplement inférieure.

>ne peut-on pas espérer
>un gain de temps d'accès moyen en tablant sur le fait que
>statistiquement on va chercher sur chaque disque des données à des
>emplacements non corrélés et donc que les déplacements des têtes sont
>indépendants ?

Intuitivement, je dirais que tu as raison.

Fabien LE LEZ a écrit :
>
>>Si la taille moyenne des accès aléatoires est petite devant la taille
>>des bandes [...] du RAID0,
>
> Ou tout simplement inférieure.

Oui mais non : si elle est juste inférieure mais pas sensiblement, la
probabilité que la donnée soit à cheval entre deux bandes est grande. Du
coup il faut lire une bande sur chaque disque et adieu le gain de temps
d'accès.

>>ne peut-on pas espérer
>>un gain de temps d'accès moyen en tablant sur le fait que
>>statistiquement on va chercher sur chaque disque des données à des
>>emplacements non corrélés et donc que les déplacements des têtes sont
>>indépendants ?
>
> Intuitivement, je dirais que tu as raison.

Le Wed, 23 May 2007 22:08:47 +0200, Pascal Hambourg a écrit:

>
> En moyenne. Le temps de latence (latency time) varie entre 0 et le temps
> d'un tour complet.
>
>> +le temps de lecture.
>
> + le temps de déplacement du bras de têtes (seek time).

C'est bien il y en a qui suivent

> Pensée :
> Si la taille moyenne des accès aléatoires est petite devant la taille
> des bandes (c'est comme ça qu'on dit ?) du RAID0, ne peut-on pas espérer
> un gain de temps d'accès moyen en tablant sur le fait que statistiquement
> on va chercher sur chaque disque des données à des emplacements non
> corrélés et donc que les déplacements des têtes sont indépendants ?

En effet. C'est valable aussi pour les autres types de RAID, en lecture.

--
It is better to remain silent and be thought a fool than to open one's
mouth and remove all doubt.
Abraham Lincoln.

Le Thu, 24 May 2007 01:19:08 +0200, Pascal Hambourg a écrit:

>
> Oui mais non : si elle est juste inférieure mais pas sensiblement, la
> probabilité que la donnée soit à cheval entre deux bandes est grande.
> Du coup il faut lire une bande sur chaque disque et adieu le gain de temps
> d'accès.

En effet. Typiquement, on considère le gain intéressant si la taille du
bloc lu tourne autour d'un bloc de système de fichiers (entre 1 et 4 Ko
en général), les bandes étant elles plutôt entre 4 et 256Ko, en général.

--
I am not a vegetarian because I love animals; I am a vegetarian
because I hate plants.
A. Whitney Brown