0

我的数据库服务器占用超过 100% 的 CPU

当我运行 mysqltuner 时，它给出了以下内容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

4

1 回答 1

1

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

在双核 + 类型线程系统上，您有 4 个虚拟 CPU。每一个满载的 CPU 都会使监控程序中的“100% 负载”如此之高。因此，在该示例中，一些可以利用多个处理器（mysql 服务器这样做）的单个程序最多可以吃掉 400%。

更多的 100% 负载本身并不是一个错误。这只是某事（好或坏）的症状。什么是真正的问题，迫使您查看 CPU 负载？

">100% load" 可能是由高查询率或查询复杂性引起的。

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

首先，让我们试试您的脚本建议的内容：

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)

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

还考虑做：

  • 检查查询以优化表结构，重新排列查询。但我认为，你的指数相当不错。

  • 降低查询率（开玩笑;-)）

于 2013-04-12T11:25:59.840 回答