2 votes

comment benchmarker dbms (sql et nosql) sur une architecture s390x (mainframes IBM essentiellement)

J'ai accès à une machine s390x, une zbc12 pour être précis, avec 32GB de RAM, que je peux utiliser comme laboratoire pour quelques mois( !).

Je voulais explorer les capacités de cette architecture, en particulier en ce qui concerne les dbms, et j'aimerais tester à la fois sql et nosql. En comparant cela à une architecture x86, j'ai aussi un x86 qui traîne et je peux connecter les deux au même SAN, donc je serais en mesure de comparer correctement les architectures. J'ai peu ou pas d'expérience en matière de benchmarking. Quels autres tests souhaiteriez-vous voir ? J'ai des mois sur cette machine et je peux jouer avec autant que je veux, avez-vous des idées intéressantes ?

2voto

Hogstrom Points 188

Félicitations pour l'accès à un système Z.

Pour la comparaison de différentes bases de données, je ne peux fournir que des indications générales. Voici quelques éléments à prendre en compte lors de l'élaboration de votre plan.

  1. Atomicité - divisez vos bases de données en types ACID et BASE, car la cohérence varie d'un type à l'autre et il faut tenir compte de considérations supplémentaires en termes de configuration (réseau, disque, etc.).

  2. Le système sous test (SUT) doit être bien défini en termes de nombre et de types de nœuds. Documentez le réseau et le stockage sous-jacents du mieux que vous pouvez afin que les gens puissent comparer votre configuration au déploiement prévu. Quels commutateurs utilisez-vous ? Êtes-vous configuré pour les Jumbo Frames ? Le stockage est-il en connexion directe ou en SAN ? Quelle est l'infrastructure réseau sous-jacente pour les deux (vitesse et IOPS) ?

  3. La configuration de la mémoire doit être bien documentée en ce qui concerne la façon dont la BD est configurée, assurez-vous qu'elle est cohérente, ou si vous testez cela, documentez la progression des configurations.

  4. Si vous comparez ACID et BASE, quel est l'objectif de cohérence et comment vous assurez-vous que la cohérence est complète en termes de réplication / enregistrement des transactions.

  5. Tenez compte de l'objectif de point de récupération (RPO), c'est-à-dire de la quantité de données que je suis prêt à perdre, ainsi que de l'objectif de temps de récupération (RTO), c'est-à-dire du moment où la base de données sera à nouveau disponible en cas de panne. Cela aura un impact sur votre configuration et vos hypothèses.

  6. Un client cohérent pour générer une charge répétable afin d'assurer la cohérence des tests. Le nombre de clients est-il évolutif ? Pouvez-vous faire une validation a posteriori pour vous assurer que le résultat attendu en termes de persistance a été atteint ?

Il existe un certain nombre d'autres facteurs à prendre en compte dans tout test, mais ceux-ci vous fourniront une base sur laquelle vous pourrez vous appuyer.

1 votes

Merci ! ces points me semblent raisonnables et bons, le s390x est génial entre parenthèses ! Je comprends pourquoi ces machines coûtent autant d'argent, le 3270 est un peu difficile à utiliser mais quand on comprend la logique derrière, ça fonctionne très bien.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X