Recherche dans un forum

50 réponses

Page 1 23

Auteur	Message
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 23/10/2006 à 13:36 Pour moi il s'agit plus du "key_buffer_size" que "table_cache", bien qu'il soit également important. Dans les bouquins spécialisés ils conseillent même de monter ce paramêtre jusqu'à la moitié de la mémoire de la machine. Bien sûr, si la base fait 100Mo en tout, pas besoin d'un cache d'1Go non plus Mmm, ce serait plutot un quart d'après la doc officielle : Augmentez cette valeur pour obtenir une meilleure gestion des index (pour les lectures et écritures multiples), autant que vous le pouvez : 64 Mo sur une machine de 256 Mo est une valeur répandue. Toutefois, si vous utilisez une valeur trop grande (par exemple, plus de 50% de votre mémoire totale), votre système risque de commencer à utiliser sa mémoire swap, et devenir très lent. N'oubliez pas que MySQL ne met pas en cache les données lues, et il faut laisser le système d'exploitation respirer. daevel : infogérance et conseil \|\| moi
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 23/10/2006 à 14:08 j'ai 256 Mo dans key_buffer_size et 1024 dans table_cache Je peux augmenter tout ca car d'apres mrtg, la RAM est utilisée a 25-30% seulement en fait ma table de messages de forum fait 500Mo + 100 Mo d'index Mais ca grossit tres vite et de plus en plus vite Ma base complete fait pres de 2 Go j'ai deja regardé des tutos. Celui de telaxo confirme que j'ai de bons paramètres Key_read_requests = 20 G Key_reads = 720 k soit un excellent rapport de 0,000036 ! pour le open_table, c'est bon aussi. je ne depasse pas les 1024 Et j'ai aussi Handler_read_rnd = 3 G qui apparait en rouge Mais ca correspond à des tris de tables ce que je fais enormement sur BT (tri de produits, par note, prix, marque...) La difficulté qui reste vient de la taille de forum_message je pense Je vais essayer de faire l'index fulltext dessus ce soir pour voir si la recherche est activable en remplacant les LIKE par des MATCH AGAINST Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 23/10/2006 à 14:15 devtribu, si tu trouves une solution miracle, hésites pas à la poster. J'ai sensiblement le meme nombre de message que toi (un peu plus) et j'ai les mêmes soucis que toi, google référence vraiment pas tout, fulltext je peux pas étant donné que je suis en InnoDB, la technique PunBB semble être délicate non pas quand on recherche, mais plus quand on envoi un message (explode etc... c'est quand meme lourd pour chaque envoi de messages). Donc bref, j'ai limité la recherche sur les titres pour le moment, faute d'avoir rien trouvé de mieux ;)
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 23/10/2006 à 14:16 oui, ta conf a l'air bien pourtant... tes tables sont en MyIsam ? devtribu a dit : Et j'ai aussi Handler_read_rnd = 3 G qui apparait en rouge Mais ca correspond à des tris de tables ce que je fais enormement sur BT (tri de produits, par note, prix, marque...) Ca ca s'optimise avec les bons index, on alors au pire en faisant faire les tris par PHP plutot que par MySQL (apres a toi de deplacer la charge ou tu preferes selon ton architecture, tes contraintes, etc...). En optimisant ca, tu aura deja un bon gain de perf a mon avis, mais ca ne resoudra pas ton probleme de recherche dans le forum, ca lui laissera juste un peu plus de ressources
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 23/10/2006 à 14:35 les tables sont en myisam Je prefere laisser la charge sur mysql qui est (d'apres mes modestes tests et connaissances) plus efficace que php pour trier je vais essayer de tester fulltext ce soir HS - autre probleme en ce moment : ovh Le ping sur leur reseau interne est enorme (2 a 3 ms) avec des pertes de paquets (au lieu de 0.3 ms) en temps normal Quand on a une architecture distribuée qui communique (un serveur apache et un serveur mysql), les pages mettent 1 ou 2 secondes a se generer au lieu de 30 a 50ms en temps normal ! Et le support me parle de rotation de log ou de maxclients qui n'ont rien a voir avec le sujet ! Le reseau interne de ovh est minable depuis quelques jours mais ils ne veulent pas le reconnaitre... Et ca commence a me gonfler serieusement ! Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 23/10/2006 à 15:47 devtribu a dit : Je prefere laisser la charge sur mysql qui est (d'apres mes modestes tests et connaissances) plus efficace que php pour trier Pour les tris basique, oui, par contre, si tu as des tris sur plusieurs champs avec des ASC et des DESC melanges, il est assez mauvais Mais ca reste des utilisations particulieres, dans 99% des cas, un tri sur un seul champs est extremement rapide (surtout si tu as bien fait des index, car les index permettent d'optimiser les tris en plus des WHERE :wink devtribu a dit : HS - autre probleme en ce moment : ovh Le ping sur leur reseau interne est enorme (2 a 3 ms) avec des pertes de paquets (au lieu de 0.3 ms) en temps normal Quand on a une architecture distribuée qui communique (un serveur apache et un serveur mysql), les pages mettent 1 ou 2 secondes a se generer au lieu de 30 a 50ms en temps normal ! Et le support me parle de rotation de log ou de maxclients qui n'ont rien a voir avec le sujet ! Le reseau interne de ovh est minable depuis quelques jours mais ils ne veulent pas le reconnaitre... Et ca commence a me gonfler serieusement ! Oui, j'ai le meme souci, et c'est assez enervant, les communications entre serveurs sont tres lentes depuis mercredi / jeudi Mais par contre, le fait est reconnu par OVH, c'est juste que comme d'hab le support n'est au courant de rien : http://travaux.ovh.com/?do=details&id=1177
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 23/10/2006 à 16:16 J'ai pas de multisort ou pratiquement pas Pour les pings : Le fait est reconnu a moitié par ovh, mais la tache est cloturée dans la page Pour eux, ca roule... Alors que c'est d'une instabilité permanente A l'instant ou j'ecris, ca a l'air bon ping interne entre 0.18 et 0.35 ms Ma homepage se génére en moins de 30ms Je demande juste au support de dire ce qui se passe et les actions qu'ils mettent en place pour resoudre le pb. Je peux accepter des pb. Ce que je n'accepte pas, c'est d'etre dans l'incertitude sur la durée Et quand on me parle a la place de logrotate a passer en daily alors que j'ai desactivé les logs apache, ca m'enerve un peu ! Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 23/10/2006 à 16:21 Sur les mailing d'entraide, le sujet est aborde et Octave travaille dessus. Il sait que ce n'est pas resolu, et meme si la tache est cloturee, le probleme n'est pas clot de leur cote. Personnellement, je ne passe jamais par le support, ils sont vraiment trop incompetants des que ca devient un peu precis
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 23/10/2006 à 16:26 Sur quelle mailing list tu vois ca ? Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 23/10/2006 à 16:39 Extrait des footers des mails de la liste : Desinscription: envoyez un message a: sd-pro-unsubscribe@ml.ovh.net Pour obtenir de l'aide, ecrivez a: sd-pro-help@ml.ovh.net L'inscription doit donc se faire a sd-pro-subscribe@ml.ovh.net a mon avis
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 25/10/2006 à 00:16 Pour revenir aux problemes reseau d'OVH : Bonjour, Depuis quelques jours, nous avons quelques problèmes de routage sur Paris 19 en heure de pointe. Après pas mal de recherche, le problème vient du fait qu'on sature le bus de communication de 32Gbps à l'intérieur de nos routeurs p19-2-6k et p19-7-6k. Nous allons donc mettre en place cette nuit 2 nouveaux routeurs p19-52-6k et p19-57-6k (sup720) puis basculer la répartition de charge de l'hébergement mutualisé de p19-2/7 vers p19-52/57 demain avant midi (sur 4 cartes CMS). Ceci déchargera p19-2/7 et permettra un retour à la normale. Dans le 2ème temps, nous allons changer toutes les cartes 16x1Gbps vers les nouveaux modèle qui ont des bus de communication de 2x8Gbps par carte au lieu d'un bus mutualisé de 32Gbps. Ainsi, la carte de routage pourra communiquer avec toutes les cartes (10Gbps et 1Gbps) via les bus séparés. En savoir plus: http://travaux.ovh.com/?do=details&id=1188 http://travaux.ovh.com/?do=details&id=1189 Amicalement Octave

Auteur

Message

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 23/10/2006 à 13:36

Pour moi il s'agit plus du "key_buffer_size" que "table_cache", bien qu'il soit également important.

Dans les bouquins spécialisés ils conseillent même de monter ce paramêtre jusqu'à la moitié de la mémoire de la machine.
Bien sûr, si la base fait 100Mo en tout, pas besoin d'un cache d'1Go non plus

Mmm, ce serait plutot un quart d'après la doc officielle :

Augmentez cette valeur pour obtenir une meilleure gestion des index (pour les lectures et écritures multiples), autant que vous le pouvez : 64 Mo sur une machine de 256 Mo est une valeur répandue. Toutefois, si vous utilisez une valeur trop grande (par exemple, plus de 50% de votre mémoire totale), votre système risque de commencer à utiliser sa mémoire swap, et devenir très lent. N'oubliez pas que MySQL ne met pas en cache les données lues, et il faut laisser le système d'exploitation respirer.

daevel : infogérance et conseil || moi

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 23/10/2006 à 14:08

j'ai 256 Mo dans key_buffer_size
et 1024 dans table_cache

Je peux augmenter tout ca car d'apres mrtg, la RAM est utilisée a 25-30% seulement

en fait ma table de messages de forum fait 500Mo + 100 Mo d'index
Mais ca grossit tres vite et de plus en plus vite
Ma base complete fait pres de 2 Go

j'ai deja regardé des tutos. Celui de telaxo confirme que j'ai de bons paramètres
Key_read_requests = 20 G
Key_reads = 720 k
soit un excellent rapport de 0,000036 !

pour le open_table, c'est bon aussi. je ne depasse pas les 1024

Et j'ai aussi Handler_read_rnd = 3 G qui apparait en rouge
Mais ca correspond à des tris de tables ce que je fais enormement sur BT (tri de produits, par note, prix, marque...)

La difficulté qui reste vient de la taille de forum_message je pense
Je vais essayer de faire l'index fulltext dessus ce soir pour voir si la recherche est activable en remplacant les LIKE par des MATCH AGAINST

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

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 23/10/2006 à 14:15

devtribu, si tu trouves une solution miracle, hésites pas à la poster. J'ai sensiblement le meme nombre de message que toi (un peu plus) et j'ai les mêmes soucis que toi, google référence vraiment pas tout, fulltext je peux pas étant donné que je suis en InnoDB, la technique PunBB semble être délicate non pas quand on recherche, mais plus quand on envoi un message (explode etc... c'est quand meme lourd pour chaque envoi de messages).
Donc bref, j'ai limité la recherche sur les titres pour le moment, faute d'avoir rien trouvé de mieux ;)

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 23/10/2006 à 14:16

oui, ta conf a l'air bien pourtant... tes tables sont en MyIsam ?

devtribu a dit :
Et j'ai aussi Handler_read_rnd = 3 G qui apparait en rouge
Mais ca correspond à des tris de tables ce que je fais enormement sur BT (tri de produits, par note, prix, marque...)

Ca ca s'optimise avec les bons index, on alors au pire en faisant faire les tris par PHP plutot que par MySQL (apres a toi de deplacer la charge ou tu preferes selon ton architecture, tes contraintes, etc...).

En optimisant ca, tu aura deja un bon gain de perf a mon avis, mais ca ne resoudra pas ton probleme de recherche dans le forum, ca lui laissera juste un peu plus de ressources

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 23/10/2006 à 14:35

les tables sont en myisam
Je prefere laisser la charge sur mysql qui est (d'apres mes modestes tests et connaissances) plus efficace que php pour trier

je vais essayer de tester fulltext ce soir

HS - autre probleme en ce moment : ovh
Le ping sur leur reseau interne est enorme (2 a 3 ms) avec des pertes de paquets (au lieu de 0.3 ms) en temps normal
Quand on a une architecture distribuée qui communique (un serveur apache et un serveur mysql), les pages mettent 1 ou 2 secondes a se generer au lieu de 30 a 50ms en temps normal !
Et le support me parle de rotation de log ou de maxclients qui n'ont rien a voir avec le sujet !
Le reseau interne de ovh est minable depuis quelques jours mais ils ne veulent pas le reconnaitre... Et ca commence a me gonfler serieusement !

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

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 23/10/2006 à 15:47

devtribu a dit :
Je prefere laisser la charge sur mysql qui est (d'apres mes modestes tests et connaissances) plus efficace que php pour trier

Pour les tris basique, oui, par contre, si tu as des tris sur plusieurs champs avec des ASC et des DESC melanges, il est assez mauvais

Mais ca reste des utilisations particulieres, dans 99% des cas, un tri sur un seul champs est extremement rapide (surtout si tu as bien fait des index, car les index permettent d'optimiser les tris en plus des WHERE :wink

devtribu a dit :
HS - autre probleme en ce moment : ovh
Le ping sur leur reseau interne est enorme (2 a 3 ms) avec des pertes de paquets (au lieu de 0.3 ms) en temps normal
Quand on a une architecture distribuée qui communique (un serveur apache et un serveur mysql), les pages mettent 1 ou 2 secondes a se generer au lieu de 30 a 50ms en temps normal !
Et le support me parle de rotation de log ou de maxclients qui n'ont rien a voir avec le sujet !
Le reseau interne de ovh est minable depuis quelques jours mais ils ne veulent pas le reconnaitre... Et ca commence a me gonfler serieusement !

Oui, j'ai le meme souci, et c'est assez enervant, les communications entre serveurs sont tres lentes depuis mercredi / jeudi

Mais par contre, le fait est reconnu par OVH, c'est juste que comme d'hab le support n'est au courant de rien : http://travaux.ovh.com/?do=details&id=1177

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 23/10/2006 à 16:16

J'ai pas de multisort ou pratiquement pas

Pour les pings :
Le fait est reconnu a moitié par ovh, mais la tache est cloturée dans la page
Pour eux, ca roule...
Alors que c'est d'une instabilité permanente

A l'instant ou j'ecris, ca a l'air bon
ping interne entre 0.18 et 0.35 ms
Ma homepage se génére en moins de 30ms

Je demande juste au support de dire ce qui se passe et les actions qu'ils mettent en place pour resoudre le pb. Je peux accepter des pb. Ce que je n'accepte pas, c'est d'etre dans l'incertitude sur la durée
Et quand on me parle a la place de logrotate a passer en daily alors que j'ai desactivé les logs apache, ca m'enerve un peu !

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

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 23/10/2006 à 16:21

Sur les mailing d'entraide, le sujet est aborde et Octave travaille dessus. Il sait que ce n'est pas resolu, et meme si la tache est cloturee, le probleme n'est pas clot de leur cote.

Personnellement, je ne passe jamais par le support, ils sont vraiment trop incompetants des que ca devient un peu precis

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 23/10/2006 à 16:26

Sur quelle mailing list tu vois ca ?

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

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 23/10/2006 à 16:39

Extrait des footers des mails de la liste :
Desinscription: envoyez un message a: sd-pro-unsubscribe@ml.ovh.net
Pour obtenir de l'aide, ecrivez a: sd-pro-help@ml.ovh.net

L'inscription doit donc se faire a sd-pro-subscribe@ml.ovh.net a mon avis

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 25/10/2006 à 00:16

Pour revenir aux problemes reseau d'OVH :

Bonjour,
Depuis quelques jours, nous avons quelques problèmes
de routage sur Paris 19 en heure de pointe. Après
pas mal de recherche, le problème vient du fait qu'on
sature le bus de communication de 32Gbps à l'intérieur
de nos routeurs p19-2-6k et p19-7-6k. Nous allons donc
mettre en place cette nuit 2 nouveaux routeurs p19-52-6k
et p19-57-6k (sup720) puis basculer la répartition de
charge de l'hébergement mutualisé de p19-2/7 vers
p19-52/57 demain avant midi (sur 4 cartes CMS).
Ceci déchargera p19-2/7 et permettra un retour à la
normale. Dans le 2ème temps, nous allons changer
toutes les cartes 16x1Gbps vers les nouveaux modèle
qui ont des bus de communication de 2x8Gbps par
carte au lieu d'un bus mutualisé de 32Gbps. Ainsi,
la carte de routage pourra communiquer avec toutes
les cartes (10Gbps et 1Gbps) via les bus séparés.

En savoir plus:
http://travaux.ovh.com/?do=details&id=1188

http://travaux.ovh.com/?do=details&id=1189

Amicalement
Octave

Page 1 23

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.