J'ai des problèmes avec un site Web avec 600 Mo de base de données MySQL. Le site Web est beaucoup trop lent. J'ai remarqué que plus la base de données MySQL est grande, plus elle ralentit. Quand il faisait 5 Mo, le site Web était très rapide. Quand il a commencé à grossir, il a commencé à devenir de plus en plus lent et maintenant, à 600 Mo, il est vraiment lent, prenant environ 10 secondes pour charger les pages.
J'ai vérifié les meilleurs processus et cela n'a rien à voir avec une charge élevée ou quoi que ce soit. Il n'est même pas lié aux IOPS car j'ai testé sur des disques durs de 7,2 k tr/min et cela a posé le même problème maintenant avec les tests avec des disques SSD Intel 320, donc je ne pense pas qu'il s'agisse de requêtes élevées.
Le site Web utilise Wordpress et il y a comme 9 plugins actifs. Les gens ont dit que ce pourrait être les plugins ... enfin peut-être ... mais pour le moment je veux juste mettre en cache toute la base de données en mémoire et aimerait obtenir de l'aide et des directives sur où commencer et comment le faire.
J'ai 16 Go RAM et i5-2400 4 cœurs @ 3,1 GHz. OS est centos 5.7
top - 07:23:57 up 9 days, 12:15, 0 users, load average: 0.09, 0.04, 0.05
Tasks: 162 total, 1 running, 161 sleeping, 0 stopped, 0 zombie
Cpu(s): 8.2%us, 1.0%sy, 0.0%ni, 90.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16367532k total, 3641628k used, 12725904k free, 612140k buffers
Swap: 1046520k total, 0k used, 1046520k free, 1538896k cached
Si j'étais vous, je basculerais toutes les données vers InnoDB. Le verrouillage de table/verrouillage de ligne a longtemps été discuté par beaucoup. Je choisirais toujours InnoDB haut la main. Cependant, il y a une autre raison profonde pour choisir InnoDB ... CACHING .
Alors que la plupart des gens se vantent que MyISAM est plus rapide pour les lectures, la plupart des gens oublient que les nombreux caches de MyISAM, appelés cache de clés (défini par key_buffer_size), ne mettent en cache que les pages d'index des fichiers .MYI. Il ne met jamais en cache les pages de données. Il a un maximum officiel de 4 Go dans les systèmes 32 bits. 8 Go est le meilleur maximum pour 64 bits.
Le pool de tampons InnoDB met en cache les pages de données et d'index. En fonction du serveur dont vous disposez, vous pouvez mettre en cache l'ensemble de données dans la RAM. Vous pouvez régler InnoDB jusqu'à 80% RAM et 10% pour les connexions DB, et laisser 10% pour le système d'exploitation. Cela est vrai même pour différents systèmes d'exploitation .
J'ai recommandé ces choses pour Drupal clients avec un merveilleux succès. Cela s'applique à Wordpress tout aussi bien. J'ai fourni un support DB pour les clients avec WordPress. Mêmes améliorations.
Vous pouvez toujours configurer la mémoire pour InnoDB plus efficacement que vous pouvez plus MyISAM. Il y a toujours un moyen de tweek InnoDB pour répondre à vos besoins de performance . Au fur et à mesure que vos données augmentent, elles finiront par devenir une exigence .
Si votre ensemble de données complet est suffisamment petit, vous pouvez exécuter une requête SELECT sur chaque table que vous avez juste après le démarrage de mysql.
Pour toutes les tables qui sont InnoDB et/ou MyISAM, exécutez cette requête:
SELECT DISTINCT
CONCAT('SELECT ',ndxcollist,' FROM ',
db,'.',tb,' ORDER BY ',ndxcollist,';') SelectQueryToLoadCache
FROM (
SELECT
engine,table_schema db,table_name tb,index_name,
GROUP_CONCAT(column_name ORDER BY seq_in_index) ndxcollist
FROM (
SELECT
B.engine,A.table_schema,A.table_name,
A.index_name,A.column_name,A.seq_in_index
FROM
information_schema.statistics A INNER JOIN
(SELECT engine,table_schema,table_name
FROM information_schema.tables
WHERE engine IN ('InnoDB','MyISAM')) B
USING (table_schema,table_name)
WHERE
B.table_schema NOT IN ('information_schema','mysql')
AND A.index_type <> 'FULLTEXT'
ORDER BY
table_schema,table_name,index_name,seq_in_index
) A
GROUP BY
table_schema,table_name,index_name
) AA
ORDER BY
engine DESC,db,tb
;
Cela produira toutes les requêtes SELECT possibles que vous devez exécuter et qui convoquera tous les index à référencer. Placez cette requête dans un fichier appelé /root/MakeSelectQueriesToLoad.sql. Exécutez le script et collectez la sortie /root/SelectQueriesToLoad.sql. Enfin, exécutez-le:
mysql -u... -p... -AN < /root/MakeSelectQueriesToLoad.sql > /root/SelectQueriesToLoad.sql
mysql -u... -p... < /root/SelectQueriesToLoad.sql
Cela préchargera certainement toutes les pages d'index dans le pool de tampons InnoDB et le cache de clés MyISAM. Si toutes vos données sont InnoDB, apportez deux modifications:
WHERE engine IN ('InnoDB','MyISAM')
par WHERE engine='InnoDB'
CONCAT('SELECT ',ndxcollist,' FROM ',
par CONCAT('SELECT * FROM ',
Cela remplira également plus de pages de données dans le pool de tampons InnoDB.
NOTE FINALE: Assurez-vous que le pool de tampons InnoDB est suffisamment grand pour contenir toutes vos données InnoDB
Vous mettez déjà en cache toute la base de données en mémoire. Le problème est presque certainement le temps qu'il faut pour rechercher la base de données, même en RAM.
Regardez les statistiques d'E/S de votre disque. Vous verrez probablement qu'il n'y a que quelques bits aléatoires d'E/S disque. La base de données est en mémoire. Ce n'est pas ça le problème. Vous devez d'abord installer iostat
. Vous ne mentionnez pas votre plate-forme ou distribution, mais c'est probablement dans un package appelé iostat
. Vous pouvez trouver atop
plus convivial.
Est-ce que les personnes qui vous ont dit cela après avoir obtenu des preuves que votre base de données entière n'était pas déjà en mémoire ou que les E/S du disque étaient le problème? Sinon, leurs conseils sont l'équivalent d'un médecin qui ne vous a jamais vu ou examiné, mais vient d'entendre que votre bras vous fait mal de vous dire de jeter un plâtre.