<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>
<title><![CDATA[向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除]]></title> 
<link>http://jackxiang.com/index.php</link> 
<description><![CDATA[赢在IT，Playin' with IT,Focus on Killer Application,Marketing Meets Technology.]]></description> 
<language>zh-cn</language> 
<copyright><![CDATA[向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除]]></copyright>
<item>
<link>http://jackxiang.com/post//</link>
<title><![CDATA[值得参考：MySQL InnoDB性能调整的一点实践]]></title> 
<author>jack &lt;xdy108@126.com&gt;</author>
<category><![CDATA[WEB2.0]]></category>
<pubDate>Sat, 25 Sep 2010 11:15:17 +0000</pubDate> 
<guid>http://jackxiang.com/post//</guid> 
<description>
<![CDATA[ 
	因为JavaEye网站的数据库服务器搬家的时候被托管商的工作人员狠狠摔了一下，所以硬盘整个挂掉了，我重新安装数据库服务器的时候，顺手下载了 Percona patch过的MySQL5.0版本，使用MySQL自带的heavy innodb配置文件改了改，作为my.cnf启动运行。数据库服务器的物理内存有6GB，其中有4GB可以被MySQL使用，my.cnf相关配置参数如下：<br/><br/><br/><br/><br/><div class="code">&nbsp;&nbsp;1. memlock <br/>&nbsp;&nbsp; 2. innodb_buffer_pool_size = 2G <br/>&nbsp;&nbsp; 3. innodb_log_file_size = 256M <br/>&nbsp;&nbsp; 4. innodb_log_files_in_group = 3 <br/>&nbsp;&nbsp; 5. #innodb_flush_method=fdatasync 默认设置 </div><br/><br/><br/><div class="code">memlock<br/>innodb_buffer_pool_size = 2G<br/>innodb_log_file_size = 256M<br/>innodb_log_files_in_group = 3<br/>#innodb_flush_method=fdatasync 默认设置</div><br/><br/><br/><br/>buffer pool越大越好，官方推荐使用物理内存的50%－80%；log_file_size也是越大越好，官方推荐log size加起来要达到buffer pool的25%－100%。使用memlock可以避免MySQL内存进入swap，这些都是默认的推荐配置了，没有什么可以质疑的地方。但是数据库服务器启动以后，运行不太正常。表现出来的现象是：<br/><br/>1、操作系统内存Disk Cache使用了2.7GB<br/>2、操作系统swap空间使用了200MB左右，一直不停进行swap in/swap out<br/>3、CPU的IO Wait偏高，平均在10%以上<br/><br/>这个现象看起来非常怪异和矛盾。IO Wait偏高显然是因为频繁的使用swap进行内存换页引起的，但问题是物理内存非常空闲，操作系统明明有2.7GB空闲物理内存做Disk Cache，怎么不吐出来一点，非要去用swap呢？<br/><br/>想来想去只有一种可能性，就是MySQL存在非常巨大的，频繁的文件读写操作，迫使操作系统不得不分配了2.7GB的Disk Cache，从而造成了物理内存的不足，被迫使用swap。而可能造成巨大文件读写操作的就是buffer pool的flush和log file的flush操作了。因此配置文件做如下修改：<br/><br/><br/><br/><br/><div class="code">&nbsp;&nbsp; 1. memlock <br/>&nbsp;&nbsp; 2. innodb_buffer_pool_size = 2G <br/>&nbsp;&nbsp; 3. innodb_log_file_size = 64M <br/>&nbsp;&nbsp; 4. innodb_log_files_in_group = 2 <br/>&nbsp;&nbsp; 5. innodb_flush_method=O_DIRECT </div><br/><br/><div class="code"><br/>memlock<br/>innodb_buffer_pool_size = 2G<br/>innodb_log_file_size = 64M<br/>innodb_log_files_in_group = 2<br/>innodb_flush_method=O_DIRECT</div><br/><br/><br/><br/>减少log file size和数量，使用O_DIRECT。重启以后，数据库服务器恢复正常。操作系统Disk Cache下降到900MB，Swap使用了200多MB，但是不再进行swap in/swap out操作，CPU的IO Wait下降到2-3%。<br/><br/>通过这次MySQL InnoDB的调优经历，发现一些和MySQL官方推荐配置不符合的疑惑之处，值得思考和探索：<br/><br/>1、innodb_flush_method究竟应不应该使用O_DIRECT？<br/><br/>所有MySQL调优的建议都说，如果硬件没有预读功能，那么使用O_DIRECT将极大降低InnoDB的性能，因为O_DIRECT跳过了操作系统的文件系统Disk Cache，让MySQL直接读写磁盘了。<br/><br/>但是在我的实践中来看，如果不使用O_DIRECT，操作系统被迫开辟大量的Disk Cache用于innodb的读写缓存，不但没有提高读写性能，反而造成读写性能急剧下降。而且buffer pool的数据缓存和操作系统Disk Cache缓存造成了Double buffer的浪费，显然从我这个实践来看，浪费得非常厉害。<br/><br/>说O_DIRECT造成MySQL直接读写磁盘造成得性能下降问题，我觉得完全是杞人忧天。因为从JavaEye的数据库监测来看，Innodb 的buffer pool命中率非常高，有98%以上，真正的磁盘操作是微乎其微的。为了1%的磁盘操作能够得到Disk Cache，而浪费了98%的double buffer内存空间，无论从性能上看，还是从内存资源的消耗来看，都是非常不明智的。<br/><br/>2、innodb_log_file_size究竟应该大一点，还是小一点？<br/><br/>所有MySQL调优建议都说，innodb_log_file_size要越大越好，避免无谓的buffer pool的flush操作。<br/><br/>但是在我的实践中来看，innodb_log_file_size开得太大，会明显增加innodb的log写入操作，而且会造成操作系统需要更多的Disk Cache开销。<br/><br/>因此从我的经验来看，innodb_flush_method=O_DIRECT是必须的，而innodb_log_file_size也不宜太大 
]]>
</description>
</item><item>
<link>http://jackxiang.com/post//#blogcomment</link>
<title><![CDATA[[评论] 值得参考：MySQL InnoDB性能调整的一点实践]]></title> 
<author> &lt;user@domain.com&gt;</author>
<category><![CDATA[评论]]></category>
<pubDate>Thu, 01 Jan 1970 00:00:00 +0000</pubDate> 
<guid>http://jackxiang.com/post//#blogcomment</guid> 
<description>
<![CDATA[ 
	
]]>
</description>
</item>
</channel>
</rss>