Question

我有一个Amazon s3实例，我们在服务器上的项目执行了很多INSERT和UPDATE以及一些复杂的SELECT

我们发现MySQL经常会占用大量的CPU。

我正在尝试确定更高内存或更高CPU是否优于上述设置。

以下是cat /proc/meminfo

的输出

MemTotal:      7347752 kB
MemFree:         94408 kB
Buffers:         71932 kB
Cached:        2202544 kB
SwapCached:          0 kB
Active:        6483248 kB
Inactive:       415888 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:          168264 kB
Writeback:           0 kB
AnonPages:     4617848 kB
Mapped:          21212 kB
Slab:           129444 kB
SReclaimable:    86076 kB
SUnreclaim:      43368 kB
PageTables:      54104 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   3673876 kB
Committed_AS:  5384852 kB
VmallocTotal: 34359738367 kB
VmallocUsed:       180 kB
VmallocChunk: 34359738187 kB

当前设置：

高CPU超大型实例

7 GB内存20 EC2计算单元（8   具有2.5 EC2 Compute的虚拟核心   每个单位）1690 GB的实例   存储64位平台I / O.   性能：高API名称：c1.xlarge

可能的设置：

高记忆双超大号   实例

34.2 GB内存13 EC2计算单元（4个虚拟核心，3.25 EC2计算   每个单元）850 GB的实例存储   64位平台I / O性能：高   API名称：m2.2xlarge

Answer 1

我会在RAID中使用32GB内存和更多硬盘。 CPU无济于事 - 你有足够的CPU功率。您还需要正确配置mysql。

为操作系统缓存和临时表留下1-2 GB。
增加tmp_table_size
删除交换
优化query_cache_size（不要太大 - 请参阅有关它的mysql文档）
定期运行FLUSH QUERY CACHE。如果您的查询缓存大于＆lt; 512 MB - 每5分钟运行一次。这个不会清理缓存，它会对其进行优化（碎片整理）。这是来自mysql docs：

更好地对查询缓存进行碎片整理利用它的记忆力。 FLUSH QUERY CACHE 不会删除任何查询缓存，与FLUSH TABLES或RESET不同 QUERY CACHE。

但是我注意到另一个解决方案有半个磁盘空间：850GB，可能会减少硬盘数量。这通常是一个坏主意。数据库中最大的问题是硬盘。如果您使用RAID5 - 请确保您不使用较少的硬盘。如果你根本不使用raid - 我建议raid 0。

Answer 2

使用vmstat和iostat来确定CPU或I / O是否是瓶颈（如果I / O - 添加更多RAM并将数据加载到内存中）。从shell运行并检查结果：

vmstat 5
iostat -dx 5

如果CPU出现问题vmstat将在us列中显示较高的值，iostat将显示磁盘使用率较低（util）
如果I / O出现问题，则vmstat会在us列中显示较低的值，而iostat会显示较高的磁盘利用率（util）;高我的意思是> 50％

Answer 3

这取决于应用程序。

您可以使用memcached来缓存mysql查询。这样可以简化cpu的使用，但是使用这种方法，你可能需要增加RAM来存储查询。

另一方面，如果根据应用类型不可行，那么我会建议更高的CPU。

Answer 4

MySQL使用大量CPU的原因并不多：它既可以处理存储的例程（存储过程或存储的函数），也可以进行排序，可以占用CPU。

如果由于存储例程而使用大量CPU，那么你做错了，无论如何你的灵魂都无法保存。

如果由于排序而使用大量CPU，可以根据查询的性质做一些事情：您可以扩展索引以包含最后的ORDER BY列，或者您可以删除ORDER BY子句并在客户端排序。

选择何种方法取决于CPU使用的实际原因 - 是查询和排序？并在实际查询。因此，无论如何，您首先需要更好的监控。

没有监控信息，一般建议总是：为数据库购买更多内存，而不是更多CPU。

Answer 5

EC2的按需性质是否使得租用一天可能的设置变得相当简单，并进行一些负载测试？测量胜于雄辩。

Answer 6

使用“高CPU额外大型实例”。

在您当前的设置中，MySQL不受内存限制：

MemTotal:      7347752 kB    
MemFree:         94408 kB    
Buffers:         71932 kB    
Cached:        **2202544 kB**

在7 GB内存中，2 GB未使用，并被OS用作I / O缓存。

在这种情况下，增加CPU数量可以让你获得更多收益。

重的mysql使用CPU或内存

6 个答案: