Journal Performance MYSQL

Posté par  (site web personnel) .
Étiquettes : aucune
4
9
juil.
2009
Bonjour,
Je viens sonder votre opinion pour un problème de performance.
J'explique ma situation :
J'utilise une base de données Mysql pour stocker les données de notre GPAO/ERP. Ces données sont lue par des programmes en Qt/C++ et stocké dans des tables MyIsam.
La base n'est pas énorme en gros la base fait 2Go et la plus grosse table fait 600Mo. Par contre on a un nombre énorme d'accès et de requêtes a la seconde. Et ces requêtes sont réparti a 50/50 en lecture et écriture.
Le serveur Mysql est un DELL avec un bi-XEON 2.8GHz, 2 giga de ram, 3 disques SCSI 15Ktr/min monté en RAID5.

En ce moment on fait face a un vrai problèmes de performances auquel on cherche des solutions.

c'est pour cela que je viens vous demander votre avis. Pour ce type de systèmes et sachant qu'on souhaite avoir une solution pérenne que prendriez vous comme matériel et que changeriez vous pour ne pas avoir a vous dire dans trois ans : "mince ca rame encore" et pour sentir un vrai gain de performance?

  • # Problème de clés ?

    Posté par  (site web personnel) . Évalué à 5.

    Est ce que les clés sont biens placées ?

    • [^] # Re: Problème de clés ?

      Posté par  (site web personnel) . Évalué à 3.

      Je dirais que non pour certaines d'entre elles. Mais pour la plupart oui.
      Notre problème vient essentiellement de la charge et du fait que nous avons énormément d'écriture qui verrouille les tables un peu trop longtemps.
      Bref certes une passe sur les clefs, les requetes lentes est nécessaire et sera faites. Mais ma question se portait plus sur la structure de notre base et ce qu'il faudrait changer pour l'améliorer autant en software qu'en hardware.

      PS : désolé d'avoir créer un journal mon doigt a ripper au moment de créer un post sur un forum.

      • [^] # Re: Problème de clés ?

        Posté par  . Évalué à 6.

        Ben, déjà une passe sur les index et l'utilisation du slow query log permettra de détecter pas mal de trucs, un EXPLAIN sur les requêtes les plus lentes permettra de détecter ce qui ne va pas (attention, les indexes ne sont pas toujours la bonne solution, si la cardinalité de la colonne est trop faible ça servira à rien)
        Ensuite il faut faire une passe sur le code de l'application et vérifier que tout ce qui peut être fait en SQL est fait en SQL et que seul le nécessaire est rapatrié. J'ai vu des applications avec des perfs pitoyables juste parce qu'elle ramenait 3x trop d'informations et filtraient "à la main", hors SGBD ou qui imbriquaient des boucles avec des requêtes au lieu de faire une bonne requête pour ramener les données puis les traiter.

        • [^] # Re: Problème de clés ?

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          On peut aussi optimiser en rassemblant les requêtes. Si par exemple on doit faire 3 insert à la suite sur la même table, rassembler tout ça en un seul insert.

          On peut aussi faire de la duplication d'informations (mais pas trop :-)). Par exemple, on affiche une liste de discussions, et on veut afficher pour chacune d'elles le nombre de reponses. Plutôt que de faire un count pour chaque discussion et/ou des group by , on pourrait mettre un champs qui contient le nombre de réponse, ça évite d'avoir à le "calculer" à chaque fois, ça évite les jointures. Certes, ça fait pas très propre pour un puriste, mais d'un point de vue pragmatique, ça permet d'améliorer les perfs.

          Et puis en mysql 5, on peut aussi utiliser les triggers. Alors si on doit effectuer des modifications sur d'autres tables quand on en modifie une, utiliser les triggers. ça évite de faire X requetes "à la main", et sera bien plus optimisé au niveau execution (et puis le code client sera plus propre). les triggers ça permet aussi de garder une cohérence dans le schema sans avoir toutes les rêgles de gestion en tête. Par exemple, lors de l'insertion d'une réponse dans la base, le trigger ira faire un update du champs "nombre de reponse" sur la discussion ;-).

          Bref, essayer d'optimiser au mieux le sql.

          • [^] # Re: Problème de clés ?

            Posté par  . Évalué à 3.

            Plutôt qu'un trigger, ne vaudrait-il mieux pas faire cela (insertion + mise à jour du compteur) dans une procédure stockée ? Le code SQL serait ainsi regroupée en un seul endroit.

            Mes connaissances en SQL étant loin d'être aussi poussées que celles de pas mal d'intervenants ici, je dis peut-être une connerie...

            • [^] # Re: Problème de clés ?

              Posté par  . Évalué à 2.

              [...]dans une procédure stockée[..]
              C'est le mieux pour pleins de raisons, plus facile par exemple le binding est fait simplement, gestion des dépendances (maintenance plus rapide), les parses sont minimisées etc..
              Je ne sais pas si toutes les bases implémentes tout ca, mais ca vaut le coup de regarder.

            • [^] # Re: Problème de clés ?

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              non, parce que ça veut dire que pour inserer les elements il faille explicitement appeler cette procédure stockée. Et ça veut donc dire que si, pour une raison ou une autre, à un moment il soit fait directement un insert dans la table, la procédure n'est pas appelée. Du coup, cohérence des données cassée.

              L'intérêt des triggers c'est que ça permet une implémentation beaucoup plus transparente de tes règles de gestion. Un développeur n'a pas à connaitre des dizaines de procédures stockées, et savoir quand il doit appeler une procédure ou quand il peut faire une requête directe sur la table. Avec un triigger, il fait son insert sans se soucier de rien du tout, et tout se fait automatiquement.

              Et on peut mettre aussi les applications au même plan que le développeur. Imagine plusieurs applications qui attaquent la même base (ça arrive très souvent dans les moyennes et grosses boites). Imaginons donc que l'on ait, en reprenant mon exemple, à ajouter un champs qui est calculé à l'insertion ou modification d'un enregistrement. Si je fais ça dans une procédure stockée, je vais devoir modifier aussi toutes les applis pour qu'elles appellent la procédure stockée plutôt que de faire leur insert. Avec un trigger, pas besoin, ça sera transparent pour elles.

              Note qu'un trigger peut appeler une procédure stockée. Et qu'une procédure stockée reste toutefois utile pour les problèmes plus complexe que de simple opération à exécuter sur des changements sur une table ou autre.

              • [^] # Re: Problème de clés ?

                Posté par  . Évalué à 3.

                Si tu crées une API (procédures stockés) personne n'aura les droits pour manipuler les données directement.
                Les triggers servent éventuellement à contourner temporairement des bugs, sinon leur utilisation entraine des gros problèmes de perf et niveau maintenant c'est pire que tout.

                • [^] # Re: Problème de clés ?

                  Posté par  (site web personnel, Mastodon) . Évalué à 3.

                  utiliser des triggers, c'est pas moins performant que de faire soit même les requêtes à partir du programme. Il faut bien évidement faire attention aux cascades que cela peut entrainer.

                  Mais utiliser un trigger pour mettre à jour une table après la modification d'une autre table, je ne vois pas en quoi c'est moins performant que de faire les deux requetes à la suite en php par exemple.


                  bon sinon, comme ton commentaire précédent, je n'ai pas tout compris, il manque des mots dans ta phrase. "et niveau maintenant " : tu voulais dire quoi ?

                  • [^] # Re: Problème de clés ?

                    Posté par  . Évalué à 2.

                    "bon sinon, comme ton commentaire précédent, je n'ai pas tout compris, il manque des mots dans ta phrase. "et niveau maintenant " : tu voulais dire quoi ?"
                    Je suppose qu'il fallait y lire "maintenance"...

  • # MyISAM, RAID 5

    Posté par  (Mastodon) . Évalué à 6.

    Si tu as beaucoup d'écritures, utiliser des tables MyISAM me semble être un très mauvais choix, les verrous étant au niveau de la table, ça limite énormément les possibilités de parallélisation.

    Autre problème : le RAID 5 n'est absolument pas adapté pour une base de données, il vaut beaucoup mieux investir dans un disque supplémentaire et passer en RAID 10. Ça donnera de bien meilleures performances (surtout en écriture), et une meilleure tolérance aux pannes.

    • [^] # Re: MyISAM, RAID 5

      Posté par  (site web personnel) . Évalué à 2.

      Pour les tables en innodb on fait des tests en ce moment meme pour voir si ca peut nous permettre de gagner en performance.
      Pour le Raid10 en effet je n'y avais pas pensé.
      Merci.

      • [^] # Re: MyISAM, RAID 5

        Posté par  . Évalué à 1.

        je pertinente:
        - solution rapide / pas chère, mais avec le moins de gain:
        RAID 10 avec le maximum de disques possibles, et éventuellement un peu de RAM en plus, au prix de ce que ça coûte...
        - solution pérenne, idéale: mettre un outil de prise de stat sur la DB pour voir les requêtes les plus gourmandes, les temps d'attente de l'instance, etc.... Mysql, connait pas, mais sur Oracle on a PERFSTAT

        • [^] # Re: MyISAM, RAID 5

          Posté par  (site web personnel) . Évalué à 2.

          Si la base fait 2Go, passer à plus de RAM actuellement à 2 Go, devrait beaucoup se voir non ?

          "La première sécurité est la liberté"

          • [^] # Re: MyISAM, RAID 5

            Posté par  . Évalué à 2.

            Pas du tout si le goulot d'étranglement se situe dans les IO. A moins d'avoir 4 Go de RAM et un buffer cache de 2 Go :) Mais ça me parait pas judicieux ....

            • [^] # Re: MyISAM, RAID 5

              Posté par  (site web personnel) . Évalué à 2.

              Je pensais à ça car la gestion d'un raid 5 introduit toujours des latences de fou, surtout si il y a des cycles de lecture/écriture. Si la RAM est pleine, cela doit bien bloquer au niveau IOs à cause des fifo trop petites pour absorber la latence.

              "La première sécurité est la liberté"

              • [^] # Re: MyISAM, RAID 5

                Posté par  . Évalué à 2.

                Je ne sais pas comment est géré le buffer cache sur linux, mais peut-être aurait-il intéret à réduire celui du système, et utiliser le cache de son SGBD et monter les FS oracle de façon à bypasser le cache, quitte à augmenter la zone de cache allouée au sGBD C'est possible sur certaisn OS mais je ne sais pas si c'est possible sur Linux.

                • [^] # Re: MyISAM, RAID 5

                  Posté par  (site web personnel) . Évalué à 1.

                  Sous Linux, il suffit que l'application demande explicitement à bypasser le cache kernel en utilisant les "direct I/O" (O_DIRECT sur le open(2)). Apparement, MySQL+InnoDB le permet avec "innodb_flush_method = O_DIRECT", je suppose qu'en cherchant un peu on peut trouver l'option pour les autres formats aussi.

                  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                  • [^] # Re: MyISAM, RAID 5

                    Posté par  . Évalué à 2.

                    Sur HP-UX par exemple, tu peux spécifier cette option au montage du FS (avec Vxfs au moins). Même si ton appli ne le spécifie pas, tu le bypasse quand même

                    Il faudrait que je regarde dans les pages man d'un mount_ext3 ou un truc du genre .... (quand j'aurai un linux sous la main).

            • [^] # Re: MyISAM, RAID 5

              Posté par  . Évalué à 2.

              Une base de 2 GO qui est a peu près uniformément lue ne tient dans 2 Go de RAM. Ca veut dire que même des select consomment des IO alors que si la base tenait entièrement en RAM, beaucoup de select ne consommeraient plus d'IO.

              Le 2eme point, c'est qu'une table de 600 Mo, c'est couteux. Ca fait des indexs importants à parcourir et à rééquilibrer en cas d'insert. C'est ptet le moment de penser à un partitionnement applicatif.

              Petite remarque à part : un bi-xeon avec 2 Go de ram, c'est comme une porsche avec des pneux de twingo : ça m'étonnerait pas que le moteur soit sous exploité ;-)

              Et pour savoir ce qu'il faut pour dans 3 ans, il serait interressant de connaitre le rythme de croissance de la base ? 1 Mo par mois ou 300 Mo par mois ?

        • [^] # Re: MyISAM, RAID 5

          Posté par  . Évalué à 1.

          J'ajouterais que si c'est de la perf que tu cherches, envisage une solution RAID hardware avec cache intégré au controleur.

          • [^] # Re: MyISAM, RAID 5

            Posté par  . Évalué à 2.

            La dernière fois (~2ans) que j'ai regardé, le rapport performance/sécurité/prix était très très mauvais (sachant que je comptais 2 fois le prix de la carte pour avoir un spare).

            Avec la montée en puissance permanentes des proc, le raid soft (avec de bons disques/contrôleurs) devrait toujours avoir l"avantage, mais je prends toute analyse récente.

            • [^] # Re: MyISAM, RAID 5

              Posté par  (Mastodon) . Évalué à 2.

              En RAID 10, je suis d'accord avec toi, je pense que le hard n'apporte pas grand chose.

              Pour du RAID 5, le calcul des informations de parité reste couteux, et un contrôleur avec un gros cache peut aussi considérablement réduire les I/O nécessaires, donc j'aurais tendance à favoriser la solution hardware.

              • [^] # Re: MyISAM, RAID 5

                Posté par  (site web personnel) . Évalué à 2.

                Sauf qu'il existe plein de monde pour dire que le raid 5 ne sert à rien. Il couvre bien trop peu de cas de panne réelle pour être utile et coute très très chère. Un raid 1 c'est vraiment plus fiable et pas besoin d'un énorme cache avec batterie pour conserver les données correctement.

                "La première sécurité est la liberté"

                • [^] # Re: MyISAM, RAID 5

                  Posté par  (Mastodon) . Évalué à 2.

                  Le RAID 5 ne sert pas à rien, il reste utile dans le cas où la quantité d'espace disque disponible est plus important que les performances ou la sécurité. Un exemple typique, ça serait un miroir de FTP publics.

                  Mais si tu relis mes commentaires, tu verras que je suis le premier à dire que ce n'est pas adapté pour une base de données.

            • [^] # Re: MyISAM, RAID 5

              Posté par  . Évalué à 2.

              Je ne suis pas convaincu du tout .... La gestion du cache IO n'est pas négligeable, et dans le cas de besoin de performances, tu allèges ta machine. Avoir un controleur hard avec cache géré par le controleur c'est bien mieux.. Je dis pas ça inocemment, j'ai à gérer des serveurs qui demandent de la perf sur des baies SAN, et on voit une grosse différence lorsqu'on passe une appli sur une baie ayant un cache plus important ...

              • [^] # Re: MyISAM, RAID 5

                Posté par  (site web personnel) . Évalué à 2.

                Et si les données des serveurs étaient sur les serveurs en question en local, cela serait sans doute encore plus rapide.

                "La première sécurité est la liberté"

                • [^] # Re: MyISAM, RAID 5

                  Posté par  . Évalué à 2.

                  ... modulo l'inertie des disques ..... et c'est la que le cache hardware peut aider ... .Cela dit 150 To en local ....

                  • [^] # Re: MyISAM, RAID 5

                    Posté par  (site web personnel) . Évalué à 2.

                    certe :) Disons sur une grappe de machine pas chère dans une armoire ? (genre avec 4to par machine, cela fait 40 machines) Faut-il encore avoir un SGBD qui se découpe correctement :)

                    "La première sécurité est la liberté"

                    • [^] # Re: MyISAM, RAID 5

                      Posté par  . Évalué à 2.

                      Je pense qu'à ce niveau il y aurait peut-être des problèmes de contention réseau, vu la façon dont la base est sollicitée .... Cela dit je serais très curieux de voir ça, parce que modulo une réorganisation des tables de la BDD, le reste de l'archi pourrait le permettre (mais à quel prix ????) ....

                      Je pense que si cette appli était codée aujourd'hui c'est dans cette voie que l'on partirait.

    • [^] # Re: MyISAM, RAID 5

      Posté par  (site web personnel) . Évalué à 1.

      Si le serveur est dédié à la DB, en plus de InnoDB et de vérifier que les requetes tirent bien partie des transactions (genre des insert en boucle avec un auto commit apres chaque insert), je ferais 2/3 tests avec le scheduler IO NOOP.

  • # Call Center LinuxFR

    Posté par  . Évalué à 8.

    » En ce moment on fait face a un vrai problèmes de performances auquel on cherche des solutions.

    Si déjà tu nous disais ce qu'il y va pas concrètement;
    Parce que moi le « j'ai un problème de perf » ca me dit absolument rien.

    Commence déjà par des chiffres ...

    • [^] # Re: Call Center LinuxFR

      Posté par  (site web personnel) . Évalué à 1.

      Disons que quand je parle de probléme de performance c'est du ressenti. On lance un logiciel qui met deux secondes a trouver une référence, et par moment il reste bloqué plus de 10 secondes pour faire la même chose.
      Après au niveau des chiffres je dirais que quand je regarde le nombre de requête par secondes, par moment on a du 800requetes/sec au mieux et une moyenne a 400, par contre parfois on descend a moins de 100 requêtes par secondes traitée par le serveur et ca pendant 30 secondes.
      Et en dehors du fait qu'on ait que 2 giga que ram et que celle ci soit utilisé a fond on ne voit aucune autre raison.

  • # RAM limite ?

    Posté par  (site web personnel) . Évalué à 3.

    La base fait 2go, et le serveur n'a que 2 go de RAM...

    Je ne suis pas du tout un spécialiste MySQL, mais j'imagine qu'il doit faire pas mal d'aller-retours HD/RAM dans ce genre de cas, non ?

    • [^] # Re: RAM limite ?

      Posté par  . Évalué à 8.

      Euh ... J'ai ici au taf un serveur avec 150 To de base au cul, est-ce à dire que je dois lui donner 150 To de RAM ?

      • [^] # Re: RAM limite ?

        Posté par  . Évalué à 2.

        Regarde le fonctionnement de MySQL (ISAM ou innodb) tu seras moins surpris.
        Un nouveau moteur en gestation pour MySQL devrait pouvoir considérablement arranger les choses.

        • [^] # Re: RAM limite ?

          Posté par  . Évalué à 2.

          Je n'ai pas regardé mais ce que t me dis ne m'encourage pas à utiliser MySQL (je n'étais déjà pas trop chaud d'avance pour l'utiliser mais la tu ne fais que me convaincre davantage).

          Ca confirme bien ce que je pensais : PHP+MySQL = outils pourris juste bon a faire tenir un pauvre blog ou un petit site perso ....

          • [^] # Re: RAM limite ?

            Posté par  (site web personnel) . Évalué à 2.

            Sans vouloir troller, je me suis rendu compte de cet état de fait lorsque j'ai migré une base de 10Go de MySQL vers PostgreSQL.

            Depuis, il n'y a pas photo, avec 4 fois moins de RAM consommée par le SGBD, j'obtiens les même perfs sans tuning particulier.

            • [^] # Re: RAM limite ?

              Posté par  . Évalué à 2.

              > Depuis, il n'y a pas photo, avec 4 fois moins de RAM consommée par le SGBD, j'obtiens les même perfs sans tuning particulier.

              En même temps, c'est assez normal : MySQL alloue explicitement de la RAM pour gérer lui-même son cache (du moins avec InnoDB, et à hauteur de ce que l'admin à configuré), tandis que PostgreSQL laisse l'OS gérer ce cache, (Linux utilisera la RAM libre dispo pour cacher les données utilisées par PG, mais cette utilisation ne sera pas "imputée" à PG, pas comptabilisée dans top/ps/...). Autrement dit : si tu utilisais la RAM ainsi "libérée" pour d'autres applis, ou enlevait les barrettes "superflues", les performances chuteraient vraisemblablement (sauf si application peu sensible à la qté de ram).

      • [^] # Re: RAM limite ?

        Posté par  . Évalué à 2.

        >Euh ... J'ai ici au taf un serveur avec 150 To de base au cul, est-ce à dire que je dois lui donner 150 To de RAM ?

        Est-ce à dire que tu penses que faire tourner ton serveur avec 256 Mo de RAM n'aura pas d'impact sur ses performances ;-) ?

        Le cas ici est simple : il est possible de faire tenir l'ensemble des données en ram. C'est pas difficile d'ajouter 2 Go. Au pire l'entreprise a perdu 40 €. Au mieux y'a tout un tas de select qui ne seront plus dépendant des disques durs.

        • [^] # Re: RAM limite ?

          Posté par  . Évalué à 3.

          Est-ce à dire que tu penses que faire tourner ton serveur avec 256 Mo de RAM n'aura pas d'impact sur ses performances ;-) ?
          Bine sur que si, mais dans le cas qui nous intéresse je suis convaincu que 2 Go sont suffisants et qu'ajouter de la RAM, ce n'est pas une soluion viable dans le temps .... Toute base est ammenée à évoluer, et ajouter de la RAM juste pour pallier une déficience autre n'est pas une solution : c'est à long terme se trainer un boulet .....

  • # Diagnostic difficile

    Posté par  (site web personnel) . Évalué à 5.

    Avec les bases de données les problèmes de lenteur peuvent venir d'un très grand nombre de causes. Question taille de la base, le nombre d'octets ne signifie pas grand chose, ça va plutôt être le nombre d'enregistrements qui va être déterminant. Quelques pistes :

    Il faut bien séparer la lecture et l'écriture (qui sont de nature totalement différente pour les BDD) et savoir laquelle est lente. Une optimisation de la lecture a tendance à dégrader l'écriture et vice versa.

    Souvent, il s'agit de quelques requêtes en lecture qui ralentissent tout. Ça peut se guérir par l'ajout d'indexes bien placés ou la réécriture des requêtes.

    Inversement, si c'est l'écriture qui est lente, ça peut être dû à un excès d'indexes (il faut écrire dans la table et dans chacun des indexes).

    S'il y a déjà beaucoup d'indexes, comme il y a beaucoup d'écriture, il peut y avoir un problème de déséquilibre des indexes. Pour faire simple, c'est un peu comme la fragmentation des disques. Il existe des opération rééquilibrant les indexes (la plus brutale, supprimer l'index et le recréer).

    Il faut aussi vérifier que c'est bien programmé. Si le programme rapatrie toute la base à chaque requête, c'est le réseau qui doit pécher.

    J'ai souvent entendu dire que MySQL était bon en lecture mais pas en écriture. C'est à vérifier, mais pas facile de tester une autre base comme ça (en fait j'ai travaillé longtemps avec Oracle mais chaque base est spécifique).

    Autre chose, il est souvent bon de répartir les données accédées simultanément sur plusieurs disques. Par exemple, la table sur un disque et son index sur un autre. Ainsi on gagne beaucoup en temps d'aller retour table-index.

    Peut être que MySQL possède des outils de monitoring qui peuvent te renseigner sur ce sur quoi elle dépense son temps.

    C'était quelques pistes mais c'est quasiment impossible de diagnostiquer un problème de performance sans une quantité monstrueuse de données.

  • # Ah les perfs mysql

    Posté par  . Évalué à 2.

    Comme a très bien résumé Pyrollo les pb de performances sur une base de données sont très liés au code et peuvent venir de maints endroits.

    Je suppose que tu ne maistrise pas le code donc :
    1 - Soit tu achetes un monstre de guerre
    2 - Soit tu essayes de tuner

    Dans ce cas, regarde les indicateurs de ton serveurs (utilisation cpu/disque/RAM ...), tu pourras voir ou se trouve le bottleneck.
    Parfois ce n'est pas la CPU qui pose pb.

    log les slow-query dans mysql (+ explain SQL + optimize table + rebuild index) ..., tune tes buffer et autre, met tes tables temp en RAM etc ...

    Une autre alternative est de purger tes données. En effet bien souvent on garde des données dans les bases qui ne sont quasiment jamais consultées.
    Les extraire en les copiant dans une autre base peut etre tres benefique à ton server.

    Ta config me semble correcte pour une base de cette taille donc il y a peut etre des choses à faire pour améliorer les perfs.

  • # tuning primer

    Posté par  . Évalué à 4.

    Salut,

    Tu peux aussi regarder au niveau des buffers de mysql...
    Par exemple si ton buffer d'index est trop petit, les accès disques risquent de beaucoup pénaliser les lectures.
    Il y a beaucoup de paramètres de configuration de mysql qui peuvent influencer les performances ... difficile de les lister ici.

    Il existe un script sh simple, réalisé par un dev de mysql, qui permet de faire un audit rapide des bases et quelques précos de tuning: tuning primer -> http://forge.mysql.com/projects/project.php?id=44

    Johann

  • # mysqltuner.pl

    Posté par  . Évalué à 3.

    à executer sur la base qui a un peu vécu ...

    http://mysqltuner.com/mysqltuner.pl

    Pour jouer sur le paramétrage des tailles de buffer, zone memoire, etc ...

    Dam

  • # Personne pour le faire ?

    Posté par  . Évalué à -4.

    Bon, puisque personne ne veut le faire, je vais assumer le role du gros-con-bien-relou :

    Post FORUM !



    Et voila, c'est fait !

    Si vous avez besoin d'autres prestations de ce genre, je suis à votre service !

  • # réplication master/master

    Posté par  . Évalué à 1.

    Après il y a des solution de réplication (même en master/master) pour étaller la charge sur N serveurs :

    Elles ont été pas mal détaillées il n'y a pas si longtemps dans cette dépêche :

    http://linuxfr.org/2009/06/18/25620.html

    J'aime beaucoup celle qui joue sur les increment des autoindent ... très original. ( http://linuxfr.org/2009/06/18/25620.html#1041871 )

    Dam

    • [^] # Re: réplication master/master

      Posté par  (site web personnel) . Évalué à 2.

      A force de lire des docs google, j'aurais tendance à vouloir utiliser leur téchnique : prendre le meilleur rapport qualité prix, en gros qq serveurs quadricore mono cpu pas trop chère en SATA avec des disques en RAID 10 (4?) avec 3 Go de ram.

      Combien on peut avoir de serveur sata mono-socket pour le prix d'un monstre avec disque à 15k ?

      En plus, dans 2 ans, si cela rame, il suffit de rajouter un serveur (et de virer la machine la plus ancienne).

      "La première sécurité est la liberté"

      • [^] # Re: réplication master/master

        Posté par  (site web personnel) . Évalué à 2.

        D'ailleurs avec une base aussi petite, l'utilisation d'un SSD "moderne" pourrait améliorer les choses (gamme Vertex de chez OCZ et la gamme pro de chez Intel).

        "La première sécurité est la liberté"

        • [^] # Re: réplication master/master

          Posté par  . Évalué à 1.

          Ouaip, ou un petit jouet genre http://www.dvnation.com/Fusion-IO-IODrive-SSD-Solid-State-Di(...) , un peu cher, mais de sacres perfs :+)

          • [^] # Re: réplication master/master

            Posté par  (site web personnel) . Évalué à 2.

            IOPS (WRITE) 96,000 (sustained 4K random writes)

            C'est aussi un prix n'ayant plus rien à voir avec un SSD:) Je crois qu'un bon SSD, c'est une centaine d'IO en écriture de 4 Ko...

            "La première sécurité est la liberté"

            • [^] # Re: réplication master/master

              Posté par  . Évalué à 1.

              Tout a fait, mais dans qqe annees ca aura un prix tout a fait decent, et je me demandes bien quel impact cela va avoir. Si ce genre de jouets se democratise, la frontiere entre disque dur et RAM va serieusement s'affaiblire.

              • [^] # Re: réplication master/master

                Posté par  (site web personnel) . Évalué à 2.

                D'ailleurs, je ne comprends pas pourquoi cela n'existe pas plus.

                La différence, c'est de remplacer le lien sata sur les contrôleurs de SSD par un lien PCI-express. Au pire tu peux faire une fusion d'un controlleur SATA et d'un controlleur de SSD.

                M'enfin, le mieux serait d'avoir n canaux de mémoire flash sur le chipset avec l'OS qui se débrouille plutot que d'avoir des traductions vers le sata qui empêche de voir les tailles de secteurs et autre contrainte. A la limite, une sorte de gestion de pagination hardware pourrait être utile pour faire de la lecture rapide en cas de wear leveling mais l'algo de placement devrait rester dans l'OS.

                M'enfin, un SSD intel dispose de 10 canaux, cela fait pas mal de pin même pour des données sur 16 bits. On aurait donc un lien chipset<->flash comme il y avait un lien chipset<->ram.

                Le plus simple serait d'avoir une interface vaguement standard vers ce type de contrôleur.

                Mais bon on aurait toujours qu'une centaine de Go en flash, il y aurait toujours les disque en To pour stocker les rip de BR.

                "La première sécurité est la liberté"

                • [^] # Stockage en RAM

                  Posté par  . Évalué à 1.

                  > D'ailleurs, je ne comprends pas pourquoi cela n'existe pas plus.

                  J'aurais tendance à dire de façon provocatrice : parce que ce n'est peut-être pas si utile que ça :)

                  Ou plus exactement : parce que les solutions actuelles et éprouvées se rapprochent de ce que peuvent fournir les solutions de stockage RAM+BBU :

                  - Pour les lectures : la RAM "centrale" de la machine produit les mêmes effets car elle est exploitée par le page cache de l'OS ; de plus elle peut être utilisée pour d'autres choses en cas de besoin de l'OS ou des applications. Dans le cas de MySQL par ex., le buffer_pool_cache d'InnoDB est nettement plus rapide d'accès que le cache de l'OS (et probablement, qu'un accès via stockage de masse "ram-based") parce qu'il est "sur mesure" et n'impose pas de passer par la conversion en requètes de lecture/écriture et les diverses couches scsi/block/io_scheduler/... de l'OS pour atteindre les données. Ce n'est généralement pas protégée par batterie, mais ce n'est pas critique (ormi la dégradation initiale des perfs lors d'un cold boot, le temps que le cache de l'OS ou de l'appli se remplisse).

                  - Pour les écritures, il y a la RAM dans le contrôleur RAID (protégée par BBU). Si elle est de taille suffisante, elle permet souvent d'agréger suffisamment les I/O aléatoire pour s'approcher du débit linéaire du stockage de masse (ce qui est quand même pas mal, le débit linéaire d'un simple agrégat de 4 disques SAS 15krpm en RAID 10 est honorable de nos jours).

                  En comparaison, le SSD reste intéressant pour les machines ne pouvant intégrer suffisamment de RAM (par ex. les desktop ou serveurs installés en 32 bits), de contrôleur raid moderne (ditto). Et aussi (surtout) pour des questions de place et d'économie d'énergie : les disques durs, ça suce.

                  • [^] # Re: Stockage en RAM

                    Posté par  (site web personnel) . Évalué à 2.

                    Tu es en train de me raconter que la RAM, c'est bien pour faire du cache. Ben, c'est évident. Mais il est encore difficile d'imaginer des PC avec plus de 64 go de RAM, et cela coute d'ailleurs une véritable fortune.

                    Ensuite, pour les écritures, que cela soit de la RAM sur une carte IO ou de la RAM sur la carte contrôleur, cela reste de la RAM. Rajouter une carte spécialisé décharge le processeur mais à quel prix !

                    De plus comparer des disques dur avec un fusio-io (pas un SSD!), je crois que l'on ne parle pas vraiment de la même chose. On parle de centaine IO par seconde pour un disque sata, sans doute un peu plus pour un disque SAS.

                    Le fusion IO propose presque 100 000 IO en écriture 4k, ce qui représente le pire cas. Ce n'est pas le même monde.

                    "La première sécurité est la liberté"

                    • [^] # Re: Stockage en RAM

                      Posté par  (Mastodon) . Évalué à 2.

                      Tu es en train de me raconter que la RAM, c'est bien pour faire du cache. Ben, c'est évident. Mais il est encore difficile d'imaginer des PC avec plus de 64 go de RAM, et cela coute d'ailleurs une véritable fortune.

                      On parle de base de donnée et de serveur. Un serveur avec 64Go ça se trouve sur le marché et ce n'est pas très cher.

                    • [^] # Re: Stockage en RAM

                      Posté par  . Évalué à 2.

                      > Tu es en train de me raconter que la RAM, c'est bien pour faire du cache. Ben, c'est évident. Mais il est encore difficile d'imaginer des PC avec plus de 64 go de RAM, et cela coute d'ailleurs une véritable fortune.

                      De fait, une solution de stockage de masse ultra rapide de plus de 64 GB coute une fortune, qu'il s'agisse de SSD pro, d'un IOdrive, ou de solution persistante "ram based" (= où il faut de toutes façons, là aussi, payer pour la quantité de ram).

                      En revanche l'OS (ou l'applicatif, s'il est bien fait) cachera les pages "chaudes", réellement utilisées/accédées et beaucoup moins les données "mortes", ce qui permet parfois d'avoir de bonnes performances avec une quantité de ram largement inférieure aux jeux de données complètes sur disque dur (tandis qu'une solution de stockage totalement en ram sans autre forme de persistance doit pouvoir stocker tout le jeux de données).

                      Mais tu as raison d'amener cette question dans la discussion : c'est vraiment le prix, en terme de rentabilité par IOPS, en ne négligeant pas l'état de l'art des matériels classiques (controlleurs raid, chipsets de CM, RAM), et en prenant en compte les couts indirects (dont la conso électrique) qui fera la différence. Certains ce sont amusés à calculer les rapports performances/prix SSD vs. raid matériel sous diverses charges de benchmarks SQL typiques, et à l'heure actuelle les résultats ne sont pas encore univoques.

                      > De plus comparer des disques dur avec un fusio-io (pas un SSD!), je crois que l'on ne parle pas vraiment de la même chose.
                      > Le fusion IO propose presque 100 000 IO en écriture 4k, ce qui représente le pire cas. Ce n'est pas le même monde.

                      Oui pardon, je répondais au « pourquoi "ce genre de jouets" n'existe pas plus » en extrapolant aux solutions SSD et RAM+BBU (I-RAM, RAMSAN & co) en général (et non aux résultats épatants* de l'IOdrive).

                      Cela étant : je comparais les solutions classiques en général vs. les solutions alternatives modernes "en général", mais je ne compare pas "un SSD" ou juste "des disques durs" au FusioIO, j'indiquais justement que dans ce type de comparatifs qu'il ne faut pas négliger le write-cache des controlleurs RAID modernes, et la qté de ram qu'on peux coller pour pas cher. Ces derniers permettent d'élever considérablement les IOPS sur les données chaudes, et on (nous autres les geeks technophiles ;) a souvent tendance à oublier de les prendre en compte dans les comparaisons avec les nouveaux produits exitants comme l'IOdrive de FusionIO.

                      Le iodrive coute la bagatelle de 3000$ pour 80 GB (et 14 000$ pour le 320 GB) : pour ce prix, on peux mettre en place un _gros_ système RAID encaissant un bon paquet d'I/O ! Une machine avec controlleur RAID récent (par ex. avec 1 GB de RAM + BBU, qui permet d'aggréger un bon paquet d'I/O de lui même), et 10 disques 15 krpm en RAID 10 derrière (pour se répartir le reste des I/O non agrégées) offre de bonnes performances, un bon volume de stockage - et de la redondance/résistance aux pannes.

                      Bref, les produits FusioIO sont surement idéals pour certains types d'utilisation, mais pas encore la solution miracle.

                      * FusionIO au sujet duquel j'aimerai pointer ceci :
                      http://www.mysqlperformanceblog.com/2009/06/15/testing-fusio(...)

                      Autrement ce joli joujou ment à l'OS et ne synchronise pas réellement les données lorsqu'on lui demande, ce qui est dangereux parce qu'il n'est pas protégé par une BBU (à la différence d'un controlleur RAID correct). Il fournis néanmoins un mode de configuration permettant de forcer les sync() à être honnorés, et dans ces conditions les performances sont considérablement réduites. (et puis les 100 kIOPS, c'est les données constructeur hein ;).

                      • [^] # Re: Stockage en RAM

                        Posté par  (site web personnel) . Évalué à 2.

                        A choisir de mettre 500€ de matos en plus, je pencherais pour de la ram plutot qu'une carte raid avec BBU. Même si les prix sont tombés par rapport à une autre époque. (d'ailleurs, cela ne coute pas moins chère de mettre un petit APS à coté du serveur qui provoque un fsync clean avant que la batterie sois complètement vide ?)

                        "La première sécurité est la liberté"

                        • [^] # Re: Stockage en RAM

                          Posté par  . Évalué à 2.

                          > A choisir de mettre 500€ de matos en plus, je pencherais pour de la ram plutot qu'une carte raid avec BBU. Même si les prix sont tombés par rapport à une autre époque. (d'ailleurs, cela ne coute pas moins chère de mettre un petit APS à coté du serveur qui provoque un fsync clean avant que la batterie sois complètement vide ?)

                          Pour rester sur ma ligne "à cette heure il n'y a pas une solution qui les écrase toutes" ;) :
                          je crois que c'est vraiment un choix (sur quel type de matos flamber le budtet) qui doit se faire au cas par cas, selon les besoins de l'appli.

                          Par exemple pour reprendre tes suggestions citées juste au dessus (qui peuvent être bien pertinentes dans certains cas) :

                          * La RAM (dans l'OS) est principalement mise à profit pour réduire les lectures (ok, et les écritures si elles sont asynchrones, généralement pas le cas des SGBD). Donc très profitable pour une appli faisant beaucoup de lecture.

                          * Il y a des cas où augmenter la RAM n'apporte rien de significatif (par ex. si on a déjà 32 GB de RAM pour une bdd de 20 GB)

                          * Le couple cache_controlleur+BBU n'est pas tout à fait équivalent/remplaçable par une UPS :

                          - Il termine ses écritures même en cas de crash et arrets de l'OS, pas seulement en cas de pannes electriques. Ca signifie que même avec du writecache une transaction validée sera vraiment stockée, ce qui peux être - ou pas - une nécessité, selon le type d'appli. Dans le cas d'un système avec UPS : soit on écrit de façon synchrone (mauvaises perfs en écritures random), soit on prends le risque de valider des écritures non persistées (écritures async => utilisation du page cache de l'os => pertes en cas de crash). Ca protège aussi des problèmes de cables qui "se débranchent" (que le premier qui a bossé en salle serveur me jette la pière ;).

                          - La BBU permet d'activer le mode writeback du cache en écriture du controlleur (ces derniers le désactivent en général automatiquement en l'absence de BBU, pour ne pas perdre les données sales en cache en attente d'aggregation et d'envois vers les disques)

                          - Les controlleurs connaissent bien le layout physiques des disques, et s'ils sont dotés d'un cache (et qu'ils peuvent l'exploiter, donc d'une BBU), ils savent (plus ou moins) balancer les écritures de façon optimales sur les pools de disques disponibles. C'est aussi le cas du MD logiciel de Linux, mais n'est plus le cas s'il y a une couche LVM sur le MD.

                          * Tout ces questions ne sont pertinentes que pour une appli nécessitant beaucoup d'écritures random et synchrones ; il est clair qu'un logiciel dont le besoin premier est d'écrire, de façon asynchrone, de gros volumes de données a plutôt besoin d'une grosse bande passante.

                          • [^] # Re: Stockage en RAM

                            Posté par  (site web personnel) . Évalué à 2.

                            Concernant les BBU, les caches sur contrôleur et tout. Je comprends tout à fait le recourt au cache en écriture pour les accélérer.

                            Mais quel différence entre mettre la barrière de synchro au niveau de l'OS ou de tricher au niveau disque ?

                            J'ai l'impression que l'OS voyant des fsync() partout se sent obliger des les honorer rapidement, alors qu'il y en aurait pas besoin avec un APS.

                            D'ailleurs, cela va être pire avec les modifs du fsync() qui en place passe en priorité maintenant. Souvent on ne veut pas un fsync(), on veut un fdone().

                            "La première sécurité est la liberté"

                            • [^] # Re: Stockage en RAM

                              Posté par  . Évalué à 3.

                              > Mais quel différence entre mettre la barrière de synchro au niveau de l'OS ou de tricher au niveau disque ?

                              Je ne sais pas... mais il faut dire que je n'ai pas compris la question ;)

                              > J'ai l'impression que l'OS voyant des fsync() partout se sent obliger des les honorer rapidement, alors qu'il y en aurait pas besoin avec un APS.

                              Je réitère la remarque ci-dessus : s'il ne les honore pas, il perds des données qu'il a prétendu écrire en cas de crash système ou de cable d'alim (UPS ou pas). La panne électrique n'est pas le seul malheur qui peux frapper un serveur écrivant en asynchrone.

                              Avec ext3, l'intervalle par défaut de commit des dirty pages est de 5 secondes : ça peux représenter un bon paquet de transactions perdues...

                              Un autre aspect à évoquer : les SGBDS s'efforcent de garantir la persistance de toutes les données commitées (le D de ACID) via fsync() (et c'est bien ce qui les rends gourmands en IOPS). Mais en pratique, pour une application donnée, il n'est pas rare que ce besoin de garantie de persistance ne soit vraiment impérieux que pour une toute petite fraction des écritures. Par ex. sur une appli web de commerce, c'est souvent une garantie nécessaire lorsqu'un utilisateur valide un achat en ligne, souvent moins nécessaire lorsqu'il met à jour des infos sur son profile, poste un commentaire, lorsqu'on stocke les stats de visites par page, etc. (moins impérieux = au sens où on la perte de quelques minutes de données tout les un ou deux ans (interval de crash système) n'est pas un drame si elle permet en contrepartie de multiplier les perfs du système par 10). La tradition et les applications classiques utilisant un SGBD tendent à tout stocker de façon synchrone, sans distinction, ce qui est souvent un gros gaspillage de ressources les plus précieuses (les I/O), bien sûr.

                              D'où l'émergence de solutions mixtes (SGBD relationnel + stockage asynchrone), ou l'utilisation d'extensions comme le "insert delayed" de mysql (mais n'a pas d'équivalent pour update et delete)... Je rejoint donc ta remarque sur l'utilité d'une marge de tricherie en disant qu'il serait bien utile de pouvoir, transaction par transaction, indiquer à l'OS s'il doit vraiment honorer une écriture de façon synchrone ou pas. Les besoins d'une appli de type "web social" à fort traffic ne sont généralement pas exactement ceux d'un système bancaire.

              • [^] # Re: réplication master/master

                Posté par  (site web personnel) . Évalué à 2.

                Et nous aurons enfin droit à des systèmes qui bootent instantanément quel que soit l'OS utilisé.

      • [^] # Re: réplication master/master

        Posté par  (site web personnel) . Évalué à 1.

        Mouais.
        Le probléme c'est encore d'en avoir la possibilité.
        De notre coté c'est un seul serveur SQL faisant tourner une seule table SQL.
        Donc au final ca s'étale pas trés bien sur plusieurs serveurs (pour augmenter les perfs)

        • [^] # Re: réplication master/master

          Posté par  (site web personnel) . Évalué à 2.

          Et une bête répartition maitre/esclave ne ferait que répartir la lecture et non les écritures.

          Mais je ne comprends pas en quoi l'utilisation "d'une seule table SQL." empêche de faire du clustering.

          "La première sécurité est la liberté"

          • [^] # Re: réplication master/master

            Posté par  (site web personnel) . Évalué à 1.

            en rien mais visiblement d'après mes lecture et essai rapide le clustering SQL ne fait pas gagner énormément en performances mais plus en haute disponibilité et nécessite pas mal de matériel ( chaque serveur doit pouvoir stocker toute la base en RAM)

          • [^] # Re: réplication master/master

            Posté par  . Évalué à 3.

            Peut-être qu'il est là le problème : vous n'avez qu'une seule table ....

            En répartissant les donées dans plusieurs table ça irait peut être un peu mieux ....

      • [^] # Re: réplication master/master

        Posté par  . Évalué à 1.

        > En plus, dans 2 ans, si cela rame, il suffit de rajouter un serveur (et de virer la machine la plus ancienne).

        Certes, mais attention, la réplic va permettre sans effort :
        1- La haute disponibilité tout les accès (lectures et écritures) (le service ne s'interrompt pas si un serveur est en carafe ou en maintenance).
        2- La "scalabilité" horizontale des lectures (on ajoute un serveur et hop, le système encaisse plus de selects).

        En revanche il ne suffit pas d'ajouter des serveurs pour "scaler" les écritures, car tout les serveurs d'un même cluster doivent recevoir et appliquer toutes les requêtes en écriture (par opposition à la lecture qui peut-être dispatchée entre les machines), que ce soit directement depuis l'applicatif ou depuis un autre serveur du cluster via la réplication.

        Pour pouvoir répartir horizontalement les écritures, il faut faire des modifications généralement complexes et couteuses dans le code applicatif afin d'implémenter une forme de partitionnement horizontal/sharding (découper les tables et les assigner à des groupes/clusters de SGBD distincts, et se passer des jointures entre ces données distinctes, gérer les accès aux divers clusters selon le type de données ou les clefs de partitionnement, etc).

        Arrivé à ce point, et tant qu'à faire, il peut devenir plus intéressant d'envisager une solution plus moderne (et hype ;) de key-value store ou similaire, naturellement distribué (à la CoucheDB, Tokyo Cabinet et consorts).

  • # On va essayer de répondre....

    Posté par  . Évalué à 6.

    La seule information que l'on a est qu'il y a enormément de requètes. C'est maigre.
    Il va falloir d'autres informations :
    a) c'est quoi enormément ? 100/min 1000/min 1M/min ?
    b) c'est quoi comme requète ? Requètes simples ? Requètes complexes avec jointure aggregats et conditions ? Appel de procédures stoquées avec des fonctions des 12Mo ?
    c) Combien d'utilisateurs simultanés sur la base , typiquement ? En pointe ?
    d) Quel est le volume des données retournées ? (Non parceque si c'est systèmatiquement des centaines de milliers de tuples sur une connexion 100Mb/s ca va grincer même si tu mets un cluster Oracle)
    e) Combien de tables sont accédées typiquement ? 1 ? 10 ? 100

    Attention pub gratuite

    De façon générale il faut préférer Postgres à MySQL en cas de forte charge. MySQL est plus rapide sur les requètes simples sur de petites tables, mais il scale très mal et de plus il est assez loin des normes SQL (sans compter qu'il n'y a pas de méthode pour mettre en cluster simplement)

    • [^] # Re: On va essayer de répondre....

      Posté par  . Évalué à 5.

      80% des problèmes de perf SGBD dont j'ai entendu parler étaient soit une requête mal écrite (plus de la moitié des cas), soit un manque d'index. A chaque fois on vient demander à l'admin système de régler le pb .... alors qu'il n'y peut rien.

      • [^] # Re: On va essayer de répondre....

        Posté par  . Évalué à 10.

        80% des problèmes de perf SGBD dont j'ai entendu parler étaient soit une requête mal écrite (plus de la moitié des cas), soit un manque d'index. A chaque fois on vient demander à l'admin système de régler le pb .... alors qu'il n'y peut rien.

        Il peut toujours faire porter le chapeau à l'équipe réseau. Qui normalement devrait se lacher sur la sécurité. Laquelle sécurité ira voir l'équipe projet pour lui transmettre l'impossibilté de changer les règles pour une appli. De fait le projet ira voir les utilisateurs pour dire que la sécurité ne veut pas changer les règles qui permettrait d'avoir des perfs digne de ce nom.

        Généralement les utilisateurs remontent à la direction pour pleurer.
        a) La direction a autre chose à foutre -> le système reste lent
        b) La direction tape du poing sur la table -> Une des équipes mentionnées plus haut en prend plein la gueule (rarement l'équipe projet ceci dit, car elle a un bien meilleur positionnement politique au sein de la boite).

        Quand on en est à ce stade la seule solution est de faire un devis pour du matos démesurément puissant (Genre demander un switch fibre 10Gb/s 48 ports et le cablage qui va avec si ca tombe sur le réseau)

        Après ca varie... Mais c'est vrai que l'argument "On a acheté à la demande du projet un matos 40 fois trop puissant qui est sur un circuit à part et ca rame toujours" augmente grandement les chances que la foudre tombe enfin sur les developpeurs. Mais dans la plupart des cas la demande d'achat est refusée, et ca sert d'argument dans les discussions houleuses qui suivent...

    • [^] # Re: On va essayer de répondre....

      Posté par  (site web personnel) . Évalué à 1.

      Bonjour.
      Alors je vais essayer de répondre a ces questions :
      a) grosso modo on tourne a 300 requetes / secondes avec des piques a 1200.
      b)On a de tout au niveau des requetes, de la toute simple et de la trés compliqué avec 10 jointures et des dizaines de conditions. par contre pas de procédures stoquées. Par contre les jointures font qu'aucune division des tables pour les répartir sur plusieurs serveurs n'est visible.
      c) en moyenne une centaine.
      d) En analysant les sorties de la carte réseau elle est grandement sous utilisé la plupart du temps. Donc je pense pas que le ralentissement soit de ce coté.
      e) on a environ 200 tables qui sont quasiment en permanence toute utilisée.

      Pour postgreSQL a vrai dire on utilise mysql depuis trop longtemps pour pouvoir changer de base de donnée comme ca. Si aucune autre solution n'existe alors oui on le fera mais ca sera un dernier recours.

      Merci de votre aide.

      • [^] # Re: On va essayer de répondre....

        Posté par  . Évalué à 6.

        a) grosso modo on tourne a 300 requetes / secondes avec des piques a 1200.

        Normalement ca devrait passer à condition de ne pas réétablir une connexion à chaque requète. Valider avec les devs que les connexions restent ouvertes un moment et servent à plusieurs requètes. Ca pourrait même valoir le coup de passer sur du pooling un peu costaud (penser à augmenter la mémoire dans ce cas là genre 8GB)

        b)On a de tout au niveau des requetes, de la toute simple et de la trés compliqué avec 10 jointures et des dizaines de conditions. par contre pas de procédures stoquées. Par contre les jointures font qu'aucune division des tables pour les répartir sur plusieurs serveurs n'est visible.

        Sur les requètes complexes on y gagne souvent à faire des vues, voire des vues stoquées mise à jour à intervalle régulier. Mais bon les vues stoquées et MySQL ca fait pas bon ménage.

        c) en moyenne une centaine.
        Là on a un problème : ca n'est pas normal que 100 utilisateurs fassent 300 connexions/seconde en soutenu. Il y a des mises à jour en continue (genre raffraichissement des données toutes les 5 secondes) ? Parceque sinon il y a un truc à creuser là. Je pense qu'une bonne partie de la logique de traitements/de filtres a du se retrouver dans les applis plutôt que sur le serveur. Si ca peut limiter le nombre de requètes ou la taille des données renvoyées il vaut mieux passer par des procédures stoquées.

        e) on a environ 200 tables qui sont quasiment en permanence toute utilisée.
        Ca par contre c'est largement en dessous de ce que MySQL peut faire. Une fois de plus un boost de mémoire devrait aider. Et comme les tables doivent être assez volumineuses il peut être bon de passer sur un RAID 10 (en gardant du SCSI/SAS, le Sata en accès concurrents c'est pas çà )

        Pour postgreSQL a vrai dire on utilise mysql depuis trop longtemps pour pouvoir changer de base de donnée comme ca.

        Il ne devrait pas y avoir de gros problèmes à faire la migration, surtout si il n'y a pas de procédures stoquées. Par contre après tu auras beaucoup plus de flexibilité pour répartir la charge, analyser les goulots d'étranglement etc.

        Bref vu ta situation pas de solution miracle. Je pense qu'il y a un peu de ménage à faire au niveau du code car le nombre de requètes me parait disproportionné vu le nombre d'utilisateurs...

    • [^] # fanboyisme

      Posté par  . Évalué à 3.

      > De façon générale il faut préférer Postgres à MySQL en cas de forte charge [...] (sans compter qu'il n'y a pas de méthode pour mettre en cluster simplement)

      ENORME ! :)
      +1 point de mauvaise foi postgrefanboyiste, bien mérité dans ce cas :)

      La fameuse capacité de montée en charge et de mise en cluster/répartition horizontale de pg, qui fait qu'il est utilisé sur tout les gros LAMP connus comme wikipedia, youtube, yahoo, digg, livejournal, flickr, facebook, ...). heu,...

      • [^] # Re: fanboyisme

        Posté par  . Évalué à 2.

        La fameuse capacité de montée en charge et de mise en cluster/répartition horizontale de pg, qui fait qu'il est utilisé sur tout les gros LAMP connus

        Impossible ....
        Dans ce cas c'est du LAPP.

  • # 300 € HT

    Posté par  . Évalué à 2.

    Tu ajoutes 100 € de mémoire (4 Go) et 200 € de disque-dur (RAID 10) et ton problème est repoussé.

    Je dirais même plutôt 4 Go de mémoire, et RAID 1 avec un disque d'avance, ça devrait largement suffir.

    Avant cela tu regardes quel est le goulot d'étranglement: ta charge processeur en est où ? Ton swap ? Tes entrées/sorties ?
    Si tu vois que la mémoire est bien pleine, passe directement à 8 Go, ça ne coûte vraiment rien.

    Tu fais ta mise à jour matérielle et tu regardes à nouveau. Ton goulot d'étranglement ne sera plus le même.

    • [^] # Re: 300 € HT

      Posté par  (site web personnel) . Évalué à 2.

      Les SSD cela s'utilise en BDD ? vu leur perf, c'est intéressant ou pas ?

      "La première sécurité est la liberté"

      • [^] # Re: 300 € HT

        Posté par  . Évalué à 2.

        Pour l'instant je ne sais pas. Je vois ici et là des exclamations comme quoi c'est génial. J'ai testé le fameux Intel X-25 M à travers un RAID matériel et j'ai en gros les mêmes performances qu'avec du SATA à travers le même RAID.

        Mon test s'est limité à un bête dd if=/dev/sda of=/dev/null bs=1M puis à la même chose lancé plusieurs fois en parallèle avec des offset différents afin de mettre en évidence le ralentissement des disques-durs. Les disques-durs n'ont pas été plus lents que les SSD.

        • [^] # Re: 300 € HT

          Posté par  (site web personnel) . Évalué à 1.

          Un truc qui a marché pour quelqu'un que je connait qui avait enormement d'écriture sur des bases mysql c'est le premier
          système SSD ayant existé, a base de barrettes mémoires le i-RAM ou l'HyperDrive je ne sait plus.

          En effet la latence d'écriture sur les disques, de quelque vitesse qu'ils soient était la cause principale de son soucis

          http://en.wikipedia.org/wiki/I-RAM
          http://en.wikipedia.org/wiki/Hyperdrive_%28storage%29

          Après c'est le genre de truc a essayé après s'être demandé si le code, les algos et les requetes SQL sont bien optimum

          • [^] # Re: 300 € HT

            Posté par  (site web personnel) . Évalué à 2.

            En gros c'est comme le Fusion-IO mais en utilisant de la RAM au lieu de mémoire Flash (donc attention au coupure de courant)

            "La première sécurité est la liberté"

        • [^] # Re: 300 € HT

          Posté par  (site web personnel) . Évalué à 1.

          Ce test ne sert à rien du tout. C'est un pure test de bande passante qui dans le cas d'un gros raid sera limité par la carte contrôleur.

          Si tu veux voir la différence fait un "dd if=/dev/sda of=/dev/null bs=1" et l'inverse pour tester la lecture.

          L'énorme différence entre SSD et HD c'est la latence de positionnement des têtes. En lecture, c'est énorme. En écriture, les dernier SSD sont moins mauvais mais dépassent maintenant les disques durs.

          En gros, les SDD gèrent très bien les petits accès de lecture et de mieux en mieux les petits accès en écriture ( ~100 io/s contre autour de 2/3 pour les 1er modèles sortis)

          Certain NAS utilise une partition sur un SSD pour stocker le journal d'un autre fs.

          "La première sécurité est la liberté"

  • # Fais appel à un expert MySQL

    Posté par  . Évalué à 1.

    Honnêtement, toutes les solutions proposées ci-dessus peuvent marcher mais cela dépend beaucoup de tes schema/ton applications, tes requêtes, etc...

    Conseil: fais appel à un expert qui te proposera une solution adaptée et non une solution générique qui risque de ne pas marcher (ou mal)... ou si tu veux bénéficier de conseils gratuits, il va falloir fournir bien plus de détails (et tomber sur une âme charitable)

  • # ton ERP

    Posté par  . Évalué à 2.

    c'est quoi, un truc fait à la mano juste pour vous, un truc Open Source, ça m'intéresse .. les clients se connectent directement à la base ou passent par un service mutualisant les accès?

    Sinon, un petit vmstat te permet de savoir où est le problème système (grossièrement), si ce n'est pas un problème lié à la quantité de mémoire et que ton CPU semble bien occupé, tu peux chercher 'Huge page' sur google. Je n'ai pas fait d'optimisation MySQL, mais dans certains scénario, ça peut aider.

    Mais avant cela il faut optimiser tes requêtes, pour voir lesquelles prennent le plus de temps et bien gérer tes indexes. Désolé, je ne me rappelle plus des commandes/configuration de log pour voir les temps passés par requête.

    • [^] # Re: ton ERP

      Posté par  . Évalué à 1.

      Personne n'a trop parlé de l'appli, mais ça me semble important aussi. Vous ne trouvez pas curieux qu'un erp engendre autant de requêtes ?
      S'il y a une grosse appli centralisée, il doit y avoir moyen de gérer un cache à ce niveau. Si c'est une myriades d'applis qui attaquent la base il faut peut-être envisager d'utiliser quelque chose comme memcached.

      Dans tous les cas il est impératif de voir le problème globalement car si c'est un problème de conception, au prochain ajout de fonctionalité le problème risque d'empirer...

      Vu l'appli et le nb de requête je rejoint les autres, faut payer un audit.

  • # Quelques pistes...

    Posté par  . Évalué à 2.

    Vous devriez étudier cela:

    * En MyISAM, ne pas mettre un"key_buffer_size" trop grand, il n'est utilisé que pour les indexes (MySQL compte sur l'OS pour le cache des données, il faut donc lui laisser de la RAM)
    * Passer en InnoDB
    * Ajouter de la RAM
    * Faire en sorte que la machine ne "swap" pas MySQL
    * Activer le "Query cache" avec une taille suffisante
    * Pour les écritures, solution très efficace: utiliser un contrôleur RAID avec un cache en écriture (secouru par batterie, ex: 128Mo BWCC)
    * Activer et analyser le log des "slow queries" (avec "explain")
    * Utiliser "MySQL Administrator" ou autre pour tracer certaines valeurs.

    Au niveau disque:
    * Eviter, si possible, le RAID5 (RAID10 idéal en général)
    * Aligner les données (Disque / RAID chunk / Partition / FS )
    * Désactiver le ReadAhead (actif par défaut en LVM)

    Autre:
    * Faire intervenir un expert MySQL

    Une source très intéressante est le livre "High Performance MySQL" chez O'Reilly; il explique tout ce dont vous aurez besoin pour tirer un maximum de votre plate-forme.

  • # Isolez les fonctions consommatrice en temps

    Posté par  . Évalué à 2.

    En identifiant les fonctions consommatrice, vous pourrez identifier la partie à optimiser en priorité.
    Voici quelques recommandations pour corriger les problèmes de temps:
    - Identifiez si les requetes exploitent bien les index.
    - Reduire le nombre de données rapatriées
    - Si les requetes sont des updates, on peut gagner du temps en supprimant un lot de données et en les inserants en lots
    Si le temps perdu vient d un nombre important d accès à des tables parametres envisagent de créer un cache logiciel d accès à ces tables.

  • # Analyse / Optimize / Check

    Posté par  . Évalué à 1.

    Bonjour,

    Je ne crois pas que quelqu'un en ait vraiment parlé, alors je rajoute mon grain de sel.
    N'hésite pas à faire des ANALYZE, OPTIMIZE et CHECK régulièrement.

    J'ai déjà vu le cas ou des index sont bien renseignés dans le DESCRIBE de la table, alors qu'en fait, l'index est complètement vérolé / pas utilisé.

    Ces 3 commandes lancées sur chaque table permettent de "ranger"/"nettoyer" un peu les données.

    Bien sûr je plussoie les commentaires à propos du slow-query => explain ...
    Si par moment il y a 800req/sec, c'est que ca gère bien, c'est p'tet que quelques requêtes qui chient ... auquel il faut absolument trouver lesquelles, éventuellement en baissant le seuil de log de slow-query.

    Bon courage.

  • # mysql=oracle donc poubelle

    Posté par  . Évalué à -10.

    Rien de plus

  • # partition de table ?

    Posté par  . Évalué à 1.

    et pourquoi pas partitionner les tables qui sont volumineuses ?

    Je ne sais pas si c'est possible avec mysql.

  • # il ne faut pas chercher plus loin ...

    Posté par  (site web personnel) . Évalué à 2.

    il est là votre problème : ces requêtes sont réparti a 50/50 en lecture et écriture

    vous pouvez mettre les machines les plus puissantes, votre probleme restera le meme, il sera juste atténué par la puisse des machines mais sera de nouveau visible quand le volume sera plus conséquent.

    La solution ?
    A. Revoir l'ensemble des requetes pour les simplifier
    B. Verifier que je schéma de base réponds aux formes normales
    B. Faire de l'agrégation de contenu dès la primo-insertion
    C. Déleguer les lectures à plusieurs petits serveurs avec plein de RAM
    D. Refléchir à la pertinence du choix MySQL
    E. Reperer TOUTES LES requetes de type select A where B qui sont couplé a des insert/update A where B pour mettre un cache par dessus de type memcache
    F. Réflechir à la pertinence d'un moteur SQL

  • # lock

    Posté par  . Évalué à 1.

    une table de 600MB, une base de 2GB, le tout en MyISAM.

    donc la majorité de la base de donnée verrouillée à chaque requête.
    la solution, changer de moteur pour InnoDB qui lock au niveau de la ligne.

    avant de jeter le matériel, il faut absolument tester ça.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.