Comment optimiser l'utilisation de la mémoire de MySQL?

9

MA CONFIGURATION ( exemple )

J'utilise Linux sur une instance Amazon High CPU Extra Large EC2 avec les spécifications suivantes:

7 Go de mémoire
20 unités de calcul EC2 (8 cœurs virtuels avec 2,5 unités de calcul EC2 chacune)
1690 Go de stockage d'instance locale
Plateforme 64 bits

J'ai deux grandes bases de données MySQL fonctionnant sur le moteur de stockage MyISAM. L'un est de 2 Go et l'autre de 500 Mo. Je voudrais m'assurer que MySQL utilise autant de RAM qu'il peut / besoin pour maximiser les vitesses de requête. Je sais qu'il y a un tas d'options de configuration de mémoire MySQL comme key_buffer_sizeet MyISAM_sort_buffer_size,je ne suis pas familier avec l'optimisation de celles-ci.

DES QUESTIONS

Comment vérifier la mémoire actuellement utilisée par MySQL sur un système Linux?
Comment maximiser / optimiser l'utilisation de la mémoire MySQL?
En supposant que mes requêtes et mon schéma sont optimisés, quelles autres modifications dois-je envisager?

mysql linux memory

— T. Brian Jones
source

vous pouvez vérifier avec le programme htop.

— neworld

Maximiser l'utilisation de la mémoire n'entraîne pas l'intégralité de la base de données en mémoire. Vous devez avoir un système de fichiers basé sur RAM ...

4

Le système de fichiers basé sur la RAM n'est pas sûr. Si le serveur

— plante,

7

C'est un sujet difficile. Je ne peux pas répondre ici, des livres entiers ont été écrits à ce sujet. Je recommande de rendre votre taille innodb_buffer_pool_size assez grande. Si vous utilisez des tables myisam, vérifiez key_buffer_size. Table_cache et max_connections doivent également être pris en compte.

Voici quelque chose qui peut vous aider:

http://www.mysqlperformanceblog.com/2006/09/29/what-to-tune-in-mysql-server-after-installation/ http://www.mysqlperformanceblog.com/2007/11/01/innodb- optimisation des performances-bases / http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/

ÉDITER:

Comme l'a dit @ drew010, il est important de considérer le type d'utilisation de la base de données. Le réglage pour une base de données de lecture intensive est très différent d'une écriture lourde. Vous pouvez également envisager d'autres stratégies. Comme Memcached, les bases de données nosql, etc.

— santiago.basulto
source

2

D'accord, ce sont de très petites bases de données trop relativement parlant. Si vous vous attendez à une tonne d'accès en lecture à la base de données, vous pouvez envisager une sorte de système de mise en cache comme memcached que votre application peut utiliser pour stocker des valeurs de la base de données afin de réduire les accès à la base de données. Si vous effectuez principalement des insertions, le disque sera un facteur très important. Dans une certaine mesure, la question dépend de vos cas d'utilisation. Si les données ne changent pas beaucoup, le cache de requêtes mysql devrait également aider beaucoup avec des requêtes plus rapides. Assurez-vous également que vos index / clés primaires sont bons.

— drew010

+1 vous avez raison frère. Je supposais qu'il demandait un réglage de base, mais il est important de considérer l'utilisation de la base de données et d'autres choses. Encore une fois, je ne peux pas en parler ici, je pense.

— santiago.basulto

1

Si vous devez être sûr que MySQL utilise toute la mémoire dont il a besoin, vous devez passer à InnoDB. À moins que vous n'utilisiez FULLTEXTles capacités de recherche MySQL , il n'y aura pas de problèmes graves.

Dans le cas de MyISAM, un certain nombre de caches sont mis en service, y compris les tampons de clés MySQL internes et le cache système. Si vous voulez les meilleures performances, vous devez laisser de la place à l'un ou l'autre des caches, mais je ne recommande pas MyISAM à cet effet, surtout si vos bases de données sont lourdes en écriture: MyISAM verrouille toute la table en écriture, tandis qu'InnoDB ne verrouille que les lignes affectées.

Même si vous mettez toutes vos bases de données en mémoire, vous pouvez toujours avoir des requêtes à exécution lente en raison d'index insuffisants ou pour d'autres raisons.

— sanmai
source