Kioob

non, cette "recommandation" concernant innodb_log_file_size date d'une époque où MySQL n'était utilisé que pour des petites bases. Voici un article un peu plus intéressant à ce sujet : http://www.mysqlperformanceblog.com/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/ (qui évoque l'autre article de Peter Zaitsev, détaillant le comment du pourquoi). Sinon oui ce sont bien les fichier ib_logfile0 & ib_logfile1 dont je parlais. Et oui innodb_file_per_table & innodb_file_format sont à appliquer avant la conversion en InnoDB pour pouvoir en profiter. Quant aux indexes fulltext, ils ne sont pas compatibles avec InnoDB (sauf version très récente, et encore le fonctionnement diffère). Donc les tables utilisant des indexes fulltext ne pourront pas être converties.

A partir du moment où tu modifies innodb_log_file_size, il faut éteindre MySQL proprement, déplacer les 2 fichiers ib_logfile[01] ailleurs, puis re-démarrer MySQL, afin qu'il re-construise ces fichiers à la bonne taille. A noter que 5G ici me semble monstrueux... j'ai pas souvenir avoir dépassé 256Mo sur ce critère, avec pourtant de grosses bases, très sollicitées. Pour le innodb_flush_log_at_trx_commit, je pense que la valeur 2 aurait suffit, et pour ma part j'aurais ajouté innodb_file_per_table ainsi que innodb_flush_method = O_DIRECT et innodb_file_format = barracuda. Dans tous les cas, généralement il faut superviser l'impact de tout ça avant de modifier, et de préférence comprendre l'impact de la modification avant de l'appliquer.

Hello, pour ma part je tracerais toutes les requêtes supérieures à 100ms (c'est déjà beaucoup pour du web...), et ferais analyser le résultat par un outil type «mk-query-digest» (ou pt-query-digest selon la version) issu de maat-kit (= perconal-toolkit). Au moins tu sauras où commencer. Petite remarque en passant : comme tu le dis tu es en full MYISAM pour tes tables, ça tombe bien, MYISAM gère très très mal les accès concurrents, ce qui vu ta charge est probablement la source du problème. INNODB de son coté tient vraiment beaucoup mieux, à condition de le configurer (oui la grosse abération de MySQL c'est de débarquer avec un INNODB inutilisable «out of the box»).

Bonjour, si tu es sur dédié, tu peux probablement déplacer ce cache en mémoire (tmpfs), par exemple en changeant le chemin de stockage en /dev/shm, ou mieux en ajoutant une ligne spécifique dans ton fichier /etc/fstab : quickcache /chemin/de/ton/cache tmpfs defaults,atime,nodev,nosuid,noexec 0 0 Restera à faire mount /chemin/de/ton/cache. Vérifie toutefois que tu ais assez de place en mémoire pour te permettre ce genre d'optimisation. Et si «QuickCache» est bien l'outil auquel je pense, il ne fait pas le nettoyage de lui même. Donc à placer en cron, toutes les nuits par exemple : find /chemin/de/ton/cache -atime +2 -type f -delete

Bonjour, je ne suis pas certain qu'il soit nécessaire de chercher plus loin : depuis plusieurs semaines (mois ?) le mutualisé d'OVH a de gros gros problèmes de performances. Il faut soit prendre son mal en patience, soit migrer ailleurs. Pour ce qui est du cache, je suppose qu'il gère plusieurs «backend», là tu as choisi memcache, ce qui implique généralement d'avoir recours à un serveur dédié. Regarde si tu peux utiliser un «backend» différent, via des fichiers par exemple.

Dans ce cas, si le système de cache n'est pas fiable, change-en. Non ?

Hello, saturation de l'espace disque de la partition en question ?

A moins que Varnish propose un service du type CloudFlare, je vois pas bien ce que Varnish va apporter à un hébergement mutualisé...

Le cluster mutualisé d'OVH a de gros problèmes de performances en ce moment il paraît. Avant de tout bricoler, je pense que c'est de ce coté qu'il faut regarder. Un client ce matin m'indiquait un passage de 9s à 600ms sur son site, juste en quittant le mutu OVH, et deux autres m'ont indiqué les mêmes tendances la semaine dernière. Donc si tu peux, patientes un peu ils sont visiblement au courant, et planchent dessus.

A noter justement que tu peux te servir d'une petite VM de ce genre pour y placer uniquement un «Varnish», permettant uniquement d'améliorer les perfs du site pour les visiteurs locaux.

Bonjour, depuis peu tu peux commander des VM «low latency», basées entre autre à Hong-Kong. Je ne sais pas si ça change quoi que ce soit en terme de filtrage, mais en tous cas ça améliorera fortement les performances.

Non, cette règle ne bloque que wget. Mais tu peux tester facilement en ligne de commande : wget http://tonsite/undossierbloqué

Complètement oui.

Histoire de préciser un peu plus. Dans ton .htaccess, au lieu de mettre un mot de passe, bloque wget : RewriteCond %{HTTP_USER_AGENT} ^Wget RewriteRule .* http://www.va-voir-ailleurs.com/

Bonjour, moui, si c'est une attaque, elle est drôlement mal foutue : les gars annoncent la couleur, c'est téléchargé via wget. Te suffirait donc de bloquer wget. Par contre effectivement, pas mal d'IP différentes... peut être qu'en mettant un quota de visite sur ton moteur de recherche, ça réglerait le problème. Pour ce qui est de l'impact que ça a sur les autres sites, il faudrait essayer de cloisonner un peu tout ça. Avec le module fCGI d'Apache par exemple tu peux faire en sorte que le quota de «clients» soit par site, et non global. En bridant à 50 par site exemple, ça éviterait que ce site bloque les autres. Bon... reste à voir la tronche du MySQL derrière, mais déjà ça limite la casse.

Bonsoir, qu'entends tu par «ça ne fonctionne toujours pas» ? Quel est le message d'erreur exact ? Parce que sur le principe, c'est relativement simple : - s'assurer qu'il n'y ait pas de «skip-networking» dans la conf MySQL - vérifier que MySQL écoute sur 0.0.0.0 et non 127.0.0.1 (facilement vérifiable avec un «netstat -lnp | grep 3306») - vérifier que le firewall ne foute pas la grouille (iptables -L -n -v) Donc, après avoir vérifié tout ça, quel message d'erreur as-tu ?

Bonsoir, justement, memcached n'est pas du tout un cache d'opcode, mais un cache de données. Dans les grandes lignes : PHP est un langage interprété, à chaque «hit», tel que l'accès à une page, le moteur PHP doit lire et «déchiffrer» tous les scripts, toutes les commandes, il les converti dans un format binaire qu'il saura exécuter rapidement : l'opcode. Un cache d'opcode permet d'éviter cette phase de lecture/conversion du code PHP, et exécute directement l'opcode. Bref, ce n'est pas un cache de données ni même un cache de rendu, le cache d'opcode permet uniquement d'accélérer fortement l'exécution des scripts PHP. Donc si tu n'en avais pas auparavant, il est normal que tu vois de grosses différences. Maintenant ZendGuard intègre peut-être d'autres micro-optimisations (tout comme APC d'ailleurs), mais généralement le gros du gain vient vraiment du cache d'opcode.

Hello, avais-tu un autre cache d'opcode installé, tel qu'APC ou X-Cache auparavant ?

Bonsoir, merci pour ce retour. Comme tu l'auras probablement constaté, le soucis avec java/j2ee est le manque de «communauté» si j'ose dire. Il faut plutôt aller chercher dans des cercles un peu plus orientés professionnels / ssii pour trouver des gens ayant fait le même choix.

Bonsoir, attention, à un moment ou un autre il faudra bien que quelqu'un configure MySQL, justement pour ne pas retrouver à nouveau ces problèmes de performances. Sans être un expert MySQL, le minimal syndical sera probablement de lancer un coup de mysqltuner afin d'essayer de suivre ses recommandations. Ce n'est certainement pas Byzance, mais ça limitera la casse. Coté fournisseur nu, et à ce budget, il y a «l'OVH SP 32G 2013» http://www.ovh.com/fr/serveurs_dedies/sp_32g_ssd.xml qui est un excellent rapport qualité/prix. Restera à mettre la main à la pate pour la gestion de la machine.

Bonjour, sous quel système ? Dans le cas de Debian par exemple il faut installer le paquet php5-odbc.

Hello Dadou, il n'y a malheureusement pas de vérité absolue de ce coté, le load average n'est qu'un indicateur parmi d'autres. Il s'agit en gros de compter le nombre moyen de process en cours d'exécution, sur 1, 5 ou 15 minutes. Avec un quad core hyperthreadé, il peut donc être normal de voir 8 process simultanés en cours d'exécution, au delà il y a de l'attente. Mais là dans les 3 cas il s'agit d'une moyenne, et c'est donc lissée. Tu peux très bien avoir à un instant T 12 process en cours d'exécution, et donc un léger "lag", sans pour autant que le load average grimpe. Bref, à chacun de voir ce qu'il accepte comme latence, s'il faut te donner un ordre d'idée, sur le monitoring on pourrait configurer : - si nb running process > nb coeurs virtuels => notice (à tester toutes les 5 secondes ?) - si load-average sur une minute > 2 * nb coeurs virtuels => alerte (à tester toutes les 30 secondes ?) - si load-average sur cinq minutes > nb coeurs virtuels => alerte (à tester toutes les minutes ?) A toi de voir ce qui correspond vraiment à tes besoins / exigences.

Et bien je n'ai pas essayé, mais les déclarations d'Octave sont assez claires sur le sujet je pense. C'est comme un dédié, aucun bridage de ce genre. Seul le blocage du port 25 (en sortie) a été évoqué pendant un temps. Maintenant, à 0.01 de l'heure, tu ne prends pas bcp de risques à essayer

Bonjour, à priori si tu prends un "miniCloud" OVH (pas un devCloud), ça devrait te permettre ça, à prix dérisoir. Il y a d'ailleurs de nombreux autres vendeurs de solution similaire.

Bonjour, bien que cet hébergeur n'ait pas excellente réputation, ça m'étonnerait fortement qu'ils facturent les hits DNS Généralement quand on parle de facturation aux hits, il s'agit des hits HTTP. De plus les réponses DNS sont bien souvent mises en cache (par les différents FAI, "Box" et navigateurs), si bien que le volume est généralement très très inférieur aux hits HTTP.