MySQL double chargement empêchant

Question

gars droit,

J'ai une base de données MySQL, en utilisant InnoDB sur les tables, tous si souvent je dois effectuer un gros travail de cron qui fait un grand lot de requêtes et inserts. Lorsque j'exécute ce travail cron, pendant les 5 minutes ou environ qu'il est en cours d'exécution, aucune autre page n'est en mesure de charger. Dès que cela est fait, les requêtes sont exécutées et la page se charge.

La table qui contient réellement toutes ces données n'est même pas interrogée par le site principal. C'est simplement que lorsque MySQL fait beaucoup de travail, le reste du site est intouchable. Cela ne doit sûrement pas être correct, qu'est-ce qui pourrait causer cela? L'utilisation du processeur pour les fusées MySQLD à des chiffres énormes comme 120% (!!!!!) et toutes les requêtes MySQL sont verrouillées.

Ce qui pourrait causer/réparer ceci?

Answer 1

Vous pouvez avoir un délai de script d'environ 1/10 seconde entre chaque requête. Cela prendra plus de temps mais permettra l'activité en arrière-plan.

sleep(0.1); 

Vous aurez probablement besoin de faire cela pour les écritures, les lectures sont très bon marché.

Answer 2

Non, c'est évidemment faux. Ceci est probablement lié à une mauvaise configuration. Jetez un oeil à la taille du pool de tampons innodb et voyez si elle peut être augmentée. Cela ressemble à un cas typique de pénurie de bélier. Les configurations saines ne sont presque jamais liées à un processeur, et certainement pas lors d'insertions en masse.

Answer 3

Avec InnoDB, d'autres choses devraient pouvoir accéder à la base de données. Êtes-vous prêt à montrer le schéma (ou partie pertinente de celui-ci) et les parties pertinentes de l'application?

Peut-être que c'est un problème de matériel.

Quelle est la taille des transactions que votre travail "cron" utilise? L'utilisation de minuscules transactions créera une quantité massive d'IO inutilement. Vos serveurs de base de données disposent-ils de contrôleurs RAID (dans l'hypothèse où vos serveurs utilisent des disques durs non SSD)? Sinon, les commits seront assez lents.

De combien de RAM est votre serveur de base de données? Si possible, assurez-vous qu'il est un peu plus grand que votre base de données et définissez innodb_buffer_pool à> taille des données - cela signifie que les charges de travail lues sortent de la mémoire RAM, ce qui devrait les rendre rapides. Pouvez-vous reproduire le problème dans un système de test sur du matériel de qualité de production?

Answer 4

Je pense que vous pourriez avoir besoin de repenser la façon dont vous construisez vos requêtes. InnoDB a des verrous au niveau de la page, mais avec des mises à jour massives, vous pouvez toujours verrouiller un bon nombre de vos requêtes. Postez vos requêtes actuelles et réessayez .. Je ne pense pas qu'il existe une solution générique pour une question générique comme celle-ci, alors essayez d'optimiser ce que vous faites aujourd'hui.