2014-05-06 2 views
-1

Je gère un site qui ne streaming vidéo, le site est en cours d'exécution au large:100% CPU MySQL Utilisez

Intel (R) Xeon (R) CPU @ 3.10GHz E31220

16 Go de RAM

2 x 2 To RAID1

1Gbit bande passante est unmetered pas un problème car l'utilisation est seulement 150-250mbit etc.

Sur cette machine, je lance ce qui suit: - apache pour héberger l '[url] www.domain.com [/ url] - serveur mysql (apt-get install mysql-server)

Tout va bien maintenant, sauf qu'il y a maintenant 200 personnes qui téléchargent des vidéos à un moment donné. Donc maintenant je remarque que le site se charge plus lentement .. Je crois que c'est parce que mysql utilise 100% cpu. Ci-dessous j'ai collé mon top, et aussi mes paramètres mysql. Quelqu'un pourrait-il m'aider avec les paramètres mysql pour ralentir cela? Je me rends compte qu'à un certain moment je dois déplacer le serveur mysql vers un autre ordinateur seul, mais je pense toujours avec les paramètres actuels sur le point de publier, il utiliserait encore 100% cpu même sur la machine autonome .. donc je pense que les paramètres doivent être changés? ou quelqu'un peut-il me guider. En outre, je ne peux pas baisser le wait_timeout parce que quand je fais cela, il provoque des erreurs sur le script de conversion vidéo qui récupère les vidéos et les convertit et parfois il peut prendre un certain temps, je ne sais pas si c'est un problème ou

my.cnf: 
# * Fine Tuning 
# 
max_allowed_packet  = 16M 
thread_stack   = 1M 
thread_cache_size  = 50 
# This replaces the startup script and checks MyISAM tables if needed 
# the first time they are touched 
myisam-recover   = BACKUP 
max_connections  = 1000 
wait_timeout   = 20000 
tmp_table_size   = 500M 
max_heap_table_size  = 1000M 
table_cache   = 1000 
#thread_concurrency  = 10 
# 
# * Query Cache Configuration 
# 
query_cache_limit  = 4M 
query_cache_size  = 64M 
# 
# * Logging and Replication 
# 
# Both location gets rotated by the cronjob. 
# Be aware that this log type is a performance killer. 
# As of 5.1 you can enable the log at runtime! 
#general_log_file  = /var/log/mysql/mysql.log 
#general_log    = 1 
# 
# Error log - should be very few entries. 
# 
log_error = /var/log/mysql/error.log 
# 
# Here you can see queries with especially long duration 
#log_slow_queries  = /var/log/mysql/mysql-slow.log 
#long_query_time = 2 
#log-queries-not-using-indexes 
# 
# The following can be used as easy to replay backup logs or for replication. 
# note: if you are setting up a replication slave, see README.Debian about 
#  other settings you may need to change. 
#server-id    = 1 
#log_bin      = /var/log/mysql/mysql-bin.log 
expire_logs_days  = 10 
max_binlog_size   = 100M 
#binlog_do_db   = include_database_name 
#binlog_ignore_db  = include_database_name 
# 
# * InnoDB 
# 
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/. 
# Read the manual for more InnoDB related options. There are many! 
# 
# * Security Features 
# 
# Read the manual, too, if you want chroot! 
# chroot = /var/lib/mysql/ 
# 
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca". 
# 
# ssl-ca=/etc/mysql/cacert.pem 
# ssl-cert=/etc/mysql/server-cert.pem 
# ssl-key=/etc/mysql/server-key.pem 



[mysqldump] 
quick 
quote-names 
max_allowed_packet  = 16M 

[mysql] 
#no-auto-rehash # faster start of mysql but no tab completition 

[isamchk] 
key_buffer_size    = 64M 

---------------------------------------- 

    >> MySQLTuner 1.1.1 - Major Hayden <[email protected]> 
    >> Bug reports, feature requests, and downloads at [url]http://mysqltuner.com/[/url] 
    >> Run with '--help' for additional options and output filtering 
    [!!] Successfully authenticated with no password - SECURITY RISK! 

-------- General Statistics -------------------------------------------------- 

    [--] Skipped version check for MySQLTuner script 
    [OK] Currently running supported MySQL version 5.5.37-0ubuntu0.13.10.1 
    [OK] Operating on 64-bit architecture 

-------- Storage Engine Statistics ------------------------------------------- 

    [--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster 
    [--] Data in MyISAM tables: 1G (Tables: 41) 
    [--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17) 
    [!!] InnoDB is enabled but isn't being used 
    [!!] Total fragmented tables: 4 

-------- Security Recommendations ------------------------------------------- 

    [OK] All database users have passwords assigned 

-------- Performance Metrics ------------------------------------------------- 
[--] Up for: 22h 23m 46s (5M q [69.809 qps], 1M conn, TX: 8B, RX: 4B) 
[--] Reads/Writes: 29%/71% 
[--] Total buffers: 716.0M global + 3.5M per thread (1000 max threads) 
[OK] Maximum possible memory usage: 4.1G (26% of installed RAM) 
[OK] Slow queries: 0% (2/5M) 
[OK] Highest usage of available connections: 77% (775/1000) 
[OK] Key buffer size/total MyISAM indexes: 8.0M/119.0M 
[OK] Key buffer hit rate: 99.4% (33M cached/208K reads) 
[OK] Query cache efficiency: 67.6% (1M cached/1M selects) 
[OK] Query cache prunes per day: 0 
[OK] Sorts requiring temporary tables: 0% (0 temp sorts/921 sorts) 
[!!] Temporary tables created on disk: 28% (244 on disk/849 total) 
[OK] Thread cache hit rate: 98% (17K created/1M connections) 
[OK] Table cache hit rate: 62% (428 open/681 opened) 
[OK] Open file limit used: 9% (476/5K) 
[!!] Table locks acquired immediately: 55% 

-------- Recommendations ----------------------------------------------------- 
General recommendations: 
    Add skip-innodb to MySQL configuration to disable InnoDB 
    Run OPTIMIZE TABLE to defragment tables for better performance 
    MySQL started within last 24 hours - recommendations may be inaccurate 
    Enable the slow query log to troubleshoot bad queries 
    Temporary table size is already large - reduce result set size 
    Reduce your SELECT DISTINCT queries without LIMIT clauses 
    Optimize queries and/or use InnoDB to reduce lock wait 
------------------------------------------------------- 

Il est dit d'optimiser la table, mais comment faire? Sur le web, j'ai essayé de chercher et a trouvé pour exécuter la commande de contrôle de MySQL, mais je reçois

# mysqlcheck -u root -p --auto-repair --check --optimize --all-databases 
Error: mysqlcheck doesn't support multiple contradicting commands. 

De plus, est-il sûr d'optimiser simplement la base de données? Il ne fera pas mal ou quoi que ce soit? Bien sûr, mal de retour en premier

J'ai activé journal des requêtes lentes maintenant, mais jusqu'à présent, rien encore ..

À un moment donné, je le disais mysqltuner avait atteint 996/1000 connexions .. mais quand je suis allé pour aller augmenter le max_connections à 2000 et puis j'ai redémarré le serveur mysql, le site est devenu encore plus lent qu'auparavant. Peut-être que je ne devrais pas redémarrer le serveur mysql et juste ajuster globalement?

top - 23:27:42 up 11 days, 5:28, 3 users, load average: 2.41, 4.40, 5.97 
Tasks: 269 total, 3 running, 265 sleeping, 0 stopped, 1 zombie 
%Cpu(s): 24.3 us, 5.6 sy, 0.0 ni, 69.3 id, 0.3 wa, 0.0 hi, 0.5 si, 0.0 st 
KiB Mem: 16408692 total, 16237624 used, 171068 free,  9552 buffers 
KiB Swap: 15624184 total,  8220 used, 15615964 free, 15072644 cached 

    PID USER  PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND                
29178 mysql  20 0 2662m 73m 7280 S 100.4 0.5 4:49.03 /usr/sbin/mysqld              
29428 daemon 20 0 544m 19m 7048 S 2.7 0.1 0:07.81 /usr/sbin/apache2 -k start            
29943 daemon 20 0 543m 17m 5428 S 2.0 0.1 0:02.57 /usr/sbin/apache2 -k start            
29945 daemon 20 0 543m 17m 5352 S 2.0 0.1 0:00.76 /usr/sbin/apache2 -k start            
29672 daemon 20 0 543m 16m 4696 S 1.7 0.1 0:00.63 /usr/sbin/apache2 -k start            
29792 daemon 20 0 544m 17m 5396 S 1.3 0.1 0:00.15 /usr/sbin/apache2 -k start            
    183 root  20 0  0 0 0 S 1.0 0.0 8:51.20 [md0_raid1]               
29445 daemon 20 0 543m 16m 4700 S 0.7 0.1 0:01.04 /usr/sbin/apache2 -k start            
29744 daemon 20 0 543m 16m 5384 S 0.7 0.1 0:00.23 /usr/sbin/apache2 -k start            
7705 root  35 15  0 0 0 D 0.3 0.0 2:27.65 [md0_resync]               
29435 daemon 20 0 543m 17m 5596 S 0.3 0.1 0:00.37 /usr/sbin/apache2 -k start            
29451 daemon 20 0 543m 17m 5356 S 0.3 0.1 0:00.44 /usr/sbin/apache2 -k start            
29453 daemon 20 0  0 0 0 Z 0.3 0.0 0:00.07 [apache2] <defunct>             
29501 daemon 20 0 543m 16m 5324 S 0.3 0.1 0:00.10 /usr/sbin/apache2 -k start            
29518 daemon 20 0 543m 17m 5948 S 0.3 0.1 0:00.31 /usr/sbin/apache2 -k start            
29534 daemon 20 0 543m 17m 5456 S 0.3 0.1 0:00.42 /usr/sbin/apache2 -k start            
29539 daemon 20 0 543m 16m 5348 S 0.3 0.1 0:00.24 /usr/sbin/apache2 -k start            
29542 daemon 20 0 543m 16m 4680 S 0.3 0.1 0:00.51 /usr/sbin/apache2 -k start            
29549 daemon 20 0 543m 17m 5352 S 0.3 0.1 0:00.90 /usr/sbin/apache2 -k start            
29656 daemon 20 0 543m 16m 4792 S 0.3 0.1 0:00.25 /usr/sbin/apache2 -k start            
29673 daemon 20 0 543m 16m 5392 R 0.3 0.1 0:00.20 /usr/sbin/apache2 -k start            
29682 daemon 20 0 543m 16m 4704 S 0.3 0.1 0:00.58 /usr/sbin/apache2 -k start            
29791 daemon 20 0 543m 17m 5392 S 0.3 0.1 0:00.81 /usr/sbin/apache2 -k start            
29793 daemon 20 0 543m 17m 5712 S 0.3 0.1 0:00.12 /usr/sbin/apache2 -k start            
29926 daemon 20 0 543m 16m 4704 S 0.3 0.1 0:00.44 /usr/sbin/apache2 -k start            
29956 daemon 20 0 543m 16m 4700 S 0.3 0.1 0:00.33 /usr/sbin/apache2 -k start  

===================================== 


# free -tm 
      total  used  free  shared buffers  cached 
Mem:   16024  15861  162   0   4  14351 
-/+ buffers/cache:  1506  14517 
Swap:  15257   8  15249 
Total:  31282  15870  15411 

question supplémentaire: Si je fais passer le mysql à sa propre machine, si le disque dur est SSDs? est-ce mieux pour mysql? et aurait 32 Go de RAM suffisante

La chose la plus importante dans la base de données est la table de sessions qui peut obtenir aussi grand que 1,5 Go à ce jour .. mais je l'effacer et la base de données se rétrécit sous 100mb

+1

Cette question devrait probablement être posée dans [Server Fault] (http://www.serverfault.com). – vvanasten

+0

Après avoir augmenté le cache des requêtes, mysql utilise toujours 100% cpu. J'ai augmenté le key_buffer_size à 256mb et maintenant son fait un peu mieux mais toujours l'utilisation globale de n'importe où de 50 à 90% cpu par moments .. est-ce normal? – user3609978

Répondre

0

I crois que vous ne pouvez pas --check et --optimize en même temps, parce que --check signifie "juste vérifier, ne touchez à rien".

Il n'est pas normal que MySQL utilise beaucoup de CPU, car son principal objectif est de stocker et d'extraire des informations, et non de les traiter. Il devrait cependant utiliser beaucoup de mémoire, en fait il est bon d'autoriser MySQL à utiliser autant de mémoire que vous en avez. Après tout, la mémoire inutilisée est gaspillée en mémoire. Je vois que MySQL utilise 0.5%. C'est définitivement un mauvais signe. Réglez votre cache de requête.

Vous utilisez peut-être trop de requêtes SQL sur votre site, mais si je devais deviner je crois que votre problème peut être un manque d'indexation correcte dans vos tables.

Lorsque vous faites des choses comme SELECT * FROM parent, child WHERE child.parent_id = parent.id, il est important que parent.id soit un PRIMARY KEY afin de permettre à MySQL d'effectuer sa tâche plus efficacement.

+0

À quoi dois-je définir mon query_cache_limit? de 4m à? si la machine a 16gb de ram lorsque je définis la taille du cache de requête à dire .. 264 ou .. 1600 .. puis je redémarre le serveur mysql son comme le site prend une éternité à charger – user3609978

+0

Le réglage à 8 Go pourrait être un bon début. Si vous ne pensez pas qu'Apache ou d'autres processus auront besoin des 8 Go restants pour quelque chose, vous pouvez le régler jusqu'à 12 Go. – Havenard