重型MySQL的使用CPU或内存

我有一个Amazon S3的情况下，我们必须在服务器上的项目做了很多INSERT和UPDATE和一些复杂的SELECT重型MySQL的使用CPU或内存

我们发现，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

来源

2011-03-03 Lizard

表是所有/主要是MyISAM或InnoDB？ – robjmills 2011-03-03 10:32:47

InnoDb for most tables ...我已将MyISAM保留在我们执行全文搜索的1个表上 – Lizard 2011-03-03 12:13:15

您是否尝试过使用mk-query-digest（在maatkit中）或mtop来确定资源使用量最重的位置？慢查询日志和查询分析器？ – coolgeek 2011-03-13 17:17:52

我会去32GB的内存，也许更多的硬盘在RAID中。 CPU不会有太大的帮助 - 你有足够的CPU能力。您还需要正确配置mysql。

离开1-2 GB用于OS缓存和临时表。
增加tmp_table_size的
删除交换
优化query_cache_size变量（不让它过大 - 看到它MySQL文档）
定期运行FLUSH QUERY CACHE。如果您的查询缓存是< 512 MB - 每5分钟运行一次。这不清理缓存，它优化它（碎片整理）。这是从MySQL文档：

整理查询缓存，以更好地利用它的内存。与FLUSH TABLES或RESET QUERY CACHE不同，FLUSH QUERY CACHE 不会删除缓存中的任何查询。

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

来源

2011-03-30 14:31:20 NickSoft

这取决于应用。

您可以使用memcached缓存mysql查询。这可以缓解CPU占用率，但是使用这种方法，您希望增加用于存储查询的RAM。

另一方面，如果它不适用于基于应用程序的类型，那么我会推荐更高的CPU。

来源

2011-03-03 15:59:31 RDL

MySQL没有太多的理由使用大量的CPU：它要么处理存储的例程（存储过程或存储函数），要么进行可以吃掉CPU的排序。

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

如果由于排序正在进行而使用大量CPU，取决于查询的性质，可以完成一些操作：可以扩展索引以在末尾包括ORDER BY列，或者可以放下ORDER BY子句并在客户端进行排序。

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

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

来源

2011-03-13 16:52:41 Isotopp

你是否暗示sprocs不好？ – 2011-03-13 17:03:55

在MySQL中，实现非常糟糕。该代码未被解析，该过程的ASCII源存储在磁盘上。每个连接都会解析该过程并在其连接结构中缓存解析的代码，连接之间不会共享。另外，实现是不完整的（在5.5中稍微纠正）并且难以调试。即使没有这些问题，存储过程也是运行在系统中最昂贵且最不容易扩展的CPU上的代码，因此通常是一个坏主意（存在反例）。 – Isotopp 2011-03-13 17:08:17

然而，它仍然会比将数据传送到您的应用程序进行处理然后通过网络发回他的结果的速度更快（并且需要更少的网络资源） – coolgeek 2011-03-13 17:12:39

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

来源

2011-03-13 17:02:41

使用“高CPU超大实例”。

在当前设置中，MySQL不受存储器约束：

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

在对7 GB存储器，2 GB未被使用，正在使用的OS作为I/O缓存。

在这种情况下，CPU数量的增加可以让你更加放心。

来源

2011-03-14 08:25:17

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

vmstat 5 
iostat -dx 5

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

来源

2011-05-25 11:29:21 matt

重型MySQL的使用CPU或内存

回答

相关问题