Limiter utilisation ressources mysql

Bonjour,

J'administre un serveur Centos qui héberge un backoffice avec PHP5/MySql5. Mon problème est que certaines pages sont très (très très très vraiment beaucoup) lourdes, cela bloque parfois le serveur.

Concrêtement, certaines pages font de très lourdes requêtes MySQL. Le processus mysql monopolise alors 100% des ressources pendant plus de 5 min (si si c'est possible, je savais pas avant de le voir non plus...) de sorte que les autres utilisateurs se retrouvent, même avec des pages très légères, complèment bloqués le temps que la grosse page ait fini sa requête.

J'ai bien trouvé des paramétrages pour limiter l'utilisation mémoire, mais ce que je recherche précisément serait de pouvoir limiter, pour un processus mysql, l'utilisation CPU à 50% par exemple (peu de risque que 2 utilisateurs ouvrent en même temps cette même page).

Y'a-t-il des configurations miracles pour ce faire ???

Pour qu'une requête dure plus de 5 minutes il faut qu'elle soit très complexe sur plusieurs tables avec un très grand nombre de données.

Ou alors c'est qu'il y a un problème :
- de modélisation des données ;
- d'indexation de tables ;
- de requête pas otpimisée.

Avant de penser à changer les paramètres du serveur, il faudrait peut-être déjà analyser ça ?

Oui effectivement, en fait c'est un peu délicat car c'est une page sur laquelle 5 types de recherche sont possible avec une même base, donc on construit une requête de base que des variables modifient suivant le type de recherche, ce qui explique que ce n'est pas optimisé. L'autre fait est que ça recherche sur beaucoup de données, de tête ça fait des jointures externes sur plusieurs tables, et sur plus de 600 lignes.

J'ai repris un développement déjà fait par d'autres, et carrément pas optimisé (j'ai réussi à tout bloquer quelques heures aussi aucune BDD du serveur ne réagissait plus...) sur du MySQL 3 et, pour limiter la casse en attendant de passer en MySQL 5 et de réécrire les principales requêtes, je voudrais juste empêcher pour l'instant la base de se bloquer (parce qu'on a un ecommerce derrière quand même) !

Citation:

---

Envoyé par rolintoucour

Oui effectivement, en fait c'est un peu délicat car c'est une page sur laquelle 5 types de recherche sont possible avec une même base, donc on construit une requête de base que des variables modifient suivant le type de recherche, ce qui explique que ce n'est pas optimisé.

---

Ben tu construis la requête dynamiquement en fonction des paramètres de recherche. C'est courant comme système !

Citation:

---

L'autre fait est que ça recherche sur beaucoup de données, de tête ça fait des jointures externes sur plusieurs tables, et sur plus de 600 lignes.

---

Lol ! C'est ridiculement petit ! :lol:
J'ai fait des requêtes avec des jointures sur des tables de plusieurs dizaines de millions de lignes avec une réponse en moins de 5 secondes, et sur un simple PC portable d'il y a 3 ans !

Citation:

---

sur du MySQL 3

---

Il est grand temps de migrer quand même ! 8O

Citation:

---

et, pour limiter la casse en attendant de passer en MySQL 5 et de réécrire les principales requêtes, je voudrais juste empêcher pour l'instant la base de se bloquer (parce qu'on a un ecommerce derrière quand même) !

---

Tu ne développes quand même pas sur le serveur de prod ? :aie:

Citation:

---

Envoyé par CinePhil

Ben tu construis la requête dynamiquement en fonction des paramètres de recherche. C'est courant comme système !

---

Oui mais là je rajoute 2 jointures externes sur 2 des paramètres, ce qui fout la merde !

Citation:

---

Envoyé par CinePhil

Lol ! C'est ridiculement petit ! :lol:
J'ai fait des requêtes avec des jointures sur des tables de plusieurs dizaines de millions de lignes avec une réponse en moins de 5 secondes, et sur un simple PC portable d'il y a 3 ans !

---

Les 600 lignes sont recherchées parmi 8000 autres, c'est juste sur la table principale... Après je regarderai les index c'est une bonne piste, mais les anciens développeurs avaient l'habitude de mettre des LEFT JOIN partout, ce qui est vachement moins optimal qu'un JOIN normal....

Citation:

---

Envoyé par CinePhil

sur du MySQL 3
Il est grand temps de migrer quand même ! 8O


Tu ne développes quand même pas sur le serveur de prod ? :aie:

---

....
....
Ils y a quelques années, le développeur bossait directement sur la base de prod, un suivant a eu la bonne idée de créé une BDD de test mais ça suffit pas... Je voudrais essayer de synchroniser 2 bases distantes plus tard mais je vois pas encore trop comment on fait (y'a un petit retard je crois avec la méthode traditionnelle)...

Pour en revenir à la question de départ, on peut pas limiter l'utilisation CPU d'un des processus ???

Je ne suis pas un expert comme CinePhil, mais ton problème ne viens pas de jointures.

Plus dans la construction de ta requête... tu pourrais nous montré une requête complète pour voir a quoi elle ressemble ?

Utilises tu des index également ?

Les requêtes ne sont certes pas optimisées, il y a bien des index mais tout le back-office rame beaucoup. Ca a été écris il y a 8 ans en partie et pas beaucoup mis à jour depuis...

Après en plus des requêtes qui puent, j'ai remarqué avec grande surprise quelque chose que je ne pensais pas possible. Si j'affiche l'ensemble des requêtes exécutée en chargeant des pages (j'utilise Smarty qui le permet facilement), sur toutes les pages y'a un demi-écran de requêtes SQL qui se lancent, donc à chaque action utilisateur le serveur prend un coup...

J'ai du mal à comprendre la logique (apparemment des ajustements faits dans des stocks et plein de contrôles), mais c'est surtout ça qui fait ramer je pense. Des pages dépassent l'écran de requêtes (sans saut à la ligne et en taille normale, si si).

Enfin bref, si je pouvais juste limiter les ressources utilisées par un utilisateur, qui a ralentir le chargement pour que ça dispatche mieux, ça serait aussi bien pour l'instant...