IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MySQL Discussion :

Problème de LOCK MySQL


Sujet :

MySQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Août 2007
    Messages
    20
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 20
    Par défaut Problème de LOCK MySQL
    Bonjour,

    J'aimerai avoir quelques conseils pour optimiser les performances de ma base de données.

    Voici déjà quelques statistiques sur les requêtes:
    Total : 81 M
    ø par heure : 145,07 k
    ø par minute : 2,42 k
    ø par seconde : 40,30


    Je suis souvent confronté à des blocages de mes requêtes (lock) car j'ai sur mon site un robot qui crawl des pages en continu pour mettre à jour le contenu vu par les utilisateurs du site.
    Donc la table principale du site est constamment assiégé de requête INSERT, SELECT, UPDATE etc...

    Pour essayer de ménager la table, je joue beaucoup avec les HIGH/LOW PRIORITY, INSERT DELAYED etc... Mais ce n'est pas suffisant, je suis obliger de restreindre l'accès du site aux spider voir même aux utilisateurs lorsque le nombre de thread mysql dépasse un certain nombre.
    Bref c'est vraiment du bidouillage et ce que j'aimerai c'est savoir si il n y aurai pas un moyen d'optimiser tous ça ?

    Je suis sur un MySQL 4.1.22, je n'ai pas encore passé sur MySQL 5 ou 5.4, y a t'il eu des évolutions qui pourrait régler mon souci ?

    Merci !

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 998
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 998
    Billets dans le blog
    6
    Par défaut
    L'optimisation commence par le modèle de données. Lisez les articles que j'ai écrit à ce sujet :
    http://sqlpro.developpez.com/optimisation/
    (bien que ces papiers soient écrit pour SQL Server ils sont valable quelque soit le SGBDR)
    Votre base respecte-elle les 3 premières forme normale ? Si non, n'espérez jamais des performances !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Août 2007
    Messages
    20
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 20
    Par défaut
    Merci, je vais lire les documents et vérifier que je n'est pas fait de boulette.

  4. #4
    Membre expérimenté
    Avatar de Tesing
    Profil pro
    Étudiant
    Inscrit en
    Septembre 2009
    Messages
    272
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : Septembre 2009
    Messages : 272
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Votre base respecte-elle les 3 premières forme normale ? Si non, n'espérez jamais des performances !
    Ca m'étonne, la normalisation nuit aux performances plutôt qu'autre chose, non ?
    Dans les Datawarehouses on évite de normaliser les tables car ca nuit aux performances.

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 998
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 998
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par FFFFFF-000000 Voir le message
    Ca m'étonne, la normalisation nuit aux performances plutôt qu'autre chose, non ?
    Dans les Datawarehouses on évite de normaliser les tables car ca nuit aux performances.
    Lisez l'article au lieu de dire des énormités pareilles ! A votre avis les bases de données relationnelles sont faites pour faire des relations ou des fichiers Cobol ?

    Pour un data warehouse le problème n'est pas du tout le même car :
    1) il n'y a pas de transaction puisqu'en principe il n'y a qu'un seul utilisateur qui met à jour
    2) le nombre de mise à jour concurrentielle est très faibles par rapport au nombre de lectures puisqu'en principe il n'y a qu'un écrivain
    3) cela répond à des besoins fonctionnels très différents de celui des applications de gestion.

    Je doute que vous fassiez un site web marchand en utilisant une structure décisionnelle pour vendre vos produits !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  6. #6
    Membre expérimenté
    Avatar de Tesing
    Profil pro
    Étudiant
    Inscrit en
    Septembre 2009
    Messages
    272
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : Septembre 2009
    Messages : 272
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Lisez l'article au lieu de dire des énormités pareilles !
    OK je vais y jeter un coup d'oeil..

    EDIT:

    Mais je ne dis pas d'énormités...

    La normalisation est efficace dans un contexte transactionnel intensif.

    Pour le web, ce n'est pas toujours le cas.

    Si vous avez l'esprit ouvert et un peu de temps :

    http://highscalability.com/scaling-s...eed-and-profit

    Flickr both denormalizes and duplicates data. Horror!
    Ebay is the most radical in moving almost all functionality out of the database and into the application.
    Plenty of Fish also advocates denormalization as a key strategy.

  7. #7
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 998
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 998
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par FFFFFF-000000 Voir le message
    Si vous avez l'esprit ouvert et un peu de temps :

    http://highscalability.com/scaling-s...eed-and-profit
    Dans cet article on lit les habituelles imbécilités comme : "The problem is joins are relatively slow..."
    C'est bien évidemment le contraire à condition de savoir utiliser les types de données judicieux et de savoir modéliser.

    Pour ma part je modélise des bases de données considérables (genre ERP) dans lequel les volumes attendus se mesurent en To et mes tables font en moyenne moins de 8 colonnes et mes requêtes plus de 10 jointures avec des performances tout à fait normales (quelques ms pour la plupart).

    Les seules dénormalisations parfois nécessaires sont effectuées non pas sur le modèle mais de manière interne au SGBDR à l'aide par exemples de vues indexées ou de partitionnement....

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. Problème de configuration MySQL Apache
    Par FredMines dans le forum Installation
    Réponses: 4
    Dernier message: 01/07/2005, 11h43
  2. Problème avec Ado, MySQL
    Par sylvain.g dans le forum Bases de données
    Réponses: 2
    Dernier message: 07/06/2005, 10h45
  3. problème démarrage serveur mysql
    Par vbcasimir dans le forum SQL Procédural
    Réponses: 6
    Dernier message: 25/04/2005, 14h14
  4. Problème sous requete MySQL
    Par gavelin dans le forum Langage SQL
    Réponses: 3
    Dernier message: 20/07/2004, 10h36
  5. problème de connection mysql par tcp/ip
    Par leroyphil dans le forum Administration
    Réponses: 5
    Dernier message: 04/09/2003, 18h27

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo