CPU Dual Quad Core Xeon, mas ainda alta carga

Question

Eu tenho um servidor dedicado com as seguintes especificações:

1. Dois Intel Xeon-Harpertown 5430-Quadcore [2,66 Ghz]
2. RAM DDRII de 4 GB
3. HD SATAII de 500 GB
4. CentOS 5.5 de 64 bits

O problema é que, mesmo com essas especificações, o MySQL ainda requer alto uso da CPU. Quase permanece acima de 150% o tempo todo e a maior parte do tempo fica acima de 300%. Eu vim a saber sobre isso depois de executar o comando "top". Agora, a coisa é assim que eu corro "watch mysqladmin pr" para ver o que está acontecendo, então não vejo nenhum problema. Embora existam consultas em execução, mas não são como algumas consultas muito pesadas, com exceção de uma ou duas.

Eu rodei "mysqltunner.pl" e ele me mostrou o seguinte:

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 362M (Tables: 255)
[--] Data in InnoDB tables: 880K (Tables: 55)
[!!] Total fragmented tables: 2

-------- Performance Metrics -------------------------------------------------
[--] Up for: 3h 26m 51s (1M q [138.122 qps], 43K conn, TX: 3B, RX: 246M)
[--] Reads / Writes: 93% / 7%
[--] Total buffers: 830.0M global + 3.9M per thread (300 max threads)
[OK] Maximum possible memory usage: 1.9G (50% of installed RAM)
[OK] Slow queries: 0% (47/1M)
[OK] Highest usage of available connections: 6% (18/300)
[OK] Key buffer size / total MyISAM indexes: 256.0M/169.9M
[OK] Key buffer hit rate: 100.0% (5B cached / 36K reads)
[OK] Query cache efficiency: 84.2% (1M cached / 1M selects)
[!!] Query cache prunes per day: 338346
[OK] Sorts requiring temporary tables: 0% (989 temp sorts / 242K sorts)
[!!] Temporary tables created on disk: 38% (160K on disk / 420K total)
[OK] Thread cache hit rate: 99% (18 created / 43K connections)
[OK] Table cache hit rate: 98% (446 open / 452 opened)
[OK] Open file limit used: 1% (663/65K)
[OK] Table locks acquired immediately: 99% (684K immediate / 684K locks)
[OK] InnoDB data size / buffer pool: 880.0K/8.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Temporary table size is already large - reduce result set size
    Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
    query_cache_size (> 64M)
------------------------------------------------------------------------------

Como você pode ver, a maioria dos parâmetros estão corretos, exceto alguns como 2 tabelas de desfragmentação e tamanho pequeno do cache de consulta. Mesmo se eu corrigir isso, não vejo nenhum aumento perceptível de desempenho. Então agora eu tenho voltado minha atenção para este "tabelas temporárias criadas no disco de 38%" Você acha que é por causa disso que o MySQL está tomando muito tempo de CPU? Como posso melhorar isso? Ou você acha que há algo mais depois de ver o resultado acima?

Atualmente, minha configuração referente a tabelas temporárias no arquivo de configuração do MySQL é:

tmp_table_size = 1000 milhões max_heap_table_size = 500 milhões

Mesmo se eu aumentar esses valores, o MySQL ainda cria tabelas temporárias no disco. Como faço para corrigir isso? Eu posso ver mysqltuner.pl também diz que eu preciso reduzir o meu conjunto de resultados, mas se eu der muita RAM para criar tabelas temporárias não deve o problema ir embora?

Obrigado

    

Answer 1

Você pode estar lidando com o sintoma e não com o problema. O lugar para começar é observar o que está tornando sua carga tão alta. É atividade do modo kernel? É atividade do usuário? Se for o modo kernel, meu palpite é que você está tendo problemas para gravar em disco com rapidez suficiente e o io está em estado de espera. Olhe para ferramentas como top, iostat, vmstat, etc para começar a reduzir o seu problema.

Com uma carga tão alta, é provável que você esteja vendo algum tipo de espera que esteja causando o enfileiramento de pedidos no kernel.

    

Answer 2

Por favor, verifique várias coisas:

1) join_buffer_size link
link

2) sort_buffer_size
link

3) Criação de arquivos temporários link

4) SELECT consultas que possuem sub-SELECTs

Você provavelmente tem muitas consultas que fazem associações lentas devido à presença de tabelas sem precisar de colunas indexadas.

Se seu buffer de junção / buffer de classificação em uma determinada conexão de banco de dados for muito pequeno para manter resultados temporários, o buffer de associação e / ou o buffer de classificação precisariam ser exibidos em disco como uma tabela temporária.