Recherche fulltext aie aie 15 minutes

38 réponses

Page 12

Auteur	Message
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 02/04/2008 à 21:05 Je m'en sert de façon TRES régulière, jusqu'à plusieurs fois par seconde lorsque Google passe pour indexer les pages concernées. Le site possède un système de taggage et les pages de tags sont des recherches dans la base. Google indexe toutes les pages de tag (50 résultats / page), donc il passe dessus très régulièrement et déclenche donc des recherches fullText. En plus chaque page fait 2 recherches fullText, une pour avoir le nombre total de resultats (COUNT() pour connaitre le nombre total de pages), et une pour avoir les résultats de la page en cours (avec un LIMIT x,y).
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 02/04/2008 à 21:09 A mon avis, l'élément primordial est vraiment la gestion du disque et de la mémoire, sur vos graphes MRTG, vous ne devez JAMAIS avoir de lecture sur les disques, seulement au demarrage du serveur pour tout monter en mémoire. En utilisation normale, il n'y a que des écritures sur les disques (les logs, les mises a jour des fichiers des tables, etc...) mais aucune lecture. De manière générale, c'est vrai pour tous les types de serveur (web ou mysql), en respectant cette règle, vous êtes surs d'une part de ne jamais casser vos disques dur, et d'autre part de ne pas avoir ce goulot d'étranglement ultra lent qu'est le disque. Avant quand mes serveurs faisaient encore des lectures a longueur de journées, un disque tenait en moyenne 1 an. Depuis que j'applique cette règle, je n'ai pas cassé un seul disque en 3 ans. Je sais pas si c'est directement lié ou si OVH a fourni de meilleur disque, amélioré ses datacenter ou quoi, mais au final, c'est vraiment mieux En plus niveau perf ca n'a rien à voir, le HDD est l'élément le plus lent sur un serveur, c'est bête de caler tout le serveur sur sa vitesse.
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 02/04/2008 à 22:12 En même temps avoir tout le site et/ou toute la base de données en mémoire, ce n'est possible que ces sur les petits volumes de données (ou les monstres à 16Go de mémoire). Pour MySQL le plus important est d'avoir tous les indexes en mémoire (le keybuffer justement). C'est d'ailleurs pour cela qu'il est conseillé d'y attribuer environ la moitié de notre mémoire. daevel : infogérance et conseil \|\| moi
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 02/04/2008 à 22:15 Et moi qui oublie tout ... ->[]
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 02/04/2008 à 22:17 Telaxo a dit : Je sais pas si c'est directement lié ou si OVH a fourni de meilleur disque, amélioré ses datacenter ou quoi, mais au final, c'est vraiment mieux Ils ont changé les disques et c'est nettement mieux oui. C'était leur énorme point faible. Chambres d'hote tavel Séjours en provence Forum mariage
Julgates \| Julien Administrateur Inscrit le : 09/03/2005	# Le 02/04/2008 à 22:28 Et vous avez jamais envisagé PG et ses extensions ? Shopping Time Network - Founder / CTO
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 02/04/2008 à 22:43 Julgates : je n'en ai pas l'utilité à vrai dire ; et du (très) peu que j'ai lu il n'est pas plus rapide que MySQL. Le problème sera le même quelque soit le SGBD d'ailleurs : comme le dit Telaxo/Mathieu si les indexes ne sont pas en mémoire, les accès disque vont tout plomber. Rano : la température a vachement baissé surtout. Mes précédentes machines OVH accusaient entre 15 et 20°C de plus pour les disques. daevel : infogérance et conseil \|\| moi
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 02/04/2008 à 22:45 Pour le changement de disque, ils l'avaient annoncés. Mais c'est vrai qu'ils ont l'air au point sur le refroidissement selon ce que disait Octave sur une des mailing list Chambres d'hote tavel Séjours en provence Forum mariage
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 02/04/2008 à 22:49 J'avais fait beaucoup de bench il y a un peu plus de 3 ans, et a l'époque, PG était beaucoup plus lent que Mysql sous un faible charge. Sous une forte charge, par contre, PG ne ralentissait pas, et mysql finissait par etre aussi "lent" que pg. Donc au final, mysql ralentissait avec la charge, alors que pg lui allait toujours a la meme vitesse... mais jamais plus vite que mysql Ensuite, mysql offre differents moteurs de stockage ce qui est tres pratique pour optimiser les tables selon leur utilisation (lecture / ecriture / mixte / etc...). Et puis maintenant je connais tellement bien mysql que c'est un gain enorme de travailler dessus, si il fallait que je redecouvre tous les parametres de pg, je perdrais enormement de temps. Actuellement, je n'ai pas encore trouve les limites de mysql, donc ca me va parfaitement
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 02/04/2008 à 23:22 Bool a dit : En même temps avoir tout le site et/ou toute la base de données en mémoire, ce n'est possible que ces sur les petits volumes de données (ou les monstres à 16Go de mémoire). Pour MySQL le plus important est d'avoir tous les indexes en mémoire (le keybuffer justement). C'est d'ailleurs pour cela qu'il est conseillé d'y attribuer environ la moitié de notre mémoire. J'ai un serveur mysql avec 12go de mémoire, mais ma base fait 2go sur 120 tables et ça rame grave ... dès que ca dépasse les 1000 requêtes SQL par secondes ... L'écriture sature ... il faut que je réduise mes update et delete ... sauf qu'au niveau de mon code c'est déjà au minimum, vous avez une idée de comment faire ? @+ Jean-Philippe
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 02/04/2008 à 23:41 Faut verifier si c'est ton disque qui sature en ecriture, si c'est le cas, il faut mettre tes tables en innodb et mettre innodb_flush_log_at_trx_commit = 2 En gros, ca dit a mysql de ne pas ecrire sur disque chaque changement, mais seulement de faire 1 ecriture par seconde quel que soit le nombre de changements sur tes tables. Ca evitera de saturer ton disque. La doc en reference : http://dev.mysql.com/doc/refman/4.1/en/innodb-para... Apres faut aussi verifier que ton cache de table est assez grand pour que le serveur passe pas son temps a ouvrir et fermer les tables.
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 03/04/2008 à 09:41 Super merci telaxo, je vais regarder cela de plus près. Y a moyen que tu copies colle ton my.cnf pour avoir une idée des modifications à effectuer ? @+ Jean-Philippe
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 03/04/2008 à 10:18 Pour la configuration du as des exemples fournis avec MySQL (dans /usr/share/doc/mysql-server-5.0/examples sous Debian). Mais comme chaque machine et base de données est différente, faut adapter. Du genre les tables temporaires de 700Mo et les buffers de tri de 128Mo comme dans la configuration de la page précédente, ça ne passera pas sur beaucoup de machines/bases. La proportion de tables MyISAM/InnoDB influe beaucoup sur la configuration également. daevel : infogérance et conseil \|\| moi
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 03/04/2008 à 10:25 Oui, clair, moi j'ai un serveur specialise dans l'innoDB et un autre spécialisé pour les bases MyISAM, ca permet de bien adapter la conf des serveurs a leur usage. Pareil pour differentes variables : set-variable = max_allowed_packet=32M c'est surement pas necessaire dans beaucoup de cas set-variable = thread_cache_size=25 idem, pas forcement utile selon les usages set-variable = connect_timeout=20 depend de l'usage, ca peut etre descendu ou augmente selon l'environnement Le mieux dans tous les cas est de lire la doc, elle est tres bien faite et explique absolument tout. Une fois que tu as identifie le point qui ralenti ton serveur, en explorant la doc tu trouves toujours des choses a tuner pour resoudre le probleme
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 03/04/2008 à 10:42 Quand je lis ce topic, je me dis que je suis vraiment a la ramasse sur mySQL. Faut vraiment que je me mette a potasser la doc un jour. JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 03/04/2008 à 13:57 Telaxo > Merci, je dois regarder ca pour réactiver la recherche dans les forums... Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
Julgates \| Julien Administrateur Inscrit le : 09/03/2005	# Le 03/04/2008 à 18:36 krucial a dit : Quand je lis ce topic, je me dis que je suis vraiment a la ramasse sur mySQL. Faut vraiment que je me mette a potasser la doc un jour. T'oublies qu'a une époque encore pas si lointaine tu connaissais pas les Jointures JC, comme quoi tu progresses quand même Sinon pour PG, la relation objet est quand meme énorme Shopping Time Network - Founder / CTO
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 03/04/2008 à 20:12 C'est un peu comme la POO en web, je suis pas persuadé que ce soit très rentables sur des sites "simples". Après, pour des projets complexes, il est évident que c'est intéressant, mais dans la grande majorité des sites, c'est une surcouche couteuse pour peu de choses a mon sens.
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 03/04/2008 à 20:52 Eternel débat Je crois que maintenant je serai plus faire autrement. Je sais pas ce que tu appels des "sites simples", mais en dehors de site de présentation, ça me semble toujours utile. (et comme je fais jamais de sites de présentation ...).

Auteur

Message

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 02/04/2008 à 21:05

Je m'en sert de façon TRES régulière, jusqu'à plusieurs fois par seconde lorsque Google passe pour indexer les pages concernées.

Le site possède un système de taggage et les pages de tags sont des recherches dans la base. Google indexe toutes les pages de tag (50 résultats / page), donc il passe dessus très régulièrement et déclenche donc des recherches fullText.

En plus chaque page fait 2 recherches fullText, une pour avoir le nombre total de resultats (COUNT() pour connaitre le nombre total de pages), et une pour avoir les résultats de la page en cours (avec un LIMIT x,y).

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 02/04/2008 à 21:09

A mon avis, l'élément primordial est vraiment la gestion du disque et de la mémoire, sur vos graphes MRTG, vous ne devez JAMAIS avoir de lecture sur les disques, seulement au demarrage du serveur pour tout monter en mémoire.

En utilisation normale, il n'y a que des écritures sur les disques (les logs, les mises a jour des fichiers des tables, etc...) mais aucune lecture.

De manière générale, c'est vrai pour tous les types de serveur (web ou mysql), en respectant cette règle, vous êtes surs d'une part de ne jamais casser vos disques dur, et d'autre part de ne pas avoir ce goulot d'étranglement ultra lent qu'est le disque.

Avant quand mes serveurs faisaient encore des lectures a longueur de journées, un disque tenait en moyenne 1 an. Depuis que j'applique cette règle, je n'ai pas cassé un seul disque en 3 ans. Je sais pas si c'est directement lié ou si OVH a fourni de meilleur disque, amélioré ses datacenter ou quoi, mais au final, c'est vraiment mieux En plus niveau perf ca n'a rien à voir, le HDD est l'élément le plus lent sur un serveur, c'est bête de caler tout le serveur sur sa vitesse.

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 02/04/2008 à 22:12

En même temps avoir tout le site et/ou toute la base de données en mémoire, ce n'est possible que ces sur les petits volumes de données (ou les monstres à 16Go de mémoire).

Pour MySQL le plus important est d'avoir tous les indexes en mémoire (le keybuffer justement). C'est d'ailleurs pour cela qu'il est conseillé d'y attribuer environ la moitié de notre mémoire.

daevel : infogérance et conseil || moi

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 02/04/2008 à 22:15

Et moi qui oublie tout ...

->[]

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 02/04/2008 à 22:17

Telaxo a dit :
Je sais pas si c'est directement lié ou si OVH a fourni de meilleur disque, amélioré ses datacenter ou quoi, mais au final, c'est vraiment mieux

Ils ont changé les disques et c'est nettement mieux oui. C'était leur énorme point faible.

Chambres d'hote tavel
Séjours en provence
Forum mariage

Julgates | Julien
Administrateur

Inscrit le : 09/03/2005

# Le 02/04/2008 à 22:28

Et vous avez jamais envisagé PG et ses extensions ?

Shopping Time Network - Founder / CTO

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 02/04/2008 à 22:43

Julgates : je n'en ai pas l'utilité à vrai dire ; et du (très) peu que j'ai lu il n'est pas plus rapide que MySQL. Le problème sera le même quelque soit le SGBD d'ailleurs : comme le dit Telaxo/Mathieu si les indexes ne sont pas en mémoire, les accès disque vont tout plomber.

Rano : la température a vachement baissé surtout. Mes précédentes machines OVH accusaient entre 15 et 20°C de plus pour les disques.

daevel : infogérance et conseil || moi

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 02/04/2008 à 22:45

Pour le changement de disque, ils l'avaient annoncés. Mais c'est vrai qu'ils ont l'air au point sur le refroidissement selon ce que disait Octave sur une des mailing list

Chambres d'hote tavel
Séjours en provence
Forum mariage

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 02/04/2008 à 22:49

J'avais fait beaucoup de bench il y a un peu plus de 3 ans, et a l'époque, PG était beaucoup plus lent que Mysql sous un faible charge.

Sous une forte charge, par contre, PG ne ralentissait pas, et mysql finissait par etre aussi "lent" que pg.

Donc au final, mysql ralentissait avec la charge, alors que pg lui allait toujours a la meme vitesse... mais jamais plus vite que mysql

Ensuite, mysql offre differents moteurs de stockage ce qui est tres pratique pour optimiser les tables selon leur utilisation (lecture / ecriture / mixte / etc...).

Et puis maintenant je connais tellement bien mysql que c'est un gain enorme de travailler dessus, si il fallait que je redecouvre tous les parametres de pg, je perdrais enormement de temps. Actuellement, je n'ai pas encore trouve les limites de mysql, donc ca me va parfaitement

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 02/04/2008 à 23:22

Bool a dit :
En même temps avoir tout le site et/ou toute la base de données en mémoire, ce n'est possible que ces sur les petits volumes de données (ou les monstres à 16Go de mémoire).

Pour MySQL le plus important est d'avoir tous les indexes en mémoire (le keybuffer justement). C'est d'ailleurs pour cela qu'il est conseillé d'y attribuer environ la moitié de notre mémoire.

J'ai un serveur mysql avec 12go de mémoire, mais ma base fait 2go sur 120 tables et ça rame grave ... dès que ca dépasse les 1000 requêtes SQL par secondes ...

L'écriture sature ... il faut que je réduise mes update et delete ... sauf qu'au niveau de mon code c'est déjà au minimum, vous avez une idée de comment faire ?

@+ Jean-Philippe

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 02/04/2008 à 23:41

Faut verifier si c'est ton disque qui sature en ecriture, si c'est le cas, il faut mettre tes tables en innodb et mettre innodb_flush_log_at_trx_commit = 2

En gros, ca dit a mysql de ne pas ecrire sur disque chaque changement, mais seulement de faire 1 ecriture par seconde quel que soit le nombre de changements sur tes tables. Ca evitera de saturer ton disque.

La doc en reference : http://dev.mysql.com/doc/refman/4.1/en/innodb-para...

Apres faut aussi verifier que ton cache de table est assez grand pour que le serveur passe pas son temps a ouvrir et fermer les tables.

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 03/04/2008 à 09:41

Super merci telaxo, je vais regarder cela de plus près.

Y a moyen que tu copies colle ton my.cnf pour avoir une idée des modifications à effectuer ?

@+ Jean-Philippe

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 03/04/2008 à 10:18

Pour la configuration du as des exemples fournis avec MySQL (dans /usr/share/doc/mysql-server-5.0/examples sous Debian). Mais comme chaque machine et base de données est différente, faut adapter.

Du genre les tables temporaires de 700Mo et les buffers de tri de 128Mo comme dans la configuration de la page précédente, ça ne passera pas sur beaucoup de machines/bases.
La proportion de tables MyISAM/InnoDB influe beaucoup sur la configuration également.

daevel : infogérance et conseil || moi

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 03/04/2008 à 10:25

Oui, clair, moi j'ai un serveur specialise dans l'innoDB et un autre spécialisé pour les bases MyISAM, ca permet de bien adapter la conf des serveurs a leur usage.

Pareil pour differentes variables :
set-variable = max_allowed_packet=32M c'est surement pas necessaire dans beaucoup de cas
set-variable = thread_cache_size=25 idem, pas forcement utile selon les usages
set-variable = connect_timeout=20 depend de l'usage, ca peut etre descendu ou augmente selon l'environnement

Le mieux dans tous les cas est de lire la doc, elle est tres bien faite et explique absolument tout. Une fois que tu as identifie le point qui ralenti ton serveur, en explorant la doc tu trouves toujours des choses a tuner pour resoudre le probleme

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 03/04/2008 à 10:42

Quand je lis ce topic, je me dis que je suis vraiment a la ramasse sur mySQL. Faut vraiment que je me mette a potasser la doc un jour.

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 03/04/2008 à 13:57

Telaxo > Merci, je dois regarder ca pour réactiver la recherche dans les forums...

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

Julgates | Julien
Administrateur

Inscrit le : 09/03/2005

# Le 03/04/2008 à 18:36

krucial a dit :
Quand je lis ce topic, je me dis que je suis vraiment a la ramasse sur mySQL. Faut vraiment que je me mette a potasser la doc un jour.

T'oublies qu'a une époque encore pas si lointaine tu connaissais pas les Jointures JC, comme quoi tu progresses quand même

Sinon pour PG, la relation objet est quand meme énorme

Shopping Time Network - Founder / CTO

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 03/04/2008 à 20:12

C'est un peu comme la POO en web, je suis pas persuadé que ce soit très rentables sur des sites "simples". Après, pour des projets complexes, il est évident que c'est intéressant, mais dans la grande majorité des sites, c'est une surcouche couteuse pour peu de choses a mon sens.

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 03/04/2008 à 20:52

Eternel débat
Je crois que maintenant je serai plus faire autrement.

Je sais pas ce que tu appels des "sites simples", mais en dehors de site de présentation, ça me semble toujours utile. (et comme je fais jamais de sites de présentation ...).

Page 12

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.