数据库服务器CPU

吃超过100％

吃超过100％，当我运行mysqltuner其给出以下recommendation

]# sudo ./mysqltuner.pl 

>> MySQLTuner 1.2.0 - Major Hayden <[email protected]> 
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/ 
>> Run with '--help' for additional options and output filtering 

-------- General Statistics -------------------------------------------------- 
[--] Skipped version check for MySQLTuner script 
[OK] Currently running supported MySQL version 5.0.92-community 
[!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM 

-------- Storage Engine Statistics ------------------------------------------- 
[--] Status: +Archive -BDB +Federated +InnoDB -ISAM -NDBCluster 
[--] Data in MyISAM tables: 1G (Tables: 9347) 
[--] Data in InnoDB tables: 477M (Tables: 1803) 
[--] Data in MEMORY tables: 0B (Tables: 4) 
[!!] Total fragmented tables: 98 

-------- Security Recommendations ------------------------------------------- 
[OK] All database users have passwords assigned 

-------- Performance Metrics ------------------------------------------------- 
[--] Up for: 2d 8h 25m 8s (87M q [430.053 qps], 534K conn, TX: 2B, RX: 2B) 
[--] Reads/Writes: 89%/11% 
[--] Total buffers: 670.0M global + 2.7M per thread (100 max threads) 
[OK] Maximum possible memory usage: 938.7M (30% of installed RAM) 
[OK] Slow queries: 0% (1K/87M) 
[!!] Highest connection usage: 100% (101/100) 
[OK] Key buffer size/total MyISAM indexes: 8.0M/610.0M 
[OK] Key buffer hit rate: 96.9% (10B cached/331M reads) 
[OK] Query cache efficiency: 89.9% (73M cached/81M selects) 
[!!] Query cache prunes per day: 148657 
[OK] Sorts requiring temporary tables: 0% (467 temp sorts/560K sorts) 
[!!] Joins performed without indexes: 11968 
[OK] Temporary tables created on disk: 23% (334K on disk/1M total) 
[OK] Thread cache hit rate: 86% (71K created/534K connections) 
[!!] Table cache hit rate: 0% (80 open/918K opened) 
[OK] Open file limit used: 11% (117/1K) 
[OK] Table locks acquired immediately: 96% (11M immediate/11M locks) 
[OK] InnoDB data size/buffer pool: 477.2M/500.0M 

-------- Recommendations ----------------------------------------------------- 
General recommendations: 
    Run OPTIMIZE TABLE to defragment tables for better performance 
    Enable the slow query log to troubleshoot bad queries 
    Reduce or eliminate persistent connections to reduce connection usage 
    Adjust your join queries to always utilize indexes 
    Increase table_cache gradually to avoid file descriptor limits 
Variables to adjust: 
    max_connections (> 100) 
    wait_timeout (< 28800) 
    interactive_timeout (< 28800) 
    query_cache_size (> 96M) 
    join_buffer_size (> 128.0K, or always use indexes with joins) 
    table_cache (> 80) 


    Already my.cnf value is 

[mysqld] 
innodb_buffer_pool_size = 500M 
max_heap_table_size = 64M 
query_cache_limit = 1M 
query_cache_size = 96M 
query_cache_type = 1 
table_cache = 128 
thread_cache_size = 4 
tmp_table_size = 96M

现在我能在my.cnf做好心帮我 tks

来源

2013-04-12 Piyush Bhardwaj

输出是从MySQL - 不是SQL服务器。请正确标记。 – Oded

MySQL吃得更多100％，因为它可以做到这一点。想想，你有超线程\多核\多处理器服务器（或某种组合）。

在双核+型号系统上，您有4个虚拟CPU。每个满载的CPU都会在监控程序中“100％加载”，如top。因此，在这个例子中，一些可以利用多个处理器（mysql服务器这样做）的单个程序可以吃掉多达400％。

更多100％负载本身不是一个错误。这只是某种东西的症状（好或坏）。什么是真正的问题，迫使你看CPU负载？

“> 100％负载”可能由高查询率或查询复杂性引起。

有几种方法来帮助服务器执行查询更快

ALL 的首先，让我们试着劝你的脚本：

Variables to adjust: 
    max_connections (> 100) 
    wait_timeout (< 28800) 
    interactive_timeout (< 28800) 
    query_cache_size (> 96M) 
    join_buffer_size (> 128.0K, or always use indexes with joins) 
    table_cache (> 80)

这可以解决一些问题，查询和索引缓存子系统。而且它还允许服务器吃更多的RAM，并行处理更多的查询并提升CPU负载。

也可以考虑做：

检查查询优化表结构，重新查询。但我认为，您的指标非常好。
降低查询速度（开玩笑;-)）

来源

2013-04-12 11:25:59

数据库服务器CPU

回答

相关问题