我的数据库服务器占用CPU超过100%
当我在recommendation
]# sudo ./mysqltuner.pl
>> MySQLTuner 1.2.0 - Major Hayden <major@mhtx.net>
>> 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
答案 0 :(得分:1)
MySQL吃得多100%,因为它可以这样做。想想,你有thyperthreading \ multicore \ multiprocessor服务器(或某种组合)。
在双核+类型线程系统上,您有4个虚拟CPU。 每个满载的CPU都会在监控程序中“100%负载”,例如顶部。 因此,一些可以利用多个处理器的单个程序(mysql服务器这样做)在这个例子中最多可以吃掉400%。
更多100%的负载本身并不是一个错误。这只是某种事物(好的或坏的)的症状。 什么是真正的问题,迫使你看看CPU负载?
“&gt; 100%加载”可能是由高查询率或查询复杂性引起的。
有几种方法可以帮助服务器更快地执行查询
首先 让我们试试你的脚本建议:
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负载。
还要考虑做:
检查查询以优化表结构,重新排列查询。但我认为,你的指数相当不错。
降低查询率(开玩笑; - ))