> A choisir de mettre 500€ de matos en plus, je pencherais pour de la ram plutot qu'une carte raid avec BBU. Même si les prix sont tombés par rapport à une autre époque. (d'ailleurs, cela ne coute pas moins chère de mettre un petit APS à coté du serveur qui provoque un fsync clean avant que la batterie sois complètement vide ?)
Pour rester sur ma ligne "à cette heure il n'y a pas une solution qui les écrase toutes" ;) :
je crois que c'est vraiment un choix (sur quel type de matos flamber le budtet) qui doit se faire au cas par cas, selon les besoins de l'appli.
Par exemple pour reprendre tes suggestions citées juste au dessus (qui peuvent être bien pertinentes dans certains cas) :
* La RAM (dans l'OS) est principalement mise à profit pour réduire les lectures (ok, et les écritures si elles sont asynchrones, généralement pas le cas des SGBD). Donc très profitable pour une appli faisant beaucoup de lecture.
* Il y a des cas où augmenter la RAM n'apporte rien de significatif (par ex. si on a déjà 32 GB de RAM pour une bdd de 20 GB)
* Le couple cache_controlleur+BBU n'est pas tout à fait équivalent/remplaçable par une UPS :
- Il termine ses écritures même en cas de crash et arrets de l'OS, pas seulement en cas de pannes electriques. Ca signifie que même avec du writecache une transaction validée sera vraiment stockée, ce qui peux être - ou pas - une nécessité, selon le type d'appli. Dans le cas d'un système avec UPS : soit on écrit de façon synchrone (mauvaises perfs en écritures random), soit on prends le risque de valider des écritures non persistées (écritures async => utilisation du page cache de l'os => pertes en cas de crash). Ca protège aussi des problèmes de cables qui "se débranchent" (que le premier qui a bossé en salle serveur me jette la pière ;).
- La BBU permet d'activer le mode writeback du cache en écriture du controlleur (ces derniers le désactivent en général automatiquement en l'absence de BBU, pour ne pas perdre les données sales en cache en attente d'aggregation et d'envois vers les disques)
- Les controlleurs connaissent bien le layout physiques des disques, et s'ils sont dotés d'un cache (et qu'ils peuvent l'exploiter, donc d'une BBU), ils savent (plus ou moins) balancer les écritures de façon optimales sur les pools de disques disponibles. C'est aussi le cas du MD logiciel de Linux, mais n'est plus le cas s'il y a une couche LVM sur le MD.
* Tout ces questions ne sont pertinentes que pour une appli nécessitant beaucoup d'écritures random et synchrones ; il est clair qu'un logiciel dont le besoin premier est d'écrire, de façon asynchrone, de gros volumes de données a plutôt besoin d'une grosse bande passante.
[^] # Re: Stockage en RAM
Posté par herodiade . En réponse au journal Performance MYSQL. Évalué à 2.
Pour rester sur ma ligne "à cette heure il n'y a pas une solution qui les écrase toutes" ;) :
je crois que c'est vraiment un choix (sur quel type de matos flamber le budtet) qui doit se faire au cas par cas, selon les besoins de l'appli.
Par exemple pour reprendre tes suggestions citées juste au dessus (qui peuvent être bien pertinentes dans certains cas) :
* La RAM (dans l'OS) est principalement mise à profit pour réduire les lectures (ok, et les écritures si elles sont asynchrones, généralement pas le cas des SGBD). Donc très profitable pour une appli faisant beaucoup de lecture.
* Il y a des cas où augmenter la RAM n'apporte rien de significatif (par ex. si on a déjà 32 GB de RAM pour une bdd de 20 GB)
* Le couple cache_controlleur+BBU n'est pas tout à fait équivalent/remplaçable par une UPS :
- Il termine ses écritures même en cas de crash et arrets de l'OS, pas seulement en cas de pannes electriques. Ca signifie que même avec du writecache une transaction validée sera vraiment stockée, ce qui peux être - ou pas - une nécessité, selon le type d'appli. Dans le cas d'un système avec UPS : soit on écrit de façon synchrone (mauvaises perfs en écritures random), soit on prends le risque de valider des écritures non persistées (écritures async => utilisation du page cache de l'os => pertes en cas de crash). Ca protège aussi des problèmes de cables qui "se débranchent" (que le premier qui a bossé en salle serveur me jette la pière ;).
- La BBU permet d'activer le mode writeback du cache en écriture du controlleur (ces derniers le désactivent en général automatiquement en l'absence de BBU, pour ne pas perdre les données sales en cache en attente d'aggregation et d'envois vers les disques)
- Les controlleurs connaissent bien le layout physiques des disques, et s'ils sont dotés d'un cache (et qu'ils peuvent l'exploiter, donc d'une BBU), ils savent (plus ou moins) balancer les écritures de façon optimales sur les pools de disques disponibles. C'est aussi le cas du MD logiciel de Linux, mais n'est plus le cas s'il y a une couche LVM sur le MD.
* Tout ces questions ne sont pertinentes que pour une appli nécessitant beaucoup d'écritures random et synchrones ; il est clair qu'un logiciel dont le besoin premier est d'écrire, de façon asynchrone, de gros volumes de données a plutôt besoin d'une grosse bande passante.