我刚刚读完这个旧的问答，它有一些与我们类似的设置的非常好的详细信息，但不幸的是我们的问题（现在）不在于复制。
我们有一个新的主数据库服务器（服务器版本：5.5.27-log MySQL Community Server）位于裸机服务器上，其规格如下：
- 2 个英特尔 E5-2620-v2
- 64GB 内存
- 2 个 Fusion-io 600Gb 卡 (Raid 1)，用于 MySql
- 1 个适用于 Centos 6.5 的 SSD
- 1Gbps 网络
超线程尚未在服务器上禁用，因为对于这是否有助于大内存系统存在不同的看法，但我们并不反对尝试它。
我们目前将数据复制到在 SSD 集群上虚拟化的 3 个从属服务器。我们原本要复制到 4 个从属服务器，但这似乎对 SSD 集群来说太多了，而且我们出现了一段时间的延迟。
所有表都是 InnoDB，主数据库和从数据库写入介于3.5K - 2.5K QPS， 同时 阅读在主人身上7.5k - 10k QPS。
主DB的设置如下：
long-query-time=10
slow-query-log
max_connections=500
max_tmp_tables=1024
key_buffer = 1024M
max_allowed_packet = 32M
net_read_timeout=180
net_write_timeout=180
table_cache = 512
thread_cache = 32
thread_concurrency = 4
query_cache_type = 0
query_cache_size = 0M
innodb_file_per_table
innodb_file_format=barracuda
innodb_buffer_pool_size=49152M
innodb_buffer_pool_instances=2
innodb_read_io_threads=16
innodb_write_io_threads=16
innodb_io_capacity = 500
innodb_additional_mem_pool_size=20M
innodb_log_file_size=1024M
innodb_log_files_in_group = 2
innodb_doublewrite=0
innodb_flush_log_at_trx_commit=2
innodb_flush_method=O_DIRECT
我们的问题是 CPU 负载，尤其是 Sys Cpu。从 mpstat 中可以看到，iowait 为 0%，而 %sys 非常高。
Linux 2.6.32-431.29.2.el6.x86_64 13/11/14 _x86_64_ (24 CPU)
13:57:18 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
13:57:19 all 23.35 0.00 74.65 0.00 0.00 0.88 0.00 0.00 1.13
13:57:20 all 21.95 0.00 75.50 0.00 0.00 0.96 0.00 0.00 1.59
13:57:21 all 23.74 0.00 72.63 0.00 0.00 1.00 0.00 0.00 2.63
13:57:22 all 23.88 0.00 71.64 0.00 0.00 1.17 0.00 0.00 3.31
13:57:23 all 23.26 0.00 73.89 0.00 0.00 0.92 0.00 0.00 1.92
13:57:24 all 22.87 0.00 74.87 0.00 0.00 1.00 0.00 0.00 1.25
13:57:25 all 23.41 0.00 74.51 0.00 0.00 0.96 0.00 0.00 1.12
以前，主数据库在虚拟化服务器（与从属服务器相同的 SSD 集群）上运行。它在 vSphere 集群中拥有自己的主机，该主机具有：
- 2 个英特尔 X5570
- 32GB 内存
- 集群共享的 SSD
之前从来没有出现过任何问题，尽管 SQL 吞吐量较低，但服务器运行多年且没有故障。
查询都很简单，索引已针对插入和更新进行了优化，因为复杂的客户端查询是在从属服务器上执行的。没有删除，只有插入和更新。大多数表（所有大表）都有主键。
一旦内存缓冲区满了，CPU 使用率似乎就会增加，并且 MySql 是服务器上唯一运行的应用程序。
连接数范围约为 200-400，其中约 100-200 个正在运行。Innodb 缓冲池命中率为 100%。从未创建过交换内存，因此我看不出这是问题所在：
http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/
我们与 New Relic 有大量的合作历史，但不幸的是我无法在这里粘贴截图。
我已经浏览过无数类似这样的博客和问答，但找不到任何原因或解决方案，所以我把它放在那里。有什么想法吗？
更新
看来我现在可以发布截图了。这两个来自 New Relic 的截图显示了 6 小时窗口期内服务器上的系统负载和查询负载，中间重新启动了 mysql。
答案1
InnoDB 和 FusionIO 单独运行时对 CPU 的占用非常大，而组合使用时则更是如此。
我有关于此的旧帖子
Aug 25, 2013：MySQL / Fusion IO 配置问题Jun 19, 2013：MySQL 使用过多 CPU
这里的关键是调整 InnoDB 时要更自由一些。
建议
您需要选择以下一项或多项建议：
- 确定要使用哪个版本的 MySQL
- 升级到 MySQL 5.6.21 (更好的 InnoDB 存储引擎+最新的安全补丁）
- 升级到 MySQl 5.5.40 (最新的安全补丁）
- 提升默认值为 innodb_buffer_pool_instances。改为 8（这是 MySQL 5.6 的默认值）
- 最大化 IO 线程
- 增加innodb_log_file_size= 128M，实现更好的日志写入性能
- 双倍的innodb_io_capacity至 1000
- 增加innodb_io_capacity_max至 2000（仅限 MySQL 5.6）
- 增加删除 innodb_purge_threads至 4（仅限 MySQL 5.6）
- 比较将 innodb_flush_log_at_trx_commit 设置为 0 和 2 以查看哪个刷新更平滑（也许是六个，另一个半打）