Reprise du message précédent :
Pour le query cache, il supprime bien tout le cache concernant une table dès qu'une seule ligne dans la table est modifié ( delete, update, insert ) ?
 
Si oui, dans chaque table il y a des informations qui varient souvent et donc c'est bizarre que ca marche autant chez vous

Je suis à "seulement" 650 req/ s avec 2000 connectés la journée et 3000 en soirée

Tiens, ils ont changé l'interface de MSN  

Les autres (après [myisamchk] notammant) pas besoin d'y toucher ?
 

 
Je peux restarter ?
 

Et encore, c'est un paramètre qui date de l'époque où j'avais de gros problème de charge. Là je dois pouvoir le passer à 20 que ca ferait pas de différence : même en pleine journée, quand le nombre de connectés approche 900, il faut vraiment s'exciter sur le show processlist en ligne de commande pour espérer voir plus de 2 requêtes s'accumuler.
 
Du coup je vois pas l'intéret de le mettre plus haut

Core 666: Tu as combien dans max_used_connections?

je viens de faire un show processlist, j'avais aucune query en cours d'execution

moi j'ai le max

Gestion des sujets favoris dans la 9.1, YESSSSS

Il est bien à 60. Mais vu que j'ai pas restarté MySQL depuis bientot un mois et que j'ai fais pas mal de modif de ma struture BDD ces derniers temps, il a du être atteind lors d'ALTER TABLE gourmand. Hors opérations de maintenance je dois vraiment pouvoir le revoir à la baisse.

 
C'est comme ca sur des lignes et des lignes ... Bon, en même temps il n'y a personne

J'en ai 3 en cours d'execution par contre j'ai des dizaines en sleep

 
Quel site ?
 
joce > pas bien les tests sur un serveur en prod
 

 
Bon, en même temps c'est rare que teste un truc en local avant de le mettre en ligne

oui moi aussi j'ai des sleeps, il vaut mieux en fait

C'était pas un test, j'ai juste redemarré MySQL avec un paramêtre revu à la hausse

Tu ne fermes pas manuellement tes connexions chaque fois que tu n'as plus besoin de MySQL ? Je sais que pour ma part j'ai aucun script sans mysql_close, c'est peut être pour ca que je suis pas gêné par un max connections tout petit.

Bah merde alors
 
Ca prend moins de temps pour MySQL de se raccrocher à une connexion en attente que d'en re-ouvrir une ?

mysql_close est absolument inutile (sauf si tu veux fermer la connexion avec la fin de l'execution de la page PHP), les connexions sont automatiquement fermées à la fin de l'execution de la page php.

oui
l'ouverture / fermeture des connexions consomment pas mal de CPU

C'est ce qu'indique la doc effectivement, mais ca ne se vérifie par forcément dans la pratique vu qu'avant que je ne fasse ainsi j'en avais toujours une dizaine en sleep ...

aceboard
 
J'ai un pseudo sous windows et l'autre sous Linux

Ah ok
 
Alors, tu as regardé quel ratio requêtes / requêtes depuis le query cache tu as sous Aceboard ?

joce => avant que je ne restarte MySQL tu vois une autre valeur abérante ou c'est à peu près potable comme conf ?
 
[mysqld]  
set-variable = connect_timeout=20  
set-variable = max_connections=60  
skip-locking  
set-variable    = key_buffer=512M (300 avant)
set-variable    = tmp_table_size=64M  
set-variable    = join_buffer_size=64M  
set-variable    = max_allowed_packet=1M  
set-variable    = table_cache=256  
set-variable    = sort_buffer=2M (64 avant)
set-variable    = record_buffer=1M  
set-variable    = myisam_sort_buffer_size=64M  
set-variable    = thread_cache=4  
set-variable    = thread_concurrency=8  
# log-bin  
server-id       = 1  
 
set-variable = query_cache_type=ON  
set-variable = query_cache_size=128M (10 avant)
set-variable = query_cache_limit=1M  
 
log-slow-queries  
set-variable = long_query_time=2  
 
[isamchk]  
set-variable    = key_buffer=128M  
set-variable    = sort_buffer=128M  
set-variable    = read_buffer=2M  
set-variable    = write_buffer=2M  
 
[myisamchk]  
set-variable    = key_buffer=128M  
set-variable    = sort_buffer=128M  
set-variable    = read_buffer=2M  
set-variable    = write_buffer=2M

long_query_time il faut mettre 1

Ca te fait quand même 19%, c'est pas négligeable

il a du lowmem_prunes aussi c'est moi qui gagne

http://dev.mysql.com/doc/mysql/en/Query_Cache_How.html
 
Je comprends pas, si ca fonctionne comme ca logiquement il ne devrait  plus souvent supprimer le cache que de piocher les requetes dedans

Pourtant d'après le free j'ai 1Go de ram encore dispo  
 
A moins qu'il se base sur la valeur que j'ai donné au query_cache alors il suffirait de l'augmenter

tout dépend comme de query tu te tappes avant une modif de la table.
Sur HFR comme y a enormement de consultation, y a bcp de querys effectuées avant qu'une table ne change.

Il y a quand même des tables qui sont peu mises à jours. Sur FA par exemple je stocke toute la config dans une table, c'est plus facile à maintenir qu'un fichier texte à la conf.inc.php. Cette table doit être mise à jour une fois par semaine à tout casser, toutes les requetes qui la concernent doivent être lues dans le QUERY CACHE. Bon, évidement c'est l'exemple extrème, mais en réféchissant bien on doit pouvoir gagner un peu.
 
Je suis quand même impressionné par les +/- 50% de joce

oui mais rien que la table des topics tu peux pas du tout la cacher à cause des vues qui augmentent à chaque vue.
 
De même sur les autres tables, ya souvent un champ qui vient tout faire foirer

Rien que l'incrémentation des vues suffit à mettre en l'air l'efficacité du QUERY CACHE. Pourtant tu le gères bien en temps réel. Ca a quand même ses limites comme système

Merde, grillé
 
joce a peur que je lui passe devant sur le lowmem_prunes, il veut pas me dire si elles suxe moins ma conf MySQL

le lowmem_prunes augmente lorsqu'il n'arrive plus à allouer assez de block, du coup il vire des querys du cache pour en mettre d'autre.
Par exemple si t'as un query_alloc_block_size à 16K, ba il alloue un block de 16K pour chaque query, et si tes querys sont très petites, y a de l'espace perdu, et bcp de fragmentation qui fait que bien qu'il semble de rester plein de mémoire dans le query cache, lui ne peut plus rien allouer, et donc il fait du pruning
Dans ce cas, soit tu fais régulièrement des FLUSH QUERY CACHE pour défragmenter le cache, soit t'augmentes le query_cache, soit tu diminues le query_alloc_block_size (au risque de voir les perfs du query cache diminuer quand tes requètes qu'il doit cacher sont plus grosses que la valeur allouée)

tout dépend dans quelle table se situe ce champ, après tout se joue au niveau du choix de l'archi de ton forum
Typiquement FA à forcement un query cache qui est pénalisé par le fait d'avoir une table unique pour tous les forums. (probabilité de modif de la table bcp plus grande que si les tables sont séparées par cat)

C'est l'un des avantages supplémentaires du slip des tables (une section = une table). Nous quand quelqu'un poste ca vire le query cache sur l'ensemble des messages. Sur PPC c'est beaucoup plus efficace. Rien que ca ca doit suffire à expliquer une bonne partie de ses 50%

voire mon edit

Ca serait quand meme bcp mieux si le query-cache supprimait la requete du cache quand il y a une modif sur cette requete et non sur la table

et tu perdrais tout le gain apporté par le système de cache par un système de gestion de query cache super lourd

Je suppose que tu préfère le mysql_pconnect à l'autre pour te connecter au server ...

non j'utilise le mysql_connect, pconnect c'est de la merde (et ca n'existe plus dans les extensions MySQLi de PHP5)