Serveur haut de la charge causée par mysql
Nous avons un VPS et l'expérience d'une haute charge provoquée par le serveur mysql. Actuellement, nous sommes incapables de trouver la cause de ce problème et, par conséquent, j'espère que quelqu'un peut me pointer dans la bonne direction.
Le VPS a 4 processeurs et de 4 go (18/11 EDIT: maintenant 8 GO) de RAM disponible. Les informations du disque n'est pas disponible, mais je crois qu'ils ne sont pas les plus rapides. Sur ce VPS, nous courons 1 magento CE 1.7.0.2 installation avec 20 boutiques en ligne et 8 installations wordpress (connecté au système magento). Nous avons quelques extensions personnalisées installé dans le système magento. Nous utilisons Ubuntu 13.04 avec Nginx 1.2.6, mysql 5.5.34, PHP 5.4.9, varnishd 3.0.4 et l'utilisation de l'APC comme un opcode cacher.
Lors de l'exécution de haut:
top - 13:58:21 up 17:51, 2 users, load average: 4.40, 4.09, 3.91
Tasks: 119 total, 3 running, 116 sleeping, 0 stopped, 0 zombie
%Cpu(s): 94.0 us, 3.5 sy, 0.0 ni, 2.0 id, 0.2 wa, 0.0 hi, 0.0 si, 0.3 st
KiB Mem: 4049220 total, 3101744 used, 947476 free, 253548 buffers
KiB Swap: 1044476 total, 22324 used, 1022152 free, 1442356 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22378 mysql 20 0 3439m 588m 7888 S 224.0 14.9 73:21.99 mysqld
24650 eemeega6 20 0 532m 56m 28m S 26.0 1.4 0:11.25 php5-fpm
24658 eemeega6 20 0 534m 57m 27m S 25.8 1.5 0:02.80 php5-fpm
24649 eemeega6 20 0 529m 58m 33m S 25.4 1.5 0:12.95 php5-fpm
24652 eemeega6 20 0 532m 61m 33m R 22.2 1.5 0:05.00 php5-fpm
24659 eemeega6 20 0 538m 59m 25m R 16.6 1.5 0:00.83 php5-fpm
24661 eemeega6 20 0 533m 55m 27m S 16.2 1.4 0:00.81 php5-fpm
24648 eemeega6 20 0 535m 65m 34m S 15.4 1.7 0:14.46 php5-fpm
24653 eemeega6 20 0 536m 64m 32m S 11.8 1.6 0:04.55 php5-fpm
24662 eemeega6 20 0 533m 49m 21m S 6.2 1.3 0:00.31 php5-fpm
1236 nobody 20 0 731m 369m 76m S 1.0 9.4 6:38.74 varnishd
22478 www-data 20 0 90532 10m 1044 S 0.4 0.3 0:07.56 nginx
10 root 20 0 0 0 0 S 0.2 0.0 2:29.32 rcu_sched
247 root 20 0 0 0 0 S 0.2 0.0 1:20.05 jbd2/dm-0-8`
Notre mon.cnf fichier a les valeurs suivantes:
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
bind-address = 127.0.0.1
key_buffer = 64M
max_allowed_packet = 1M
thread_stack = 192K
thread_cache_size = 8
myisam-recover = BACKUP
max_connections = 50
table_cache = 2048
table_definition_cache = 1024
#thread_concurrency = 10
thread_cache_size = 24
wait_timeout = 60
interactive_timeout = 60
query_cache_limit = 1M
query_cache_size = 64M
log_error = /var/log/mysql/error.log
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 8
#log-queries-not-using-indexes = /var/log/mysql/mysql-not-indexes.log
expire_logs_days = 10
max_binlog_size = 100M
#InnoDB
innodb_buffer_pool_size = 1280M
innodb_additional_mem_pool_size = 32M
innodb_log_buffer_size = 1M
innodb_thread_concurrency = 8
innodb_lock_wait_timeout = 60
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
#no-auto-rehash # faster start of mysql but no tab completition
[isamchk]
key_buffer = 16M
!includedir /etc/mysql/conf.d/
Notre sortie de mysqltuner.pl:
[--] Reads /Writes: 97% /3%
[--] Total buffers: 1.4G global + 2.7M per thread (50 max threads)
[OK] Maximum possible memory usage: 1.6G (40% of installed RAM)
[OK] Slow queries: 0% (0/1M)
[OK] Highest usage of available connections: 42% (21/50)
[OK] Key buffer size / total MyISAM indexes: 64.0M/35.4M
[OK] Key buffer hit rate: 99.8% (902K cached / 1K reads)
[!!] Query cache efficiency: 1.2% (16K cached / 1M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 739K sorts)
[!!] Joins performed without indexes: 129
[OK] Temporary tables created on disk: 5% (56K on disk / 1M total)
[OK] Thread cache hit rate: 99% (21 created / 16K connections)
[OK] Table cache hit rate: 24% (940 open / 3K opened)
[OK] Open file limit used: 9% (378/4K)
[OK] Table locks acquired immediately: 100% (4M immediate / 4M locks)
[OK] InnoDB data size / buffer pool: 339.7M/1.2G
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Adjust your join queries to always utilize indexes
Variables to adjust:
query_cache_limit (> 1M, or use smaller result sets)
join_buffer_size (> 128.0K, or always use indexes with joins)
Nous avons couru mysql plus longtemps que 24 heures et utilisé optimisé la plupart des paramètres en fonction de mysqltuner et tuning-primer ainsi. Utilisé réparer et optimiser les fonctions à optimiser toutes les bases de données.
Malheureusement mysql est un échange sur le disque et je pense que, par conséquent, la charge élevée de l'UC.
J'espère que quelqu'un peut me pointer dans la bonne direction, de trouver la cause de l'échange/de charge élevée. Nous ne vivons pas lent journal des requêtes beaucoup (uniquement lors de la réindexation de magento).
Si quelqu'un a besoin de plus d'informations, veuillez me le demander.
[SOLUTION]:
Donc, fondamentalement, nous avons résolu ce problème en désactivant les connexions persistantes en php.ini: mysql.allow_persistent = Off
Nous avons remarqué une baisse de l'utilisation du PROCESSEUR à partir de mysql. Tuning-prmier ne s'en plaint pas plus au sujet de nos applications de ne pas fermer leurs connexions. Nous avons quelques améliorations à faire, car pas toutes nos requêtes sont de l'utilisation d'index correctement, mais pour l'instant ce correctif nous aide à garder notre serveur.
Salutations,
Sander.
Joins performed without indexes: 129
J'ai vu des cas lors de l'ajout d'un indice de la charge CPU passée de 200 à 30%. Je voudrais commencer par la vérification de tiers tables.Merci Simon H, je suis à la recherche dans les requêtes lentes. Je dois l'avouer, il y a beaucoup de requêtes sans index en cours d'exécution. Je ne sais pas encore vraiment comment faire pour ajouter correctement l'index (sur les champs). Est l'augmentation de la join_buffer_size une bonne idée?
En général, l'ajout d'un index sur les colonnes qui sont utilisés pour les jointures est une bonne idée. Pour identifier les requêtes, vous pouvez utiliser la requête lente journal ou d'une requête comme
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, LEFT(INFO, 51200) AS Info FROM information_schema.PROCESSLIST;
pour identifier les requêtes en cours d'exécution.J'étais déjà à la recherche dans le non-indexé requêtes à l'intérieur de la base de données mysql-slow.fichier journal après l'activation de la log-requêtes-pas-à l'aide d'indices, d'où mon observation qu'il y avait beaucoup de requêtes sans index. Et, en effet, la plupart des requêtes sont de tiers (extensions de deviner!), ce qui le rend difficile à améliorer. Je vais passer par le fichier de la non-indexé requêtes et ajouter l'index. Va afficher les résultats plus tard. Merci beaucoup pour votre aide!
OriginalL'auteur Sander | 2013-11-15
Vous devez vous connecter pour publier un commentaire.
J'ai trouvé que les performances du serveur peut être "améliorée" par différentes choses, certains d'entre eux sont:
De savoir combien de mémoire vous devez laisser MySQL aller à travers l'ensemble de vos données mais aussi la fourniture de trésorerie d'exécution des requêtes SQL.
Vous pouvez lire tous liés à la mémoire des trucs ici et comprendre comment il fonctionne. Après cela, vous pouvez Permettre À Grande Page De Soutien
J'ai trouvé que vous pouvez améliorer les performances en permettant APC où vous pouvez réellement voir comment il améliore vos performances.
Aussi jeter un oeil à cette.
À l'aide de vernis, mais c'est une longue histoire, de type ici. Il descend à lui que vous avez besoin d'une très bonne config pour qu'il fonctionne parfaitement.
Si vous rencontrez toujours des problèmes, essayez d'utiliser Xdebug pour savoir qu'est-ce que la tenue de chaque processus.
Vous pourriez faire de ce dernier depuis le début, même si, comme votre MySQL va essayer d'exécuter tout u poser, mais 1 processus à la fois.
À cet effet, il va stocker tous les processus, il ne peut pas s'exécuter dans la mémoire et si cela arrive attribuer, elle déborde de votre mémoire.
Ma conclusion a été que, de plus en php/mysql liées (ce que votre serveur a besoin de temps ou de ressources) que vous pouvez ré-utiliser par l'obtenir à partir de votre trésorerie (Vernis, APC, MySQL mem), le plus de connexions qu'il peut gérer sans la création d'une haute charge du serveur.
Salut Sander, qu'est-APC dites-vous? Pouvez-vous poster le graphique s'il vous plaît? Quelle config utilisez-vous pour le vernis? Et enfin sont u assurez-vous que chaque WP et Magento site est en cours d'exécution avec un bon codage?
Bonjour Gelleby, Veuillez consulter notre APC schéma ici: emega.nl/apc-diagram.jpg Quant à notre Vernis de configuration, nous avons intégré le Phoenix PageCache extension et il est livré avec un fichier de configuration qui nous avons modifié nos ports et adresses ip. Je peux poster le fichier de configuration ci-dessus si vous voulez, mais je pense qu'il ya quelque chose de mal dans notre configuration de mysql qui je suis incapable de trouver, d'où mon post ici.
Ont u essayé d'utiliser d'autres paramètres pour MySQL? Suivi l'exemple sur cette page? Ou essayer de donner MySQL plus de mémoire?
Nous utilisons tuning-apprêt et mysqltuner pour l'optimisation de la configuration de mysql. Nous avons mis à niveau à 8 go de mémoire et j'ai mis mysql à utiliser 4 GO, mais mysqltuner et tuning-primer ont pas à se plaindre de toute la mémoire utilisée. J'ai essayé mysqlreport et ce fut montrant que 99% de la mémoire a été utilisé. Mais, après une hausse de mémoire, le problème est toujours persistant. Avez-vous des suggestions concernant la configuration de mysql? Merci pour votre coopération!
OriginalL'auteur gelleby
Avez-vous vérifié votre espace disponible? Nous avons eu quelques problèmes d'une journée à cause de l'énorme journal de fichiers txt que magento crée.À vérifier pour votre magento sites qu'ils ont désactivé le journal d'erreur de la part du Développeur->Paramètres de Journal. Il n'y a pas de limite de la taille de ces fichiers peut être! Au moins, c'est ce que je sais..
Espère que vous aide.
Cheers!
OriginalL'auteur vbak
Sander,
Ne savez pas sur le serveur de choses, bien que travaillant dans magento trouvé quelque chose d'utile, vous pourriez voulez regarder dans.
Certaines sociétés d'hébergement offrent de haute qualité de Magento solutions d'hébergement avec serveur optimisé afin d'assurer une meilleure Magento performance. Voici quelques exemples de ce que vous pourriez envisager:
Aussi une fois j'ai lu sur le clustering magento avec de grandes données et l'accès des clients (grandes transactions db), ce qui est fait sur le web, base de données et de niveau de système de fichiers.
Voici un guide pour le faire:
http://www.severalnines.com/blog/how-cluster-magento-nginx-and-mysql-multiple-servers-high-availability
Aussi peu simple, mais des conseils utiles sont les suivants :
Je crois qu'il doit mêmes choses disponibles pour wordpress.
Espère ci-dessus peut aider un peu si pas complètement.
Sander, mon plaisir peut-être alors vous devez déplacer une partie de votre site WP ou Magento à différents endroits, peut-être et je l'espère de tous vos sites sont génératrices de buisness.. et le serveur n'est pas en mesure d'assumer la charge.
Grâce SKV, mais je crois que notre serveur doit être en mesure de gérer ce type de charge. Nous voyons autour de 3k visiteurs uniques par jour (selon google analytics) et ont de 20 à 30 commandes par jour. Je pense que le serveur doit être capable de gérer cela et il l'a fait pour un couple de semaines. Mais alors, tout à coup mysql consommait le CPU et nous sommes maintenant à trouver comment résoudre ce problème. La charge du serveur augmenté, passant de 100 à 150% à 250 à 300% sans une grande différence dans la circulation ou des ordres.
OriginalL'auteur Sunil Verma