La performance malgré l’augmentation de la volumétrie

Présentation effectuée au meetup LeMug par Christophe Villeneuve et Sébastien Giraud sur "La performance malgré l’augmentation de la volumétrie".
Cette session vous aidera à résoudre les problèmes de performance que les projets rencontres lors de l'augmentation de la volumétrie

Transcript

1. La performance malgré l’augmentation de la volumétrie Sébastien Giraud Senior Solution Architect MariaDB Plc Christophe Villeneuve Atos - Eviden Meetup Le Mug 19/06/2024
2. Sébastien GIRAUD Christophe Villeneuve Senior Solution Architect MariaDB Plc
3. Agenda • Optimisation des performances de MariaDB • Principes communs et bonnes pratiques • Paramètres de configuration • Encore plus en profondeur
4. • Optimisation des performances • Principes communs et bonnes pratiques • Paramètres de configuration • Encore plus en profondeur
5. Comprendre MariaDB • MariaDB est une solution modulaire ◦ Moteurs de stockage ◦ Plugins • Architecture Linux like ◦ Hautement ajustable ◦ 800 variables de configuration • Solution green (codé en C) ◦ Package de 100 Mo • Réplication entre différents moteurs • Ecosystem de plus en plus complet ◦ MaxScale ◦ MariaBackup ◦ MariaDB Shell ◦ Connecteurs ◦ MariaDB Cloud
6. Tuning ? • Une application / logiciel évolue ◦ Maintenir des performances optimales pour un nombre croissant de clients • C’est pourquoi : ◦ Utiliser efficacement les ressources du serveur ◦ La meilleure performance pour les utilisateurs ◦ Éviter les pannes dues à la lenteur du serveur ◦ Capacités ▪ être prêt à répondre aux exigences du développement d'applications ▪ permettre des pics de trafic inattendus ou d'autres changements dans la demande.
7. Configuration minimale • Les valeurs recommandées (à ajuster en fonction des ressources et versions) ◦ transaction-isolation = REPEATABLE READ ◦ key_buffer = 128MB -> 1GB of RAM (MyIsam) ◦ sort_buffer_size = 1MB -> 1GB of RAM (Session client en mémoire) ◦ read_buffer_size = 1MB -> 1GB of RAM (Session client en mémoire) ◦ read_rnd_buffer_size = 1MB -> 1GB of RAM (Session client en mémoire) ◦ thread_pool_size ▪ Est basé sur le nombre de CPU, et l’augmenter au besoins ◦ Thread-handling = pool-of-threads ◦ innodb_flush_log_at_trx_commit ▪ A ajuster en fonction du besoin et des contraintes ▪ 0 rapide ▪ 1 ACID ◦ open_files_limit = 50000
8. Performance par les valeurs • Les paramètres de performance de MariaDB ◦ InnoDB file-per-table ◦ InnoDB Buffer Pool Size ◦ Désactivation du Swap avec MariaDB ◦ Max Connections ◦ Thread Cache ou Thread pool ◦ Désactivation du DNS Lookups ◦ Query Cache ◦ Tmp Table Size ◦ Max Heap Table Size ◦ Slow Query Logs
9. • Optimisation des performances • Principes communs et bonnes pratiques • Paramètres de configuration • Encore plus en profondeur
10. Quand faire du tuning ? • Monitoring ◦ show global status ◦ show global variables • Utilisation dès le début du cycle de vie de l'application ◦ Corréler les graphes avec la charge ◦ Commencer tôt pour s'assurer que le schéma est bien construit ◦ Tester les requêtes sur des données lues - surveiller les goulets d'étranglement ◦ Seul la production permet de reproduire la charge de la production ▪ Un réglage excessif sans données de production ou trafic est contre-productif • Procéder à des examens périodiques des systèmes de production ◦ surveiller le schéma, les requêtes et les changements importants ◦ vérifier soigneusement les nouvelles fonctionnalités de l'application ◦ surveiller les ressources du système - disque, mémoire, réseau, CPU
11. Réglages my.cnf (½) • Modifiez un paramètre à la fois... (pas de big bang) ◦ C'est la seule façon de déterminer si un changement est bénéfique. ◦ La plupart des paramètres peuvent être modifiés au moment de l'exécution avec ▪ SET GLOBAL. ◦ C'est très pratique et cela vous permet de revenir rapidement sur la modification si nécessaire. ◦ Attention aux différences entre la configuration active et la configuration sur disque • Pour rendre une modification permanente, vous devez mettre à jour le fichier de configuration et redémarrer le serveur MariaDB pour garantir la syntaxe • Si un changement dans la configuration n'est pas visible même après un redémarrage de MariaDB... ◦ Avez-vous utilisé le bon fichier de configuration ? ◦ Avez-vous placé le paramètre dans la bonne section ? ◦ Normalement la section [mariadb] pour ces paramètres
12. Réglages my.cnf (2/2) • Le serveur refuse de démarrer après une modification : ◦ Avez-vous utilisé les bonnes unités ? ◦ Par exemple, innodb_buffer_pool_size doit être défini en octets alors que max_connection est sans unité ◦ Ne pas dupliquer des paramètres dans le fichier de configuration ◦ Vérifier les calculs de dimensionnement des variables ◦ Vérifier les log de démarrage • Pour garder une trace des modifications, utilisez le contrôle de version • Ne faites pas de calculs empiriques ◦ "mon nouveau serveur à 2 fois plus de RAM, il suffira de multiplier toutes les valeurs par 2 par rapport aux précédentes"
13. • Optimisation des performances • Principes communs et bonnes pratiques • Paramètres de configuration • Encore plus en profondeur
14. Configuration matérielle • L'idéal est d'avoir un service par serveur afin d'éviter les conflits. ◦ faire en sorte que le serveur de base de données ne soit qu'un serveur de base de données, etc. • Plus grand nombre de cœurs de processeur est généralement une bonne chose • Plus grand nombre de disques est généralement préférable ◦ pour les grands ensembles de données, des disques rapides sont préférés • Plus grande quantité de mémoire vive est généralement préférable - en fonction du trafic ◦ plus de données en mémoire, moins d'opérations lentes sur les disques
15. Configuration OS Linux • Swap ◦ Partition d’échange sur disque du système d'exploitation ◦ 60 par défaut ◦ Généralement à 10 ou plus ◦ 1 mais pas 0 • Noatime ◦ monter un disque avec cette option ◦ désactive l'écriture du temps d'accès sur le disque à chaque accès au fichier ◦ sans cette option, chaque lecture devient une écriture supplémentaire
16. Performance par le proxy • Adapter l'architecture ◦ aux exigences de performance • Comprendre le cas d'utilisation • Multiplier les moteurs ◦ selon les besoins • Un proxy pour tout simplifier
17. Trafic distribué avec MaxScale Primary Replicas 172.20.0.2 172.20.0.3 172.20.0.4 172.20.0.6:4006 Distribution automatique en lecture / Écriture Applications & Tools Application connecté à MaxScale Défaillance serveur primaire Primary Replicas 172.20.0.2 172.20.0.3 172.20.0.4 172.20.0.6:4006 Applications & Tools
18. 10 points à configurer au minimum • Innodb_buffer_pool_size • Query_cache_size • Innodb_file_per_table • Désactiver la résolution DNS et le parcours de liens symbolique • Variable max_connections • Vérifier les connexions inactives • thread_cache_size • Memory parameters • Buffer sizes • Max_allowed_packet
19. Surveiller l’environnement système / serveur (½) • Supervision des systèmes ◦ Mémoire, swap ◦ Load, CPU, réseau (bande passante et perte de paquets) ◦ Max open file, inodes, semaphores ◦ Acces disque, IOPS, latence, IO Queue • Monitoring et alerting disque
20. Surveiller l’environnement système / serveur (2/2) • Métriques MariaDB ◦ Aborted connections ◦ Used and max connections ◦ Thread connected ◦ Lock wait ◦ Replication lag • Erreurs typiques de MariaDB : points à surveiller ◦ Deadlock ◦ Long running transactions ◦ Requetes sans index ◦ Processlist • Monitoring ◦ Caches ◦ Buffers ◦ Monitoring requêtes actives
21. Requêtes lentes : Configuration • Activer les logs • Les requêtes lentes peuvent aider à déterminer les problèmes de votre base de données et à les déboguer. • Ceci peut être facilement activé en ajoutant les valeurs suivantes dans votre fichier de configuration my.cnf : ◦ slow-query-log = 1 ◦ slow-query-log-file = /var/lib/mysql/mysql-slow.log ◦ long_query_time = 1 . - Activer la journalisation - Chemin fichier log - long_query_time pour définir le temps considéré comme long pour qu'une requête
22. Requêtes lentes : Mise en place • Essayez de ne pas faire de Query Tune sur le serveur de production • Utilisez un serveur de test avec le même matériel et le même système d'exploitation • Faire un clone de l'ensemble de données de production • La fréquence des requêtes est aussi importante que la vitesse des requêtes ◦ Les requêtes modérément lentes sont souvent un plus gros problème qu'une requête très lente rarement exécutée
23. Requêtes lentes : Optimisation • Les index ◦ Améliorent les performances de lecture ◦ MariaDB peut sauter aux lignes demandées ◦ Réduction des E/S et amélioration des performances ◦ Augmente le coût des écritures ◦ Indexer pour la vitesse, mais éviter d'indexer de manière excessive ou arbitraire • Fonctions utiles ◦ SHOW PROCESSLIST ◦ SHOW STATUS global ◦ PERFORMACE_SCHEMA
24. • Optimisation des performances • Principes communs et bonnes pratiques • Paramètres de configuration • Encore plus en profondeur
25. Le cas du transactionnel • Quand les performances ne sont plus au rendez vous ? ◦ Passer en revue les serveurs ◦ Passer en revue les configurations ◦ Optimiser l’utilisation de la mémoire et du CPU ◦ Vérifier la complexité des requêtes ▪ ANALYZE FORMAT=JSON is a mix of the EXPLAIN FORMAT=JSON and ANALYZE statement features. The ANALYZE FORMAT=JSON $statement will execute $statement, and then print the output of EXPLAIN FORMAT=JSON, amended with data from the query execution. ▪ EXPLAIN FORMAT=JSON is a variant of EXPLAIN command that produces output in JSON form. The output always has one row which has only one column titled "JSON". The contents are a JSON representation of the query plan, formatted for readability: EXPLAIN FORMAT=JSON SELECT * FROM t1 WHERE col1=1\G • ET APRES ?
26. Optimisation des cas transactionnel • MyRocks ? Oui le moteur de Facebook ! • LSM algorithm : indexation rapide des gros volumes https://mariadb.com/resources/blog/facebook-myrocks-at-mariadb/#sthash.ZlEr7kNq.dpuf
27. Et pourquoi pas diviser les schémas ? • Le Sharding avec Spider CREATE TABLE s( id INT NOT NULL AUTO_INCREMENT, code VARCHAR(10), PRIMARY KEY(id) ) ENGINE=SPIDER COMMENT 'host "127.0.0.1", user "msandbox",\ password "msandbox", port "8607"';
28. Et pourquoi pas diviser les schémas ? • Le Sharding avec MaxScale [accounts_east] type=server address=192.168.56.102 port=3306 [accounts_west] type=server address=192.168.122.85 port=3306 [Sharded-Service] type=service router=schemarouter servers=accounts_west,accounts_east
29. Apercu de MaxScale Advanced • Performance and scalability ◦ Read/write split ◦ Load balancing adaptatif ◦ Causal reads ◦ Caching des résultats de requête avec Redis • HA ◦ Failover Automatique ◦ Transaction replay • Moniteurs ◦ Replicated environments ◦ Galera • Verrouillage coopératif ◦ MaxScale HA ◦ Multiple MaxScale Moniteurs dans un Cluster • Sécurité ◦ Masquage dynamique des données ◦ Limitation des requêtes ◦ Limitation des résultats des requêtes ◦ Statistiques de performance ◦ Enregistrement central des requêtes Basics
30. Thanks Sébastien seb@mariadb.com @GiraudSebastie3 Christophe @hellosct1 @hellosct1@mamot.fr