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.

Êtes-vous sûr que les requêtes lentes ne sont pas un problème? 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