VBET HAUTE CPU / mémoire due à l'utilisation de MySQL

[magmf]

Les gars,

J'ai vraiment besoin ont vBET plus optimisé pour mon site.

VBET devient m'a fait beaucoup de nouveaux utilisateurs que j'ai vraiment aimé l'outil, mais utilise trop de ressources.


Ma charge CPU avant vBET a soufflet 2 et il est maintenant plus de 4 tous les temps

maintenant par exemple
08:32:18 jusqu'à 11 jours, 2h27, 1 utilisateur, charge moyenne: 7.45, 8.24, 8.26

attachés quelques billets avant et après vBET activé dans mon site


Je tiens à vous partager que je sauté de 70.000 pages indexées sur Google à plus de 500.000

mon rang au Alexa sauté aussi
Sous-linux.org - Infos sur le site d'Alexa (http://www.alexa.com/siteinfo/under-linux.org)

et je suis reçu plus de visites quotidiennes, mais j'ai encore besoin d'une meilleure optimisation sur la façon vBET gérer les requêtes.

jetez un oeil sur mon top



top - 08:53:46 up 11 days, 2:49, 1 user, load average: 10.77, 9.81, 9.06
Tasks: 423 total, 5 running, 418 sleeping, 0 stopped, 0 zombie
Cpu(s): 15.7%us, 2.4%sy, 0.0%ni, 66.6%id, 9.8%wa, 0.1%hi, 5.4%si, 0.0%st
Mem: 12330536k total, 11619688k used, 710848k free, 24064k buffers
Swap: 995988k total, 994972k used, 1016k free, 2917568k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29384 mysql 20 0 5722m 2.5g 4552 S 99 20.9 3661:46 mysqld



comme vous pouvez voir en haut mysql raison de vBET


MySQL SHOW PROCESSLIST;



mysql> show processlist;
+********-+************+****************-+************+********-+****--+************--+****************************************************************************************************--+
| Id | User | Host | db | Command | Time | State | Info |
+********-+************+****************-+************+********-+****--+************--+****************************************************************************************************--+
| 3102552 | underlinux | localhost:49801 | underlinux | Query | 16 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102570 | underlinux | localhost:49843 | underlinux | Query | 12 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102597 | underlinux | localhost:49901 | underlinux | Query | 9 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102600 | underlinux | localhost:49907 | underlinux | Query | 9 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102617 | underlinux | localhost:49944 | underlinux | Query | 6 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102620 | underlinux | localhost:49953 | underlinux | Query | 6 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102632 | underlinux | localhost:49986 | underlinux | Query | 3 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102633 | underlinux | localhost:49988 | underlinux | Query | 0 | statistics | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102636 | underlinux | localhost:49994 | underlinux | Sleep | 1 | | NULL |
| 3102639 | underlinux | localhost:50000 | underlinux | Query | 0 | statistics | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102641 | underlinux | localhost:50005 | underlinux | Query | 0 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102648 | underlinux | localhost:50021 | underlinux | Sleep | 1 | | NULL |
| 3102649 | underlinux | localhost:50022 | underlinux | Query | 0 | statistics | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102651 | root | localhost | NULL | Query | 0 | NULL | show processlist |
| 3102652 | underlinux | localhost:50027 | underlinux | Query | 0 | statistics | SELECT translated FROM vbvbenterprisetranslator_cache_medium_vi WHERE originaltext='Cadastrar+200+cl |
| 3102660 | underlinux | localhost:50044 | underlinux | Query | 0 | statistics | SELECT translated FROM vbvbenterprisetranslator_cache_medium_fa WHERE originaltext='BackTrack+4+%28F |
| 3102661 | underlinux | localhost:50047 | underlinux | Query | 0 | statistics | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102663 | underlinux | localhost:50051 | underlinux | Sleep | 1 | | NULL |
| 3102664 | underlinux | localhost:50052 | underlinux | Query | 1 | end | UPDATE vbuser SET
profilevisits = profilevisits + 1
WHERE userid = 61484 |
| 3102666 | underlinux | localhost:50056 | underlinux | Query | 0 | update | REPLACE INTO vbdatastore
(title, data, unserialize)
VALUES
('cron', '1275652500', 0) |
+********-+************+****************-+************+********-+****--+************--+****************************************************************************************************--+
20 rows in set (0.16 sec)

mysql>




mysql et l'utilisation du CPU avant et après vBET

http://under-linux.org/wiki/images/1/14/Mysql-vbet.png

http://under-linux.org/wiki/images/f/f0/Vbetmysql2.png

http://under-linux.org/wiki/images/6/65/Vbet-cpuusage.png

[vBET]

Bonjour.

Comme vous avez écrit vBET vous a donné beaucoup de nouveaux trafics. Alors comparant utilisation du processeur et membres avant et après vBET, est vraiment comparer utilisation du processeur et membres avant et après l'avoir plus de trafic ...
Ainsi cette comparaison n'est pas appropriée. Il n'y a aucune possibilité d'avoir l'utilisation des ressources même avec de plus gros trafic. Aussi s'il vous plaît noter que vBET prend pratiquement pas de ressources pour les pages normales (seulement génère des drapeaux) et donc tous vos usage des ressources supplémentaires provient de trafic supplémentaire - le trafic vers des pages traduites. Plus de trafic = plus de ressources nécessaires

S'il vous plaît noter que les requêtes sont optimisées vBET, tous utilisent des index et de prendre toutes les données dans les requêtes peu. S'il vous plaît vérifier les requêtes lentes journal pour déterminer ce qui prend vraiment le plus de temps MySQL. Aussi - vous pouvez toujours reconstruire les index dans le cas où, si quelque chose s'est écrasé dans votre base de données MySQL.

S'il vous plaît dire quelle est la taille de vos tables de cache? Aussi s'il vous plaît dire quelle version de vBET utilisez-vous et donnez votre URL forum.

S'il vous plaît consulter notre astuces performances: http://www.vbenterprisetranslator.com/forum/vbet4-general-discussions/408-vbet-performance.html

Bien sûr, nous améliorons en permanence vBET. Dans la version majeure suivante, nous allons soutenir cache de fichiers:) Donc des améliorations de performance qui va se passer:) Encore s'il vous plaît noter que votre comparaison chemin n'est pas appropriée et ne pas montrer combien plus de ressources prend vBET - il montre comment beaucoup plus de ressources de votre forum prend avec votre plus de trafic.

[magmf]

vBET,

cache de fichiers ou mysql non requêtes mises en cache utiliser beaucoup d'I / O faisant charger dispositif d'être élevé.

Ma suggestion pour vous est d'utiliser le cache Memcache fichier au lieu o et mysql ou connectez vBET avec vboptimise qui ont déjà un soutien pour de nombreux types de caches

exemple de vboptimise utilisation avec vBET sera quelque chose comme ça


if ($cache = vb_optimise::$cache->get('unique language key'))
{
***//use cache
}
else
{
***// get from elsewhere
***vb_optimise::$cache->set('unique language key');
}



pourquoi vous n'essayez pas de parler avec Deceptor DragonByte Forums Tech - Technologies DragonByte Accueil (http://www.dragonbyte-tech.com/)

mon site est de sauver plus de 10 millions de requêtes par jour avec vboptimise et si vous travaillez avec lui à chacun de mieux soutenir vBET peut être heureux

jetez un oeil
vB Optimiser - Statistiques sur les ressources (http://www.dragonbyte-tech.com/vboptimisesites.php)

[vBET]

Merci pour vos conseils:) Je mets votre dernier message dans la liste TODO.

S'il vous plaît répondre aux questions donnée - ce qui est l'URL de votre forum et la version vBET utilisé. Nous voulons vérifier que vous avez d'installation appropriée - les versions précédentes utilisées vBET redirections double qui n'est plus utilisé, en cas de vBSEO elle nécessite l'intégration appropriée.

[magmf]

mon url est sous-linux.org
vBET 4.2.2
vBulletin 4.0.3
vBSEO 3.5 finale

[vBET]

OK - vous n'avez pas de double redirection et la version vBET dernier. En ce moment je ne peux que vous conseiller d'utiliser nos conseils performances (lien dans la première réponse) - en particulier dans le bloc de contenu non pertinent robots.txt - pages des membres, comme, le calendrier, et quelques autres (à noter que ces pages vont disparaître à partir des indices, mais il est bon pour votre référencement, car ce sont souvent considérées comme duplication de contenu).

Aussi - si votre serveur sera chaude traiter tous les 52 langues - s'il vous plaît envisager de désactiver certains de ceux-ci. En ce moment je comprends que ce qu'il gère, il vous suffit seraient plus heureux si avec moins de ressources;)

Nous travaillerons également sur le soutien du cache de fichiers non seulement, mais aussi les bibliothèques cache existant:) Merci encore pour votre soupçon.

[magmf]

VBET,

Je suis juste inquiet de l'avenir. Pour l'instant mon site peut gérer mais depuis vBET travaille je peux obtenir un grand nombre de nouveaux utilisateurs, ce qui peut rendre mon serveur tombe en panne: (

aussi je suis déjà bloquer contenu non pertinent dans mon fichier robots.txt

[vBET]

Beaucoup de nouveaux utilisateurs hawing va vous faire réfléchir sur l'évolutivité chaque fois que vous avez vBET ou non. Nous sommes vraiment heureux que vBET est de vous donner beaucoup de nouveaux utilisateurs et les revenus publicitaire possible:) Comme je l'ai déjà écrit, nous allons améliorer le système de cache:)

[vBET]

Prochaine publication aura cache de fichier complet qui va rendre vos pages plus rapide de générer pour les clients - même ceux ne se traduit pas:)

[bhanuprasad1981]

Prochaine publication aura cache de fichier complet qui va rendre vos pages plus rapide de générer pour les clients - même ceux ne se traduit pas:)

espérons nous obtenons ce bientôt:)

[vBET]

Ce mois-ci à coup sûr:) cache de fichiers complet pour les clients fonctionne bien sur nos forums, je veux juste ajouter quelques autres nouvelles fonctionnalités:)

[bhanuprasad1981]

toute mise à jour:)

[vBET]

Aujourd'hui, nous aurons la libération des vBET3.x - pour vBET4.x dans la première semaine du mois prochain:)

[bhanuprasad1981]

ohhh pas 15 jours de plus: (

[vBET]

Nous avons plus à faire en cas de vB4 (support + Friendly URLs plusieurs types de liens traduits pour vBSEO). Aussi cette fois-ci nous donner vos commentaires sur cette nouvelle fonctionnalité (c'est à dire que nous avons déjà eu l'idée d'un utilisateur pour permettre de le désactiver pour les pages normales). Alors il faudra encore quelque temps, mais à la fin vous aurez une meilleure solution qui est testé et avec des fonctionnalités supplémentaires:)