☰

双四核Xeon CPU但负载仍然很高

tag-icon • tag-icon mysql cpu-usage
双四核Xeon CPU但负载仍然很高

我有一台专用服务器，其规格如下：

  1. 两台 Intel Xeon-Harpertown 5430-四核 [2.66 Ghz]
  2. 4GB DDRII 内存
  3. 500GB SATAII 硬盘
  4. CentOS 5.5 64 位

问题是，即使有这样的规格，MySQL 的 CPU 使用率仍然很高。它几乎一直保持在 150% 以上，大多数时候超过 300%。我在运行“top”命令后才知道这一点。现在的情况是，只要我运行“watch mysqladmin pr”来查看发生了什么，我就不会看到任何问题。虽然有查询在运行，但它们并不像一些非常繁重的查询，除非可能有一两个。

我运行了“mysqltunner.pl”，它显示了以下内容：

-------- 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)
------------------------------------------------------------------------------

如您所见，除了几个参数（如 2 个碎片整理表和较小的查询缓存大小）外，大多数参数都是正确的。即使我修复了这个问题，我也没有看到任何明显的性能提升。所以现在我把注意力转向了“磁盘上创建的临时表 38%”你认为这是因为 MySQL 占用了太多 CPU 时间吗？我该如何改进它？或者你认为在查看上述结果后还有其他原因吗？

目前我在 MySQL 配置文件中关于临时表的设置是：

tmp_table_size=1000M 最大堆表大小=500M

即使我增加这些值，MySQL 仍然会在磁盘上创建临时表。我该如何修复它？我可以看到 mysqltuner.pl 也说我需要减少结果集，但如果我给它足够的 RAM 来创建临时表，问题应该会消失吗？

谢谢

答案1

您可能只解决了症状，而没有解决根本问题。首先要查看是什么导致您的负载如此之高。是内核模式活动吗？是用户空间活动吗？如果是内核模式，我猜您在写入磁盘时遇到了问题，速度不够快，并且 io 处于等待状态。查看 top、iostat、vmstat 等工具，开始缩小问题范围。

当负载如此之高时，您可能会看到某种导致内核对请求进行排队的等待。

答案2

请检查以下几件事：

1）join_buffer_size
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_join_buffer_size
http://www.mysqlperformanceblog.com/2010/07/05/how-is-join_buffer_size-allocated/

2）sort_buffer_size
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_join_buffer_size

3）创建临时文件
http://dev.mysql.com/doc/refman/5.1/en/temporary-files.html

4）带有子 SELECT 的 SELECT 查询

您可能有许多查询由于没有所需列被索引而导致连接速度变慢。

如果给定 DB 连接中的连接缓冲区/排序缓冲区太小而无法保存临时结果，则连接缓冲区和/或排序缓冲区必须作为临时表分页到磁盘。

相关内容