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?
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
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
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
Mihamina (R12y) Rakotomandimby
Emmanuel Florac - :
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?
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?
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?
Matthieu Moy
"Mihamina (R12y) Rakotomandimby" writes:
Emmanuel Florac - :
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.
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.
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
Arol
"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 ?
"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 ?
"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 ?
Emmanuel Florac
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.
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.
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.
Pascal Hambourg
[...] 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 ?
[...] 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 ?
[...] 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 ?
Fabien LE LEZ
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 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 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 ?
Fabien LE LEZ
On Wed, 23 May 2007 22:08:47 +0200, Pascal Hambourg :
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.
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 ?
On Wed, 23 May 2007 22:08:47 +0200, Pascal Hambourg :
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.
Pascal Hambourg
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.
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 ?
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.
Emmanuel Florac
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 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 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.
