Serveur avec disque SSD ou SAS

[ams51]

Je recopie intégralement un billet publié chez moi... ça peut aider.

Je suis loin d'être un expert en hardware (bien au contraire) donc c'est une base de réflexion et non une étude définitive

Suite à une surcharge permanente de mon serveur depuis quelques mois je songe sérieusement à le changer. Je vais rester chez OVH, je suis assez content de leur service depuis le début et mon ange de l'infogérance qui m'a sauvé plus d'une fois ne travaille qu'avec OVH... Alors on ne change pas une équipe qui gagne.

A départ je pensais passer sur une architecture avec 2 serveurs. Le plan de dev pour modifier mes scripts était bien avancé. J'ai entendu parler de Memcached chez Mrboo, ce qui m'a rappelé un billet chez Koreus. Bref, j'ai passé une petite journée dans la doc de Memcached puis dans mon code pour voir comment je pouvais l'adapter chez moi. Et là c'est le coup de foudre... Je peux jeter mon sale système de cache maison qui fait planter ma machine contre un système de cache un poil plus sérieux utilisé par des startups qui montent (digg et facebook par exemple).

Mon architecture à deux serveur ne présentant plus beaucoup d'intérêt, je jète mon dévolu sur un serveur HG-2010. Reste à choisir le disque SSD 80Go ou SAS 15000rpm 300Go. Sachant qu'ils seront monté en RAID1 (disques miroir).

Le disque SSD est plus petit mais peut largement contenir mon site et mes bases de données si je n'utilise pas mon système de cache merdique. A priori ça ne devrait pas dépasser 10Go... Et même si ça double (peu probable) il me reste 60Go de marge.

Et là je tombe sur un comparatif très détaillé des disques SSD Intel X25-E SLC 32Go et SAS Seagate Cheetah 15000RPM 300Go.

OVH propose un SSD Intel X25-M (et pas E) et pas de référence pour le SAS. On dira que les disques SAS sont à peu près équivalents. Pour les caractéristiques des SSD :

• X25-M: Read 65µs, Write 85µs, MTBF 1.2million heures, sequential read 250Mb/s, sequential write 70Mb/s. Voir la doc
  
• X25-E: Read 75µs, Write 85µs, MTBF 2millions heures, sequential read 250Mb/s, sequential write 170Mb/s. Voir la doc
  

En gros les perfs sont équivalentes seulement le M écrit 2.5 fois moins vite. Je prendrais donc les résultats du comparatif et je diviserais par 2.5 pour les tests d'écriture et les tests de R/W (les résultats seront faux mais pas surestimés). Autre point, la durée de vie est plus faible... mais 1.2 million d'heure reste quand même raisonnable (en plus il y a la sécurité du RAID1).

Bref, voici les résultats du comparatif compilés et corrigés pour une utilisation mono-disque.

Les résultats d'écriture/lecture random sont, parait-il, plus proche de la réalité. Pour de l'I/O simple le SSD aurait un débit 240% meilleur (au minimum, certainement plus vu mon approximation). Pour de l'écriture sur base de données l'amélioration est de 650%, en lecture 2300%.

Bref, malgré les incertitudes de mes approximations le SSD semble meilleur sur tous les points.

Reste à savoir maintenant comment je vais configurer Memcached. Je vais avoir 48Go de RAM sur mon serveur, je pense allouer entre 8 et 12 Go pour Memcache, d'après mes estimations ça devrait être assez bien dosé (je compte bien utiliser le cache à fond). Par contre je n'ai jamais vu autant d'allocation de mémoire (en général c'est plutôt quelques Mo)... Ce sera donc la grande surprise sur les performances globales.

Si je travaille bien, le temps d'accès aux pages devrait redescendre sous la seconde (disque SSD + cache en RAM+ 3fois+de mémoire + proc plus puissant + eaccelerator = un peu mieux qu'avant?)

Je ne devrais plus avoir le fameux répertoire de cache qui emm.. ennuie Dan pour la sauvegarde du serveur

[Kioob]

Bonsoir,

quelques remarques en vrac :

- "sécurité du RAID 1", les deux SSD risquent d'avoir strictement la même usure dans le cas présent, donc pour le moment je suis assez dubitatif quant à l'intérêt du RAID 1 dans ce cas

- 48Go de mémoire, 10Go de données sur le disque, et malgré tout des problèmes de temps de lecture disque !? Es-tu certain que ce ne sont pas seulement les écritures qui te posent problème ?

- pour moi le principal intérêt de memcached c'est l'accès réseau, il permet d'avoir un cache commun à plusieurs serveurs. Dans une config mono serveur j'aurais tendance à lui privilégier des solutions d'accès à la mémoire partagée (via xcache, apc, ou autre), généralement beaucoup plus rapide.

[ams51]

- "sécurité du RAID 1", les deux SSD risquent d'avoir strictement la même usure dans le cas présent, donc pour le moment je suis assez dubitatif quant à l'intérêt du RAID 1 dans ce cas

C'est RAID1 ou RAID0 avec 2 disques. RAID0 est plus rapide mais RAID1 plus sûr. Je ne sais pas s'ils auront la même usure mais en cas de casse il est peu probable qu'ils cassent la même jour (où alors j'ai vraiment pas de chance)

- 48Go de mémoire, 10Go de données sur le disque, et malgré tout des problèmes de temps de lecture disque !? Es-tu certain que ce ne sont pas seulement les écritures qui te posent problème ?

Mon serveur actuel n'a que 16Go. Après analyse approfondie mes problèmes viennent de mon système de cache qui travaille sur des millions de fichiers qui prennent entre 40 et 50Go sur le disque. Il y a un très gros ralentissement de ce côté. L'idée est de changer de système de cache et de placer une partie des données dans un cache mémoire avec memcached.

Mon futur serveur aura 48Go de mémoire et 10Go de données sur disque.

- pour moi le principal intérêt de memcached c'est l'accès réseau, il permet d'avoir un cache commun à plusieurs serveurs. Dans une config mono serveur j'aurais tendance à lui privilégier des solutions d'accès à la mémoire partagée (via xcache, apc, ou autre), généralement beaucoup plus rapide.

D'après ce que j'ai lu memcached est beaucoup utilisé avec MySQL pour stocker le résultat des requêtes en cache. Ce qui permet d'alléger la charge sur les BDD.

Xcache compile les scripts php et place le tout en mémoire... ça accélère le php mais je ne crois pas que ça améliore MySQL. Pour ça je vais mettre eaccelerator qui fait la même chose.

[Nicolas]

As-tu essayé sans système de cache ? car un système de cache mal conçu ou mal paramétré aura plutôt tendance à ralentir ta machine.

16Go de Ram c'est quand même pas mal... ;-)

Concernant les disques SSD le mode raid 1 est utile car si les 2 disques travaillent de la même façon la durée de vie de chaque cellule mémoire est différente (même si la durée de vie théorique de chaque cellule est identique bien sur). Une cellule sur le 1er disque peut lâcher sans pour autant que cette même cellule (même = même adressage mémoire et même position physique) lâche sur le 2nd disque.

[ams51]

Sans cache les accès MySQL font tomber la machine.

Mon pb vient en grande partie des crawlers qui bouffent entre 250'000 et 300'000 pages par jour (3 fois plus que les visiteurs). Je dois donc servir 400'000 pages par jour et entre 5 à 10 pages par seconde en pointe. C'est pas énorme mais suffisamment lourd pour mon système bancale.

[Nicolas]

Ok je comprends mieux ;-)

A voir si Eaccelerator améliore tout ça...

[Kioob]

C'est RAID1 ou RAID0 avec 2 disques. RAID0 est plus rapide mais RAID1 plus sûr. Je ne sais pas s'ils auront la même usure mais en cas de casse il est peu probable qu'ils cassent la même jour (où alors j'ai vraiment pas de chance)

Et bien justement, un SSD est sensé ne pas "casser" mais au contraire peut s'user. En RAID 1 les écritures seront effectuées en simultané sur les deux SSD et auront ainsi chacun la même usure, d'où mon hésitation. Mais Nicolas a répondu à ce point

Mon serveur actuel n'a que 16Go. Après analyse approfondie mes problèmes viennent de mon système de cache qui travaille sur des millions de fichiers qui prennent entre 40 et 50Go sur le disque. Il y a un très gros ralentissement de ce côté. L'idée est de changer de système de cache et de placer une partie des données dans un cache mémoire avec memcached.

Mon futur serveur aura 48Go de mémoire et 10Go de données sur disque.

40 à 50Go de "cache" pour si peu de données derrière, oui je veux bien croire que ce soit complètement non productif.

Il n'en reste pas moins qu'avec 48Go de mémoire à mon avis l'intégralité du disque sera dans le cache, et donc que les performances en lecture importent peu dans ton cas.

D'après ce que j'ai lu memcached est beaucoup utilisé avec MySQL pour stocker le résultat des requêtes en cache. Ce qui permet d'alléger la charge sur les BDD.

Xcache compile les scripts php et place le tout en mémoire... ça accélère le php mais je ne crois pas que ça améliore MySQL. Pour ça je vais mettre eaccelerator qui fait la même chose.

Je parlais "évidement" des API fournies par xcache, apc et même eaccelerator qui permettent d'accéder à une zone mémoire commune (avec gestion des verrous intégrée) ; ce qui est généralement beaucoup plus rapide que memcached. Mais oui memcached est beaucoup utilisé (je l'utilise moi même), mais essentiellement dans des contextes multi serveur, là où les solutions mémoire ne peuvent être utilisées.

[destroyedlolo]

Ce qui est important avec les disques SSD (flash n'est-ce pas ?), c'est le nombre maxi d'ecriture par cellule.

Il faut donc que tu evites de faire trop d'ecriture, en particulier, tu as interet a virer les modifications des "acces time" des fichiers.

[Dan]

D'accord avec destroyedlolo, dans la mesure où cela n'impacte pas le fonctionnement de memcache..

Mais bon, comme le dit Nicolas, les disques en Raid1 auront de toutes manières une durée de vie différente... ne fût-ce quelques jours. Cela permet à OVH de remplacer le disque fautif le cas échéant.

Effectivement les disques SSD sont TRES rapides. Rien qu'à l'installation on sent une vraie différence.

Et le fait de ne plus avoir ton cache de furieux sur le disque devrait faire du bien, et pas qu'au serveur de sauvegarde !