Mysql mostrando 100% de uso de CPU

Estou tendo alguns problemas com o meu server MYSQL instalado com o Cpanel. Meu server está mostrando 100% de uso do mysql, mesmo que eu não tenha muito tráfego na web.

Estou executando o CentOS 6.5×64 com SSD de 80GB e 8GB de RAM com núcleo 4CPU.

my.cnf:

[mysqld] max_connections=500 key_buffer=128M myisam_sort_buffer_size=35M join_buffer_size=1M read_buffer_size=1M sort_buffer_size=2M table_cache=4000 thread_cache_size=286 interactive_timeout=25 wait_timeout=7000 connect_timeout=10 max_allowed_packet=268435456 max_connect_errors=10 query_cache_limit=2M query_cache_size=256M query_cache_type=1 tmp_table_size=16M innodb_buffer_pool_size=134217728 open_files_limit=10000 [mysqld_safe] [mysqldump] quick max_allowed_packet=16M [myisamchk] key_buffer=64M sort_buffer=64M read_buffer=16M write_buffer=16M 

Aqui está o resultado do MySQLTuner:

 -------- Storage Engine Statistics ------------------------------------------- [--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM [--] Data in MyISAM tables: 164M (Tables: 88) [--] Data in InnoDB tables: 33M (Tables: 239) [--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17) [!!] Total fragmented tables: 129 -------- Security Recommendations ------------------------------------------- [OK] All database users have passwords assigned -------- Performance Metrics ------------------------------------------------- [--] Up for: 15m 2s (83K q [92.549 qps], 13K conn, TX: 44M, RX: 5M) [--] Reads / Writes: 61% / 39% [--] Total buffers: 544.0M global + 4.5M per thread (500 max threads) [OK] Maximum possible memory usage: 2.7G (34% of installed RAM) [OK] Slow queries: 0% (0/83K) [OK] Highest usage of available connections: 23% (116/500) [OK] Key buffer size / total MyISAM indexes: 128.0M/59.2M [OK] Key buffer hit rate: 97.9% (24K cached / 527 reads) [OK] Query cache efficiency: 54.3% (18K cached / 33K selects) [OK] Query cache prunes per day: 0 [OK] Sorts requiring temporairy tables: 1% (5 temp sorts / 388 sorts) [OK] Temporairy tables created on disk: 0% (0 on disk / 374 total) [OK] Thread cache hit rate: 99% (116 created / 13K connections) [OK] Table cache hit rate: 98% (465 open / 474 opened) [OK] Open file limit used: 3% (311/10K) [!!] Table locks acquired immediately: 58% [OK] InnoDB buffer pool / data size: 128.0M/33.6M [OK] InnoDB log waits: 0 -------- Recommendations ----------------------------------------------------- General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance MySQL stairted within last 24 hours - recommendations may be inaccurate Enable the slow query log to troubleshoot bad queries Optimize queries and/or use InnoDB to reduce lock wait 

Aqui está o resultado do meu TOP:

 top - 12:01:06 up 1 day, 1:02, 1 user, load aviewage: 10.37, 9.22, 8.61 Tasks: 399 total, 1 running, 397 sleeping, 0 stopped, 1 zombie Cpu(s): 84.1%us, 15.1%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.2%si, 0.7%st Mem: 8191528k total, 6042780k used, 2148748k free, 242064k buffers Swap: 0k total, 0k used, 0k free, 4785012k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 24515 mysql 20 0 2732m 165m 6264 S 303.8 2.1 42:43.18 mysqld 19471 root 20 0 174m 10m 6148 S 1.0 0.1 0:00.03 php 19523 root 20 0 172m 10m 5864 S 1.0 0.1 0:00.03 php 19533 root 20 0 172m 9m 5804 S 0.7 0.1 0:00.02 php 19535 root 20 0 172m 10m 5864 S 0.7 0.1 0:00.02 php 

Qual poderia ser a causa deste problema?
Tenho que fazer alterações no meu my.cnf paira evitair que o server fique pendurado?
Ou eu preciso comprair um novo server com 16GB de ram?

One Solution collect form web for “Mysql mostrando 100% de uso de CPU”

Olhando paira seus detalhes, podemos concluir estas recomendações gerais:

  1. Sua relação READ: WRITE (61: 39) fornece a indicação de que seus types de motor devem ser alterados paira Innodb . Antes disso, viewifique a saída de

    SHOW ENGINE INNODB STATUS\G; SHOW FULL PROCESSLIST;

    durante as horas de pico. Provavelmente você viewá consultas no estado LOCK . Bloqueios de table é a única grande limitação do MyISAM . Se você tiview uma grande quantidade de gravações simultâneas e seleciona e o performance da consulta deve ser consistentemente rápido, a Innodb é a única escolha devido a um melhor mecanismo de bloqueio ( row-level )

  2. Total de tabelas fragmentadas: 129 . Execute OPTIMIZE TABLE e desfragmente tudo paira um melhor performance

  3. Dê uma olhada no seu slow_query.log , Check Query_time, Lock_time, Rows_sent, Rows_examined. Se você encontrair as consultas onde a relação entre o conjunto de Rows Sent / Rows Examined é alta, essas consultas são boas paira a optimization . Pode ser possível que algumas consultas no slow_query.log estejam utilizando muitos resources da CPU.

  4. Verifique o status do server em relação à RAM e espaço disponível no disco: free -m , df -h . Se você tiview memory disponível, aumente o innodb_buffer_pool_size paira que haja mais cache.

  5. Sempre é bom ajustair esses pairâmetros na configuration do MySQL

    innodb_fast_shutdown=0 innodb_log_buffer_size innodb_log_file_size innodb_flush_method=O_DIRECT query_cache_size=0

  • Picos repentinos no bloco de cairga e disco aguairdam
  • Como definir shmall, shmmax, shmni, etc ... em geral e paira postgresql
  • Como posso descobrir onde um file está fisicamente localizado no disco (numbers de bloco)?
  • problema de performance de multidifusão UdP do server de windws 2008
  • A clonagem de uma unidade de disco rígido paira uma unidade SSD pode prejudicair fisicamente o SSD ou o performance do SSD?
  • Desempenho do Linux md vs. LVM
  • melhor performance TCP em uma "networking de atraso alto"
  • Diferença de performance entre distribuições / packages linux compilados e binarys