Conseils pour hébergement WEB

 
Plus il y a de disques, et pire le ratio est.
 
Pour schématiser, ce n'est pas dur : le raid 5, en ecriture, va "a peu pret" a la vitesse d'un seul disque.
 
En théorie, le raid 10, s'il contient n disque, va n/2 fois plus vite.
 
Bien entendu, je ne parle pas des debits bruts lors de transfert linéaire la (meme si en pratique il ressemble tout de meme un peu a ca, avec un peu moin de malus pour le raid 5 qui tire plus partie de son cache), mais pour plein de petite ecriture/modification a droite a gauche sur un pool de data assez important.

 
En fait, l'administration systeme, c'est un peu mon metier, j'ai passé bien du temps a tester les differentes vitesse d'écriture, que ce soit avec mysql ou autre chose (flux videos multiple, nfs, etc etc), sur differente machine, avec differente carte et different disque, pour differente utilisation ...
 
Dans tout les cas, le raid 5 va moin vite en écriture. Et de beaucoups. Toujours. Genre 2 ou 3 fois, en fonction du nombre de disque.
 

 
Qu'il soit hardware ou software ne change pas grand chose, en fait.
 
Il se trouve meme que la plupart du temps, le raid software va bien plus vite que le raid hardware.
 
Le seul reel avantage du raid hard est quand la carte SCSI a vraiment beaucoup de cache, et que ce cache est batterie backuped. Et encore :)
 
Dans tout les cas, cela ne change pas la complexité des écritures dans le cas d'un raid 5, et donc de leur mauvaise performance par rapport a un raid 10.
 
 
 
Enfin vu l'animausité qui commence a transparaitre de tout ca, j'imagine que tu mets toujours du raid 5 et donc que mon dialogue t'ennuie pas mal, dans tout les cas, il doit commencer a devenir ininterressant pour la plupart des gens, aussi je t'invite a continuer en PV :)

 
Houlala. Alors la, pas du tout :)
 
Concernant le cache, en effet, il y en a, mais ca ne change pas le fait qu'au final pour ecrire une quantité X de data, il faut relire Y data a coté. On y peut rien. Dans l'absolu (enfin dans un monde parfait), il faut que toute la base tienne dans la ram (en gros). Mais si cela doit absolument etre le cas, alors il ne sert a rien de gagner de la place en utilisant du raid5 plutot que du raid 10, vu que clairement personne n'a ne serait-ce que 36 Go de ram dans sa machine :)
 
Concernant la complexité, justement, tout le probleme des B-Tree, c'est de permettre une lecture (donc, un select) accelérée, a *condition* que ce B-Tree soit correctement balancé, et pour cela, il y a tout un tas de calcul a faire lors des inserts, il faut parfois rebalancé l'arbre, etc etc, ce qui est assez lourd. Encore une fois, oui, les écritures peuvent etre caché, mais cela n'empeche pas que lorsqu'il faut les écrirent, ca va bien plus vite sur du raid 10 :)
 
Bref, finissons ce troll qui risque de durer bien longtemps sinon, mais crois moi, le raid 5 pour une bdd, c'est *mal*.

 
Les perfs en *lecture* reste tres interressante, mais pour tout ce qui est écriture, c'est une sainte catastrophe (dans l'absolue, ca va moin vite qu'un disque tout seul). Hors un serveur SQL est justement une machine qui fait pas mal d'ecriture. Je m'explique :
 
En raid 5, quand on ecrit un fichier de 192k sur, par exemple, 4 disques, avec un stripesize de 64k (re-par-exemple), voila ce qu'il se passe : les premiers 64 k sont mis sur un premier disque, de 64 a 128k, c'est sur le deuxieme, et de 128 a 192, c'est sur le 3eme. Ensuite, la parité est mise sur le 4eme (bon, c'est pas toujours cet ordre, mais la théorie est la). Pour calculer la parité, facile, il suffit de XORer l'ensemble des 3 strippes qui a été ecrit. Ca va super vite (les processeurs actuels le font a quelques centaines de Mo/s). Jusque la, toujours pas de probleme, ca va assez vite ... Il faut quand meme noter que dans l'histoire, pour ecrire un seul fichier, on a fait seeker nos 4 disques durs, donc meme si en debit continue, cela tiens le debit théorique de 3 disques, en pratique, cela fait qu'on ne peut pas faire plus de 200 ecritures differentes par seconde (vu que le seek d'un disque moyen est de 5 ms) sur l'ensemble du raid (mais ca, c'est pareil sur un raid 0).
 
Maintenant, si notre fichier de 192k est, par exemple, une base sql, et que l'on vient de modifier un champs, qui on va dire est au 100eme Ko du fichier, que ce passe-t-il ? Sur un disque normal, facile, le secteur qui contient le champs (de 4k) est relu, modifier, et reecrit. Sur un raid 0 (ou 10), idem. Mais sur un raid 5 ? Et bien sur un raid 5, on fait pareil, sauf qu'on a le droit de relire l'integralité des 192 ko pour recalculer la parité juste derriere. Donc refaire seeker l'ensemble de nos disques juste pour une petite écriture.
 
Bien entendu, tant que le fichier original est toujours dans le buffer cache (dans le cas d'un raid soft) ou dans le cache de la carte raid (dans le cas d'un raid hard), cela va vite, mais en pratique, si on met du raid 5, c'est pour avoir de la place, et il y a donc peu de chance pour que toutes nos bases tiennent en cache :)
 
A noter aussi qu'avec tout les systemes de fichier journalisé, l'impact est double, car toute ecriture est toujours doublé dans le log du fs (et vi ... meme si c'est juste 10 octets :().  
 
Petite parenthese sur le mode dégradé : en fait, celui ci rame juste parce que la complexité de la lecture d'un bloc devient la meme que celle de l'ecriture d'un block (ie, il faut lire tout les blocks d'a coté pour pouvoir recalculer ce qui manque ... comme deja dit, le recalcul est super rapide, ce n'est donc pas un probleme, seul le fait de faire seeker tout les disques en est un). En ecriture, a priory, les perfs doivent rester les meme.
 
Re-petite-parenthese completement a part sur le "pourquoi que le raid 0 va toujours plus vite que le raid 5 alors que justement sur le raid 5 la parité est répartie sur les disques pour que tout les disques puissent etre utilisé en lecture" : appelez moi "read ahead" :). Tout les disques mettent des données en cache lorsque l'on demande une lecture d'un secteur, ce qui est tout a fait normal, puisqu'un rapide calcul nous montre que meme pour un disque seekant en moyenne a 5 ms, il ne peut le faire que 200 fois par secondes. Donc le temps d'un seek est égal a, sur un disque debitant 40 Mo/s, environ 200 ko. Donc toute lecture inferieur a 200 ko n'est pas rentable, puisque le temps de seek deviendrait alors plus long que le temps de lecture, c'est pourquoi souvent les disques lisent systematiquement 256 ko, quelque soit la taille de ce qu'on a demandé a lire. Bien souvent, c'est un choix judicieu, mais dans le cas du raid, il se trouve que cela fait que votre disque lit systematiquement le bloc de parité en lisant le bloc précédent celui ci ... donc vous vous retrouvez, en debit brut, avec les perfs de n-1 disques a la place d'avoir les perfs de n disque ... A noter quand meme que lorsqu'il y a beaucoup d'io simultané, vous beneficiez quand meme d'un disque supplémentaire pouvant aller chercher des infos, ca vaut donc le coup par rapport a un raid 4.
 

 
active le gzip ... héhé :p
 
Non, pour un forum tel que celui ci, cela ne m'étonne pas [trop], surtout quand on voit la taille des posts des abrutits comme moi :)
N'empeche que j'aimerais bien savoir quel est la part de burst et la part d'utilisation reele dans tout cela :)
 
Enfin cela n'empeche pas que pour la majorité des gens, 10 Mbits ne seront *jamais* la cause de ramage intempestif, d'ou ma remarque. (si t'as des graphs j'veux bien :) )

 
A savoir que le raid 5, ca pue pour faire du SQL (prendre du raid 0, 1 ou 10)
 

 
Toutes les modifications sont plus longues (nécéssité de maintenir l'index a jour). Mais sur 90% des applications, c'est un gain énorme, qui permet par exemple de retrouver une entrée dans une table gigantesque en quelques microseconde :)
 

 
Pour ce qui est du lien 10 Mbits entre les 2 serveurs, ce n'est pas un probleme. Il est tres rare d'acceder a de grosse quantités de données en SQL, et il ne faut pas oublier que 10 Mbits, cela fait quand meme facilement 1 Millions de caracteres par seconde.
Par contre, il est vrai aussi qu'une carte reseau 100 Mbits coute moin de 10 Euros, donc c'est un peu con de s'en priver :)
 
Pour savoir si c'est le serveur SQL qui rame, je ne connais pas bien ceux disponible sous windows, mais il y a sans doute moyen de prendre connaissance de la longueur moyenne des requetes, de celles qui sont les plus longues, etc etc etc.

Quelles sont les configs en gros et le Windows utilisé dessus ? :??:

La charge CPU est plus importante sur le SQL malgré ça ? Peut être un problème d'index SQL ou de disque  pas assez performant ( simple IDE ou SATA ou SCSI ou RAID ? )
 

A la base la solution généralement sympathique et simple est d'avoir un SQL puissant et N webs en fonction des ressources nécessaires. Seulement si c'est le SQL qui charge, éventuellement il serait intéressant de séparer entre 2 machines pour situer quel(s) site(s) bouffe autant si la machine est puissante. 10 MBps entre les 2 serveurs c'est vraiment pas terrible par contre, 100 MBps serait bien mieux surement. Tu peux voir l'occupation de ce lien via le monitoring des ressources ?
 

Là encore il faut situer d'abord où se trouve le problème à la base, si c'est l'accès au SQL, c'est pas forcément ça qui va aider. Dans tous les cas remplacer une machine préhistorique par une nouvelle puissante est plus intéressant que de mettre l'ancienne et la nouvelle ensemble ( question de déséquilibre )
 

Outre le lien, après ce n'est pas temps d'accès mais surement le traitement qui joue, c'est à dire le temps pour traiter une requête. Si tu fais une requête qui doit parcourir toute une énorme table sans arrêt parce qu'il n'y a pas d'index ou ce genre de choses, c'est problématique forcément :/
 
 

Chacun son métier c'est normal, bon courage en tout cas. Eventuellement un audit de la plateforme serait intéressant avant que tu ne décides un changement, afin de mieux cibler le point de ralentissement :)