<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>评论：MySQL/InnoDB源代码：线程并发访问控制(续)</title>
	<atom:link href="http://www.orczhou.com/index.php/2010/07/mysql-innodb-source-code-sync-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.orczhou.com/index.php/2010/07/mysql-innodb-source-code-sync-2/</link>
	<description>一个故事@MySQL DBA</description>
	<lastBuildDate>Tue, 17 Jan 2012 07:17:56 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>来自：MySQL/InnoDB源代码：线程并发访问控制(再续) - 一个故事@MySQL DBA</title>
		<link>http://www.orczhou.com/index.php/2010/07/mysql-innodb-source-code-sync-2/comment-page-1/#comment-1103</link>
		<dc:creator>MySQL/InnoDB源代码：线程并发访问控制(再续) - 一个故事@MySQL DBA</dc:creator>
		<pubDate>Mon, 26 Jul 2010 11:19:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.orczhou.com/?p=2215#comment-1103</guid>
		<description>[...] MySQL/InnoDB源代码：线程并发访问控制(再续) 2010-07-26 &#160;&#124;&#160; 19:19分类：MySQL,代码细节&#160;&#160;&#124;&#160;&#160;5 views 这是该系列的第三篇文章（1，2）了。之所以选择并发线程控制着手研究InnoDB的代码有两个原因：第一，这段代码相对独立，不要了解太多的相关代码就可以理解；第二，稍微多看一些代码你会发现，到处都是线程并发控制相关的代码出现，所以这也是一个基础。 [...]</description>
		<content:encoded><![CDATA[<p>[...] MySQL/InnoDB源代码：线程并发访问控制(再续) 2010-07-26 &nbsp;|&nbsp; 19:19分类：MySQL,代码细节&nbsp;&nbsp;|&nbsp;&nbsp;5 views 这是该系列的第三篇文章（1，2）了。之所以选择并发线程控制着手研究InnoDB的代码有两个原因：第一，这段代码相对独立，不要了解太多的相关代码就可以理解；第二，稍微多看一些代码你会发现，到处都是线程并发控制相关的代码出现，所以这也是一个基础。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>来自：plantegg</title>
		<link>http://www.orczhou.com/index.php/2010/07/mysql-innodb-source-code-sync-2/comment-page-1/#comment-1048</link>
		<dc:creator>plantegg</dc:creator>
		<pubDate>Fri, 09 Jul 2010 17:30:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.orczhou.com/?p=2215#comment-1048</guid>
		<description>@orczhou 磁盘IO繁忙
                 ~~~~~~~~~~这个也是我发现的症状，当大量并发冲进来（比如定时任务），内存有不够的时候，需要使用Swap，问题就出现了。

我也是估计，但是没证实，应该是这个时候全局锁被OS Swap到硬盘上了，而MySQL没有意识到这点。

我翻了一下源代码，好像这个锁是一个全局锁。

现在只是从实践上验证了，尽量把定时任务分散、避免Swap IO，这个问题就不再重现了。</description>
		<content:encoded><![CDATA[<p>@orczhou 磁盘IO繁忙<br />
                 ~~~~~~~~~~这个也是我发现的症状，当大量并发冲进来（比如定时任务），内存有不够的时候，需要使用Swap，问题就出现了。</p>
<p>我也是估计，但是没证实，应该是这个时候全局锁被OS Swap到硬盘上了，而MySQL没有意识到这点。</p>
<p>我翻了一下源代码，好像这个锁是一个全局锁。</p>
<p>现在只是从实践上验证了，尽量把定时任务分散、避免Swap IO，这个问题就不再重现了。</p>
]]></content:encoded>
	</item>
	<item>
		<title>来自：orczhou</title>
		<link>http://www.orczhou.com/index.php/2010/07/mysql-innodb-source-code-sync-2/comment-page-1/#comment-1041</link>
		<dc:creator>orczhou</dc:creator>
		<pubDate>Thu, 08 Jul 2010 05:28:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.orczhou.com/?p=2215#comment-1041</guid>
		<description>@plantegg 深层的原因并没有找到。我们的症状，发现是磁盘IO繁忙的时候会有，适当避免IO繁忙可以绕过。有很多其他相关的Bug报告在MySQL Bug上，也可以看一下。</description>
		<content:encoded><![CDATA[<p>@plantegg 深层的原因并没有找到。我们的症状，发现是磁盘IO繁忙的时候会有，适当避免IO繁忙可以绕过。有很多其他相关的Bug报告在MySQL Bug上，也可以看一下。</p>
]]></content:encoded>
	</item>
	<item>
		<title>来自：plantegg</title>
		<link>http://www.orczhou.com/index.php/2010/07/mysql-innodb-source-code-sync-2/comment-page-1/#comment-1037</link>
		<dc:creator>plantegg</dc:creator>
		<pubDate>Wed, 07 Jul 2010 09:13:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.orczhou.com/?p=2215#comment-1037</guid>
		<description>CentOS 5.0   MySQL 5.0.41  innodb的话官网打包自带的，估计是1.0.6？</description>
		<content:encoded><![CDATA[<p>CentOS 5.0   MySQL 5.0.41  innodb的话官网打包自带的，估计是1.0.6？</p>
]]></content:encoded>
	</item>
	<item>
		<title>来自：orczhou</title>
		<link>http://www.orczhou.com/index.php/2010/07/mysql-innodb-source-code-sync-2/comment-page-1/#comment-1036</link>
		<dc:creator>orczhou</dc:creator>
		<pubDate>Wed, 07 Jul 2010 08:13:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.orczhou.com/?p=2215#comment-1036</guid>
		<description>@plantegg  说说你的OS版本 MySQL/InnoDB版本</description>
		<content:encoded><![CDATA[<p>@plantegg  说说你的OS版本 MySQL/InnoDB版本</p>
]]></content:encoded>
	</item>
	<item>
		<title>来自：plantegg</title>
		<link>http://www.orczhou.com/index.php/2010/07/mysql-innodb-source-code-sync-2/comment-page-1/#comment-1035</link>
		<dc:creator>plantegg</dc:creator>
		<pubDate>Wed, 07 Jul 2010 07:03:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.orczhou.com/?p=2215#comment-1035</guid>
		<description>InnoDB: Warning: a long semaphore wait:
–Thread 1222654272 has waited at ./include/btr0btr.ic line 53 for 241.00 seconds the semaphore:
S-lock on RW-latch at 0×2aaab510b818 created in file buf/buf0buf.c line 680
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~不知道这个问题怎么样解决才能让MySQL不当机呢？

我也多次碰到过这种问题，一旦这样的错误一多、等待时间一长，基本上MySQL要挂掉了。

我的经验是大概等待13分钟，MySQL自动重启，这个过程中，MySQL不再有任何响应，系统压力基本为0了</description>
		<content:encoded><![CDATA[<p>InnoDB: Warning: a long semaphore wait:<br />
–Thread 1222654272 has waited at ./include/btr0btr.ic line 53 for 241.00 seconds the semaphore:<br />
S-lock on RW-latch at 0×2aaab510b818 created in file buf/buf0buf.c line 680<br />
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~不知道这个问题怎么样解决才能让MySQL不当机呢？</p>
<p>我也多次碰到过这种问题，一旦这样的错误一多、等待时间一长，基本上MySQL要挂掉了。</p>
<p>我的经验是大概等待13分钟，MySQL自动重启，这个过程中，MySQL不再有任何响应，系统压力基本为0了</p>
]]></content:encoded>
	</item>
	<item>
		<title>来自：hoterran</title>
		<link>http://www.orczhou.com/index.php/2010/07/mysql-innodb-source-code-sync-2/comment-page-1/#comment-1034</link>
		<dc:creator>hoterran</dc:creator>
		<pubDate>Wed, 07 Jul 2010 05:02:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.orczhou.com/?p=2215#comment-1034</guid>
		<description>innodb 居然自己实现读写锁，我还以为和mysql一样用pthread_rwlock_t原语，compare and swap 也是与时俱进啊~~~

文章不错，赞~~</description>
		<content:encoded><![CDATA[<p>innodb 居然自己实现读写锁，我还以为和mysql一样用pthread_rwlock_t原语，compare and swap 也是与时俱进啊~~~</p>
<p>文章不错，赞~~</p>
]]></content:encoded>
	</item>
</channel>
</rss>

