Discussion :

[tchize_]

sachant qu'une requete DB ne devrais pas mettre plus de quelques ms, tu as vraiment un problème avec ta base de données mysql. Je ne vois rien dans le code qui justifierais ces lenteurs et tu as des index sur toutes les colonne concernées donc le ddl est bon. Il y a actuellement combien de lignes dans la base?

[Sennad]

Dans cette table en particulier il y a 1 216 302 enregistrements mais il y en aura environ 20 000 000 après.. C'est trop peut être ?
800 000 dans une autre table (ici il y en aura environ 30 000 000), une 4 000 et le reste est raisonnable (<150).
Je suis sûr que le problème vient de la DB moi, j'ai enfin réussi à la redémarrer mais bon c'est pas beaucoup mieux.
Et là ya qu'un seul process qui tourne, mais je vais devoir en lancer environ 50...

[Pill_S]

Et une install from scratch de mysql sur une autre machine, pour confirmer/infirmer que c'est ton install qui est pourrave?

[tchize_]

là où tu va avoir mal, avec 50 process, c'est la concurrence. Comme tu as des clés primaires, pour respecter les contraintes, il faut des verrous. Ce problème est indépendant de la taille des tables. Par contre un select sur 1 millions de ligne, faut que ce soit optimisé. Et sélectionner par une varchar, ce n'est malheureusement pas toujours très performant :s

2 requête (et c'est quoi, un select ou un update?) par seconde c'est catastrophiques comme performances. Il est temps de commencer à poser des question sur le forum mysql, voir à envisager de filer cette partie là du boulot à un DBA expérimenté. Une "bonne" base avec de "bonne" table, devrait pouvoir te laisser insérer plusieurs millions de lignes en une heure. là on est à moins de 10.000 :s

[Sennad]

Salut !

Merci pour vos réponses !

J'ai du nouveau !
J'ai réussi à atteindre 150 selects / sec et 150 updates / sec en même temps
Ça c'était cool mais bon..
Alors, je ne sais pas si je vais dire de la merde mais bon ^^
Enfait j'imagine qu'à force de modifier la base de donnée, rajouter des tables, enlever des colonnes, en rajouter, changer la longueur de la colonne enfin bref, ça fais 3mois que je fais pleins de modifs sur la DB, donc j'imagine que c'est pas top.
J'ai donc dumpé la BDD pour en faire une autre (je voulais garder les données) qui elle serait installée proprement.
Mais en fait quand j'ai importé ce que j'ai dumpé je pensais qu'il allait me demander quel nom donner à la DB, bah non, il a remplacé l'ancienne DB, et sans les enregistrements en plus !!
Du coup je me retrouve avec une base toute vide, toute propre, je balance mon test sur un répertoire qui mettais 4min30 avant, et là il a mit 6secondes
Donc je l'ai laissé toute la nuit sur un gros répertoire, en environ 15/16h il a fait 350 000 fichiers, ça me parait raisonnable.
Là je suis actuellement au niveau perf, toutes les 3/4 sec il monte à 30/40 select et 30/40 update à la seconde, donc c’est un peu moins bien..
Alors selon vous, ça vient du fait que la table est maintenant vide, ou du fait que j'ai réinstallé de la DB ?

Et une install from scratch de mysql sur une autre machine, pour confirmer/infirmer que c'est ton install qui est pourrave?

Ca rejoins un peu ce que j'ai fait, mais pourquoi pas ! Si je retombe dans des perfs catastrophique, je vais peut-être essayer de faire une bonne install sur une autre machine ouais !

Il est temps de commencer à poser des question sur le forum mysql, voir à envisager de filer cette partie là du boulot à un DBA expérimenté. Une "bonne" base avec de "bonne" table, devrait pouvoir te laisser insérer plusieurs millions de lignes en une heure. là on est à moins de 10.000 :s

Oui tu as raison, moi je fini ma mission la semaine prochaine, donc si d'ici là les perfs sont toujours pas terrible, il va falloir envisager un DBA effectivement !! Ça serait vraiment bien =)

Sinon la machine sur laquelle j’ai installé mySql, dispose de 74Go de RAM, d’énormément de CPU enfin c’est un avion, donc si vous avez des idées pour faire du tunning, je suis preneur
Mais bon, comme a dit Tchize il faut que j’aille faire un tour sur le forum mysql !

[benratti]

Alors selon vous, ça vient du fait que la table est maintenant vide, ou du fait que j'ai réinstallé de la DB ?

Inserts 20 000 000 d'entrées "bidon" et tu auras ta réponse !

[Sennad]

Mdr c'est pas con ! J'vai voir ça

[tchize_]

J'ai réussi à atteindre 150 selects / sec et 150 updates / sec en même temps
Là je suis actuellement au niveau perf, toutes les 3/4 sec il monte à 30/40 select et 30/40 update à la seconde, donc c’est un peu moins bien..
Alors selon vous, ça vient du fait que la table est maintenant vide, ou du fait que j'ai réinstallé de la DB ?

Je crois que tu as répondu à la question. Plus ta table grossis, plus c'est lent.... On dirait presque que les indexes sur le nom de fichier ne fonctionnent pas :s

En es-tu toujours à un commit / fichier ou tu as regroupé tes requêtes? La doc de innodb dit d'éviter de faire trop souvent des commit car un commit force un flush sur les disques. Il vaut mieux flusher tous les X inserts d'un coup plutot que 1 à la fois Mais selon moi ça n'explique pas la diminution des performances avec l'agrandissement de la table.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Donc je l'ai laissé toute la nuit sur un gros répertoire, en environ 15/16h il a fait 350 000 fichiers, ça me parait raisonnable.

C'est mieux mais toujours pas raisonnable selon moi, surtout vu l'architecture dont tu dispose. On en est à +- 7 fichiers par secondes. C'est mieux que 1 mais c'est franchement très loin des perfs qu'on peut attendre d'une DB.

Ceci dit, jette peut-être un oeil à ces docs, elles t'aideront peut être. Je peux juste te dire que t'as un sérieux problème mais je suis incapable de te dire concrètement où il est . Y a juste le commit trop fréquent qui risque de poser problème mais marginal je pense.


http://dev.mysql.com/doc/refman/5.0/...g-explain.html
http://dev.mysql.com/doc/refman/5.0/...yze-table.html
Il faudrait aussi faire des tests avec que des inserts, je soupconne le select d'être lent et de scanner toute la table plutôt que d'utiliser l'index que tu as défini dessus.

[Sennad]

Salut !

Super merci pour ta réponse !

Oui je fais des addBatch(), et je fais executeBatch() tous les 500 fichiers, plus un commit().
Je vais passer tous les 1000 ou 2000 fichiers je pense.

C'est vrai que là je fais des inserts en masse pour remplir la DB, et je suis entre 800 et 1000 insert / select à la seconde !
Mais c'est peut-être le programme maintenant qui bride nan ?
Parce que sur mon petit répertoire de référence qui mettait 4min30, sans les accès DB et fichiers, il est passé à 4secondes, et la maintenant avec les accès DB et fichiers il a mis 6 secondes (tout en insert puisque la DB était vide) donc je pense que là la DB n'a pas brider les perfs.
Par contre a la deuxième exécution (La DB a déjà les enregistrements du coup) donc en select / update il a mis 30 secondes ...

[tchize_]

Par contre a la deuxième exécution (La DB a déjà les enregistrements du coup) donc en select / update il a mis 30 secondes ...

voilà, mois les 4 secondes de bases, ça te fais 26 secondes de temps DB pour updater un répertoire de test, donc 6,5 fois plus de temps passé en DB qu'à faire son travail
Ca pue le problème d'index, mais là faut demander dans le fofo mysql, ça me dépasse

[Sennad]

Ca pue le problème d'index, mais là faut demander dans le fofo mysql, ça me dépasse

Yep !

Parcontre là j'ai 1 500 000 enregistrements dans ma DB et ca va toujours aussi vite Donc ca à l'air d'aller. J'vais en mettre 10 000 000 comme ça on sera sur que ca marche toujours aussi bien

[hwoarang]

Ca aurait peut etre valu le coup d'essayer une reconstruction d'index. Je sais pas vraiment ce qui s'est passé mais ca m'est deja arrivé d'avoir une base hyper lente et, après reconstruction d'index (qui existaient deja), ca a débloqué le truc.

[Sennad]

Ca aurait peut etre valu le coup d'essayer une reconstruction d'index. Je sais pas vraiment ce qui s'est passé mais ca m'est deja arrivé d'avoir une base hyper lente et, après reconstruction d'index (qui existaient deja), ca a débloqué le truc.

Salut et merci pour ta réponse.
Qu'est ce qu'une reconstruction d'index ? Les supprimer et les refaire ?


Sinon j'ai mis 8 000 000 d'enregistrement bidon dans la table, et boom ça re-rame en SELECT !
Je vais peut être faire ce qu'on avait dis plus haut, à savoir faire un gros select au début et tout stocker dans un hashMap pour pas refaire de select pour chaque fichiers.
Ou alors faire la requete unique qu'on a vu plus haut aussi.

[Sennad]

Salut à tous !

J'ai fais le HashMap pour récupérer les signature avec l'url !
J'ai gagné énormément de temps ! Merci Tchize !
Mais maintenant c'est le executeBatch() qui rame, alors que ça marchait très bien , et j'ai rien touché (enfin je crois, c'est pour ça que je regarde bien mon code mais je trouve pas..)
Je comprend pas du tout ce qui se passe, le executeBatch() était exécuté tout les 100 fichiers et je voyais dans MySQL Workbench, des pics d'insert toutes les 40sec a peut près, enfin bref c’était le executeBatch() qui mettait même pas 1sec à s’exécuter.
Maintenant ya pas de pic ni rien, ya le petit graph représentant l’écriture disque qui s’enflamme, haut bas haut bas haut bas mais en insert je suis 0 insert/s, c'est vraiment hyper long, il a mit 10min pour updater même pas 100 lignes..

***Edit***

Je crois que j'ai compris, il n'y a plus que 900Mo de libre sur ma partition où est installé la DB.. :/
Je vais faire de la place comme je peux :/

[Sennad]

Bon et bien non ce n'est pas a cause du manque d'espace disque que ça rame.
Enfait les insert rament pas, c'est les update pour mettre la colonne Checked à 1 qui rame.
J'ai pas d'index sur la colonne URL puisqu'elle a une longueur de 500 et on peut faire des index sur max 255..

Je vais clore cette discussion, parce que le problème est maintenant au niveau de la base de donnée, je vais aller faire un tour sur le fofo MySQL
Merci encore à tous pour l'aide précieuse que vous m'avez apporté.

A bientôt